RCNVTCAT and SCNVTCAT enhanced

[Sam Golob]

Hi Folks,

If you are making a new master catalog and want to catalog all of 
the old master catalog's entries in it, the RCNVTCAT or SCNVTCAT REXX 
execs are the thing for you.  (CBT File 542 on the UPDATES page of 
www.cbttape.org).  Same goes for other catalog contents, when you want 
to catalog the entries into another catalog.  To generate a pds with all 
the necessary DEFINE statements (or most of them), you just have to say:


TSO RCNVTCAT 'catalog.name'

and everything is generated for you.  But if you want to put these 
generated entries into a new catalog, you would have had to make a 
global change to all the CATALOG( ) statements generated in the pds, to 
direct the entries to the new catalog instead of the old one.  Better to 
do it automatically, so we thought.


So we enhanced (we being Lionel Dyck, John McKown and me) RCNVTCAT 
and SCNVTCAT (which also runs under UNIX) to add a TARGET keyword to 
point to a new catalog name.  So a new syntax can now be:


TSO RCNVTCAT 'catalog.name' TARGET(my.new.catalog.name)

and this will put the string 'my.new.catalog.name' into all the 
generated CATALOG( ) statements.


RCNVTCAT can also be used to compare two catalogs, but we're not 
discussing that now.  Look at the exec to see how that works.  SCNVTCAT 
(in CBT File 542) was enhanced similarly.


So see CBT File 542 on the UPDATES page of www.cbttape.org for the 
new execs RCNVTCAT and SCNVTCAT, including the TARGET( ) keyword.


Use them in good health!!!

Sincerely,   Sam

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

Re: z/VM customer who moved from HDS to IBM storage (preferably DS8884)

[Mike Schwab]

And if you can get a volume offline you can use z/VMs own command to
move it with the rest of the system up.

On Wed, Nov 16, 2016 at 8:17 PM, Mike Schwab  wrote:
> Of course, the z/VM was done with the system down.  About 1/2 TB in a
> 2 hour window.
>
> On Wed, Nov 16, 2016 at 8:16 PM, Mike Schwab  wrote:
>> I have used TDMF, FDRPAS, and EMC z/OS Migrator.  Different way of
>> doing the same thing.  They all got the job done.  30TB in a few
>> weekdays.  Ask for an expert to remote assist or on site assist for 1
>> week.
>>
>> On Wed, Nov 16, 2016 at 2:01 AM, Arye Shemer  wrote:
>>> I need a reference of z/VM customer who moved from HDS to IBM storage
>>> (preferably DS8884) and she/he willing to share their experience.
>>>
>>> I would like to know what method of copy has been use,
>>> and some details about the capacity and the time duration of the migrated
>>> data.
>>>
>>> If giving name is a problem,
>>>  I would be glad to get just the information about the experience of the
>>>  migration process.
>>>
>>> Thank you very much,
>>>
>>> Arye Shemer.
>>>
>>> --
>>> 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?
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?



-- 
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: z/VM customer who moved from HDS to IBM storage (preferably DS8884)

[Mike Schwab]

Of course, the z/VM was done with the system down.  About 1/2 TB in a
2 hour window.

On Wed, Nov 16, 2016 at 8:16 PM, Mike Schwab  wrote:
> I have used TDMF, FDRPAS, and EMC z/OS Migrator.  Different way of
> doing the same thing.  They all got the job done.  30TB in a few
> weekdays.  Ask for an expert to remote assist or on site assist for 1
> week.
>
> On Wed, Nov 16, 2016 at 2:01 AM, Arye Shemer  wrote:
>> I need a reference of z/VM customer who moved from HDS to IBM storage
>> (preferably DS8884) and she/he willing to share their experience.
>>
>> I would like to know what method of copy has been use,
>> and some details about the capacity and the time duration of the migrated
>> data.
>>
>> If giving name is a problem,
>>  I would be glad to get just the information about the experience of the
>>  migration process.
>>
>> Thank you very much,
>>
>> Arye Shemer.
>>
>> --
>> 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?



-- 
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: z/VM customer who moved from HDS to IBM storage (preferably DS8884)

[Mike Schwab]

I have used TDMF, FDRPAS, and EMC z/OS Migrator.  Different way of
doing the same thing.  They all got the job done.  30TB in a few
weekdays.  Ask for an expert to remote assist or on site assist for 1
week.

On Wed, Nov 16, 2016 at 2:01 AM, Arye Shemer  wrote:
> I need a reference of z/VM customer who moved from HDS to IBM storage
> (preferably DS8884) and she/he willing to share their experience.
>
> I would like to know what method of copy has been use,
> and some details about the capacity and the time duration of the migrated
> data.
>
> If giving name is a problem,
>  I would be glad to get just the information about the experience of the
>  migration process.
>
> Thank you very much,
>
> Arye Shemer.
>
> --
> 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

SMP/E and IEBUPDTE

[Paul Gilmartin]

On Wed, 16 Nov 2016 19:29:47 -0600, Edward Gould wrote:

>> On Nov 16, 2016, at 12:28 PM, Paul Gilmartin wrote:
>> 
>> How is this still a thing!?
>> 
>> What's a "utility"?  IEBGENER and IEBCOPY and Rexx support VB.  I'd
>> substitute "not all" for "no”.
>IBM won’t re-open the code for IEBUPDTE its stabilized. Plus it was never 
>designed for VB records.
>IBM didn’t want to reship the entire member (IEBCOPY) .
>This was design issue (architect) of IBM’s 
>This has been an issue since day 1 of SMP. IBM its in your corner.
>
And:
o SMP/E has ++MACUPD and ++SRCUPD but no facility to UPDate general
  text files, even FB 80.
o I don't believe PTFS using IEBUPDTE can be RESTORED.

But now that z/OS has UNIX System Services, there's patch(1) which has
no FB 80 limitation and has an option to undo a patch.  No need to
re-open IEBUPDTE when there's a better featured alternative available.

-- gil

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

Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Edward Gould]

> On Nov 16, 2016, at 12:28 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Wed, 16 Nov 2016 11:12:53 -0600, Edward Gould wrote:
>> 
>> I think smp (NOTE without the e) was the problem a long time ago.
>> There was a gotcha in that IEBUPDTE does *NOT* support VB records.
>> IBM needed to support VB but their utilities did NOT.
>> IBM then forced the issue of changing clists to FB. BUT by then everyone was 
>> using VB.
>> Even today there is no IBM system utility that supports VB, and IBM 
>> continues to send out FB clists.
>> 
> How is this still a thing!?
> 
> What's a "utility"?  IEBGENER and IEBCOPY and Rexx support VB.  I'd
> substitute "not all" for "no”.
IBM won’t re-open the code for IEBUPDTE its stabilized. Plus it was never 
designed for VB records.
IBM didn’t want to reship the entire member (IEBCOPY) .
This was design issue (architect) of IBM’s 
This has been an issue since day 1 of SMP. IBM its in your corner.

> 
> I'll try to deconstruct this.  255 was the largest record that could be 
> extracted from
> a buffer with the IC; BCTR; EX; MVC cliche. IC can't handle more than 255 and
> LH is undesirable because the RDW might be unaligned, resulting in a 
> specification
> exception.  3120 is probably optimum for some model DASD.
> 
> To Ed J. I'll suggest Postel's law.  Deal with anything the user presents you 
> in
> an existing data set up to 32756.  For a new data set if it's your choice, 
> 255.
> 3120?  SDB?
TSO has been stabalized and won’t (can’t) fix it . Yell at IBM.

> 
> Puzzle:  What's the smallest BLKSIZE that SDB will select for a blocked data
> set on a 3390?  I have an empirical answer, but someone else might find
> a smaller one.
> 
>> There could be a solution that IBM would support VB/FB concatenation.
>> 
> To me, it would be a boon if Rexx supported PDS/UNIX concatenation.
> It usually works, but since it's "unsupported" I can't seek relief in the
> instances when it doesn't.  It's a nuisance to copy EXECs back and
> forth when I use them in both environments.
> 
>> There are several obstacles to doing this and IBM doesn’t (IMO) want to 
>> spend the time to do so.
>> 
> BSAM/QSAM can treat a UNIX file as either VB or FB according to the
> allocation options.
> 
> And SMP/E (but not IEBUPDTE) can deal with VB with GIMDTS.
> 
> And IBM is offering me a fixtest for a problem I reported for the SDSF
> Rexx interface's failing for a SYSIN with RECFM=VB,LRECL=32753.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: TCP/IP SSL trace help please xposted to IBMMAIN

[Nims,Alva John (Al)]

What was figured out?  I have not been able to run my SMPe receive service job 
this month either, worked last month, but I am not getting an SSL error:

IBM FTP CS V1R13
FTP: EXIT has been set.
Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
220-IBM's internal systems must only be used for conducting IBM's
220-business or for purposes authorized by IBM management.
220-
220-Use is subject to audit at any time by IBM management.
220-
220-
220-dhebpcb01 secure FTP server
220  ready.
>>> AUTH TLS
234 TLSv1
Authentication negotiation succeeded
>>> PBSZ 0
200 PBSZ=0
>>> PROT P
200 Command PROT okay.
Data connection protection is private
NAME (deliverycb-bld.dhe.ibm.com:AJNIMS2):

> 
>>> USER  
331 Password required for .
PASSWORD:

> 
>>> PASS
230 virtual user  logged in from /128.227.128.75:29260.
Command:
> CCC
> BINARY
> QUIT

GIM69233I FTP FAILED, ATTEMPT 01 OF 10. FTP WILL BE RETRIED IN 60 SECONDS.

It repeats 10 times and then SMPe fails it with:
GIM22800S ** REPLY FROM THE FTP SERVER AT deliverycb-bld.dhe.ibm.com WAS NOT
 RECEIVED AFTER 10 ATTEMPTS.

No JOB log messages.

I am attempting to get my IBMLINK setup, but both the UFL persons that need to 
approve it, HAVE RETIRED! :)

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ward, Mike S
Sent: Wednesday, November 16, 2016 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TCP/IP SSL trace help please xposted to IBMMAIN

Thanks for replying. We had to use the smpe batch job name it finally worked.  
Donald J. on IBMMAIN  figured it out. 

Thanks all.

-Original Message-
From: IBM TCP/IP List [mailto:ibmtc...@vm.marist.edu] On Behalf Of VANDER 
WOUDE, PETER
Sent: Wednesday, November 16, 2016 1:30 PM
To: ibmtc...@vm.marist.edu
Subject: Re: [IBMTCP-L] TCP/IP SSL trace help please xposted to IBMMAIN

Mike,

Add the following to the ftp step.

PARM='ENVAR("GSK_TRACE=0x")/'

Then after running the job, go into USS and you will see a file that starts 
with gskssl.x.trc (where x is numbers)

Run the command

Gsktrace /tmp/gskssl.x.trc > ssltrace.txt

The ssltrace.txt file will the the ssl trace so you can see the tls exchange.

Regards,
Peter Vander Woude
Systems Administrator IV
Work: 704-844-4331
Fax: 704-844-3266
701 Crestdale Rd.
Matthews, NC 28105





-Original Message-
From: IBM TCP/IP List [mailto:ibmtc...@vm.marist.edu] On Behalf Of Ward, Mike S
Sent: Wednesday, November 16, 2016 2:19 PM
To: ibmtc...@vm.marist.edu
Subject: TCP/IP SSL trace help please xposted to IBMMAIN

Hello all, we are having a little FTPS problem. As you can see below we are 
getting: EZA1735I Std Return Code = 10234, Error Code = 00017 We are using the 
smpe secure procedure. We did this last month and it worked fine now we are 
getting the above error.

We are trying to get an SSL trace of the problem, but we can't seem to get it 
to work. Below are the commands that we are using to start the SSL trace.
After we run the job and stop the trace the dataset we use on GSKWTR is empty. 
Can someone help us with the GSK trace? Oh the jobename of the FTP started task 
is FTPD1. We have also tried tracing the TCPIP task same results.

Thanks

S GSKSRVR
TRACE CT,WTRSTART=GSKWTR
TRACE CT,ON,COMP=GSKSRVR
R n,JOBNAME=(yyy),OPTIONS=(LEVEL=255),WTR=GSKWTR,END where yyy is the name of 
STC.

SMPE FTP JOB

TRACE CT,OFF,COMP=GSKSRVR
TRACE CT,WTRSTOP=GSKWTR
get into IPCS
update 0 DEFAULTS - Specify default dump and options with GSKWTR produced




> /bin/ftp -e -v -f "//'SSF1.SMPE.JCL(FTPDATA)'"
> deliverycb-bld.dhe.ibm.com

EZY2640I Using 'SSF1.SMPE.JCL(FTPDATA)' for local site configuration parameters.

EZYFT25I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
co ntrol connection.
EZYFT31I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
da ta connection.
EZA1450I IBM FTP CS V1R13
EZA1772I FTP: EXIT has been set.
EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
EZA1554I Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
220-IBM's internal systems must only be used for conducting IBM's 220-business 
or for purposes authorized by IBM management.
220-
220-dhebpcb01 secure FTP server
220  ready.
EZA1701I >>> AUTH TLS
234 TLSv1
EZA2897I Authentication negotiation failed EZA2898I Unable to successfully 
negotiate required authentication EZA1735I Std Return Code = 10234, Error Code 
= 00017

EZA2897I Authentication negotiation failed EZA2898I Unable to successfully 
negotiate required authentication


SSF1.SMPE.JCL(FTPDATA) contains the below.

SECURE_MECHANISM TLS
TLSRFCLEVEL CCCNONOTIFY
TLSMECHANISM FTP
SECURE_FTP REQUIRED
SECURE_CTRLCONN CLEAR ; COMMANDS MAY BE CLEAR (UNENCRYPTED).
SECURE_DATACONN PRIVATE ; PAYLOAD MUST BE ENCRYPTED.
KEYRING S250SAC/IBMSHOPZ
EPSV4 TRUE

Re: TCP/IP SSL trace help please xposted to IBMMAIN

[Ward, Mike S]

Thanks for replying. We had to use the smpe batch job name it finally worked.  
Donald J. on IBMMAIN  figured it out.

Thanks all.

-Original Message-
From: IBM TCP/IP List [mailto:ibmtc...@vm.marist.edu] On Behalf Of VANDER 
WOUDE, PETER
Sent: Wednesday, November 16, 2016 1:30 PM
To: ibmtc...@vm.marist.edu
Subject: Re: [IBMTCP-L] TCP/IP SSL trace help please xposted to IBMMAIN

Mike,

Add the following to the ftp step.

PARM='ENVAR("GSK_TRACE=0x")/'

Then after running the job, go into USS and you will see a file that starts 
with gskssl.x.trc (where x is numbers)

Run the command

Gsktrace /tmp/gskssl.x.trc > ssltrace.txt

The ssltrace.txt file will the the ssl trace so you can see the tls exchange.

Regards,
Peter Vander Woude
Systems Administrator IV
Work: 704-844-4331
Fax: 704-844-3266
701 Crestdale Rd.
Matthews, NC 28105





-Original Message-
From: IBM TCP/IP List [mailto:ibmtc...@vm.marist.edu] On Behalf Of Ward, Mike S
Sent: Wednesday, November 16, 2016 2:19 PM
To: ibmtc...@vm.marist.edu
Subject: TCP/IP SSL trace help please xposted to IBMMAIN

Hello all, we are having a little FTPS problem. As you can see below we are 
getting: EZA1735I Std Return Code = 10234, Error Code = 00017 We are using the 
smpe secure procedure. We did this last month and it worked fine now we are 
getting the above error.

We are trying to get an SSL trace of the problem, but we can't seem to get it 
to work. Below are the commands that we are using to start the SSL trace.
After we run the job and stop the trace the dataset we use on GSKWTR is empty. 
Can someone help us with the GSK trace? Oh the jobename of the FTP started task 
is FTPD1. We have also tried tracing the TCPIP task same results.

Thanks

S GSKSRVR
TRACE CT,WTRSTART=GSKWTR
TRACE CT,ON,COMP=GSKSRVR
R n,JOBNAME=(yyy),OPTIONS=(LEVEL=255),WTR=GSKWTR,END where yyy is the name of 
STC.

SMPE FTP JOB

TRACE CT,OFF,COMP=GSKSRVR
TRACE CT,WTRSTOP=GSKWTR
get into IPCS
update 0 DEFAULTS - Specify default dump and options with GSKWTR produced




> /bin/ftp -e -v -f "//'SSF1.SMPE.JCL(FTPDATA)'"
> deliverycb-bld.dhe.ibm.com

EZY2640I Using 'SSF1.SMPE.JCL(FTPDATA)' for local site configuration parameters.

EZYFT25I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
co ntrol connection.
EZYFT31I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
da ta connection.
EZA1450I IBM FTP CS V1R13
EZA1772I FTP: EXIT has been set.
EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
EZA1554I Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
220-IBM's internal systems must only be used for conducting IBM's 220-business 
or for purposes authorized by IBM management.
220-
220-dhebpcb01 secure FTP server
220  ready.
EZA1701I >>> AUTH TLS
234 TLSv1
EZA2897I Authentication negotiation failed EZA2898I Unable to successfully 
negotiate required authentication EZA1735I Std Return Code = 10234, Error Code 
= 00017

EZA2897I Authentication negotiation failed EZA2898I Unable to successfully 
negotiate required authentication


SSF1.SMPE.JCL(FTPDATA) contains the below.

SECURE_MECHANISM TLS
TLSRFCLEVEL CCCNONOTIFY
TLSMECHANISM FTP
SECURE_FTP REQUIRED
SECURE_CTRLCONN CLEAR ; COMMANDS MAY BE CLEAR (UNENCRYPTED).
SECURE_DATACONN PRIVATE ; PAYLOAD MUST BE ENCRYPTED.
KEYRING S250SAC/IBMSHOPZ
EPSV4 TRUE

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

--
For IBMTCP-L subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO IBMTCP-L



CONFIDENTIALITY NOTICE: This e-mail message and all attachments may contain 
legally privileged and confidential information intended solely for the use of 
the addressee. If the reader of this message is not the intended recipient, any 
reading, dissemination, distribution, copying, or other use of this message or 
its attachments is prohibited. If you have received this communication in 
error, please notify the sender immediately by telephone at 704.844.3100 and 
delete this message and all copies and backups thereof. Thank you.

Re: TCP/IP SSL trace help please xposted to IBMMAIN

[Donald J.]

try tracing the batch job name.
your job is a client which does not use your ftp server,
it uses the ibm smp ftp server.

-- 
  Donald J.
  dona...@4email.net

On Wed, Nov 16, 2016, at 11:19 AM, Ward, Mike S wrote:
> Hello all, we are having a little FTPS problem. As you can see below we are 
> getting: EZA1735I Std Return Code = 10234, Error Code = 00017
> We are using the smpe secure procedure. We did this last month and it worked 
> fine now we are getting the above error.
> We are trying to get an SSL trace of the problem, but we can't seem to get it 
> to work. Below are the commands that we are using to start the SSL trace.
> After we run the job and stop the trace the dataset we use on GSKWTR is 
> empty. Can someone help us with the GSK trace? Oh the jobename of the FTP 
> started task is FTPD1. We have also tried tracing the TCPIP task same results.
> 
> Thanks
> 
> S GSKSRVR
> TRACE CT,WTRSTART=GSKWTR
> TRACE CT,ON,COMP=GSKSRVR
> R n,JOBNAME=(yyy),OPTIONS=(LEVEL=255),WTR=GSKWTR,END where yyy is the
> name of STC.
> 
> SMPE FTP JOB
> 
> TRACE CT,OFF,COMP=GSKSRVR
> TRACE CT,WTRSTOP=GSKWTR
> get into IPCS
> update 0 DEFAULTS - Specify default dump and options with GSKWTR produced
> 
> 
> 
> 
> > /bin/ftp -e -v -f "//'SSF1.SMPE.JCL(FTPDATA)'" deliverycb-bld.dhe.ibm.com
> 
> EZY2640I Using 'SSF1.SMPE.JCL(FTPDATA)' for local site configuration 
> parameters.
> 
> EZYFT25I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
> co
> ntrol connection.
> EZYFT31I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
> da
> ta connection.
> EZA1450I IBM FTP CS V1R13
> EZA1772I FTP: EXIT has been set.
> EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
> EZA1554I Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
> 220-IBM's internal systems must only be used for conducting IBM's
> 220-business or for purposes authorized by IBM management.
> 220-
> 220-dhebpcb01 secure FTP server
> 220  ready.
> EZA1701I >>> AUTH TLS
> 234 TLSv1
> EZA2897I Authentication negotiation failed
> EZA2898I Unable to successfully negotiate required authentication
> EZA1735I Std Return Code = 10234, Error Code = 00017
> 
> EZA2897I Authentication negotiation failed
> EZA2898I Unable to successfully negotiate required authentication
> 
> 
> SSF1.SMPE.JCL(FTPDATA) contains the below.
> 
> SECURE_MECHANISM TLS
> TLSRFCLEVEL CCCNONOTIFY
> TLSMECHANISM FTP
> SECURE_FTP REQUIRED
> SECURE_CTRLCONN CLEAR ; COMMANDS MAY BE CLEAR (UNENCRYPTED).
> SECURE_DATACONN PRIVATE ; PAYLOAD MUST BE ENCRYPTED.
> KEYRING S250SAC/IBMSHOPZ
> EPSV4 TRUE
> 
> ==
> This email, and any files transmitted with it, is confidential and intended 
> solely for the use of the individual or entity to which it is addressed. If 
> you have received this email in error, please notify the system manager. This 
> message contains confidential information and is intended only for the 
> individual named. If you are not the named addressee, you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately by e-mail if you have received this message by mistake and delete 
> this e-mail from your system. If you are not the intended recipient, you are 
> notified that disclosing, copying, distributing or taking any action in 
> reliance on the contents of this information is strictly prohibited.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

-- 
http://www.fastmail.com - Access your email from home and the web

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

TCP/IP SSL trace help please xposted to IBMMAIN

[Ward, Mike S]

Hello all, we are having a little FTPS problem. As you can see below we are 
getting: EZA1735I Std Return Code = 10234, Error Code = 00017
We are using the smpe secure procedure. We did this last month and it worked 
fine now we are getting the above error.
We are trying to get an SSL trace of the problem, but we can't seem to get it 
to work. Below are the commands that we are using to start the SSL trace.
After we run the job and stop the trace the dataset we use on GSKWTR is empty. 
Can someone help us with the GSK trace? Oh the jobename of the FTP started task 
is FTPD1. We have also tried tracing the TCPIP task same results.

Thanks

S GSKSRVR
TRACE CT,WTRSTART=GSKWTR
TRACE CT,ON,COMP=GSKSRVR
R n,JOBNAME=(yyy),OPTIONS=(LEVEL=255),WTR=GSKWTR,END where yyy is the
name of STC.

SMPE FTP JOB

TRACE CT,OFF,COMP=GSKSRVR
TRACE CT,WTRSTOP=GSKWTR
get into IPCS
update 0 DEFAULTS - Specify default dump and options with GSKWTR produced




> /bin/ftp -e -v -f "//'SSF1.SMPE.JCL(FTPDATA)'" deliverycb-bld.dhe.ibm.com

EZY2640I Using 'SSF1.SMPE.JCL(FTPDATA)' for local site configuration parameters.

EZYFT25I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the co
ntrol connection.
EZYFT31I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the da
ta connection.
EZA1450I IBM FTP CS V1R13
EZA1772I FTP: EXIT has been set.
EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
EZA1554I Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
220-IBM's internal systems must only be used for conducting IBM's
220-business or for purposes authorized by IBM management.
220-
220-dhebpcb01 secure FTP server
220  ready.
EZA1701I >>> AUTH TLS
234 TLSv1
EZA2897I Authentication negotiation failed
EZA2898I Unable to successfully negotiate required authentication
EZA1735I Std Return Code = 10234, Error Code = 00017

EZA2897I Authentication negotiation failed
EZA2898I Unable to successfully negotiate required authentication


SSF1.SMPE.JCL(FTPDATA) contains the below.

SECURE_MECHANISM TLS
TLSRFCLEVEL CCCNONOTIFY
TLSMECHANISM FTP
SECURE_FTP REQUIRED
SECURE_CTRLCONN CLEAR ; COMMANDS MAY BE CLEAR (UNENCRYPTED).
SECURE_DATACONN PRIVATE ; PAYLOAD MUST BE ENCRYPTED.
KEYRING S250SAC/IBMSHOPZ
EPSV4 TRUE

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Paul Gilmartin]

On Wed, 16 Nov 2016 11:12:53 -0600, Edward Gould wrote:
>
>I think smp (NOTE without the e) was the problem a long time ago.
>There was a gotcha in that IEBUPDTE does *NOT* support VB records.
>IBM needed to support VB but their utilities did NOT.
>IBM then forced the issue of changing clists to FB. BUT by then everyone was 
>using VB.
>Even today there is no IBM system utility that supports VB, and IBM continues 
>to send out FB clists.
> 
How is this still a thing!?

What's a "utility"?  IEBGENER and IEBCOPY and Rexx support VB.  I'd
substitute "not all" for "no".

I'll try to deconstruct this.  255 was the largest record that could be 
extracted from
a buffer with the IC; BCTR; EX; MVC cliche. IC can't handle more than 255 and
LH is undesirable because the RDW might be unaligned, resulting in a 
specification
exception.  3120 is probably optimum for some model DASD.

To Ed J. I'll suggest Postel's law.  Deal with anything the user presents you in
an existing data set up to 32756.  For a new data set if it's your choice, 255.
3120?  SDB?

Puzzle:  What's the smallest BLKSIZE that SDB will select for a blocked data
set on a 3390?  I have an empirical answer, but someone else might find
a smaller one.

>There could be a solution that IBM would support VB/FB concatenation.
>
To me, it would be a boon if Rexx supported PDS/UNIX concatenation.
It usually works, but since it's "unsupported" I can't seek relief in the
instances when it doesn't.  It's a nuisance to copy EXECs back and
forth when I use them in both environments.

>There are several obstacles to doing this and IBM doesn’t (IMO) want to spend 
>the time to do so.
> 
BSAM/QSAM can treat a UNIX file as either VB or FB according to the
allocation options.

And SMP/E (but not IEBUPDTE) can deal with VB with GIMDTS.

And IBM is offering me a fixtest for a problem I reported for the SDSF
Rexx interface's failing for a SYSIN with RECFM=VB,LRECL=32753.

-- gil

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

Re: AW: Re: Real Storage Display

[Jim Mulder]

z Systems
Processor Resource/Systems Manager
Planning Guide
SB10-7162-01

  This is the relevant sentence: 

"In support of 2 GB large pages, first introduced on 
the zEC12 models, all logical partition origins and
limits must be on a 2 GB boundary. In other words, the 
addressing range assigned to the LP will start
and end on a 2 GB (2048MB) boundary."

 So if the Initial + Reserved storage in a partition's 
profile does not add up to 2 GB multiple, LPAR adds enough 
unassigned storage to the addressing range to make things 
add up to a 2 GB multiple. That does not mean that the 
granularity for assigning storage to a zone is 2 GB. 
The granularity remains as documented in the table in 
that book.  The unassigned part of the addressing range does
not use any real storage (because no real storage is
assigned to it).  If you subsequently configure that 
addressing range  online to the partition. LPAR assigns 
real storage, and now that real storage is unavailable to 
be assigned to other partitions. 
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY



> >I discussed this further with Jim Mulder. The z12, where I recently
>>noticed the 'unassigned' value, introduced 2 GB pages, one of whose 
>>consequences is that LPAR boundaries are rounded up as needed to the
>>nearest 2 GB boundary. If an image profile specifies any other 
>>value, the 'excess' is displayed as unassigned storage. It can be 
>>configured online to the owning LPAR but cannot be allocated to any 
>>other LPAR, hence 'unassigned'. As Jim and I talked, I recollected a
>>past conversation with a local CE to that effect. The LPAR in my 
>>display recently got 15 GB of storage added to it. The resulting odd
>>value left 1 GB unassigned. 
> 
> Well this was my first tought when I saw the stroage assigned was an
> odd number of GBs: Maybe the hardware assignes storage in 2GB 
> increments. This would explain the 1GB uassigned to align to the 
> next 2GB boundary.
> 
> I usually try to verify before posting, so I looked at the z13 
> Technical Guide redbook and found the table below (only parially 
> coied here). I read there that an LPAR having less than 256GB of 
> mainstorage (yours) will have a granularity of  512MB. Well, I 
> thougth, wrong trace, and did not post.
> 
> After your post, either I misinterpret the table in the redbook 
> (most probably) or the table is in error (not likely). So the table 
> must indicate the minimum amount of storage that can be varied 
> online or offline depending on the total amount of storage assigned. 
True?
> 
> Table 3-7
> Logical partition main storage granularity
> Logical partition: 
> Largest main storage amount.Main storage granularity
> 
---..
> Main storage amount 
> <= 256 GB ..512 MB
> 
> 256 GB < 
> main storage amount 
> <= 512 GB ..1 GB
> 
> 512 GB < 
> main storage amount 
> <= 1 TB 2 GB



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

Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Edward Gould]

> On Nov 16, 2016, at 10:12 AM, Mick Graley  wrote:
> 
> I think Ed might be right here on the SYSGEN option history, however TSO
> EDIT doesn't seem to support it fully these days.
> I have access to 5 very different systems each with different heritage.
> Two of them are >30 years old and will date back to the SYSGEN days, one of
> them I'm not sure of it's age, but the other two are much younger.
> All of them use an FB 80 SYSPROC concatenation except for one of the older
> systems which uses a VB 255 SYSPROC concatenation.
> TSO EDIT creates a VB,255,3120 data set for type CLIST on all the systems
> except for the older FB 80 system, which creates a corrupt FB,80,3120 data
> set. I'm guessing that the original SYSGEN option of FB was copied across
> for this system, but it doesn't look like TSO EDIT fully supports it as
> it's obviously still using variable length edit buffers, but writing full
> FB 80 byte records to the new PDS with the line numbers at the beginning of
> the record rather than in columns 72-80. Here is a transcript of a TSO
> session on the older FB system to demonstrate this:
> 
> READY
> listds temp.clist
> IKJ58503I DATA SET xx.TEMP.CLIST NOT IN CATALOG
> READY
> e temp(hello) cl
> IKJ52320I DATA SET OR MEMBER NOT FOUND, ASSUMED TO BE NEW
> INPUT
> 00010 proc 0
> 00020 write hello mick
> 00030 end
> 00040
> E
> l
> 00010 PROC 0
> 00020 WRITE HELLO MICK
> 00030 END
> IKJ52500I END OF DATA
> end save
—_SNIP
I think smp (NOTE without the e) was the problem a long time ago.
There was a gotcha in that IEBUPDTE does *NOT* support VB records.
IBM needed to support VB but their utilities did NOT.
IBM then forced the issue of changing clists to FB. BUT by then everyone was 
using VB.
Even today there is no IBM system utility that supports VB, and IBM continues 
to send out FB clists.

There could be a solution that IBM would support VB/FB concatenation.

There are several obstacles to doing this and IBM doesn’t (IMO) want to spend 
the time to do so.

Ed

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

Re: Real Storage Display

[Jesse 1 Robinson]

I don't pretend to understand how all this fits together, but there is indeed a 
difference between 'LPAR boundary' and Storage Increment Size (SIS). We have a 
z12 and a z13 with similar real storage totals. 

z12: Total storage 320 GB
 SIS 256M 

z13: Total storage 344 GB
  SIS 512M  

SIS seems to represent the z/OS minimum for LPAR definition and CF STOR 
commands. We discovered when setting up the z13--using Activation profiles 
copied across from a z196--that one LPAR defined as 768 MB was invalid on the 
z13 HMC. It had to be increased to 1 GB to be accepted in the Image profile. 
However, that same LPAR actually initialized with 1 GB extra of unassigned 
storage, a total of 2 GB. 

So SIS is the minimum amount that can be manipulated at the z/OS (LPAR?) level, 
while the hardware (PR/SM) boundary determines how storage is divvied up 
despite Image activation profile values.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Wednesday, November 16, 2016 7:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):AW: Re: Real Storage Display

 
>I discussed this further with Jim Mulder. The z12, where I recently noticed 
>the 'unassigned' value, introduced 2 GB pages, one of whose consequences is 
>that LPAR boundaries are rounded up as needed to the nearest 2 GB boundary. If 
>an image profile specifies any other value, the 'excess' is displayed as 
>unassigned storage. It can be configured online to the owning LPAR but cannot 
>be allocated to any other LPAR, hence 'unassigned'. As Jim and I talked, I 
>recollected a past conversation with a local CE to that effect. The LPAR in my 
>display recently got 15 GB of storage added to it. The resulting odd value 
>left 1 GB unassigned.  
 


Well this was my first tought when I saw the stroage assigned was an odd number 
of GBs: Maybe the hardware assignes storage in 2GB increments. This would 
explain the 1GB uassigned to align to the next 2GB boundary.


I usually try to verify before posting, so I looked at the z13 Technical Guide 
redbook and found the table below (only parially coied here). I read there that 
an LPAR having less than 256GB of mainstorage (yours) will have a granularity 
of  512MB. Well, I thougth, wrong trace, and did not post.


After your post, either I misinterpret the table in the redbook (most probably) 
or the table is in error (not likely). So the table must indicate the minimum 
amount of storage that can be varied online or offline depending on the total 
amount of storage assigned. True?




Table 3-7
Logical partition main storage granularity Logical partition: 
Largest main storage amount.Main storage granularity
---..
Main storage amount
<= 256 GB ..512 MB


256 GB < 
main storage amount 
<= 512 GB ..1 GB


512 GB < 
main storage amount 
<= 1 TB 2 GB




--
Peter Hunkeler

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

Re: Splitting a sysplex in two

[Al Sherkow]

There is potentially an IBM Software Pricing issue with splitting a sysplex.

IBM pricing, since parallel sysplex was introduced, has allowed machines to be 
aggregated together for pricing. There are some complicated rules and a red 
paper which describes the rules is available at 
. It is more than 10 
years old, but still applicable (unless you are using IBM's Country Multiplex 
Pricing in which case it doesn't matter). In brief, you need a "primary" 
sysplex using more than 50% of the CPU time on each machine during a user/site 
determined "prime shift". 

So if you have two machines aggregated today and after this split one is 
primarily PRODUCTION and the other is primarily DEVELOPMENT you won't be able 
to aggregate them. So you'll want to spread the larger of the sysplex across 
both machines. The same applies if you have more than two machines; spread your 
primary/larger sysplex across all the machines. 

Loosing aggregation is very expensive. However, you could start using  IBM's 
Country Multiplex Pricing (CMP) to avoid this problem. Again, in general, if 
your workload is growing overtime you should be OK. IF your workload is 
shrinking then CMP may not save you money, and could cost you money. Again, the 
rules are complicated. 

Al 

Al Sherkow, I/S Management Strategies, Ltd.
Consulting Expertise on IBM Workload License Charges (WLC) and LCS Software
Seminars on IBM Mainframe Software Pricing
+1 414 332-3062
www.sherkow.com

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

Re: z/OS Bug Busterz SHARE Academy in San Jose

[Steve Thompson]

I got to Atlanta in time for the second half (because of travel plans...). 

I took the class as an IPCS refresher. To me it was worth it. I'd forgotten a 
bunch of IPCS stuff. 

Not that my endorsement means anything, but I thought some public positive 
feedback would be good. 

Sent from my iPhone

> On Nov 16, 2016, at 10:51 AM, Ed Jaffe  wrote:
> 
> The z/OS Bug Busterz SHARE Academy in Atlanta was a tremendous success, but 
> there was room for more attendees.
> 
> Many folks complained to me throughout the week that they didn't hear about 
> this amazing, Sunday deep-dive intensive until _after_ their travel plans 
> were already made and asked if it could be offered again at a future SHARE 
> event.
> 
> Based on this demand, we've been given the go ahead to repeat this incredible 
> offering at SHARE in San Jose!
> 
> This time it's being announced well in advance, so people have adequate time 
> to register and plan their trips accordingly.
> 
> http://www.share.org/san-jose-academy-zos?utm_source=prospectiveattendee_content=academy
> 
> "Back by popular demand! The SHARE Academy z/OS Bug Busterz class is 
> presented by experienced z/OS Level 2 professionals and will provide you with 
> the skills to analyze and make sense of diagnostic data captured by z/OS. You 
> will gain the knowledge necessary to perform preliminary analysis of dumps 
> and trace data using IPCS, and learn how to capture information through 
> diagnostic tools, including GTF trace, CTRACE and SLIP. The class is designed 
> for z/OS Systems Programmers and Application Programmers that support 
> products running on z/OS, and will include a pre-event webcast. No prior IPCS 
> experience is required."
> 
> NOTE: There is great demand across the various SHARE Programs for Sunday 
> SHARE Academy deep-dive showcase placement, so it's unlikely we'll be 
> repeating z/OS Bug Busterz again after San Jose. If you or someone else at 
> your company wants to take advantage of this training, this is your chance!
> 
> 
> -- 
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Real Storage Display

[Jesse 1 Robinson]

While discussing this with a colleague, we discovered that a small utility LPAR 
on our new z13s had the same problem. Two additional issues to consider:

-- Larger real storage requires larger page tables to keep track of it. Someone 
might consider this wasteful to the point of keeping some unassigned storage 
offline. I personally can't see the advantage, but it might be a consideration 
for some. 

-- When sizing a new box for memory, consider that whatever an LPAR looks like 
on pre z12 hardware, for z12 onward no LPAR can be less than 2 GB. Hence a lot 
of small LPARs will occupy more real storage in total than the same set has in 
the past. Fortunately memory is way cheaper than it used to be. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barbara Nitz
Sent: Tuesday, November 15, 2016 11:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Real Storage Display

>I discussed this further with Jim Mulder. The z12, where I recently noticed 
>the 'unassigned' value, introduced 2 GB pages, one of whose consequences is 
>that LPAR boundaries are rounded up as needed to the nearest 2 GB boundary. If 
>an image profile specifies any other value, the 'excess' is displayed as 
>unassigned storage. It can be configured online to the owning LPAR but cannot 
>be allocated to any other LPAR, hence 'unassigned'. 

Thanks for sharing this, Skip. We are in the process of increasing real storage 
assigned to lpars now that we're on a z13, and sure enough, we had a number of 
odd storage assignments. That has been rectified now. :-)

Barbara


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

Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Mick Graley]

I think Ed might be right here on the SYSGEN option history, however TSO
EDIT doesn't seem to support it fully these days.
I have access to 5 very different systems each with different heritage.
Two of them are >30 years old and will date back to the SYSGEN days, one of
them I'm not sure of it's age, but the other two are much younger.
All of them use an FB 80 SYSPROC concatenation except for one of the older
systems which uses a VB 255 SYSPROC concatenation.
TSO EDIT creates a VB,255,3120 data set for type CLIST on all the systems
except for the older FB 80 system, which creates a corrupt FB,80,3120 data
set. I'm guessing that the original SYSGEN option of FB was copied across
for this system, but it doesn't look like TSO EDIT fully supports it as
it's obviously still using variable length edit buffers, but writing full
FB 80 byte records to the new PDS with the line numbers at the beginning of
the record rather than in columns 72-80. Here is a transcript of a TSO
session on the older FB system to demonstrate this:

 READY
listds temp.clist
 IKJ58503I DATA SET xx.TEMP.CLIST NOT IN CATALOG
 READY
e temp(hello) cl
 IKJ52320I DATA SET OR MEMBER NOT FOUND, ASSUMED TO BE NEW
 INPUT
 00010 proc 0
 00020 write hello mick
 00030 end
 00040
 E
l
 00010 PROC 0
 00020 WRITE HELLO MICK
 00030 END
 IKJ52500I END OF DATA
end save
 READY
listds temp.clist
 xx.TEMP.CLIST
 --RECFM-LRECL-BLKSIZE-DSORG
   FB803120PO
 --VOLUMES--
   vv
 READY
print inda(temp.clist(hello)) char

 RECORD SEQUENCE NUMBER - 1

 0010PROC 05...IBMOSVS2
..&&..QS
.

 RECORD SEQUENCE NUMBER - 2

 0020WRITE HELLO MICK..IBMOSVS2
..&&..QS
.

 RECORD SEQUENCE NUMBER - 3

 0030ENDTE HELLO MICK..IBMOSVS2
..&&..QS
.

 IDC0005I NUMBER OF RECORDS PROCESSED WAS 3

 READY

exec temp.clist(hello)

 0010PROC 05 -È--  IBMOSVS2ØØ -- °  - &   Ø&  -  -QS  -

 IKJ56545I THIS STATEMENT HAS AN INVALID SYMBOLIC VARIABLE

 READY



Same member shown in ISPF/PDF browse:
0010PROC 05..È. ..IBMOSVS2
...ØØ°&...Ø&..QS.
0020WRITE HELLO MICK..IBMOSVS2
...ØØ°&...Ø&..QS.
0030ENDTE HELLO MICK..IBMOSVS2
...ØØ°&...Ø&..QS.


As you would expect, editing a new member in an existing FB 80 CLIST data
set works fine and puts the line numbers in the right place.

Interesting stuff!

Cheers,

Mick.


On 16 November 2016 at 04:38, Edward Gould  wrote:

> > On Nov 15, 2016, at 1:16 PM, Dyck, Lionel B. (TRA) 
> wrote:
> >
> > I'm in the 255 camp and just tried a simple experiment.
> >
> > From TSO issue the Edit command:  E T(ABC) CL
> >
> > This opens the old editor on dataset t.clist member abc and after adding
> a few records and saving I checked the dcb which was VB,255,3120
> >
> > Not the ideal blksize but the lrecl is what I expected.
> >
> > hth
> >
>
> Lionel:
>
> At least in mvs 3.8 there was a sysgen macro you could specify FB VB and
> lrecl blksize etc.
> Since system dissapeared I am not sure what the defaults are now days.
>
> Ed
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

AW: Re: Real Storage Display

[Peter Hunkeler]

>I discussed this further with Jim Mulder. The z12, where I recently noticed 
>the 'unassigned' value, introduced 2 GB pages, one of whose consequences is 
>that LPAR boundaries are rounded up as needed to the nearest 2 GB boundary. If 
>an image profile specifies any other value, the 'excess' is displayed as 
>unassigned storage. It can be configured online to the owning LPAR but cannot 
>be allocated to any other LPAR, hence 'unassigned'. As Jim and I talked, I 
>recollected a past conversation with a local CE to that effect. The LPAR in my 
>display recently got 15 GB of storage added to it. The resulting odd value 
>left 1 GB unassigned.



Well this was my first tought when I saw the stroage assigned was an odd number 
of GBs: Maybe the hardware assignes storage in 2GB increments. This would 
explain the 1GB uassigned to align to the next 2GB boundary.


I usually try to verify before posting, so I looked at the z13 Technical Guide 
redbook and found the table below (only parially coied here). I read there that 
an LPAR having less than 256GB of mainstorage (yours) will have a granularity 
of  512MB. Well, I thougth, wrong trace, and did not post.


After your post, either I misinterpret the table in the redbook (most probably) 
or the table is in error (not likely). So the table must indicate the minimum 
amount of storage that can be varied online or offline depending on the total 
amount of storage assigned. True?




Table 3-7
Logical partition main storage granularity
Logical partition:
Largest main storage amount.Main storage granularity
---..
Main storage amount
<= 256 GB ..512 MB


256 GB <
main storage amount
<= 512 GB ..1 GB


512 GB <
main storage amount
<= 1 TB 2 GB




--
Peter Hunkeler



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

z/OS Bug Busterz SHARE Academy in San Jose

[Ed Jaffe]

The z/OS Bug Busterz SHARE Academy in Atlanta was a tremendous success, 
but there was room for more attendees.


Many folks complained to me throughout the week that they didn't hear 
about this amazing, Sunday deep-dive intensive until _after_ their 
travel plans were already made and asked if it could be offered again at 
a future SHARE event.


Based on this demand, we've been given the go ahead to repeat this 
incredible offering at SHARE in San Jose!


This time it's being announced well in advance, so people have adequate 
time to register and plan their trips accordingly.


http://www.share.org/san-jose-academy-zos?utm_source=prospectiveattendee_content=academy

"Back by popular demand! The SHARE Academy z/OS Bug Busterz class is 
presented by experienced z/OS Level 2 professionals and will provide you 
with the skills to analyze and make sense of diagnostic data captured by 
z/OS. You will gain the knowledge necessary to perform preliminary 
analysis of dumps and trace data using IPCS, and learn how to capture 
information through diagnostic tools, including GTF trace, CTRACE and 
SLIP. The class is designed for z/OS Systems Programmers and Application 
Programmers that support products running on z/OS, and will include a 
pre-event webcast. No prior IPCS experience is required."


NOTE: There is great demand across the various SHARE Programs for Sunday 
SHARE Academy deep-dive showcase placement, so it's unlikely we'll be 
repeating z/OS Bug Busterz again after San Jose. If you or someone else 
at your company wants to take advantage of this training, this is your 
chance!



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

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

Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Bill Godfrey]

On 2016-11-15 12:16, Dyck, Lionel B. wrote:
> I'm in the 255 camp and just tried a simple experiment.
> 
> From TSO issue the Edit command:  E T(ABC) CL
> 
> This opens the old editor on dataset t.clist member abc and after adding a 
> few records and saving I checked the dcb which was VB,255,3120
> 
> Not the ideal blksize but the lrecl is what I expected.
>
In old TSO EDIT (alias E), 255 is not only the default lrecl for clist data 
sets, it's the maximum.

edit test1 clist new emode lrecl(256)
IKJ52335I INVALID LINE VALUE FOR CLIST, USING 255+
IKJ52335I LINE SIZE FOR CLIST MAY NOT EXCEED 255

edit test1 data new emode lrecl(256)
IKJ52335I INVALID LINE VALUE FOR DATA, USING 80+

IKJ52335I LINE SIZE FOR DATA MAY NOT EXCEED 255 

if PDS member test2.clist(a) exists and the PDS is VB with lrecl 256, EDIT 
can't handle it.
edit test2(a) clist
IKJ52336I 256 INVALID LINE VALUE FOR CLIST DATA SET

That might be the reason why, historically, clist data sets have used lrecl 255 
and not 259, even though they work as 259.

Bill

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

Re: LRECL=255 vs LRECL=259

[scott Ford]

Ed,
Lrecl=255 here

Scott

On Tuesday, November 15, 2016, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On 2016-11-15 12:16, Dyck, Lionel B. (TRA) wrote:
> > I'm in the 255 camp and just tried a simple experiment.
> >
> > From TSO issue the Edit command:  E T(ABC) CL
> >
> > This opens the old editor on dataset t.clist member abc and after adding
> a few records and saving I checked the dcb which was VB,255,3120
> >
> > Not the ideal blksize but the lrecl is what I expected.
> >
> It really should use SDB.  Please submit an RFE.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
>

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

z/VM customer who moved from HDS to IBM storage (preferably DS8884)

[Arye Shemer]

I need a reference of z/VM customer who moved from HDS to IBM storage
(preferably DS8884) and she/he willing to share their experience.

I would like to know what method of copy has been use,
and some details about the capacity and the time duration of the migrated
data.

If giving name is a problem,
 I would be glad to get just the information about the experience of the
 migration process.

Thank you very much,

Arye Shemer.

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