Re: calculating data set size - compression concern

[Mike Hochee]

Very good point.


On Wed, Nov 6, 2019 at 12:39 AM Mike Schwab wrote:

>Listcat output changes when fields need more digits.  DCollect doesn't change.


From: IBM Mainframe Discussion List  on behalf of 
Mike Schwab 
Sent: Wednesday, November 6, 2019 12:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: calculating data set size - compression concern

Caution! This message was sent from outside your organization.

Listcat output changes when fields need more digits.  DCollect doesn't change.

On Tue, Nov 5, 2019 at 11:20 PM Mike Hochee  wrote:
>
> I was unaware of both DCOLLECT as well as the compression related fields on 
> the LISTCAT output.  Thanks much to Mike and Kolusu.  We can use the LISTCAT 
> info immediately and the DCOLLECT down the road apiece. Appreciate your 
> timely help!
>
> Mike
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Mike Schwab
> Sent: Tuesday, November 5, 2019 11:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: calculating data set size - compression concern
>
> Caution! This message was sent from outside your organization.
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idai200/recstr.htm
> IDCAMS DCOLLECT
> RECORD TYPE D
> 264(X'108') CHARACTER 8 DCDUDSIZ USER DATA SIZE (64 BIT UNSIGNED BINARY 
> NUMBER) 272(X'110') CHARACTER 8 DCDCUDSZ COMPRESSED DATA SET SIZE (64 BIT 
> UNSIGNED BINARY NUMBER)
> 280(X'118') BITSTRING 1...  2 DCDEXFLG DCDBDSZ COMPRESSION FLAGS (Not 
> used for zEDC) DATA SIZES THAT ARE NOT VALID
>
> RECORD TYPE M
> 72  (48) SIGNED 4 UMDSIZE MIGRATION COPY DATA SET SIZE IN KILOBYTES/MEGABYTES
>
> 196  (C4) SIGNED 4 UMRECSP RECALL SPACE ESTIMATE IN KILOBYTES
>
> On Tue, Nov 5, 2019 at 8:55 PM Michael Hochee  wrote:
> >
> > A couple months ago I was in the process of retrieving the size of a
> > data set on disk until I came across a flag in one or more DSCBs that
> > indicate whether or not the data set is compressed.  This was the
> > point at which I stopped coding, concluding that it was probably not
> > possible to come up with an accurate uncompressed size if the data set
> > resided on a SAN with compression turned on.  Is my thinking off-base
> > here?  (of course, I have no interest in reading the file to determine
> > the actual uncompressed length)
> >
> > Thanks, Mike
> >
> > --
> > 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 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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: calculating data set size - compression concern

[Mike Schwab]

Listcat output changes when fields need more digits.  DCollect doesn't change.

On Tue, Nov 5, 2019 at 11:20 PM Mike Hochee  wrote:
>
> I was unaware of both DCOLLECT as well as the compression related fields on 
> the LISTCAT output.  Thanks much to Mike and Kolusu.  We can use the LISTCAT 
> info immediately and the DCOLLECT down the road apiece. Appreciate your 
> timely help!
>
> Mike
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Mike Schwab
> Sent: Tuesday, November 5, 2019 11:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: calculating data set size - compression concern
>
> Caution! This message was sent from outside your organization.
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idai200/recstr.htm
> IDCAMS DCOLLECT
> RECORD TYPE D
> 264(X'108') CHARACTER 8 DCDUDSIZ USER DATA SIZE (64 BIT UNSIGNED BINARY 
> NUMBER) 272(X'110') CHARACTER 8 DCDCUDSZ COMPRESSED DATA SET SIZE (64 BIT 
> UNSIGNED BINARY NUMBER)
> 280(X'118') BITSTRING 1...  2 DCDEXFLG DCDBDSZ COMPRESSION FLAGS (Not 
> used for zEDC) DATA SIZES THAT ARE NOT VALID
>
> RECORD TYPE M
> 72  (48) SIGNED 4 UMDSIZE MIGRATION COPY DATA SET SIZE IN KILOBYTES/MEGABYTES
>
> 196  (C4) SIGNED 4 UMRECSP RECALL SPACE ESTIMATE IN KILOBYTES
>
> On Tue, Nov 5, 2019 at 8:55 PM Michael Hochee  wrote:
> >
> > A couple months ago I was in the process of retrieving the size of a
> > data set on disk until I came across a flag in one or more DSCBs that
> > indicate whether or not the data set is compressed.  This was the
> > point at which I stopped coding, concluding that it was probably not
> > possible to come up with an accurate uncompressed size if the data set
> > resided on a SAN with compression turned on.  Is my thinking off-base
> > here?  (of course, I have no interest in reading the file to determine
> > the actual uncompressed length)
> >
> > Thanks, Mike
> >
> > --
> > 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 IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: calculating data set size - compression concern

[Mike Hochee]

I was unaware of both DCOLLECT as well as the compression related fields on the 
LISTCAT output.  Thanks much to Mike and Kolusu.  We can use the LISTCAT info 
immediately and the DCOLLECT down the road apiece. Appreciate your timely help! 

Mike 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Tuesday, November 5, 2019 11:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: calculating data set size - compression concern

Caution! This message was sent from outside your organization.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idai200/recstr.htm
IDCAMS DCOLLECT
RECORD TYPE D
264(X'108') CHARACTER 8 DCDUDSIZ USER DATA SIZE (64 BIT UNSIGNED BINARY NUMBER) 
272(X'110') CHARACTER 8 DCDCUDSZ COMPRESSED DATA SET SIZE (64 BIT UNSIGNED 
BINARY NUMBER)
280(X'118') BITSTRING 1...  2 DCDEXFLG DCDBDSZ COMPRESSION FLAGS (Not used 
for zEDC) DATA SIZES THAT ARE NOT VALID

RECORD TYPE M
72  (48) SIGNED 4 UMDSIZE MIGRATION COPY DATA SET SIZE IN KILOBYTES/MEGABYTES

196  (C4) SIGNED 4 UMRECSP RECALL SPACE ESTIMATE IN KILOBYTES

On Tue, Nov 5, 2019 at 8:55 PM Michael Hochee  wrote:
>
> A couple months ago I was in the process of retrieving the size of a 
> data set on disk until I came across a flag in one or more DSCBs that 
> indicate whether or not the data set is compressed.  This was the 
> point at which I stopped coding, concluding that it was probably not 
> possible to come up with an accurate uncompressed size if the data set 
> resided on a SAN with compression turned on.  Is my thinking off-base 
> here?  (of course, I have no interest in reading the file to determine 
> the actual uncompressed length)
>
> Thanks, Mike
>
> --
> 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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: calculating data set size - compression concern

[Mike Schwab]

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idai200/recstr.htm
IDCAMS DCOLLECT
RECORD TYPE D
264(X'108') CHARACTER 8 DCDUDSIZ USER DATA SIZE (64 BIT UNSIGNED
BINARY NUMBER) 272(X'110') CHARACTER 8 DCDCUDSZ COMPRESSED DATA SET
SIZE (64 BIT UNSIGNED BINARY NUMBER)
280(X'118') BITSTRING 1...  2 DCDEXFLG DCDBDSZ
COMPRESSION FLAGS (Not used for zEDC)
DATA SIZES THAT ARE NOT VALID

RECORD TYPE M
72  (48) SIGNED 4 UMDSIZE MIGRATION COPY DATA SET SIZE IN
KILOBYTES/MEGABYTES

196  (C4) SIGNED 4 UMRECSP RECALL SPACE ESTIMATE IN KILOBYTES

On Tue, Nov 5, 2019 at 8:55 PM Michael Hochee  wrote:
>
> A couple months ago I was in the process of retrieving the size of a data set 
> on disk until I came across a flag in one or more DSCBs that indicate whether 
> or not the data set is compressed.  This was the point at which I stopped 
> coding, concluding that it was probably not possible to come up with an 
> accurate uncompressed size if the data set resided on a SAN with compression 
> turned on.  Is my thinking off-base here?  (of course, I have no interest in 
> reading the file to determine the actual uncompressed length)
>
> Thanks, Mike
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: ICETOOL - SPLICE two DSNs that match on key. Output Updated and Not Updated

[Sri h Kolusu]

> 2. A dataset with data to insert into a BASE record IF the key data
match
> I'd like to outputs.
>
> 1. With the BASE records that were NOT updated
>
> 2. With the BASE records that WERE updated


George,

It is tough to diagnose without looking at the data or the joblog. SPLICE
is an old technique to match files and it has limitation when you have a
MANY to MANY match.  If both files have duplicates on the key, then splice
will not give the cartesian product. Also expanding the files to larger
lrecl and sorting it would require additional resources.

Either way you need to use Joinkeys which is much more efficient and better
processing option to match files.

Check out the following smart tricks which shows different ways to match
and update files

   Join fields from two files on a key
   Join fields from two files record-by-record
   Cartesian join
   Create files with matching and non-matching records

https://www.ibm.com/support/pages/smart-dfsort-tricks

If you have trouble adapting those tricks, here is something that I coded
so that it is easy to understand. Brief description of the job.

STEP0100 - creates a sample BASE dataset (LRECL=480, RECFM=FB)
STEP0200 - creates the UPDT dataset  (LRECL=100, RECFM=FB)
STEP0300 - Matches BASE file with UPDT file and creates with matching and
non-matching records ( This is the ONLY step that you would need to run)

//***
//* CREATE THE BASE FILE WITH SAMPLE DATA AND LRECL=480 RECFM=FB*
//***
//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD *
11   - THIS DOES NOT HAVE A MATCHING KEY
AA   - THIS DOES NOT HAVE A MATCHING KEY
BB   - HAS MATCHING KEY SO UPDATE POSITION 151
ZZ   - HAS MATCHING KEY SO UPDATE POSITION 151
//SORTOUT  DD DSN=&&BASE,DISP=(,PASS),SPACE=(TRK,(1,1),RLSE)
//SYSINDD *
  OPTION COPY
  INREC OVERLAY=(151:C'MOVE THIS VALUE TO POSITION 191',480:X)
/*
//***
//* CREATE THE UPDT FILE WITH SAMPLE DATA AND LRECL=100 RECFM=FB*
//***
//STEP0200 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD *
KK
ZZ UPDATE THE 1234 BASE
BB UPDATE THE 5678 BASE
//SORTOUT  DD DSN=&&UPDT,DISP=(,PASS),SPACE=(TRK,(1,1),RLSE)
//SYSINDD *
  OPTION COPY
  INREC OVERLAY=(100:X)
/*
//***
//* MATCH THE BASE FILE WITH KEY (1,21) AND UPDATE POS 151 FROM *
//* THE VALUES FROM UPDT FILE   *
//***
//STEP0300 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//BASE DD DISP=(OLD,PASS),DSN=&&BASE
//UPDT DD DISP=(OLD,PASS),DSN=&&UPDT
//BASEUPDT DD SYSOUT=*
//ONLYBASE DD SYSOUT=*
//SYSINDD *
  OPTION COPY
  JOINKEYS F1=BASE,FIELDS=(1,21,A)
  JOINKEYS F2=UPDT,FIELDS=(1,21,A)
  JOIN UNPAIRED
  REFORMAT FIELDS=(F1:1,480,?,F2:32,20)

  OUTFIL FNAMES=BASEUPDT,
  INCLUDE=(481,1,CH,EQ,C'B'),
  BUILD=(1,150,482,20,20X,151,330)

  OUTFIL FNAMES=ONLYBASE,
  INCLUDE=(481,1,CH,EQ,C'1'),
  BUILD=(1,150,40X,151,330)
/*

Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation

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

calculating data set size - compression concern

[Michael Hochee]

A couple months ago I was in the process of retrieving the size of a data set 
on disk until I came across a flag in one or more DSCBs that indicate whether 
or not the data set is compressed.  This was the point at which I stopped 
coding, concluding that it was probably not possible to come up with an 
accurate uncompressed size if the data set resided on a SAN with compression 
turned on.  Is my thinking off-base here?  (of course, I have no interest in 
reading the file to determine the actual uncompressed length) 

Thanks, Mike

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

Debug tool Via Zos Explorer

[Joseph Reichman]

Hi

 

Finally got zos explorer installed and configured as I am told it's the only
way to debug AMODE 64 C/C++ there doesn't seem to be a programming interface
such as CEETEST which works in AMOIDE 31

 

Running the following code  abend 4093/218 

 

 

//STARTEXEC PGM=CHELLO,


//
PARM='/TEST(,,,TCPIP&192.168.1.164%8001:*)'  

  //STEPLIB  DD
DSN=IBMUSER.DBGR.DLLLIB,DISP=SHR  

  //INSPIN  DD *


STEP ;


   

 

  /*


 

I did include CELQMAIN from CEE.SCEEBND2 still got the same abend 

 

Anybody have experience with zos explorer that could pint me in the right
direction

 

 

 

I get  a abend 4093/ 218 Language Environment initialization was requested

for an AMODE 64 application that does not contain

a main. Specifically, the CELQMAIN CSECT is not

present in the program object or the CELQMAIN

CSECT does not point to the main routine (the

address of the main is zero). One possible cause is

that the user attempted to invoke a DLL or

fetchable routine as a main.

X'21C' (540)

Load of the AMODE 64 Language Environment


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

[Mike Schwab]

Same program, different entry points.

On Tue, Nov 5, 2019 at 5:03 PM David Spiegel  wrote:
>
> Hi Skip,
> It's AMATERSE (with //SYSUT1 and //SYSUT2)
> or TRSMAIN (with //INFILE and //OUTFILE).
>
> Regards,
> David
>
> On 2019-11-05 17:40, Jesse 1 Robinson wrote:
> > Just to be clear: is that AMATERSE? I don't recall ever using IBM's TERSE 
> > internally within the shop, but I can see how it might be useful.
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > 626-543-6132 Office ⇐=== NEW
> > robin...@sce.com
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf Of 
> > Tom Conley
> > Sent: Tuesday, November 5, 2019 2:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: Zfs from 1 LPAR to another
> >
> > 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
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Zfs from 1 LPAR to another

[Jousma, David]

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

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

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




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

Re: Zfs from 1 LPAR to another

[David Spiegel]

Hi Skip,
It's AMATERSE (with //SYSUT1 and //SYSUT2)
or TRSMAIN (with //INFILE and //OUTFILE).

Regards,
David

On 2019-11-05 17:40, Jesse 1 Robinson wrote:
> Just to be clear: is that AMATERSE? I don't recall ever using IBM's TERSE 
> internally within the shop, but I can see how it might be useful.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Tom Conley
> Sent: Tuesday, November 5, 2019 2:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Zfs from 1 LPAR to another
>
> 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
>
>
> --
> 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: Zfs from 1 LPAR to another

[Jesse 1 Robinson]

Just to be clear: is that AMATERSE? I don't recall ever using IBM's TERSE 
internally within the shop, but I can see how it might be useful. 

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Conley
Sent: Tuesday, November 5, 2019 2:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Zfs from 1 LPAR to another

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


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

[Tom Conley]

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

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

Re: Improving the performance of an ISPF app using OMVS services (bpxwunix)

[Kirk Wolf]

Not necessarily.
See for example, the IBM JZOS batch launcher.   It runs in a regular z/OS
batch address space.   The address space is dubbed when Java its first OMVS
service call.   Is that "under UNIX"?

On Mon, Nov 4, 2019 at 1:07 PM ITschak Mugzach  wrote:

> The Java program does not run as a main program, but need a shell
> environment such as the one supplied by BPXBATCH. So actually the java
> program already runs under a unix thread. this is not the case with Lionel
> performance issue, as his code runs under TSO and requires an extra asid to
> run the unix code.
>
> ITschak
>
> On Mon, Nov 4, 2019 at 8:43 PM Tony Harminc  wrote:
>
> > On Mon, 4 Nov 2019 at 07:32, ITschak Mugzach  wrote:
> >  On Mon, 4 Nov 2019 at 07:30, Steve Austin 
> > wrote:
> >
> > > It was a while back, but I'm pretty sureI have used  _BPX_SHAREAS and
> the
> > > spawn syscall from REXX, to run Java in the same address space.
> >
> >
> > Thats fine. However, java itself runs under unix...
> > >
> >
> > I'm not seeing your point. Many things "run under" UNIX on z/OS. Why is
> > Java special in this context?
> >
> > Tony H.
> >
> > --
> > 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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Improving the performance of an ISPF app using OMVS services (bpxwunix)

[Kirk Wolf]

What does "under unix" mean exactly?

On Mon, Nov 4, 2019 at 6:32 AM ITschak Mugzach  wrote:

> Thats fine. However, java itself runs under unix...
>
> ITschak
>
> בתאריך יום ב׳, 4 בנוב׳ 2019, 14:30, מאת Steve Austin ‏<
> steve.aus...@macro4.com>:
>
> > It was a while back, but I'm pretty sureI have used  _BPX_SHAREAS and the
> > spawn syscall from REXX, to run Java in the same address space.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Lionel B Dyck
> > Sent: Monday, November 4, 2019 12:00 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Improving the performance of an ISPF app using OMVS services
> > (bpxwunix)
> >
> > Thanks for the education.
> >
> > Guess I need to find a faster system 😊
> >
> > 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 ITschak Mugzach
> > Sent: Monday, November 4, 2019 5:52 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Improving the performance of an ISPF app using OMVS services
> > (bpxwunix)
> >
> > No. the fork is a unix issue. the first shell task will be started as a
> > separate asid and then, if _BPXSHAREDAS is on, called shell programs will
> > run in the same (new) asid. You can see in the syslog the evidence of the
> > new ASID started. It is usually has the id of the caller plus numeric
> value.
> >
> >
> > On Mon, Nov 4, 2019 at 1:46 PM Lionel B Dyck  wrote:
> >
> > > But when rexx, under ispf, invokes bpxwunix won't the sharedas help to
> > > prevent the fork?
> > >
> > >
> > > 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 ITschak Mugzach
> > > Sent: Monday, November 4, 2019 5:36 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Improving the performance of an ISPF app using OMVS
> > > services
> > > (bpxwunix)
> > >
> > > That's because _BPX_SHAREDAS is related to a main shell program and
> > > its forks. not to the Rexx (or whatever the caller is) and the unix
> > shell.
> > >
> > >
> > >
> > > On Mon, Nov 4, 2019 at 1:29 PM Lionel B Dyck  wrote:
> > >
> > > > That was my fear 😊
> > > >
> > > > I did find these which I implemented in my .profile and I'm not
> > > > seeing any  visual improvements:
> > > >
> > > > export _BPX_SHAREAS=YES
> > > > export _BPX_SPAWN_SCRIPT=YES
> > > >
> > > >
> > > > 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 ITschak Mugzach
> > > > Sent: Monday, November 4, 2019 5:25 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: Improving the performance of an ISPF app using OMVS
> > > > services
> > > > (bpxwunix)
> > > >
> > > > Lionel,
> > > >
> > > > The secret is that zPDT systems are not heavily loaded. As you load
> > > > the system (or start mot guests, if running under z/vm), the system
> > > > starts to slow down. BPXWUNIX starts a new address space, so by
> > > > definition it is more cpu consuming, that affects elapse.
> > > >
> > > > ITschak
> > > >
> > > > On Mon, Nov 4, 2019 at 1:20 PM Lionel B Dyck 
> wrote:
> > > >
> > > > > Are there any hints/tips to improve the performance of an ISPF
> > > > > application that uses BPXWUNIX?  In running on my normal system
> > > > > the performance is very slow compared to a friends system running
> > > > > on a
> > > zPDT.
> > > > >
> > > > >
> > > > >
> > > > > I couldn't find a SHARE presentation (but I may not have used the
> > > > > correct
> > > > > keywords) and the IBM pubs are not speaking to me as nothing jumps
> > out.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > --
> > > > > -- 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* *|* *Informatio

Re: git with it

[Kirk Wolf]

Gil,

And conspicuous by your omission:  "I hate EBCDIC!"  ;-)

On Tue, Nov 5, 2019 at 1:53 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 5 Nov 2019 06:42:31 -0600, Lionel B Dyck wrote:
>
> >The countdown continues towards an epic announcement that will rock the
> z/OS
> >development world down to the bit level. Be prepared as you'll have to
> wait
> >for the announcement at GSE UK this Thursday at 11:15. Be prepared to git
> >it.  Or go to   https://zigi.rocks to be a preview.
> #git
> >#ispf #zos #zdevops #awesome #epic #gseconf
> >
> Where I read:
> Multi DCB Support
>
> With zigi you can manage your FB80's
> (not related to FaceBook), your
> VB255's and anything in between. It
> supports PO and PS datasets. It
> basically does anything that's not a
> VSAM.
>
> Conspicuous by their omission from "anything that's not a VSAM"
> are z/FS and its plethora of CCSIDs.  Was that inadvertent?
>
> ".rocks"?  Ooh!  an unregulated TLD!
>
> -- gil
> >
> >Lionel B. Dyck <
> >Website:   http://www.lbdsoftware.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: git with it

[Ronald Kristel]

Looks awesome! :)

Will most definitely check it out next Thursday!

Ronald Kristel


From: IBM Mainframe Discussion List  on behalf of 
Henri Kuiper 
Sent: Tuesday, November 5, 2019 14:35
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: git with it

Just to clarify : the link to the repo wil "404" until release time. Watch 
@ispfgit on twitter for the moment that happens.

Sent from my wireless iPhone

> On 5 Nov 2019, at 12:42, Lionel B Dyck  wrote:
>
> The countdown continues towards an epic announcement that will rock the z/OS
> development world down to the bit level. Be prepared as you'll have to wait
> for the announcement at GSE UK this Thursday at 11:15. Be prepared to git
> it.  Or go to   https://zigi.rocks to be a preview. #git
> #ispf #zos #zdevops #awesome #epic #gseconf
>
>
>
> 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
>
>
>
>
> --
> 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: CBPs (processors) - what is it?

[Mike Schwab]

The only reference I could find was in
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=35&ved=2ahUKEwj-w5G99tPlAhUEWqwKHWHNBfw4HhAWMAR6BAgBEAI&url=https%3A%2F%2Fshare.confex.com%2Fshare%2F118%2Fwebprogram%2FHandout%2FSession10691%2FIntroToSharedQueues.pdf&usg=AOvVaw3QyWMZhBU9yTFG9-57yysI
 , where it is a 10 meter Cluster Bus (?Port?).

On Tue, Nov 5, 2019 at 1:43 PM Tony Harminc  wrote:
>
> On Tue, 5 Nov 2019 at 09:12, R.S.  wrote:
>
> > We know the following types/flavours of mainframe processors: regular
> > CP, zIIP, IFL, SAP, ICF, older zAAP ...and CBP
> > This CBP is visible on Support Element panels. Help says it is "CBPs -
> > Displays the active/unassigned container based processors installed on
> > your system."
> > Container sounds like zCX, however as far as I know zCX use CP or zIIP.
> > So, what is CBP?
> > Any clue?
>
> I've never heard of this, and I have no access to current Support
> Element stuff, but my first guess is that it's for the "z/VSE Network
> Appliance" (VNA). This is a lean TCP/IP stack that runs in some kind
> of container LPAR (SSC?)and talks to z/VSE in its own LPAR (whatever
> kind that is) via HiperSockets, and to the outside world via the
> standard network interfaces. I believe it comes as "firmware" that is
> loaded into the container LPAR by some SE magic, i.e. not using z/OS
> or z/VSE style of administration. More like the way ICF code is
> loaded? Maybe a CBP *processor* is available only for such container
> LPARs? All just guessing...
>
> Google finds mainstream z/VSE books and various presentations to user
> groups and such, with nice diagrams. But VNA seems to have been
> discontinued in Sept 2019. We z/OS people rarely think about VSE, but
> it's still going strong, and with some very innovative ideas.
>
> Second related guess is that the Secure Service Container (SSC) for
> other things (IBM Cloud Private appliance?) can use this processor
> type. That doc says you can use only CPs or zIIPs, but who knows.
> Still just uninformed speculation...
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Zfs from 1 LPAR to another

[Wayne Bickerdike]

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

ICETOOL - SPLICE two DSNs that match on key. Output Updated and Not Updated

[George, William@FTB]

I have an ICETOOL process I cannot seem to get right.

I have two datasets:

1. A BASE dataset

2. A dataset with data to insert into a BASE record IF the key data match
I'd like to outputs.

1. With the BASE records that were NOT updated

2. With the BASE records that WERE updated

I'm able to get an output of the BASE records that were 'updated' but I also 
would like a separate dataset of those records that were not 'updated'.

Below are my TOOLIN cards.

NOTES:
DD IN1 is the BASE dataset and has an INREC to insert (not overlay) 40 spaces 
in position 151 and shift the data after it to the right.
This is where some data from IN2 will be overlayed.
DD IN2 is the dataset with data to overly in the matching BASE records.
IN2 has an LRECL of 100 so an INREC is used to change its length to match the 
BASE dataset's 520 LRECL
The data to copy from IN2 is in position 32 for a length of 20 and is to be 
inserted into position 151 of the BASE record.
DD OUT1 - is to contain those BASE records that were NOT updated.  THESE FILE 
COMES UP EMPTY 8-(
DD OUT2 - is to contain the updated records and this seems to work.

//TOOLIN  DD *
  COPY FROM(IN1) TO(T1) USING(CTL1)
  COPY FROM(IN2) TO(T1) USING(CTL2)
  SPLICE FROM(T1) TO(OUT2) ON(1,21,CH) WITH(151,20) USING(CTL3)
/*
//CTL1CNTL DD *
 INREC BUILD=(1:1,150,40X,151,330)
 OUTREC FIELDS=(1,520)
/*
//CTL2CNTL DD *
 OUTREC FIELDS=(1,100,151:32,20,350X)
/*
//CTL3CNTL DD *
  OUTFIL FNAMES=OUT1,INCLUDE=(151,1,CH,EQ,C' '),OUTREC=(1,520)
  OUTFIL FNAMES=OUT2,INCLUDE=(151,1,CH,NE,C' '),OUTREC=(1,520)

Any insights would be appreciated.

Bill

__
CONFIDENTIALITY NOTICE: This email from the State of California is for the sole 
use of the intended recipient and may contain confidential and privileged 
information. Any unauthorized review or use, including disclosure or 
distribution, is prohibited. If you are not the intended recipient, please 
contact the sender and destroy all copies of this email.

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

Re: git with it

[Paul Gilmartin]

On Tue, 5 Nov 2019 06:42:31 -0600, Lionel B Dyck wrote:

>The countdown continues towards an epic announcement that will rock the z/OS
>development world down to the bit level. Be prepared as you'll have to wait
>for the announcement at GSE UK this Thursday at 11:15. Be prepared to git
>it.  Or go to   https://zigi.rocks to be a preview. #git
>#ispf #zos #zdevops #awesome #epic #gseconf
> 
Where I read:
Multi DCB Support

With zigi you can manage your FB80's 
(not related to FaceBook), your
VB255's and anything in between. It
supports PO and PS datasets. It
basically does anything that's not a
VSAM.

Conspicuous by their omission from "anything that's not a VSAM"
are z/FS and its plethora of CCSIDs.  Was that inadvertent?

".rocks"?  Ooh!  an unregulated TLD!

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

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

Re: CBPs (processors) - what is it?

[Tony Harminc]

On Tue, 5 Nov 2019 at 09:12, R.S.  wrote:

> We know the following types/flavours of mainframe processors: regular
> CP, zIIP, IFL, SAP, ICF, older zAAP ...and CBP
> This CBP is visible on Support Element panels. Help says it is "CBPs -
> Displays the active/unassigned container based processors installed on
> your system."
> Container sounds like zCX, however as far as I know zCX use CP or zIIP.
> So, what is CBP?
> Any clue?

I've never heard of this, and I have no access to current Support
Element stuff, but my first guess is that it's for the "z/VSE Network
Appliance" (VNA). This is a lean TCP/IP stack that runs in some kind
of container LPAR (SSC?)and talks to z/VSE in its own LPAR (whatever
kind that is) via HiperSockets, and to the outside world via the
standard network interfaces. I believe it comes as "firmware" that is
loaded into the container LPAR by some SE magic, i.e. not using z/OS
or z/VSE style of administration. More like the way ICF code is
loaded? Maybe a CBP *processor* is available only for such container
LPARs? All just guessing...

Google finds mainstream z/VSE books and various presentations to user
groups and such, with nice diagrams. But VNA seems to have been
discontinued in Sept 2019. We z/OS people rarely think about VSE, but
it's still going strong, and with some very innovative ideas.

Second related guess is that the Secure Service Container (SSC) for
other things (IBM Cloud Private appliance?) can use this processor
type. That doc says you can use only CPs or zIIPs, but who knows.
Still just uninformed speculation...

Tony H.

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

[Pierre Fichaud]

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

Re: WTO message at the end of JCL

[Seymour J Metz]

There is, and has been since OS/360, although the details have changed. Use 
SWAREQ to run the SCT chain.


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



From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Monday, November 4, 2019 6:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO message at the end of JCL

It would be nice if there were a way to get the condition codes into the WTO 
program, something like (don't try this at home):

//WTO1 EXEC PGM=WTO,COND=EVEN,
//  PARM='Job FOOBAR terminating. Highest CC was &MAXCC'

I seem to recall a discussion here about retrieving the last and maximum job 
CC's from within a program running as a jobstep and the answer was that there 
was no good way.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, November 4, 2019 1:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO message at the end of JCL

MVS has provided such a mechanism forever using

1. a program that issues a WTO

2. conditional execution on the WTO step with COND=EVEN or ONLY (depending on 
the logic required)

Most shops already have a more or less sophisticated (security wise) program to 
issue a WTO. Conditional JCL is free for the coding. Every shop I've worked in 
uses the mechanism to manage production, including my current one. There is as 
Brian says no way to handle a JCL error without an external 'product'.

--
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: WTO message at the end of JCL

[Seymour J Metz]

You need z/OS reference manuals, not just PoOps and assembler. Since the OP 
want's previous steps, you also need the mapping macros for, e.g., JCT.


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



From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Monday, November 4, 2019 7:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO message at the end of JCL

Step and job end status are very accessible. Look at SYS1.SAMPLIB(SMFEXITS). 
Factors like step and maximum condition codes; step and job CPU totals; and I/O 
counts can be extracted from control blocks and displayed in WTOs. The code 
versions we use have been tailored over the years so that our messages don't 
look exactly like SAMPLIB examples, but it's all very doable.

All you need is a POP, a yellow card, and lots of patience. Or you could try 
your hand at writing some exit code in other than ASM. Like Metal C. A LOT of 
folks would like to get their mitts on that.

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Monday, November 4, 2019 3:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: WTO message at the end of JCL

It would be nice if there were a way to get the condition codes into the WTO 
program, something like (don't try this at home):

//WTO1 EXEC PGM=WTO,COND=EVEN,
//  PARM='Job FOOBAR terminating. Highest CC was &MAXCC'

I seem to recall a discussion here about retrieving the last and maximum job 
CC's from within a program running as a jobstep and the answer was that there 
was no good way.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, November 4, 2019 1:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO message at the end of JCL

MVS has provided such a mechanism forever using

1. a program that issues a WTO

2. conditional execution on the WTO step with COND=EVEN or ONLY (depending on 
the logic required)

Most shops already have a more or less sophisticated (security wise) program to 
issue a WTO. Conditional JCL is free for the coding. Every shop I've worked in 
uses the mechanism to manage production, including my current one. There is as 
Brian says no way to handle a JCL error without an external 'product'.


--
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: git with it

[PINION, RICHARD W.]

Git'er done!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B Dyck
Sent: Tuesday, November 5, 2019 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git with it

[External Email]

On Thursday the git repository will change from private to public and you'll be 
able to git a copy for yourself 😊


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 
Seymour J Metz
Sent: Tuesday, November 5, 2019 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git with it

I just wish it had more detail and fewer superlatives. I assume that the 
current release icon will eventually take us to details.


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



From: IBM Mainframe Discussion List  on behalf of 
Lionel B Dyck 
Sent: Tuesday, November 5, 2019 7:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: git with it

The countdown continues towards an epic announcement that will rock the z/OS 
development world down to the bit level. Be prepared as you'll have to wait for 
the announcement at GSE UK this Thursday at 11:15. Be prepared to git it.  Or 
go to  

 
https://secure-web.cisco.com/1YPLXK51W8atPq2Fbq2T7cyKbgjj4PBRfsL4uqBAnLM3zCD64WkSWXRPIzmA3j83k1pWAkNoRirKBQ56wcdIypNdU1tqYXUk0vpLUJCJR-AaJIJcewykFnhkO_Pkcptz-1jajxTIA45Xp1EdAI9TJ8XeURj2YdsRmvS9_HmJGbd5nQuGYyfhej2K66aJEeU9V5boHGknNnII456Y9jYtw_TftFipqQ5SV8pdmUffDVy7MJJrtU7nY5n2-8zwK6AwnYLuq37QKzsN0-6EX2YG5N5Z_mfOArFka3HGXPMe6_JxaqboThzzbaLyOmNVdQF7yBrLlYWmwIniVDIgzu69RDzR7u-g7yGxTjISr8GM2O38TFwIbi5Bm5yS_EhcbnuogFC_q1FldX8m43jCG4nSjVSr8bgVAbOKSmGBZZjtb22znrrN9obzjbQ!
 TterZO5pkR/https%3A%2F%2Fzigi.rocks to be a preview. #git #ispf #zos #zdevops 
#awesome #epic #gseconf



Lionel B. Dyck <
Website:  

 
http://secure-web.cisco.com/1EKmeCpOoTB2Vg9wwQzoI76J6kqN9LWevSHzFXhEIfZkfVG8PQGF0WICWRf39ZnvcJoDkjbwA3n9BRA4L3NJlcuqgCl7HlcXRqkhw-DQ7ZbsYZfQM2APgnbNpeRrA-nMBxqHnrTv2OYMJBj4FuDoQGBgU_Z6V_OV6Ct6FaAsc2750Y4qE6Kw_S9IBJSP3NB1uH1v41IU_23uy3M3_BquPXkYbdIX0htqPKUnNR-aw_oDRTWaPvqkho7h24jnHQkb9InxzSXWnwXFHav0zHpxYIfpNlJm-CNS30DLFZACCBHt5ekXto2x_XOxV4z2GgK2GcF7DKBDXYMshA9p8HPKvxmtw9NELAaGJobql2QMO08UwBM-wNk3EiwkTDfn8f_n4fBm9DXmd3iMe6Mn-oS-B0N6348wzPV_Knxm5MGTby4LW96vTiS!
 cI7IqmQt0EEAQP/http%3A%2F%2Fwww.lbdsoftware.com

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




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

Re: WTO message at the end of JCL

[Seymour J Metz]

SWAREQ. As I recall, the LCT points to the JCT, which points to the first SCT. 
There are mapping macros for all of them.


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



From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Monday, November 4, 2019 7:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO message at the end of JCL

I have ten years of commercial product experience with SMF exit development. 
:-) I am super familiar with SMF 30 subtypes 4 and 5 (and all the others). I 
have a yellow card.

I was referring to a program running as a jobstep retrieving condition codes 
for its own job. Is there an MVS service or control block chain that readily 
gives that information?

SMF exits, by the way, cannot necessarily issue WTOs.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, November 4, 2019 4:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO message at the end of JCL

Step and job end status are very accessible. Look at SYS1.SAMPLIB(SMFEXITS). 
Factors like step and maximum condition codes; step and job CPU totals; and I/O 
counts can be extracted from control blocks and displayed in WTOs. The code 
versions we use have been tailored over the years so that our messages don't 
look exactly like SAMPLIB examples, but it's all very doable.

All you need is a POP, a yellow card, and lots of patience. Or you could try 
your hand at writing some exit code in other than ASM. Like Metal C. A LOT of 
folks would like to get their mitts on that.

--
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: WTO message at the end of JCL

[Seymour J Metz]

Yes. It's easier in assembler, where4 you can use SWAREQ to deal with the 
tokens. If you do it in REXX then you need separate paths for SWA below the 
line, old format SWA above the line and new format SWA above the line.


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



From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Monday, November 4, 2019 9:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO message at the end of JCL

On 2019-11-05 8:52 AM, Charles Mills wrote:
> I was referring to a program running as a jobstep retrieving condition codes 
> for its own job. Is there an MVS service or control block chain that readily 
> gives that information?


IIRC, the SCT (Step Control Table) has this information and the SCT
extension block contains ABEND information.

--
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: WTO message at the end of JCL

[John McKown]

On Tue, Nov 5, 2019 at 12:10 PM Seymour J Metz  wrote:

> > OS/VS1 introduced the 3270 device.
>
> WTF!?
>
> I was using 3270 devices before OS/VS1 was announced. What is OS/360,
> hopped liver?
>

I remember DIDOCS 3270 consoles on MVT.


>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 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

Re: Zfs from 1 LPAR to another

[John McKown]

On Tue, Nov 5, 2019 at 12:00 PM Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> I transport ZFS's via FTP all the time.  DFDSS dump and restore.
>

That sounds like a winner to me. My first thought was to use the UNIX "pax"
utility. But ADRDSSU of the actual zFS LDS dataset sounds better. If the
creator of the zFS actually made a separate zFS dataset for the output,
with no extraneous files in 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
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Pierre Fichaud
> Sent: Tuesday, November 5, 2019 12:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Zfs from 1 LPAR to another
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> A customer wants to send us a zFS file created by an IBM product. We
> develop at Dallas and don't have the product installed.  What should the
> customer do to be able to send it to us ? I've looked through the archives
> and didn't find what I needed. I can't remember if I saw this in IBM
> manuals.
> Thanks in advance, Pierre.
>
> --
> 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
>


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

Re: WTO message at the end of JCL

[Seymour J Metz]

Does that support the new token algorithm?


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



From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Tuesday, November 5, 2019 2:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO message at the end of JCL

I use a REXX script which we use to record cond codes from test jobs.

main:
   cvt = ptr(16)
   tcbp= ptr(cvt)
   tcb = ptr(tcbp + 4)
   jscb= ptr(tcb + 180)
   ssib= ptr(jscb + 316)
   tct = ptr(tcb + 164)
   lct = ptr(tct + 152)
   jct = ptr(lct + 16)
   jobid   = stg(ssib + 12, 8)
   jobname = stg(jct + 8, 8)
   sct = c2d(stg(jct + 32, 3))

   SCT_LEN = 36

   if sct > 0 then do
 say 'Step ProcStep CondCode'
 say '  '
 do while sct > 0
   stepname = left(stg(sct + 68, 8), 8)
   procstep = left(stg(sct + 60, 8), 8)
   condcode = x2d(c2x(stg(sct + 24,2)))
   sctxbttp = c2d(stg(sct + 68, 3))
   sctxbttp = swareq(stg( sct + 68, 3))
   scabend  = stg(sctxbttp + 112, 3)
   say stepname procstep condcode scabend
   sct = x2d(c2x(stg(sct + SCT_LEN, 3)))
end
end

   exit 0

ptr: arg addr, len
   if len = '' then len = 4
   return x2d(c2x(bitand(storage(d2x(addr),len),x2c('7FF'

stg: arg addr, len
   return storage(d2x(addr),len)

swareq: procedure
   numeric digits 20 /* allow up to 2**64*/
   sva=c2d(arg(1))   /* convert to decimal   */
   tcb = c2d(storage(21C,4)) /* tcb psatold  */
   jscb = c2d(storage(d2x(tcb+180),4))   /* jscb tcbjscb  */
   qmpl = c2d(storage(d2x(jscb+244),4))  /* qmpl jscbqmpi */
   /* see if qmat can be above the bar */
   qmsta= c2x(storage(d2x(qmpl+16),1))   /* job status byte  */
   if substr(x2b(qmsta),6,1) then/* is qmqmat64 bit on?  */
   do/* yes, qmat can be atb */
 if right(x2b(c2x(arg(1))),1) \= '1' then/* swa=below ?  */
   return c2d(arg(1))+16 /* yes, return sva+16   */
 qmat=c2d(storage(d2x(qmpl+10),2))*(2**48) +,/* qmat+0 qmadd01  */
  c2d(storage(d2x(qmpl+18),2))*(2**32) +,/* qmat+2 qmadd23  */
  c2d(storage(d2x(qmpl+24),4))   /* qmat+4 qmadd*/
 return c2d(storage(d2x(qmat+(sva*12)+64),4))+16
end
else
   do/* no, qmat is btb  */
 if right(c2x(arg(1)),1) \= 'F' then /* swa=below ?  */
   return c2d(arg(1))+16 /* yes, return sva+16   */
 qmat = c2d(storage(d2x(qmpl+24),4)) /* qmat qmadd*/
 do while sva>65536
   qmat = c2d(storage(d2x(qmat+12),4))   /* next qmat qmat+12  */
   sva=sva-65536 /* 010006f -> 06f   */
end
 return c2d(storage(d2x(qmat+sva+1),4))+16
end



On 2019-11-05 2:26 PM, Brian Westerman wrote:
> Of course there is a way, all you need to do is process the SCT from your 
> program.  You will get all steps up to the one you are currently in only 
> because it has not ended yet.  But if you are running as the last step it 
> wouldn't matter.  That's not how I do it in SyzMPF/z, but it "could" be done 
> that way in another step of the job.  In fact, I think there are programs on 
> the CBT tape that do just that.
>
> 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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: git with it

[Lionel B Dyck]

On Thursday the git repository will change from private to public and you'll be 
able to git a copy for yourself 😊


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 
Seymour J Metz
Sent: Tuesday, November 5, 2019 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: git with it

I just wish it had more detail and fewer superlatives. I assume that the 
current release icon will eventually take us to details.


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



From: IBM Mainframe Discussion List  on behalf of 
Lionel B Dyck 
Sent: Tuesday, November 5, 2019 7:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: git with it

The countdown continues towards an epic announcement that will rock the z/OS 
development world down to the bit level. Be prepared as you'll have to wait for 
the announcement at GSE UK this Thursday at 11:15. Be prepared to git it.  Or 
go to  

 
https://secure-web.cisco.com/1YPLXK51W8atPq2Fbq2T7cyKbgjj4PBRfsL4uqBAnLM3zCD64WkSWXRPIzmA3j83k1pWAkNoRirKBQ56wcdIypNdU1tqYXUk0vpLUJCJR-AaJIJcewykFnhkO_Pkcptz-1jajxTIA45Xp1EdAI9TJ8XeURj2YdsRmvS9_HmJGbd5nQuGYyfhej2K66aJEeU9V5boHGknNnII456Y9jYtw_TftFipqQ5SV8pdmUffDVy7MJJrtU7nY5n2-8zwK6AwnYLuq37QKzsN0-6EX2YG5N5Z_mfOArFka3HGXPMe6_JxaqboThzzbaLyOmNVdQF7yBrLlYWmwIniVDIgzu69RDzR7u-g7yGxTjISr8GM2O38TFwIbi5Bm5yS_EhcbnuogFC_q1FldX8m43jCG4nSjVSr8bgVAbOKSmGBZZjtb22znrrN9obzjbQ!
 TterZO5pkR/https%3A%2F%2Fzigi.rocks to be a preview. #git #ispf #zos #zdevops 
#awesome #epic #gseconf



Lionel B. Dyck <
Website:  

 
http://secure-web.cisco.com/1EKmeCpOoTB2Vg9wwQzoI76J6kqN9LWevSHzFXhEIfZkfVG8PQGF0WICWRf39ZnvcJoDkjbwA3n9BRA4L3NJlcuqgCl7HlcXRqkhw-DQ7ZbsYZfQM2APgnbNpeRrA-nMBxqHnrTv2OYMJBj4FuDoQGBgU_Z6V_OV6Ct6FaAsc2750Y4qE6Kw_S9IBJSP3NB1uH1v41IU_23uy3M3_BquPXkYbdIX0htqPKUnNR-aw_oDRTWaPvqkho7h24jnHQkb9InxzSXWnwXFHav0zHpxYIfpNlJm-CNS30DLFZACCBHt5ekXto2x_XOxV4z2GgK2GcF7DKBDXYMshA9p8HPKvxmtw9NELAaGJobql2QMO08UwBM-wNk3EiwkTDfn8f_n4fBm9DXmd3iMe6Mn-oS-B0N6348wzPV_Knxm5MGTby4LW96vTiS!
 cI7IqmQt0EEAQP/http%3A%2F%2Fwww.lbdsoftware.com

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




--
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: git with it

[Seymour J Metz]

I just wish it had more detail and fewer superlatives. I assume that the 
current release icon will eventually take us to details.


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



From: IBM Mainframe Discussion List  on behalf of 
Lionel B Dyck 
Sent: Tuesday, November 5, 2019 7:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: git with it

The countdown continues towards an epic announcement that will rock the z/OS
development world down to the bit level. Be prepared as you'll have to wait
for the announcement at GSE UK this Thursday at 11:15. Be prepared to git
it.  Or go to  

 
https://secure-web.cisco.com/1YPLXK51W8atPq2Fbq2T7cyKbgjj4PBRfsL4uqBAnLM3zCD64WkSWXRPIzmA3j83k1pWAkNoRirKBQ56wcdIypNdU1tqYXUk0vpLUJCJR-AaJIJcewykFnhkO_Pkcptz-1jajxTIA45Xp1EdAI9TJ8XeURj2YdsRmvS9_HmJGbd5nQuGYyfhej2K66aJEeU9V5boHGknNnII456Y9jYtw_TftFipqQ5SV8pdmUffDVy7MJJrtU7nY5n2-8zwK6AwnYLuq37QKzsN0-6EX2YG5N5Z_mfOArFka3HGXPMe6_JxaqboThzzbaLyOmNVdQF7yBrLlYWmwIniVDIgzu69RDzR7u-g7yGxTjISr8GM2O38TFwIbi5Bm5yS_EhcbnuogFC_q1FldX8m43jCG4nSjVSr8bgVAbOKSmGBZZjtb22znrrN9obzjbQ!
 TterZO5pkR/https%3A%2F%2Fzigi.rocks to be a preview. #git
#ispf #zos #zdevops #awesome #epic #gseconf



Lionel B. Dyck <
Website:  

 
http://secure-web.cisco.com/1EKmeCpOoTB2Vg9wwQzoI76J6kqN9LWevSHzFXhEIfZkfVG8PQGF0WICWRf39ZnvcJoDkjbwA3n9BRA4L3NJlcuqgCl7HlcXRqkhw-DQ7ZbsYZfQM2APgnbNpeRrA-nMBxqHnrTv2OYMJBj4FuDoQGBgU_Z6V_OV6Ct6FaAsc2750Y4qE6Kw_S9IBJSP3NB1uH1v41IU_23uy3M3_BquPXkYbdIX0htqPKUnNR-aw_oDRTWaPvqkho7h24jnHQkb9InxzSXWnwXFHav0zHpxYIfpNlJm-CNS30DLFZACCBHt5ekXto2x_XOxV4z2GgK2GcF7DKBDXYMshA9p8HPKvxmtw9NELAaGJobql2QMO08UwBM-wNk3EiwkTDfn8f_n4fBm9DXmd3iMe6Mn-oS-B0N6348wzPV_Knxm5MGTby4LW96vTiS!
 cI7IqmQt0EEAQP/http%3A%2F%2Fwww.lbdsoftware.com

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




--
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: How display level of paging?

[Mike Schwab]

X Memory needs X disk for paging backup.  Then a System dump needs to
copy Memory + Pages, so 3X disk for X Memory.  Also leads to the
guidance that over 30% percent usage of slots you need to consider
increasing disk paging.

On Tue, Nov 5, 2019 at 10:44 AM Allan Staller  wrote:
>
> 10TB real 30TB Paging.
>
> Implies 3:1 virtual to real.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Mike Schwab
> Sent: Tuesday, November 5, 2019 10:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How display level of paging?
>
> 10TB real 30TB Paging.
>
> On Tue, Nov 5, 2019 at 10:35 AM Allan Staller  wrote:
> >
> > I never based my estimates on the amount of real.  Only on the Virtual.
> >
> > Using our same 10TB system with a 2:1 virtual to real would result in 20 TB 
> > page slots and a 60TB paging subsystem.
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Tom Marchant
> > Sent: Tuesday, November 5, 2019 8:56 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: How display level of paging?
> >
> > On Mon, 4 Nov 2019 17:46:12 -0500, Tom Conley wrote:
> >
> > >I posed this same question about 2 years ago.  Then I was dealing
> > >with an LPAR with 131GB, so I created a 400GB paging subsystem to
> > >handle the system.  Others suggested SCM, but that was not in the
> > >budget.  If the 10TB is truly fully utilized, then a 30TB paging subsystem 
> > >makes sense.
> > >Unless I hear differently from IBM, paging rules still apply, even
> > >for 10TB systems.
> >
> > Looking at one of our bigger LPARs here, we have
> >
> > 66 GB of storage
> > 8 local page data sets that fill 3390-9 volumes (total 68 GB)
> > 264 GB SCM paging devices
> >
> > So we are well within what you think is needed. I am not the sysprog here, 
> > but if I was I would not be opposed to reducing it because:
> >
> > The local page data sets are all 0% full The the SCM is using 64 M of
> > the 264 GB
> >
> > Admittedly, we are a small shop. We are also a development shop and take a 
> > fair number of SVC dumps.
> >
> > Those old rules were from the days when memory was expensive and paging was 
> > common. Back in the 80's it was not uncommon to page at rates of 50 to 100 
> > pages per second on a machine with 32 to 64 MB of main storage, and have 5 
> > GB or more of page space utilized. Today, paging, and page space 
> > utilization, is normally much less.
> >
> > What I would suggest that you need for page space today is more like the 
> > sum of:
> >
> > Maximum virtual storage in use minus real storage, multiplied by 3 and 
> > Enough to support the capture of the biggest possible SVC dump, multiplied 
> > by 3.
> >
> > I don't remember a time that the recommendation was to size paging 
> > subsystems based upon the amount of real storage on the processor.
> > Indeed, 30 years ago that would have been wholly inadequate.
> >
> > I don't buy the suggestion that an LPAR with 10 TB of storage should have 
> > 30 to 90 TB of paging space.
> >
> > I'll close with this observation. A z15 processor can have a maximum
> > of
> > 40 TB  of customer storage. The maximum amount of SCM is 6 TB. You want to 
> > configure your paging subsystem so that paging to DASD is rare, and almost 
> > all paging is to SCM, because SCM is so much faster.
> >
> > --
> > Tom Marchant
> >
> > --
> > 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 IB

Re: WTO message at the end of JCL

[Seymour J Metz]

> OS/VS1 introduced the 3270 device.

WTF!?

I was using 3270 devices before OS/VS1 was announced. What is OS/360, hopped 
liver?


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



From: IBM Mainframe Discussion List  on behalf of 
Mike Schwab 
Sent: Tuesday, November 5, 2019 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO message at the end of JCL

OS/VS1 introduced the 3270 device.

On Tue, Nov 5, 2019 at 6:41 AM scott Ford  wrote:
>
> Actually, this in the way back machine we were doing this in the OS /VS2
> days.
>
> On Tue, Nov 5, 2019 at 7:38 AM scott Ford  wrote:
>
> > Many concepts re-surface Steve.
> >
> > On Mon, Nov 4, 2019 at 10:02 PM Steve Smith  wrote:
> >
> >> This sure sounds like a discussion from the 1980s.  Operators? Consoles?
> >> Those are still a thing?
> >>
> >> Try out the new // NOTIFY statement, and send an email to whoever needs to
> >> wake up.
> >>
> >> sas
> >>
> >>
> >> On Mon, Nov 4, 2019 at 8:37 PM CM Poncelet  wrote:
> >>
> >> > The COND=EVEN/ONLY will not work if the job hits a *JCL error*. 
> >> >
> >> >
> >> > On 04/11/2019 23:56, Charles Mills wrote:
> >> > > It would be nice if there were a way to get the condition codes into
> >> the
> >> > WTO program, something like (don't try this at home):
> >> > >
> >> > > //WTO1 EXEC PGM=WTO,COND=EVEN,
> >> > > //  PARM='Job FOOBAR terminating. Highest CC was &MAXCC'
> >> > >
> >> > > I seem to recall a discussion here about retrieving the last and
> >> maximum
> >> > job CC's from within a program running as a jobstep and the answer was
> >> that
> >> > there was no good way.
> >> > >
> >> > > Charles
> >> > >
> >> > >
> >> > > -Original Message-
> >> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> >> > On Behalf Of Jesse 1 Robinson
> >> > > Sent: Monday, November 4, 2019 1:01 PM
> >> > > To: IBM-MAIN@LISTSERV.UA.EDU
> >> > > Subject: Re: WTO message at the end of JCL
> >> > >
> >> > > MVS has provided such a mechanism forever using
> >> > >
> >> > > 1. a program that issues a WTO
> >> > >
> >> > > 2. conditional execution on the WTO step with COND=EVEN or ONLY
> >> > (depending on the logic required)
> >> > >
> >> > > Most shops already have a more or less sophisticated (security wise)
> >> > program to issue a WTO. Conditional JCL is free for the coding. Every
> >> shop
> >> > I've worked in uses the mechanism to manage production, including my
> >> > current one. There is as Brian says no way to handle a JCL error
> >> without an
> >> > external 'product'.
> >> > >
> >> > > --
> >> > > 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
> >> >
> >>
> >>
> >> --
> >> sas
> >>
> >> --
> >> 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
> >
> --
> 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



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

[Seymour J Metz]

You should be able to use anything that supports Unix files, including e-mail 
and various forms of FTP. What do you normally use for file transfer with  that 
customer?


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



From: IBM Mainframe Discussion List  on behalf of 
Pierre Fichaud 
Sent: Tuesday, November 5, 2019 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Zfs from 1 LPAR to another

A customer wants to send us a zFS file created by an IBM product. We develop at 
Dallas and don't have the product installed.  What should the customer do to be 
able to send it to us ? I've looked through the archives and didn't find what I 
needed. I can't remember if I saw this in IBM manuals.
Thanks in advance, 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

Re: Zfs from 1 LPAR to another

[Allan Staller]

df/DSS DUMP of the ZFS. Use the transportation method of your choice.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pierre Fichaud
Sent: Tuesday, November 5, 2019 11:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Zfs from 1 LPAR to another

A customer wants to send us a zFS file created by an IBM product. We develop at 
Dallas and don't have the product installed.  What should the customer do to be 
able to send it to us ? I've looked through the archives and didn't find what I 
needed. I can't remember if I saw this in IBM manuals.
Thanks in advance, Pierre.

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

Re: Zfs from 1 LPAR to another

[Jousma, David]

I transport ZFS's via FTP all the time.  DFDSS dump and restore.   

_
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 
Pierre Fichaud
Sent: Tuesday, November 5, 2019 12:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Zfs from 1 LPAR to another

**CAUTION EXTERNAL EMAIL**

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

A customer wants to send us a zFS file created by an IBM product. We develop at 
Dallas and don't have the product installed.  What should the customer do to be 
able to send it to us ? I've looked through the archives and didn't find what I 
needed. I can't remember if I saw this in IBM manuals. 
Thanks in advance, Pierre.

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

Zfs from 1 LPAR to another

[Pierre Fichaud]

A customer wants to send us a zFS file created by an IBM product. We develop at 
Dallas and don't have the product installed.  What should the customer do to be 
able to send it to us ? I've looked through the archives and didn't find what I 
needed. I can't remember if I saw this in IBM manuals. 
Thanks in advance, Pierre.

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

Re: How display level of paging?

[Allan Staller]

10TB real 30TB Paging.

Implies 3:1 virtual to real.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Tuesday, November 5, 2019 10:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How display level of paging?

10TB real 30TB Paging.

On Tue, Nov 5, 2019 at 10:35 AM Allan Staller  wrote:
>
> I never based my estimates on the amount of real.  Only on the Virtual.
>
> Using our same 10TB system with a 2:1 virtual to real would result in 20 TB 
> page slots and a 60TB paging subsystem.
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Tom Marchant
> Sent: Tuesday, November 5, 2019 8:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How display level of paging?
>
> On Mon, 4 Nov 2019 17:46:12 -0500, Tom Conley wrote:
>
> >I posed this same question about 2 years ago.  Then I was dealing 
> >with an LPAR with 131GB, so I created a 400GB paging subsystem to 
> >handle the system.  Others suggested SCM, but that was not in the 
> >budget.  If the 10TB is truly fully utilized, then a 30TB paging subsystem 
> >makes sense.
> >Unless I hear differently from IBM, paging rules still apply, even 
> >for 10TB systems.
>
> Looking at one of our bigger LPARs here, we have
>
> 66 GB of storage
> 8 local page data sets that fill 3390-9 volumes (total 68 GB)
> 264 GB SCM paging devices
>
> So we are well within what you think is needed. I am not the sysprog here, 
> but if I was I would not be opposed to reducing it because:
>
> The local page data sets are all 0% full The the SCM is using 64 M of 
> the 264 GB
>
> Admittedly, we are a small shop. We are also a development shop and take a 
> fair number of SVC dumps.
>
> Those old rules were from the days when memory was expensive and paging was 
> common. Back in the 80's it was not uncommon to page at rates of 50 to 100 
> pages per second on a machine with 32 to 64 MB of main storage, and have 5 GB 
> or more of page space utilized. Today, paging, and page space utilization, is 
> normally much less.
>
> What I would suggest that you need for page space today is more like the sum 
> of:
>
> Maximum virtual storage in use minus real storage, multiplied by 3 and Enough 
> to support the capture of the biggest possible SVC dump, multiplied by 3.
>
> I don't remember a time that the recommendation was to size paging subsystems 
> based upon the amount of real storage on the processor.
> Indeed, 30 years ago that would have been wholly inadequate.
>
> I don't buy the suggestion that an LPAR with 10 TB of storage should have 30 
> to 90 TB of paging space.
>
> I'll close with this observation. A z15 processor can have a maximum 
> of
> 40 TB  of customer storage. The maximum amount of SCM is 6 TB. You want to 
> configure your paging subsystem so that paging to DASD is rare, and almost 
> all paging is to SCM, because SCM is so much faster.
>
> --
> Tom Marchant
>
> --
> 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



--
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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the m

Re: How display level of paging?

[Mike Schwab]

10TB real 30TB Paging.

On Tue, Nov 5, 2019 at 10:35 AM Allan Staller  wrote:
>
> I never based my estimates on the amount of real.  Only on the Virtual.
>
> Using our same 10TB system with a 2:1 virtual to real would result in 20 TB 
> page slots and a 60TB paging subsystem.
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Tom Marchant
> Sent: Tuesday, November 5, 2019 8:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How display level of paging?
>
> On Mon, 4 Nov 2019 17:46:12 -0500, Tom Conley wrote:
>
> >I posed this same question about 2 years ago.  Then I was dealing with
> >an LPAR with 131GB, so I created a 400GB paging subsystem to handle the
> >system.  Others suggested SCM, but that was not in the budget.  If the
> >10TB is truly fully utilized, then a 30TB paging subsystem makes sense.
> >Unless I hear differently from IBM, paging rules still apply, even for
> >10TB systems.
>
> Looking at one of our bigger LPARs here, we have
>
> 66 GB of storage
> 8 local page data sets that fill 3390-9 volumes (total 68 GB)
> 264 GB SCM paging devices
>
> So we are well within what you think is needed. I am not the sysprog here, 
> but if I was I would not be opposed to reducing it because:
>
> The local page data sets are all 0% full The the SCM is using 64 M of the 264 
> GB
>
> Admittedly, we are a small shop. We are also a development shop and take a 
> fair number of SVC dumps.
>
> Those old rules were from the days when memory was expensive and paging was 
> common. Back in the 80's it was not uncommon to page at rates of 50 to 100 
> pages per second on a machine with 32 to 64 MB of main storage, and have 5 GB 
> or more of page space utilized. Today, paging, and page space utilization, is 
> normally much less.
>
> What I would suggest that you need for page space today is more like the sum 
> of:
>
> Maximum virtual storage in use minus real storage, multiplied by 3 and Enough 
> to support the capture of the biggest possible SVC dump, multiplied by 3.
>
> I don't remember a time that the recommendation was to size paging subsystems 
> based upon the amount of real storage on the processor.
> Indeed, 30 years ago that would have been wholly inadequate.
>
> I don't buy the suggestion that an LPAR with 10 TB of storage should have 30 
> to 90 TB of paging space.
>
> I'll close with this observation. A z15 processor can have a maximum of
> 40 TB  of customer storage. The maximum amount of SCM is 6 TB. You want to 
> configure your paging subsystem so that paging to DASD is rare, and almost 
> all paging is to SCM, because SCM is so much faster.
>
> --
> Tom Marchant
>
> --
> 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



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

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

Re: How display level of paging?

[Allan Staller]

I never based my estimates on the amount of real.  Only on the Virtual.

Using our same 10TB system with a 2:1 virtual to real would result in 20 TB 
page slots and a 60TB paging subsystem.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Tuesday, November 5, 2019 8:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How display level of paging?

On Mon, 4 Nov 2019 17:46:12 -0500, Tom Conley wrote:

>I posed this same question about 2 years ago.  Then I was dealing with
>an LPAR with 131GB, so I created a 400GB paging subsystem to handle the
>system.  Others suggested SCM, but that was not in the budget.  If the
>10TB is truly fully utilized, then a 30TB paging subsystem makes sense.
>Unless I hear differently from IBM, paging rules still apply, even for
>10TB systems.

Looking at one of our bigger LPARs here, we have

66 GB of storage
8 local page data sets that fill 3390-9 volumes (total 68 GB)
264 GB SCM paging devices

So we are well within what you think is needed. I am not the sysprog here, but 
if I was I would not be opposed to reducing it because:

The local page data sets are all 0% full The the SCM is using 64 M of the 264 GB

Admittedly, we are a small shop. We are also a development shop and take a fair 
number of SVC dumps.

Those old rules were from the days when memory was expensive and paging was 
common. Back in the 80's it was not uncommon to page at rates of 50 to 100 
pages per second on a machine with 32 to 64 MB of main storage, and have 5 GB 
or more of page space utilized. Today, paging, and page space utilization, is 
normally much less.

What I would suggest that you need for page space today is more like the sum of:

Maximum virtual storage in use minus real storage, multiplied by 3 and Enough 
to support the capture of the biggest possible SVC dump, multiplied by 3.

I don't remember a time that the recommendation was to size paging subsystems 
based upon the amount of real storage on the processor.
Indeed, 30 years ago that would have been wholly inadequate.

I don't buy the suggestion that an LPAR with 10 TB of storage should have 30 to 
90 TB of paging space.

I'll close with this observation. A z15 processor can have a maximum of
40 TB  of customer storage. The maximum amount of SCM is 6 TB. You want to 
configure your paging subsystem so that paging to DASD is rare, and almost all 
paging is to SCM, because SCM is so much faster.

--
Tom Marchant

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

Re: DFHSM/DCOLLECT QUESTION [EXTERNAL]

[esmie moo]

 I checked the DFHSM proclib.  There is no CDSSHR=RLS.
Since CDSSHR is not speicfied, RLS is not being used.  Thanks for solving the 
mystery
A massive thanks.
On Tuesday, November 5, 2019, 10:58:37 a.m. GMT-5, Glenn Wilcock 
 wrote:  
 
 HSM's usage of RLS Access for the control data sets is driven by the PROCLIB 
value for CDSSHR.  CDSSHR=RLS indicates that HSM should access the CDSes in RLS 
mode.  If CDSSHR is not specified, or has any other value, then you are not 
using RLS for HSM.

DCOLLECT behaves this way because it is not running under the HSM address 
space, so it is how we determine the proper way to open the control data sets 
concurrently with HSM.

BTW - Using RLS to access the HSM control data sets is my second rated best 
practice for HSM.  If you run concurrent HSM activity across multiple LPARs, it 
can significantly improve elapsed times.  My highest rated best practice for 
HSM is to use zEDC.  zEDC does wonders for HSM elapsed times and storage 
reduction.  If migrating to ML1, it also reduces cpu consumption.

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

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

Re: DFHSM/DCOLLECT QUESTION [EXTERNAL]

[Glenn Wilcock]

HSM's usage of RLS Access for the control data sets is driven by the PROCLIB 
value for CDSSHR.  CDSSHR=RLS indicates that HSM should access the CDSes in RLS 
mode.  If CDSSHR is not specified, or has any other value, then you are not 
using RLS for HSM.

DCOLLECT behaves this way because it is not running under the HSM address 
space, so it is how we determine the proper way to open the control data sets 
concurrently with HSM.

BTW - Using RLS to access the HSM control data sets is my second rated best 
practice for HSM.  If you run concurrent HSM activity across multiple LPARs, it 
can significantly improve elapsed times.  My highest rated best practice for 
HSM is to use zEDC.  zEDC does wonders for HSM elapsed times and storage 
reduction.  If migrating to ML1, it also reduces cpu consumption.

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

Re: DFHSM/DCOLLECT QUESTION [EXTERNAL]

[esmie moo]

 As you suggested I did the command and I got the following :
THE SMSVSAM SERVER ADDRESS SPACE IS NOT ACTIVE

That answers my question.  Thanks.
On Tuesday, November 5, 2019, 09:36:19 a.m. EST, Feller, Paul 
 wrote:  
 
 Here is what I see on one of my z/OS 2.2 systems (also saw the same 
information on a z/OS 2.3 system).  There is a section for RLSDATA as part of 
the CLUSTER information.

CLUSTER --- SYSD.HSM.ED.MCDS                                                
              
    IN-CAT --- SYSUCAT.SYSTEM.ED                                                
            
    HISTORY                                                                     
             
      DATASET-OWNER-(NULL)    CREATION2017.064                      
            
      RELEASE2    EXPIRATION--.000                      
            
    SMSDATA                                                                     
             
      STORAGECLASS ---STGADMIN    MANAGEMENTCLASS---NOMGMT                      
            
      DATACLASS --DCLASSLE    LBACKUP ---.000.                      
            
      CA-RECLAIM-(YES)                                                  
            
      EATTR-(NULL)                                                  
            
      BWO STATUS--    BWO TIMESTAMP---0 00:00:00.0              
            
      BWO---(NULL)                                                  
            
    RLSDATA                                                                     
             
      LOG (NULL)  RECOVERY REQUIRED --(NO)    FRLOG 
(NULL)    
      VSAM QUIESCED ---(NO)    RLS IN USE -(NO)    
LOGREPLICATE-(NO)
      LOGSTREAMID-(NULL)                            
            
      RECOVERY TIMESTAMP LOCAL-X''                          
            
      RECOVERY TIMESTAMP GMT---X''                          
            
      DATABASE -(NULL)                                          
            
    ENCRYPTIONDATA                                                              
            
      DATA SET ENCRYPTION-(NO)                                              
            
    PROTECTION-PSWD-(NULL)    RACF(NO)                      
            
    ASSOCIATIONS                                                                
            
      DATA-SYSD.HSM.ED.MCDS.DATA                                            
            
      INDEXSYSD.HSM.ED.MCDS.INDEX                                           
             


Also you can do the command D SMS,CFLS to see if you are running RLS at all.  
If your display looks like the below example then you not doing RLS at all.

D SMS,CFLS                                    
IGW451I DFSMS SMSVSAM COMMAND REJECTED.        
THE SMSVSAM SERVER ADDRESS SPACE IS NOT ACTIVE.


Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of esmie moo
Sent: Tuesday, November 05, 2019 5:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM/DCOLLECT QUESTION [EXTERNAL]

 I tried your suggestion but the RLS IN USE doesn't show on the LISTCAT.
    On Monday, November 4, 2019, 01:36:16 p.m. GMT-5, Feller, Paul 
 wrote:  
 
 In the LISTCAT output look for "RLS IN USE", it should show YES or NO.

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of esmie moo
Sent: Monday, November 04, 2019 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFHSM/DCOLLECT QUESTION [EXTERNAL]

Gentle Readers,
     We receive a IEC161I 009-0663 (COND CODE 0008) everytime we execute a 
batch job which uses DCOLLECT:   The error occurs while reading the MCDS.
I checked the IBM documentation and I got more confused.  I found this tidbit 
of info:

This is a known condition when running IDCAMS DCOLLECT against DFSMShsm CDS

which are not in RLS mode. ARCUTIL first tries to open the CDS in RLS mode, so 
the IEC161I RC009 is issued when this fails. HSM then opens the CDS in NON RLS 
mode. This is described in DFSMShsm Implementation and Customization Guide, 
Chapter " User Application Interfaces", under Choosing a Data Collection 
Method. Customers whose HSM CDS are not in RLS mode may ignore this condition.
   I am not sure how verify if the CDS is "... are not in RLS mode."
I looked at the LISTCAT and it shows that the SHROPTIONS parm is set at 
SHROPTNS(3,3) 

Could somebody help me understand this?
Thanks.




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

Re: CBPs (processors) - what is it?

[Gord Tomlin]

On 2019-11-05 09:56, R.S. wrote:

I suspect CBP would be for running docker payloads ?
Well, as I wrote, dockers (zCX) use zIIP. You are right the name is very 
suggestive, but some presentations about docker on z/OS did not mention 
CBP.


zCX requires:
- Z14 GA2
- Hardware Feature Code 0104 (Container Hosting Foundation)

I haven't been able to find much useful information on HFC 0104, but 
would not be surprised if it is related to CBP.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Re: CBPs (processors) - what is it?

[R.S.]

W dniu 2019-11-05 o 15:34, Raphael Jacquot pisze:

On 11/5/19 3:32 PM, R.S. wrote:

Yes, it is Container Based Processor, however I knew it and wrote here
explanation of the three letter acronym.
The problem is what is the purpose of CBP?
IMHO it's easy to explain what is zIIP, IFL, ICF or IFP, but I have no
explanation for CBP. That's why I'm asking. ;-)

Regards

I suspect CBP would be for running docker payloads ?
Well, as I wrote, dockers (zCX) use zIIP. You are right the name is very 
suggestive, but some presentations about docker on z/OS did not mention 
CBP.


Regards
--
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.2019 r. wynosi 169.347.928 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.347.928 as at 1 January 2019.

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

Re: How display level of paging?

[Tom Marchant]

On Mon, 4 Nov 2019 17:46:12 -0500, Tom Conley wrote:

>I posed this same question about 2 years ago.  Then I was dealing with
>an LPAR with 131GB, so I created a 400GB paging subsystem to handle the
>system.  Others suggested SCM, but that was not in the budget.  If the
>10TB is truly fully utilized, then a 30TB paging subsystem makes sense.
>Unless I hear differently from IBM, paging rules still apply, even for
>10TB systems.

Looking at one of our bigger LPARs here, we have

66 GB of storage
8 local page data sets that fill 3390-9 volumes (total 68 GB)
264 GB SCM paging devices

So we are well within what you think is needed. I am not the sysprog 
here, but if I was I would not be opposed to reducing it because:

The local page data sets are all 0% full
The the SCM is using 64 M of the 264 GB

Admittedly, we are a small shop. We are also a development shop and 
take a fair number of SVC dumps.

Those old rules were from the days when memory was expensive and 
paging was common. Back in the 80's it was not uncommon to page at 
rates of 50 to 100 pages per second on a machine with 32 to 64 MB 
of main storage, and have 5 GB or more of page space utilized. Today, 
paging, and page space utilization, is normally much less.

What I would suggest that you need for page space today is more like 
the sum of:

Maximum virtual storage in use minus real storage, multiplied by 3
and
Enough to support the capture of the biggest possible SVC dump, 
multiplied by 3.

I don't remember a time that the recommendation was to size paging 
subsystems based upon the amount of real storage on the processor. 
Indeed, 30 years ago that would have been wholly inadequate.

I don't buy the suggestion that an LPAR with 10 TB of storage should 
have 30 to 90 TB of paging space.

I'll close with this observation. A z15 processor can have a maximum of 
40 TB  of customer storage. The maximum amount of SCM is 6 TB. You 
want to configure your paging subsystem so that paging to DASD is rare, 
and almost all paging is to SCM, because SCM is so much faster.

-- 
Tom Marchant

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

Re: CBPs (processors) - what is it?

[Raphael Jacquot]

On 11/5/19 3:32 PM, R.S. wrote:
> Yes, it is Container Based Processor, however I knew it and wrote here
> explanation of the three letter acronym.
> The problem is what is the purpose of CBP?
> IMHO it's easy to explain what is zIIP, IFL, ICF or IFP, but I have no
> explanation for CBP. That's why I'm asking. ;-)
> 
> Regards

I suspect CBP would be for running docker payloads ?

Regards

Raphaël

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

Re: CBPs (processors) - what is it?

[R.S.]

Yes, it is Container Based Processor, however I knew it and wrote here 
explanation of the three letter acronym.

The problem is what is the purpose of CBP?
IMHO it's easy to explain what is zIIP, IFL, ICF or IFP, but I have no 
explanation for CBP. That's why I'm asking. ;-)


Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 2019-11-05 o 15:14, Mark Jacobs pisze:

Container Based Processor (CBP)

https://www-01.ibm.com/support/docview.wss?uid=swg1OA55159


Sent from ProtonMail, Swiss-based encrypted email.

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

‐‐‐ Original Message ‐‐‐
On Tuesday, November 5, 2019 9:12 AM, R.S.  
wrote:


We know the following types/flavours of mainframe processors: regular
CP, zIIP, IFL, SAP, ICF, older zAAP ...and CBP
This CBP is visible on Support Element panels. Help says it is "CBPs -
Displays the active/unassigned container based processors installed on
your system."
Container sounds like zCX, however as far as I know zCX use CP or zIIP.
No information about CBP.

So, what is CBP?
Any clue?

---

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.2019 r. wynosi 169.347.928 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.347.928 as at 1 January 2019.

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

Re: CBPs (processors) - what is it?

[Mark Jacobs]

Container Based Processor (CBP)

https://www-01.ibm.com/support/docview.wss?uid=swg1OA55159


Sent from ProtonMail, Swiss-based encrypted email.

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

‐‐‐ Original Message ‐‐‐
On Tuesday, November 5, 2019 9:12 AM, R.S.  
wrote:

> We know the following types/flavours of mainframe processors: regular
> CP, zIIP, IFL, SAP, ICF, older zAAP ...and CBP
> This CBP is visible on Support Element panels. Help says it is "CBPs -
> Displays the active/unassigned container based processors installed on
> your system."
> Container sounds like zCX, however as far as I know zCX use CP or zIIP.
> No information about CBP.
>
> So, what is CBP?
> Any clue?
>
> ---
>
> 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.2019 r. wynosi 169.347.928 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.347.928 as at 1 January 2019.
>
>
> 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

CBPs (processors) - what is it?

[R.S.]

We know the following types/flavours of mainframe processors: regular 
CP, zIIP, IFL, SAP, ICF, older zAAP ...and CBP
This CBP is visible on Support Element panels. Help says it is "CBPs - 
Displays the active/unassigned container based processors installed on 
your system."
Container sounds like zCX, however as far as I know zCX use CP or zIIP. 
No information about CBP.


So, what is CBP?
Any clue?

--
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.2019 r. wynosi 169.347.928 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.347.928 as at 1 January 2019.

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

Re: git with it

[Henri Kuiper]

Just to clarify : the link to the repo wil "404" until release time. Watch 
@ispfgit on twitter for the moment that happens. 

Sent from my wireless iPhone

> On 5 Nov 2019, at 12:42, Lionel B Dyck  wrote:
> 
> The countdown continues towards an epic announcement that will rock the z/OS
> development world down to the bit level. Be prepared as you'll have to wait
> for the announcement at GSE UK this Thursday at 11:15. Be prepared to git
> it.  Or go to   https://zigi.rocks to be a preview. #git
> #ispf #zos #zdevops #awesome #epic #gseconf
> 
> 
> 
> 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
> 
> 
> 
> 
> --
> 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: git with it

[Henri Kuiper]

;)

Sent from my wireless iPhone

> On 5 Nov 2019, at 13:03, David Crayford  wrote:
> 
> WOW! That looks awsome! Thanks Lionel :)
> 
>> On 2019-11-05 8:42 PM, Lionel B Dyck wrote:
>> The countdown continues towards an epic announcement that will rock the z/OS
>> development world down to the bit level. Be prepared as you'll have to wait
>> for the announcement at GSE UK this Thursday at 11:15. Be prepared to git
>> it.  Or go to   https://zigi.rocks to be a preview. #git
>> #ispf #zos #zdevops #awesome #epic #gseconf
>> 
>>  
>> 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
>> 
>>  
>> 
>> --
>> 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: WTO message at the end of JCL

[David Spiegel]

CRJE

On 2019-11-05 08:13, Mike Schwab wrote:
> OS/VS1 introduced the 3270 device.
>
> On Tue, Nov 5, 2019 at 6:41 AM scott Ford  wrote:
>> Actually, this in the way back machine we were doing this in the OS /VS2
>> days.
>>
>> On Tue, Nov 5, 2019 at 7:38 AM scott Ford  wrote:
>>
>>> Many concepts re-surface Steve.
>>>
>>> On Mon, Nov 4, 2019 at 10:02 PM Steve Smith  wrote:
>>>
 This sure sounds like a discussion from the 1980s.  Operators? Consoles?
 Those are still a thing?

 Try out the new // NOTIFY statement, and send an email to whoever needs to
 wake up.

 sas


 On Mon, Nov 4, 2019 at 8:37 PM CM Poncelet  wrote:

> The COND=EVEN/ONLY will not work if the job hits a *JCL error*. 
>
>
> On 04/11/2019 23:56, Charles Mills wrote:
>> It would be nice if there were a way to get the condition codes into
 the
> WTO program, something like (don't try this at home):
>> //WTO1 EXEC PGM=WTO,COND=EVEN,
>> //  PARM='Job FOOBAR terminating. Highest CC was &MAXCC'
>>
>> I seem to recall a discussion here about retrieving the last and
 maximum
> job CC's from within a program running as a jobstep and the answer was
 that
> there was no good way.
>> Charles
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
>> Sent: Monday, November 4, 2019 1:01 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: WTO message at the end of JCL
>>
>> MVS has provided such a mechanism forever using
>>
>> 1. a program that issues a WTO
>>
>> 2. conditional execution on the WTO step with COND=EVEN or ONLY
> (depending on the logic required)
>> Most shops already have a more or less sophisticated (security wise)
> program to issue a WTO. Conditional JCL is free for the coding. Every
 shop
> I've worked in uses the mechanism to manage production, including my
> current one. There is as Brian says no way to handle a JCL error
 without an
> external 'product'.
>> --
>> 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
>

 --
 sas

 --
 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
>>>
>> --
>> 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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: WTO message at the end of JCL

[Mike Schwab]

OS/VS1 introduced the 3270 device.

On Tue, Nov 5, 2019 at 6:41 AM scott Ford  wrote:
>
> Actually, this in the way back machine we were doing this in the OS /VS2
> days.
>
> On Tue, Nov 5, 2019 at 7:38 AM scott Ford  wrote:
>
> > Many concepts re-surface Steve.
> >
> > On Mon, Nov 4, 2019 at 10:02 PM Steve Smith  wrote:
> >
> >> This sure sounds like a discussion from the 1980s.  Operators? Consoles?
> >> Those are still a thing?
> >>
> >> Try out the new // NOTIFY statement, and send an email to whoever needs to
> >> wake up.
> >>
> >> sas
> >>
> >>
> >> On Mon, Nov 4, 2019 at 8:37 PM CM Poncelet  wrote:
> >>
> >> > The COND=EVEN/ONLY will not work if the job hits a *JCL error*. 
> >> >
> >> >
> >> > On 04/11/2019 23:56, Charles Mills wrote:
> >> > > It would be nice if there were a way to get the condition codes into
> >> the
> >> > WTO program, something like (don't try this at home):
> >> > >
> >> > > //WTO1 EXEC PGM=WTO,COND=EVEN,
> >> > > //  PARM='Job FOOBAR terminating. Highest CC was &MAXCC'
> >> > >
> >> > > I seem to recall a discussion here about retrieving the last and
> >> maximum
> >> > job CC's from within a program running as a jobstep and the answer was
> >> that
> >> > there was no good way.
> >> > >
> >> > > Charles
> >> > >
> >> > >
> >> > > -Original Message-
> >> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> >> > On Behalf Of Jesse 1 Robinson
> >> > > Sent: Monday, November 4, 2019 1:01 PM
> >> > > To: IBM-MAIN@LISTSERV.UA.EDU
> >> > > Subject: Re: WTO message at the end of JCL
> >> > >
> >> > > MVS has provided such a mechanism forever using
> >> > >
> >> > > 1. a program that issues a WTO
> >> > >
> >> > > 2. conditional execution on the WTO step with COND=EVEN or ONLY
> >> > (depending on the logic required)
> >> > >
> >> > > Most shops already have a more or less sophisticated (security wise)
> >> > program to issue a WTO. Conditional JCL is free for the coding. Every
> >> shop
> >> > I've worked in uses the mechanism to manage production, including my
> >> > current one. There is as Brian says no way to handle a JCL error
> >> without an
> >> > external 'product'.
> >> > >
> >> > > --
> >> > > 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
> >> >
> >>
> >>
> >> --
> >> sas
> >>
> >> --
> >> 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
> >
> --
> 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



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

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

Re: WTO message at the end of JCL

[Jousma, David]

It's not obvious, but this functionality requires z/OSMF to be active as well 
as the JESEDS interface configured and active as well.

_
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 
Michael Babcock
Sent: Tuesday, November 5, 2019 7:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO message at the end of JCL

**CAUTION EXTERNAL EMAIL**

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

If the OP is running z/OS 2.3 then JES2 can send email about job completion 
using the new  NOTIFY EMAIL= parameter on the jobcard.

On Tue, Nov 5, 2019 at 12:28 AM Brian Westerman < 
brian_wester...@syzygyinc.com> wrote:

> Of course there is a way, all you need to do is process the SCT from 
> your program.  You will get all steps up to the one you are currently 
> in only because it has not ended yet.  But if you are running as the 
> last step it wouldn't matter.  That's not how I do it in SyzMPF/z, but 
> it "could" be done that way in another step of the job.  In fact, I 
> think there are programs on the CBT tape that do just that.
>
> Brian
>
> --
> 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 **CAUTION EXTERNAL 
EMAIL**

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

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


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

Re: git with it

[David Crayford]

WOW! That looks awsome! Thanks Lionel :)

On 2019-11-05 8:42 PM, Lionel B Dyck wrote:

The countdown continues towards an epic announcement that will rock the z/OS
development world down to the bit level. Be prepared as you'll have to wait
for the announcement at GSE UK this Thursday at 11:15. Be prepared to git
it.  Or go to   https://zigi.rocks to be a preview. #git
#ispf #zos #zdevops #awesome #epic #gseconf

  


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

  



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

git with it

[Lionel B Dyck]

The countdown continues towards an epic announcement that will rock the z/OS
development world down to the bit level. Be prepared as you'll have to wait
for the announcement at GSE UK this Thursday at 11:15. Be prepared to git
it.  Or go to   https://zigi.rocks to be a preview. #git
#ispf #zos #zdevops #awesome #epic #gseconf

 

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

 


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

Re: WTO message at the end of JCL

[scott Ford]

Actually, this in the way back machine we were doing this in the OS /VS2
days.

On Tue, Nov 5, 2019 at 7:38 AM scott Ford  wrote:

> Many concepts re-surface Steve.
>
> On Mon, Nov 4, 2019 at 10:02 PM Steve Smith  wrote:
>
>> This sure sounds like a discussion from the 1980s.  Operators? Consoles?
>> Those are still a thing?
>>
>> Try out the new // NOTIFY statement, and send an email to whoever needs to
>> wake up.
>>
>> sas
>>
>>
>> On Mon, Nov 4, 2019 at 8:37 PM CM Poncelet  wrote:
>>
>> > The COND=EVEN/ONLY will not work if the job hits a *JCL error*. 
>> >
>> >
>> > On 04/11/2019 23:56, Charles Mills wrote:
>> > > It would be nice if there were a way to get the condition codes into
>> the
>> > WTO program, something like (don't try this at home):
>> > >
>> > > //WTO1 EXEC PGM=WTO,COND=EVEN,
>> > > //  PARM='Job FOOBAR terminating. Highest CC was &MAXCC'
>> > >
>> > > I seem to recall a discussion here about retrieving the last and
>> maximum
>> > job CC's from within a program running as a jobstep and the answer was
>> that
>> > there was no good way.
>> > >
>> > > Charles
>> > >
>> > >
>> > > -Original Message-
>> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> > On Behalf Of Jesse 1 Robinson
>> > > Sent: Monday, November 4, 2019 1:01 PM
>> > > To: IBM-MAIN@LISTSERV.UA.EDU
>> > > Subject: Re: WTO message at the end of JCL
>> > >
>> > > MVS has provided such a mechanism forever using
>> > >
>> > > 1. a program that issues a WTO
>> > >
>> > > 2. conditional execution on the WTO step with COND=EVEN or ONLY
>> > (depending on the logic required)
>> > >
>> > > Most shops already have a more or less sophisticated (security wise)
>> > program to issue a WTO. Conditional JCL is free for the coding. Every
>> shop
>> > I've worked in uses the mechanism to manage production, including my
>> > current one. There is as Brian says no way to handle a JCL error
>> without an
>> > external 'product'.
>> > >
>> > > --
>> > > 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
>> >
>>
>>
>> --
>> sas
>>
>> --
>> 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
>
-- 
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

Re: WTO message at the end of JCL

[scott Ford]

Many concepts re-surface Steve.

On Mon, Nov 4, 2019 at 10:02 PM Steve Smith  wrote:

> This sure sounds like a discussion from the 1980s.  Operators? Consoles?
> Those are still a thing?
>
> Try out the new // NOTIFY statement, and send an email to whoever needs to
> wake up.
>
> sas
>
>
> On Mon, Nov 4, 2019 at 8:37 PM CM Poncelet  wrote:
>
> > The COND=EVEN/ONLY will not work if the job hits a *JCL error*. 
> >
> >
> > On 04/11/2019 23:56, Charles Mills wrote:
> > > It would be nice if there were a way to get the condition codes into
> the
> > WTO program, something like (don't try this at home):
> > >
> > > //WTO1 EXEC PGM=WTO,COND=EVEN,
> > > //  PARM='Job FOOBAR terminating. Highest CC was &MAXCC'
> > >
> > > I seem to recall a discussion here about retrieving the last and
> maximum
> > job CC's from within a program running as a jobstep and the answer was
> that
> > there was no good way.
> > >
> > > Charles
> > >
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jesse 1 Robinson
> > > Sent: Monday, November 4, 2019 1:01 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: WTO message at the end of JCL
> > >
> > > MVS has provided such a mechanism forever using
> > >
> > > 1. a program that issues a WTO
> > >
> > > 2. conditional execution on the WTO step with COND=EVEN or ONLY
> > (depending on the logic required)
> > >
> > > Most shops already have a more or less sophisticated (security wise)
> > program to issue a WTO. Conditional JCL is free for the coding. Every
> shop
> > I've worked in uses the mechanism to manage production, including my
> > current one. There is as Brian says no way to handle a JCL error without
> an
> > external 'product'.
> > >
> > > --
> > > 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
> >
>
>
> --
> sas
>
> --
> 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

Re: DFHSM/DCOLLECT QUESTION [EXTERNAL]

[Feller, Paul]

Here is what I see on one of my z/OS 2.2 systems (also saw the same information 
on a z/OS 2.3 system).  There is a section for RLSDATA as part of the CLUSTER 
information.

CLUSTER --- SYSD.HSM.ED.MCDS
  
 IN-CAT --- SYSUCAT.SYSTEM.ED   
  
 HISTORY
  
   DATASET-OWNER-(NULL) CREATION2017.064
  
   RELEASE2 EXPIRATION--.000
  
 SMSDATA
  
   STORAGECLASS ---STGADMIN MANAGEMENTCLASS---NOMGMT
  
   DATACLASS --DCLASSLE LBACKUP ---.000.
  
   CA-RECLAIM-(YES) 
  
   EATTR-(NULL) 
  
   BWO STATUS-- BWO TIMESTAMP---0 00:00:00.0
  
   BWO---(NULL) 
  
 RLSDATA
  
   LOG (NULL)   RECOVERY REQUIRED --(NO) FRLOG 
(NULL) 
   VSAM QUIESCED ---(NO)RLS IN USE -(NO) 
LOGREPLICATE-(NO)
   LOGSTREAMID-(NULL)   
  
   RECOVERY TIMESTAMP LOCAL-X'' 
  
   RECOVERY TIMESTAMP GMT---X'' 
  
   DATABASE -(NULL) 
  
 ENCRYPTIONDATA 
  
   DATA SET ENCRYPTION-(NO) 
  
 PROTECTION-PSWD-(NULL) RACF(NO)
  
 ASSOCIATIONS   
  
   DATA-SYSD.HSM.ED.MCDS.DATA   
  
   INDEXSYSD.HSM.ED.MCDS.INDEX  
  


Also you can do the command D SMS,CFLS to see if you are running RLS at all.  
If your display looks like the below example then you not doing RLS at all.

D SMS,CFLS 
IGW451I DFSMS SMSVSAM COMMAND REJECTED.
THE SMSVSAM SERVER ADDRESS SPACE IS NOT ACTIVE.


Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of esmie moo
Sent: Tuesday, November 05, 2019 5:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM/DCOLLECT QUESTION [EXTERNAL]

 I tried your suggestion but the RLS IN USE doesn't show on the LISTCAT.
On Monday, November 4, 2019, 01:36:16 p.m. GMT-5, Feller, Paul 
 wrote:  
 
 In the LISTCAT output look for "RLS IN USE", it should show YES or NO.

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of esmie moo
Sent: Monday, November 04, 2019 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFHSM/DCOLLECT QUESTION [EXTERNAL]

Gentle Readers,
     We receive a IEC161I 009-0663 (COND CODE 0008) everytime we execute a 
batch job which uses DCOLLECT:   The error occurs while reading the MCDS.
I checked the IBM documentation and I got more confused.  I found this tidbit 
of info:

This is a known condition when running IDCAMS DCOLLECT against DFSMShsm CDS

which are not in RLS mode. ARCUTIL first tries to open the CDS in RLS mode, so 
the IEC161I RC009 is issued when this fails. HSM then opens the CDS in NON RLS 
mode. This is described in DFSMShsm Implementation and Customization Guide, 
Chapter " User Application Interfaces", under Choosing a Data Collection 
Method. Customers whose HSM CDS are not in RLS mode may ignore this condition.
   I am not sure how verify if the CDS is "... are not in RLS mode."
I looked at the LISTCAT and it shows that the SHROPTIONS parm is set at 
SHROPTNS(3,3) 

Could somebody help me understand this?
Thanks.




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

--
Please note:  This message originated outside your organization. Please use 
caution when opening l

Re: WTO message at the end of JCL

[Michael Babcock]

If the OP is running z/OS 2.3 then JES2 can send email about job completion
using the new  NOTIFY EMAIL= parameter on the jobcard.

On Tue, Nov 5, 2019 at 12:28 AM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> Of course there is a way, all you need to do is process the SCT from your
> program.  You will get all steps up to the one you are currently in only
> because it has not ended yet.  But if you are running as the last step it
> wouldn't matter.  That's not how I do it in SyzMPF/z, but it "could" be
> done that way in another step of the job.  In fact, I think there are
> programs on the CBT tape that do just that.
>
> Brian
>
> --
> 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

Re: DFHSM/DCOLLECT QUESTION [EXTERNAL]

[esmie moo]

 I tried your suggestion but the RLS IN USE doesn't show on the LISTCAT.
On Monday, November 4, 2019, 01:36:16 p.m. GMT-5, Feller, Paul 
 wrote:  
 
 In the LISTCAT output look for "RLS IN USE", it should show YES or NO.

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of esmie moo
Sent: Monday, November 04, 2019 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFHSM/DCOLLECT QUESTION [EXTERNAL]

Gentle Readers,
     We receive a IEC161I 009-0663 (COND CODE 0008) everytime we execute a 
batch job which uses DCOLLECT:   The error occurs while reading the MCDS.
I checked the IBM documentation and I got more confused.  I found this tidbit 
of info:

This is a known condition when running IDCAMS DCOLLECT against DFSMShsm CDS

which are not in RLS mode. ARCUTIL first tries to open the CDS in RLS mode, so 
the IEC161I RC009 is issued when this fails. HSM then opens the CDS in NON RLS 
mode. This is described in DFSMShsm Implementation and Customization Guide, 
Chapter " User Application Interfaces", under Choosing a Data Collection 
Method. Customers whose HSM CDS are not in RLS mode may ignore this condition.
   I am not sure how verify if the CDS is "... are not in RLS mode."
I looked at the LISTCAT and it shows that the SHROPTIONS parm is set at 
SHROPTNS(3,3) 

Could somebody help me understand this?
Thanks.




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

--
Please note:  This message originated outside your organization. Please use 
caution when opening links or attachments.

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

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

Re: DFHSM/DCOLLECT QUESTION [EXTERNAL]

[John Dawes]

 Paul,
Thanks for your suggestion.  I ran the LISTCAT but there is no RLS IN USE 
displayed.

On Monday, 4 November 2019, 06:36:16 pm UTC, Feller, Paul 
 wrote:  
 
 In the LISTCAT output look for "RLS IN USE", it should show YES or NO.

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of esmie moo
Sent: Monday, November 04, 2019 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFHSM/DCOLLECT QUESTION [EXTERNAL]

Gentle Readers,
     We receive a IEC161I 009-0663 (COND CODE 0008) everytime we execute a 
batch job which uses DCOLLECT:   The error occurs while reading the MCDS.
I checked the IBM documentation and I got more confused.  I found this tidbit 
of info:

This is a known condition when running IDCAMS DCOLLECT against DFSMShsm CDS

which are not in RLS mode. ARCUTIL first tries to open the CDS in RLS mode, so 
the IEC161I RC009 is issued when this fails. HSM then opens the CDS in NON RLS 
mode. This is described in DFSMShsm Implementation and Customization Guide, 
Chapter " User Application Interfaces", under Choosing a Data Collection 
Method. Customers whose HSM CDS are not in RLS mode may ignore this condition.
   I am not sure how verify if the CDS is "... are not in RLS mode."
I looked at the LISTCAT and it shows that the SHROPTIONS parm is set at 
SHROPTNS(3,3) 

Could somebody help me understand this?
Thanks.




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

--
Please note:  This message originated outside your organization. Please use 
caution when opening links or attachments.

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