Re: Finding the names of hsm's BCDSs

[Manfred Lotz]

On Tue, 23 Jan 2018 14:11:35 -0600
DanD  wrote:

> Actually, if you check SHOWZOS it bounces through control blocks to
> locate the BCDS, MCDS, OCDS an JRNL.
> 

Well, yes and no. Currently, SHOWZOS is only able to find the first
BCDS and MCDS. In case of a multi CDS environment it won't show the
others.

To the author of  SHOWZOS: please correct me if I am wrong.

-- 
Manfred

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

Re: VSAM Performance - CPU reduction

[Ron hawkins]

Clark,

If you had time to read through this lengthy thread you will find that the
2nd file uses skip-sequential access. LSR is usually not an appropriate
strategy for this access pattern.

The OP has tried reducing BUFND on the second file, and observed a reduction
in throughput, which verifies the extent to which the sequential access is
taking advantage of chained Cis.

Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Tuesday, January 23, 2018 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] VSAM Performance - CPU reduction

[Default] On 5 Jan 2018 16:28:48 -0800, in bit.listserv.ibm-main
arun.venkatrat...@cognizant.com (Arun Venkatratnam) wrote:

>Hi All,
>
>We are looking to improve the performance of a COBOL program that processes
2 VSAM files. The first file is the I/P file and every record read from the
input VSAM file is searched for a matching record in the other file and a
report is written. The program also applies some business rules while
comparing each matching record.
>
>The I/P file is read sequentially while the other file is read in a skip
sequential basis. The test files that were used had 32M records each while
production files have 110M records each.

I assume using random access for the second file was tried with adequate
buffering for index and data. BLSR or the more current means of doing random
access buffering should have been used.  It may also help to save any
randomly read record that were read based on information in records from the
second file based on the match with a record from the first file.  Knowing
access patterns can help in determining the best solution.

Clark Morris 
>
>Attached is the strobe report from the execution of the test job. The test
job takes nearly 7 CPU minutes and was profiled to capture about 1 CPU
minute of execution time.
>
>We are attempting to optimize the VSAM access to these files as it is seen
to take more than 50% of the CPU consumed by this job.
>
>In the 'Attribution of CPU execution time' section, we see that the major
contributors are the components 'QSAM INIT I/O  & EXITS' (Module IGZEQBL)
and PARTITION COMMUNICATION. 
>
>Could you please help us understand:
>
>1.What these components are
>2.Why is QSAM access used instead of VSAM I/O access.
>3.What needs to be done to reduce the CPU consumption by these components.
>
>Thank you
>
>Arun
>
>
>---
>---
>
>
>1Strobe* PERFORMANCE PROFILE PROGRAMA
01/02/2018   PAGE  42 
>

>-  #ACE   ** ATTRIBUTION OF CPU EXECUTION
TIME **
>-.COBLIB  IGZCPCO  IGZEVIO   VSAM INPUT/OUTPUT

> ---WAS INVOKED BY-
-VIA---  CPU TIME %
> XACTION   MODULE   SECTION  DESCRIPTION   MODULE
SECTION  DESCRIPTION  SOLO  TOTAL
>

>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERM
.32   32
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL
QSAM INIT I/O  & EXITS1.93  1.93
>

> XACTION  MODULE   SECTION   LOCATION  LINE   SOURCE TEXT  MODULE
SECTION  DESCRIPTION 
>

>  PROGRAMA PROGRAMA   003522
1.30  1.30
>
- -
>
3.55  3.55
>-.VSAMIDA019L1   VSAM RECORD MANAGEMENT

> ---WAS INVOKED BY-
-VIA---CPU TIME %
> XACTION   MODULE   SECTION  DESCRIPTION   MODULE
SECTION  DESCRIPTION   SOLO  TOTAL
>

>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL
QSAM INIT I/O  & EXITS  1.84  1.84
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL
CURRMEM  QSAM INIT I/O  & EXITS   4.34  4.38
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL
DVFILE   QSAM INIT I/O  & EXITS.03   .03
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL
PREVMEM  QSAM INIT I/O  & EXITS  22.48 22.51
>

> XACTION  MODULE   SECTION   LOCATION  LINE   SOURCE TEXT  MODULE
SECTION  DESCRIPTION 
>

>  PROGRAMA PROGRAMA   003522   IGZCPCO
CURRMEM  PARTITION COMMUNICATION4.15  4.19
>  PROGRAMA PROGRAMA   003522   IGZCPCO
IGZEVIO  VSAM INPUT/OUTPUT   .57   .57
>  PROGRAMA PROGRAMA   003522   IGZCPCO
PREVMEM  PARTITION COMMUNICATION  16.80 16.80
>
- -
>

> 50.22 50.32
>
>--
>For IBM-MAIN subscribe / signoff / 

Re: VSAM Performance - CPU reduction

[Clark Morris]

[Default] On 5 Jan 2018 16:28:48 -0800, in bit.listserv.ibm-main
arun.venkatrat...@cognizant.com (Arun Venkatratnam) wrote:

>Hi All,
>
>We are looking to improve the performance of a COBOL program that processes 2 
>VSAM files. The first file is the I/P file and every record read from the 
>input VSAM file is searched for a matching record in the other file and a 
>report is written. The program also applies some business rules while 
>comparing each matching record.
>
>The I/P file is read sequentially while the other file is read in a skip 
>sequential basis. The test files that were used had 32M records each while 
>production files have 110M records each.

I assume using random access for the second file was tried with
adequate buffering for index and data. BLSR or the more current means
of doing random access buffering should have been used.  It may also
help to save any randomly read record that were read based on
information in records from the second file based on the match with a
record from the first file.  Knowing access patterns can help in
determining the best solution.

Clark Morris 
>
>Attached is the strobe report from the execution of the test job. The test job 
>takes nearly 7 CPU minutes and was profiled to capture about 1 CPU minute of 
>execution time.
>
>We are attempting to optimize the VSAM access to these files as it is seen to 
>take more than 50% of the CPU consumed by this job.
>
>In the 'Attribution of CPU execution time' section, we see that the major 
>contributors are the components 'QSAM INIT I/O  & EXITS' (Module IGZEQBL) and 
>PARTITION COMMUNICATION. 
>
>Could you please help us understand:
>
>1.What these components are 
>2.Why is QSAM access used instead of VSAM I/O access.
>3.What needs to be done to reduce the CPU consumption by these components.
>
>Thank you
>
>Arun
>
>
>--
>
>1Strobe* PERFORMANCE PROFILE PROGRAMA  
>01/02/2018   PAGE  42 
>   
>   
>-  #ACE   ** ATTRIBUTION OF CPU EXECUTION TIME 
>**
>-.COBLIB  IGZCPCO  IGZEVIO   VSAM INPUT/OUTPUT 
>  
> ---WAS INVOKED BY-   
> -VIA---  CPU TIME %
> XACTION   MODULE   SECTION  DESCRIPTION   MODULE   
> SECTION  DESCRIPTION  SOLO  TOTAL
>   
>   
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERM
>.32   .32
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL 
>   QSAM INIT I/O  & EXITS1.93  1.93
>   
>   
> XACTION  MODULE   SECTION   LOCATION  LINE   SOURCE TEXT  MODULE   
> SECTION  DESCRIPTION 
>   
>   
>  PROGRAMA PROGRAMA   003522   
>   1.30  1.30
>   
>   
>- -
>   
>   
>3.55  3.55
>-.VSAMIDA019L1   VSAM RECORD MANAGEMENT
>  
> ---WAS INVOKED BY-   
> -VIA---CPU TIME %
> XACTION   MODULE   SECTION  DESCRIPTION   MODULE   
> SECTION  DESCRIPTION   SOLO  TOTAL
>   
>   
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL 
>   QSAM INIT I/O  & EXITS  1.84  1.84
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL  
> CURRMEM  QSAM INIT I/O  & EXITS   4.34  4.38
>  .LELIB   CEEBINIT  LE/370 BATCH INIT/TERMIGZEQBL  
> DVFILE   QSAM INIT I/O  & EXITS.03   .03
> 

Re: CKD details

[Tony Harminc]

On 23 January 2018 at 13:56, Seymour J Metz  wrote:
> The 3330 was not the first disk drive with Set Sector; that honor belongs to 
> the 2305, formally part of the S/360 series rather than the S/370, although I 
> imagine that a lot more were sold for use on, e.g., 370/165, than for 85 or 
> 195.

What use is Set Sector without a block multiplexor channel (which
allows disconnect/reconnect)? Were those available for some S/360
models?

Tony H.

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

Re: How about HTTPS? Was: Server Certificates Expiring - Sooner!

[Kurt Quackenbush]

On 1/23/2018 11:10 AM, Dana Mitchell wrote:

What needs to be done when one uses HTTPS to download orders?   As referenced 
in the SMPE Users guide:

HTTPS Fast Path!

The quick and easy method to enable secure download operations is to instruct
the SMP/E RECEIVE command and GIMGTPKG service routine to use the
HTTPS download method and certificate authority (CA) certificates managed by
the default z/OS Java truststore. To do so, simply specify the SMP/E 
tag with the following attributes:





I am currently using Java J7.1_64,  will Java maintenence be required after 
1/29/18?
Dana


As already mentioned (thanks Dave) the CA root changes that have already 
occurred, and the impending change on Monday, January 29, 2018, only 
affect the IBM Order servers for SMP/E RECEIVE ORDER, not the download 
servers.  No specific Java maintenance will be required to address this 
issue of the DigiCert root CA for Monday.


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: CKD details

[Anne & Lynn Wheeler]

sme...@gmu.edu (Seymour J Metz) writes:

> The 3330 was not the first disk drive with Set Sector; that honor
> belongs to the 2305, formally part of the S/360 series rather than the
> S/370, although I imagine that a lot more were sold for use on, e.g.,
> 370/165, than for 85 or 195.

re:
http://www.garlic.com/~lynn/2018.html#77 CKD details
http://www.garlic.com/~lynn/2018.html#79 CKD details

2305 was also fixed-head disk (head per track, sort of replacement for
2301 & 2303 fixed-head drums) ... so there was no arm movement latency,
just rotational delay.

most internal sites used 2305-2 as paging device, approx. 11mbyte
capacity, 1.5mbyte transfer.

There was 2305-1, same number of heads, but only half the tracks, two
heads positioned on track, offset 180degrees and transferred in parallel
for 3mbytes/sec (special two byte channel), half the number of tracks,
(little less than) half the capacity and half the rotational delay
... basically even/odd bytes that could start as soon as came under
either offset/opposing heads.
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_2305.html
and
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_PH2305.html

2305 also had "multiple exposure" support ... eight device addresses
... uniform formating of tracks ... software strategies for the eight
addresses could be used to let the controller maximize the transfer per
rotation.

very late 70s, early 80s, IBM contracted with vendor for electronic
disks (for paging use at internal datacenters) ... referenced as model
1655, could simulate 2305 or operate natively (more like FBA) ... no arm
motion, no retational delay. some old email
http://www.garlic.com/~lynn/2007e.html#email820805

as aside, 3380 3mbyte channel used "data streaming" ... channels had
used protocol that did end-to-end handshaking on every byte transferred,
"data streaming" support would transfer multiple bytes per end-to-end
handshake ... allowed for increasing data transfer rate as well as
doubled maximum channel cabling distance.

trivia: ECKD was originally used for calypso ... speed-matching 3880
controller feature that allowed 3380 3mbyte/sec to used with 168 & 3033
1.5mbyte/sec channels (took enormous amount of work to get all the kinks
worked out, i've frequently commented it would have been less effort to
have just moved to FBA). some old email
http://www.garlic.com/~lynn/2007e.html#email820907b
a little more in these posts
http://www.garlic.com/~lynn/2010e.html#36 What was old is new again (water 
chilled)
http://www.garlic.com/~lynn/2015f.html#83 Formal definituion of Speed Matching 
Buffer

recent post trying to get 2nd "exposure" (device address) for the 3350
fixed-head feature (allowing data transfer overlapped with arm motion)
http://www.garlic.com/~lynn/2017k.html#44 Can anyone remember "drum" storage?

getting to play disk engineer in bldgs 14&15 posts
http://www.garlic.com/~lynn/subtopic.html#disk
CKD, FBA, multi-track search, etc posts
http://www.garlic.com/~lynn/submain.html#dasd

other past posts discussing 2305 & 1655
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction 
count instead of timer
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an 
MVT ABEND 422?
http://www.garlic.com/~lynn/2003m.html#39 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About 
DASD
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than 
disks ?
http://www.garlic.com/~lynn/2007e.html#59 FBA rant
http://www.garlic.com/~lynn/2007o.html#26 Tom's Hdw review of SSDs
http://www.garlic.com/~lynn/2007s.html#9 Poster of computer hardware events?
http://www.garlic.com/~lynn/2007u.html#4 Remembering the CDC 6600
http://www.garlic.com/~lynn/2008b.html#15 Flash memory arrays
http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the 
death of tape
http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the 
death of tape
http://www.garlic.com/~lynn/2010g.html#55 Mainframe Executive article on the 
death of tape

Re: Finding the names of hsm's BCDSs

[DanD]

Actually, if you check SHOWZOS it bounces through control blocks to locate the 
BCDS, MCDS, OCDS an JRNL.

Dan

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

Re: How about HTTPS? Was: Server Certificates Expiring - Sooner!

[Dana Mitchell]

Yes, for J7.1_64 it's in there.  Good info to know

Thank you
Dana

On Tue, 23 Jan 2018 18:07:05 +, Jousma, David  wrote:

>There is probably a better way, but browse to 
>/usr/lpp/java/J8.0/lib/security/cacerts  (replace J8.0) with what ever your 
>version of java is and do a find on " DigiCert Global Root CA"
>
>_
>Dave Jousma

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

Re: CKD details

[Christopher Y. Blaicher]

Yes, cells.  Doing too many things at once.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803    
E: cblaic...@syncsort.com

Syncsort Incorporated 
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, January 23, 2018 2:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

Shirley you mean cells. A  single sector might contain multiple records, 
depending on the device and on the record layouts.

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


From: IBM Mainframe Discussion List  on behalf of 
Christopher Y. Blaicher 
Sent: Tuesday, January 23, 2018 9:48 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CKD details

With all I put in the last post, I forgot to answer WHY 20 sectors at a minimum 
for a record.  It is because at a minimum a record consists of a COUNT and a 
DATA section. Each one takes a minimum of 10 sectors, so with even a 1 byte 
record you need 20 sectors.  If you had a 1 byte key and 1 byte of data you 
would need 30 sectors, 10 for each part.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
http://secure-web.cisco.com/1tr2nwUQE8UCOKlBckWSDEsS73jyrD5tkchlWz_x3UWkmi-GyWYzT6sI0opa2PLaHqtKYh9N6K4_BY-gs_dJezTZSGfI5OkwUyVWDHbefFcA9s0abuSW2YqPjdYa-OjDhWsHtZzGyIIBvxnb8cNCVpSPZZI5Dce_7S1AHPHa101MtzWbq82XPg5VRCQgPO9DnhsWLYUmEmbS72IO44Qz4A973zsDYkpf9v5zQ68DMzC2vAhv5vNcrnLjiDLuUDQ9xbFkg8IHYjfSEYDVPWv4YcMjslBpLecWTHFStPj7WtlXuVMvrbWBjcCKLS-Q59KUxYCk-6sWC8Ifit6ot_f9nvk_4EDwObxspsUKwY4gsVDr2LvVdqfxyvI2zK-Cs1l2P9UJidanG_iN7i_RV8cUCkXLdGpcKpt14PEtlH0jqKv4h9pM6zvHPN4ZeI3U64sie/http%3A%2F%2Fwww.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Christopher Y. Blaicher
Sent: Tuesday, January 23, 2018 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

See the following for how to calculate a sector 
https://secure-web.cisco.com/1-4xCrYaoIvd6moQu1tnY3-JDxDEVfGqTdaT9eR_T8lcfOTMZd1ZqkLdRfOBpKu_w6CucO8NILbbiePWe1dwLBleCsi9wLAQ6r0YUnbLI-JDtVjMISYH_vHRxn3AbPeQuPV4-_6vb8nUsRBzxzFxrPXfNmtDGBG9rXm02WNuOcCzLhtDjdsNHbatuqXWm3O0_hOxfKDYKqmIxtOWVxr_6Up8_WVVsLsxhJT0Q7-WyYLOYFH7h7HenBd777eQrLx82uebOVKhE_KJN5_TGL8qUh-XwSm4cJQRUGPlk29wHN4yTQwkgm_2qYFJU-ZsAqx9XbwqIb-LqJRHQk-lvnxqJGh72b0sXI8qIThw5V7AJqlUxyLwZ244dQdhkMwhkomvc3L8yx4-wCHK8p4eq_EzD2PmoGptCgENg0bgNN_7qKyoz-fWPge4EsIcRu54E42WZ/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSB27H_6.2.0%2Ffa2mr_sectval.html

Question 2: why 20 sectors at a minimum.  It's a long answer.
We tend to think of a record as three unified parts, COUNT, KEY and DATA, but 
really they are three mini-records (for lack of a better description). Each 
part needs enough cells for the data, plus 9 cells of CRC and other control 
information that we can never see.

So, for a COUNT field it takes 10 cells; for a KEY field, if present, and a 
DATA field the calculation is:

SECTORS = 9 + (KL + (6 * KN) + 6) / 34)
Where KN = (KL + 6) / 232
  KL = Key length
Change KL to DL and do the same calculation for the data area.

Question 3: Are you running under VM and using a mini-disk?  VM formats their 
R0 differently, I believe.

Hope this helps.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
http://secure-web.cisco.com/1tr2nwUQE8UCOKlBckWSDEsS73jyrD5tkchlWz_x3UWkmi-GyWYzT6sI0opa2PLaHqtKYh9N6K4_BY-gs_dJezTZSGfI5OkwUyVWDHbefFcA9s0abuSW2YqPjdYa-OjDhWsHtZzGyIIBvxnb8cNCVpSPZZI5Dce_7S1AHPHa101MtzWbq82XPg5VRCQgPO9DnhsWLYUmEmbS72IO44Qz4A973zsDYkpf9v5zQ68DMzC2vAhv5vNcrnLjiDLuUDQ9xbFkg8IHYjfSEYDVPWv4YcMjslBpLecWTHFStPj7WtlXuVMvrbWBjcCKLS-Q59KUxYCk-6sWC8Ifit6ot_f9nvk_4EDwObxspsUKwY4gsVDr2LvVdqfxyvI2zK-Cs1l2P9UJidanG_iN7i_RV8cUCkXLdGpcKpt14PEtlH0jqKv4h9pM6zvHPN4ZeI3U64sie/http%3A%2F%2Fwww.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.







ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is 

Re: CKD details

[Seymour J Metz]

Shirley you mean cells. A  single sector might contain multiple records, 
depending on the device and on the record layouts.

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


From: IBM Mainframe Discussion List  on behalf of 
Christopher Y. Blaicher 
Sent: Tuesday, January 23, 2018 9:48 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CKD details

With all I put in the last post, I forgot to answer WHY 20 sectors at a minimum 
for a record.  It is because at a minimum a record consists of a COUNT and a 
DATA section. Each one takes a minimum of 10 sectors, so with even a 1 byte 
record you need 20 sectors.  If you had a 1 byte key and 1 byte of data you 
would need 30 sectors, 10 for each part.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
http://secure-web.cisco.com/1tr2nwUQE8UCOKlBckWSDEsS73jyrD5tkchlWz_x3UWkmi-GyWYzT6sI0opa2PLaHqtKYh9N6K4_BY-gs_dJezTZSGfI5OkwUyVWDHbefFcA9s0abuSW2YqPjdYa-OjDhWsHtZzGyIIBvxnb8cNCVpSPZZI5Dce_7S1AHPHa101MtzWbq82XPg5VRCQgPO9DnhsWLYUmEmbS72IO44Qz4A973zsDYkpf9v5zQ68DMzC2vAhv5vNcrnLjiDLuUDQ9xbFkg8IHYjfSEYDVPWv4YcMjslBpLecWTHFStPj7WtlXuVMvrbWBjcCKLS-Q59KUxYCk-6sWC8Ifit6ot_f9nvk_4EDwObxspsUKwY4gsVDr2LvVdqfxyvI2zK-Cs1l2P9UJidanG_iN7i_RV8cUCkXLdGpcKpt14PEtlH0jqKv4h9pM6zvHPN4ZeI3U64sie/http%3A%2F%2Fwww.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Christopher Y. Blaicher
Sent: Tuesday, January 23, 2018 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

See the following for how to calculate a sector 
https://secure-web.cisco.com/1-4xCrYaoIvd6moQu1tnY3-JDxDEVfGqTdaT9eR_T8lcfOTMZd1ZqkLdRfOBpKu_w6CucO8NILbbiePWe1dwLBleCsi9wLAQ6r0YUnbLI-JDtVjMISYH_vHRxn3AbPeQuPV4-_6vb8nUsRBzxzFxrPXfNmtDGBG9rXm02WNuOcCzLhtDjdsNHbatuqXWm3O0_hOxfKDYKqmIxtOWVxr_6Up8_WVVsLsxhJT0Q7-WyYLOYFH7h7HenBd777eQrLx82uebOVKhE_KJN5_TGL8qUh-XwSm4cJQRUGPlk29wHN4yTQwkgm_2qYFJU-ZsAqx9XbwqIb-LqJRHQk-lvnxqJGh72b0sXI8qIThw5V7AJqlUxyLwZ244dQdhkMwhkomvc3L8yx4-wCHK8p4eq_EzD2PmoGptCgENg0bgNN_7qKyoz-fWPge4EsIcRu54E42WZ/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSB27H_6.2.0%2Ffa2mr_sectval.html

Question 2: why 20 sectors at a minimum.  It's a long answer.
We tend to think of a record as three unified parts, COUNT, KEY and DATA, but 
really they are three mini-records (for lack of a better description). Each 
part needs enough cells for the data, plus 9 cells of CRC and other control 
information that we can never see.

So, for a COUNT field it takes 10 cells; for a KEY field, if present, and a 
DATA field the calculation is:

SECTORS = 9 + (KL + (6 * KN) + 6) / 34)
Where KN = (KL + 6) / 232
  KL = Key length
Change KL to DL and do the same calculation for the data area.

Question 3: Are you running under VM and using a mini-disk?  VM formats their 
R0 differently, I believe.

Hope this helps.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
http://secure-web.cisco.com/1tr2nwUQE8UCOKlBckWSDEsS73jyrD5tkchlWz_x3UWkmi-GyWYzT6sI0opa2PLaHqtKYh9N6K4_BY-gs_dJezTZSGfI5OkwUyVWDHbefFcA9s0abuSW2YqPjdYa-OjDhWsHtZzGyIIBvxnb8cNCVpSPZZI5Dce_7S1AHPHa101MtzWbq82XPg5VRCQgPO9DnhsWLYUmEmbS72IO44Qz4A973zsDYkpf9v5zQ68DMzC2vAhv5vNcrnLjiDLuUDQ9xbFkg8IHYjfSEYDVPWv4YcMjslBpLecWTHFStPj7WtlXuVMvrbWBjcCKLS-Q59KUxYCk-6sWC8Ifit6ot_f9nvk_4EDwObxspsUKwY4gsVDr2LvVdqfxyvI2zK-Cs1l2P9UJidanG_iN7i_RV8cUCkXLdGpcKpt14PEtlH0jqKv4h9pM6zvHPN4ZeI3U64sie/http%3A%2F%2Fwww.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.







ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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

Re: CKD details

[Seymour J Metz]

The 3330 was not the first disk drive with Set Sector; that honor belongs to 
the 2305, formally part of the S/360 series rather than the S/370, although I 
imagine that a lot more were sold for use on, e.g., 370/165, than for 85 or 195.


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


From: IBM Mainframe Discussion List  on behalf of 
Anne & Lynn Wheeler 
Sent: Tuesday, January 23, 2018 12:59 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CKD details

t...@harminc.net (Tony Harminc) writes:
> I assume it is the value used in the Set Sector/Read Sector CCWs. This
> came with the 3330 (real "analogue" disk) and is part of Rotational
> Position Sensing (RPS). It should have no logical relationship to the
> cell size; it's just a logical position (degrees, radians, IBM magic
> numbers because degrees and radians were NIH...?) on the track.

re:
http://secure-web.cisco.com/15Qvoob2Vhdm6iuUGhL1j9vy6Z0pnnh0_1zx9-7pssQwkGQj6WqQBa5q13LUe_gWxcObUVVxZJCm0ptns8GHOizb8OjMMFNI5KmCXFiG3ZClHBCF0V_dlinAq_J5MwUN7delJxdujwpASYBntt0YLDqjjAK4UWc20wzoXUG3bEMDArK8KPAf5iMdAs8qRiRiOEaRP_HceOU5iNyaQcY5ORiYNfG7guN5fpRpF_q_lJqx84PI8m3seBtHRZtt9_dVcosuXwbrzVTSnV0QfcXaksiYDrGr6p7PKu04X9hBRmKzFlkFq7Oa6UdmV3jVMSWvbg3OHxP-wFCRDBuM7evMy1zaVWQzvinYlq9GKm_f5GGQIvy0NtLPiJ07Y6MhForY6WWJY5NJUfVaVf9OUekQB5S0WjtBH8pUxTtdXn1VoA_g4VNASXAJZ4TxdNCWpeK9Z/http%3A%2F%2Fwww.garlic.com%2F%7Elynn%2F2018.html#77
 CKD details

it use to be all surfaces were data ... with the 3330, one surface
became dedicated to the sector position ... 20 r/w heads, 20 surfaces,
19 data r/w heads, 19 data surfaces ... the 20th surface has the
rotational position information recorded.

Supposedly the loss in total data capacity was more than offset in
better system throughput ... RPS "set sector" in channel program
reducing channel busy involved in constant search (although it couldn't
fix multi-track search for VTOCs and PDS directorys). All that goes away
in FBA ... as can be seen in justification description going from
512 FBA to 4096 FBA:
https://secure-web.cisco.com/1sFhpvpagwxYufeiUizMjVdLuq_FtR3ppZ6xQrGCXzJRGY-lLY5nyYauQIOTTQUiQBqdn3MDx3iKD_bBKEOBl0gWQgcR8Ss-RoYSadMizTEhrI6ZiPGqyGjHA4cvvnpugqItP_q68NBeCS2s-qsSRLd4B4ia2gGQCGFEbJKL5qCnUPkqu11e9Rr9VRjoR04df8vIx43mPPWM-nIZaymf8QeJ2jb7moKRLSeehPj0RID1LLAZ_Sqz8VxwXksknY2MPjBsYsmlgskUT_k6WHM-JB8Mcm3P_vp_ESaFG3G2AGawc_HaoeOyOQUgikQnA462G04KdnBDcXnfEUyxRHYEgJh7O9iKVNp3Zxs-RxuM9FCvYrcFEVl5Mpo__rI8_hmhb5y_YDzlinDJHkOizYAj9m-Mr6-gw13iSbtacDXOG1zs/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FAdvanced_Format

i've periodically mentioned pointing out that in the 70s, increase in
disk throughput wasn't keeping up with increase in overall system
performance. Some disk division executive in the early 80s took
exception with my statement that relative system disk throughput had
declined by an order of magnitude since the 60s (disk throughput
increase 3-5 times, processor throughput increase 40-50 times)
and assigned the division performance group to refute my claim.  After a
couple weeks the group comes back and essentially say that I had
slightly understated the problem ... not bothering to include RPS-miss
in the calculations (attempting to channel reconnect at the sector
number ... but channel busy with some other device ... and so have to
loose full revolution). They then turn the analysis into SHARE
presentation on how to organize disk farms for better throughput.

--
virtualization experience starting Jan1968, online at home since Mar1970

--
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 about HTTPS? Was: Server Certificates Expiring - Sooner!

[Jousma, David]

There is probably a better way, but browse to 
/usr/lpp/java/J8.0/lib/security/cacerts  (replace J8.0) with what ever your 
version of java is and do a find on " DigiCert Global Root CA"

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Tuesday, January 23, 2018 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How about HTTPS? Was: Server Certificates Expiring - Sooner!

**CAUTION EXTERNAL EMAIL**

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

Thanks Dave!  

How can a guy tell if our current java will require any changes?

On Tue, 23 Jan 2018 16:25:23 +, Jousma, David  wrote:

>I guess I should have qualified that.  I'm running a current version of JAVA 
>V8 on my tech sandbox and required no changes.
>
>_
>Dave Jousma
>Manager Mainframe Engineering, Assistant Vice President 
>david.jou...@53.com
>1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 
>616.653.2717
>
>

--
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: CKD details

[Anne & Lynn Wheeler]

t...@harminc.net (Tony Harminc) writes:
> I assume it is the value used in the Set Sector/Read Sector CCWs. This
> came with the 3330 (real "analogue" disk) and is part of Rotational
> Position Sensing (RPS). It should have no logical relationship to the
> cell size; it's just a logical position (degrees, radians, IBM magic
> numbers because degrees and radians were NIH...?) on the track.

re:
http://www.garlic.com/~lynn/2018.html#77 CKD details

it use to be all surfaces were data ... with the 3330, one surface
became dedicated to the sector position ... 20 r/w heads, 20 surfaces,
19 data r/w heads, 19 data surfaces ... the 20th surface has the
rotational position information recorded.

Supposedly the loss in total data capacity was more than offset in
better system throughput ... RPS "set sector" in channel program
reducing channel busy involved in constant search (although it couldn't
fix multi-track search for VTOCs and PDS directorys). All that goes away
in FBA ... as can be seen in justification description going from
512 FBA to 4096 FBA:
https://en.wikipedia.org/wiki/Advanced_Format

i've periodically mentioned pointing out that in the 70s, increase in
disk throughput wasn't keeping up with increase in overall system
performance. Some disk division executive in the early 80s took
exception with my statement that relative system disk throughput had
declined by an order of magnitude since the 60s (disk throughput
increase 3-5 times, processor throughput increase 40-50 times)
and assigned the division performance group to refute my claim.  After a
couple weeks the group comes back and essentially say that I had
slightly understated the problem ... not bothering to include RPS-miss
in the calculations (attempting to channel reconnect at the sector
number ... but channel busy with some other device ... and so have to
loose full revolution). They then turn the analysis into SHARE
presentation on how to organize disk farms for better throughput.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: CKD details

[Tony Harminc]

On 23 January 2018 at 10:22, R.S.  wrote:
> Fortunately your explanation was clear enough to find out each "mini-record"
> has at least 10 cells (9 control plus a t least one for data).
>
> However you used word "SECTORS". I used  "34-byte DATA CELL", following the
> 3390 documentation (other names can be found elsewhere).
> It seems the documentation use SECTOR for something else. The SA22-1025-00
> says the 3390 device has 224 sectors per track and 222 for 3380. So, the
> SECTOR  cannot be the same as DATA CELL.
>
> I have no idea what is the SECTOR.

I assume it is the value used in the Set Sector/Read Sector CCWs. This
came with the 3330 (real "analogue" disk) and is part of Rotational
Position Sensing (RPS). It should have no logical relationship to the
cell size; it's just a logical position (degrees, radians, IBM magic
numbers because degrees and radians were NIH...?) on the track.

Tony H.

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

Re: CKD details

[R.S.]

W dniu 2018-01-23 o 17:50, Anne & Lynn Wheeler pisze:

cblaic...@syncsort.com (Christopher Y. Blaicher) writes:

Your right, things are a little confusing.
SECTORS - Think of it as 224 pieces of pie.  It is, I believe, physical.
CELL - Also physical, but I think of them as little chunks of data,
   which may be your data or control data for the hardware.
TRACK BALANCE - How much room is left on the track if you were to
   write a single block.  Look up TRKBAL macro.

That extra calculation is for device control information, part of
which I know is CRC, or at least that is what I was told.  All that
stuff other than the COUNT-KEY-DATA areas are for the hardware and we
mortals can't see it, but it is there.

and all that is now archaic fiction since no real CKD have been made for
decades, being simulated on industry standard fixed-block

this is the "real" format ... giving both 512byte FBA and the newer
4096byte FBA
https://en.wikipedia.org/wiki/Advanced_Format

part of the change justification is 4096byte is more "efficient"
... 15byte "gap, sync, address mark" for each phsical record and "512"
has 50byte ECC and 4096 has 100byte ECC for each record (eight 512 has
400byte ECC total) ... 512byte efficiency 88.7% and 4096byte efficiency
97.3%


That's true, it is emulated now. However from MVS point of view there 
are still HA, R0, C, K, D fields of records, etc. Even gaps are still 
there and it seem also CRC code still occupy virtual data cells.




Regards
--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

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


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

Re: CKD details

[Anne & Lynn Wheeler]

cblaic...@syncsort.com (Christopher Y. Blaicher) writes:
> Your right, things are a little confusing.
> SECTORS - Think of it as 224 pieces of pie.  It is, I believe, physical.
> CELL - Also physical, but I think of them as little chunks of data,
>   which may be your data or control data for the hardware.
> TRACK BALANCE - How much room is left on the track if you were to
>   write a single block.  Look up TRKBAL macro.
>
> That extra calculation is for device control information, part of
> which I know is CRC, or at least that is what I was told.  All that
> stuff other than the COUNT-KEY-DATA areas are for the hardware and we
> mortals can't see it, but it is there.

and all that is now archaic fiction since no real CKD have been made for
decades, being simulated on industry standard fixed-block

this is the "real" format ... giving both 512byte FBA and the newer
4096byte FBA
https://en.wikipedia.org/wiki/Advanced_Format

part of the change justification is 4096byte is more "efficient"
... 15byte "gap, sync, address mark" for each phsical record and "512"
has 50byte ECC and 4096 has 100byte ECC for each record (eight 512 has
400byte ECC total) ... 512byte efficiency 88.7% and 4096byte efficiency
97.3%

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: How about HTTPS? Was: Server Certificates Expiring - Sooner!

[Jousma, David]

I guess I should have qualified that.  I'm running a current version of JAVA V8 
on my tech sandbox and required no changes.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, January 23, 2018 11:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How about HTTPS? Was: Server Certificates Expiring - Sooner!

No change to java is needed.   The new cert is for the order placing process, 
as far as I can tell, I also run with https download, and use the certs 
contained in the java store for that.  I've successfully placed an order via 
the Rochester site, which has already converted with no issues.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Tuesday, January 23, 2018 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How about HTTPS? Was: Server Certificates Expiring - Sooner!

**CAUTION EXTERNAL EMAIL**

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

What needs to be done when one uses HTTPS to download orders?   As referenced 
in the SMPE Users guide:

HTTPS Fast Path!

The quick and easy method to enable secure download operations is to instruct 
the SMP/E RECEIVE command and GIMGTPKG service routine to use the HTTPS 
download method and certificate authority (CA) certificates managed by the 
default z/OS Java truststore. To do so, simply specify the SMP/E  tag 
with the following attributes:



I am currently using Java J7.1_64,  will Java maintenence be required after 
1/29/18?
Dana

--
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 **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: How about HTTPS? Was: Server Certificates Expiring - Sooner!

[Jousma, David]

No change to java is needed.   The new cert is for the order placing process, 
as far as I can tell, I also run with https download, and use the certs 
contained in the java store for that.  I've successfully placed an order via 
the Rochester site, which has already converted with no issues.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Tuesday, January 23, 2018 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How about HTTPS? Was: Server Certificates Expiring - Sooner!

**CAUTION EXTERNAL EMAIL**

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

What needs to be done when one uses HTTPS to download orders?   As referenced 
in the SMPE Users guide:

HTTPS Fast Path!

The quick and easy method to enable secure download operations is to instruct 
the SMP/E RECEIVE command and GIMGTPKG service routine to use the HTTPS 
download method and certificate authority (CA) certificates managed by the 
default z/OS Java truststore. To do so, simply specify the SMP/E  tag 
with the following attributes:



I am currently using Java J7.1_64,  will Java maintenence be required after 
1/29/18?
Dana

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

How about HTTPS? Was: Server Certificates Expiring - Sooner!

[Dana Mitchell]

What needs to be done when one uses HTTPS to download orders?   As referenced 
in the SMPE Users guide:

HTTPS Fast Path!

The quick and easy method to enable secure download operations is to instruct
the SMP/E RECEIVE command and GIMGTPKG service routine to use the
HTTPS download method and certificate authority (CA) certificates managed by
the default z/OS Java truststore. To do so, simply specify the SMP/E 
tag with the following attributes:



I am currently using Java J7.1_64,  will Java maintenence be required after 
1/29/18?
Dana

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

Re: Please Read: Server Certificates Expiring - Soon!

[Vince Getgood]

Thanks.
That's it.  I hadn't realised the global cert had to be attached to the 
SMPEKeyring.

Sorry!

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

Re: CKD details

[Christopher Y. Blaicher]

Your right, things are a little confusing.
SECTORS - Think of it as 224 pieces of pie.  It is, I believe, physical.
CELL - Also physical, but I think of them as little chunks of data, which may 
be your data or control data for the hardware.
TRACK BALANCE - How much room is left on the track if you were to write a 
single block.  Look up TRKBAL macro.

That extra calculation is for device control information, part of which I know 
is CRC, or at least that is what I was told.  All that stuff other than the 
COUNT-KEY-DATA areas are for the hardware and we mortals can't see it, but it 
is there.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, January 23, 2018 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

Fortunately your explanation was clear enough to find out each "mini-record" 
has at least 10 cells (9 control plus a t least one for data).

However you used word "SECTORS". I used  "34-byte DATA CELL", following the 
3390 documentation (other names can be found elsewhere).
It seems the documentation use SECTOR for something else. The
SA22-1025-00 says the 3390 device has 224 sectors per track and 222 for 3380. 
So, the SECTOR  cannot be the same as DATA CELL.

I have no idea what is the SECTOR.


BTW: I also do not understand the formula. For me it should be just
Numberofcells=9+RoundUP(KL/34)
of course you provided right formula as it is documented, but I simply don't 
understand the purpose of KN and 6 and 232. i'm pretty sure it is not just a 
magic, but what is the rationale behind?

Last but not least: THANK YOU VERY MUCH for the explanations you gave me, I 
appreciate it.

Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-01-23 o 15:48, Christopher Y. Blaicher pisze:
> With all I put in the last post, I forgot to answer WHY 20 sectors at a 
> minimum for a record.  It is because at a minimum a record consists of a 
> COUNT and a DATA section. Each one takes a minimum of 10 sectors, so with 
> even a 1 byte record you need 20 sectors.  If you had a 1 byte key and 1 byte 
> of data you would need 30 sectors, 10 for each part.
>
> Chris Blaicher
> Technical Architect
> Mainframe Development
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
>
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563
> Pearl River, NY 10965
> www.syncsort.com
>
> Data quality leader Trillium Software is now a part of Syncsort.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Christopher Y. Blaicher
> Sent: Tuesday, January 23, 2018 8:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CKD details
>
> See the following for how to calculate a sector 
> https://www.ibm.com/support/knowledgecenter/en/SSB27H_6.2.0/fa2mr_sectval.html
>
> Question 2: why 20 sectors at a minimum.  It's a long answer.
> We tend to think of a record as three unified parts, COUNT, KEY and DATA, but 
> really they are three mini-records (for lack of a better description). Each 
> part needs enough cells for the data, plus 9 cells of CRC and other control 
> information that we can never see.
>
> So, for a COUNT field it takes 10 cells; for a KEY field, if present, and a 
> DATA field the calculation is:
>
> SECTORS = 9 + (KL + (6 * KN) + 6) / 34)
> Where KN = (KL + 6) / 232
>KL = Key length
> Change KL to DL and do the same calculation for the data area.
>
> Question 3: Are you running under VM and using a mini-disk?  VM formats their 
> R0 differently, I believe.
>
> Hope this helps.
>
> Chris Blaicher
> Technical Architect
> Mainframe Development
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
>
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563
> Pearl River, NY 10965
> www.syncsort.com
>

==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This 

Re: CKD details

[R.S.]

Fortunately your explanation was clear enough to find out each 
"mini-record" has at least 10 cells (9 control plus a t least one for 
data).


However you used word "SECTORS". I used  "34-byte DATA CELL", following 
the 3390 documentation (other names can be found elsewhere).
It seems the documentation use SECTOR for something else. The 
SA22-1025-00 says the 3390 device has 224 sectors per track and 222 for 
3380. So, the SECTOR  cannot be the same as DATA CELL.


I have no idea what is the SECTOR.


BTW: I also do not understand the formula. For me it should be just
Numberofcells=9+RoundUP(KL/34)
of course you provided right formula as it is documented, but I simply 
don't understand the purpose of KN and 6 and 232. i'm pretty sure it is 
not just a magic, but what is the rationale behind?


Last but not least: THANK YOU VERY MUCH for the explanations you gave 
me, I appreciate it.


Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-01-23 o 15:48, Christopher Y. Blaicher pisze:

With all I put in the last post, I forgot to answer WHY 20 sectors at a minimum 
for a record.  It is because at a minimum a record consists of a COUNT and a 
DATA section. Each one takes a minimum of 10 sectors, so with even a 1 byte 
record you need 20 sectors.  If you had a 1 byte key and 1 byte of data you 
would need 30 sectors, 10 for each part.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Christopher Y. Blaicher
Sent: Tuesday, January 23, 2018 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

See the following for how to calculate a sector 
https://www.ibm.com/support/knowledgecenter/en/SSB27H_6.2.0/fa2mr_sectval.html

Question 2: why 20 sectors at a minimum.  It's a long answer.
We tend to think of a record as three unified parts, COUNT, KEY and DATA, but 
really they are three mini-records (for lack of a better description). Each 
part needs enough cells for the data, plus 9 cells of CRC and other control 
information that we can never see.

So, for a COUNT field it takes 10 cells; for a KEY field, if present, and a 
DATA field the calculation is:

SECTORS = 9 + (KL + (6 * KN) + 6) / 34)
Where KN = (KL + 6) / 232
   KL = Key length
Change KL to DL and do the same calculation for the data area.

Question 3: Are you running under VM and using a mini-disk?  VM formats their 
R0 differently, I believe.

Hope this helps.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com



==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

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


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

Re: CKD details

[Christopher Y. Blaicher]

With all I put in the last post, I forgot to answer WHY 20 sectors at a minimum 
for a record.  It is because at a minimum a record consists of a COUNT and a 
DATA section. Each one takes a minimum of 10 sectors, so with even a 1 byte 
record you need 20 sectors.  If you had a 1 byte key and 1 byte of data you 
would need 30 sectors, 10 for each part.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Christopher Y. Blaicher
Sent: Tuesday, January 23, 2018 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

See the following for how to calculate a sector 
https://www.ibm.com/support/knowledgecenter/en/SSB27H_6.2.0/fa2mr_sectval.html

Question 2: why 20 sectors at a minimum.  It's a long answer.
We tend to think of a record as three unified parts, COUNT, KEY and DATA, but 
really they are three mini-records (for lack of a better description). Each 
part needs enough cells for the data, plus 9 cells of CRC and other control 
information that we can never see.

So, for a COUNT field it takes 10 cells; for a KEY field, if present, and a 
DATA field the calculation is:

SECTORS = 9 + (KL + (6 * KN) + 6) / 34)
Where KN = (KL + 6) / 232
  KL = Key length
Change KL to DL and do the same calculation for the data area.

Question 3: Are you running under VM and using a mini-disk?  VM formats their 
R0 differently, I believe.

Hope this helps.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.







ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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

Re: Update: Server Certificates Expiring - Sooner!

[Kurt Quackenbush]

On 1/23/2018 12:51 AM, Barbara Nitz wrote:


While we're on the topic of ShopZ order downloads: Why do the SMPE books say to 
make my private certificate (that I got from IBM for shopz) a CERTAUTH 
certificate? I certainly didn't do that - it is just PERSONAL, and I made it 
the default in the keyring, and I downloaded the order that way.


The SMP/E Users Guide suggests connecting the user certificate to your 
keyring like this:


RACDCERT ID(ring-owner) CONNECT(LABEL('SMPE Client Certificate') +
RING(keyringname) USAGE(CERTAUTH) )

The note at the bottom of this page says this:

"To enable the user certificate to be easily shared by other user IDs 
without requiring unnecessarily high levels of access for those other 
user IDs, the user certificate must be connected to the key ring as a 
certificate authority (CA) certificate (USAGE of CERTAUTH). This allows 
the user certificate to be shared without requiring other user IDs to 
access the certificate’s associated private key."


I believe your point is that if you do not intend for multiple userids 
to use the same certificate, then you don't need to connect it to your 
keyring with USAGE(CERTAUTH).  Fair point.


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: Please Read: Server Certificates Expiring - Soon!

[Kurt Quackenbush]

On 1/23/2018 7:13 AM, Vince Getgood wrote:

I have that in a different keyring - always have had, and it's always worked 
before.

In my SMP/e ORDERSRVR data: -

keyring="userid/SMPEKeyring"
certificate="SMPE Client Certificate"

in my FTP data options: -

KEYRING   IBMUSER/FtpSecur

(don't blame me, this is the way it was set up when I got here!)


Nope.  The keyring identified in the  must contain the 
certificate you request and download from Shopz, *AND* the appropriate 
certificate authority certificates for the order servers.  As of today, 
that should include both the GeoTrust and the DigiCert CA certs.


The keyring you identify in your FTP.DATA file only needs to contain the 
appropriate CA certificate for the download server.  As of today, that 
is the GeoTrust CA.


However, rather than identify a specific keyring in your FTP.DATA file, 
and worry about which CA certs are connected to that keyring, I 
recommend you use this to tell the ftp client to use as necessary any 
and all CA certificates in your security data base:


keyring *AUTH*/*

Kurt Quackenbush -- IBM, SMP/E Development

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

Re: Update: Server Certificates Expiring - Sooner!

[Elardus Engelbrecht]

Timothy Sipples wrote:

>4. *RIGHT CLICK* on the link, and select "Save Link As..."

Thats the missing link. I *LEFT CLICK* there initially from both FF and IE with 
all the usual drama.

... left ... right ... left ... right ... hmmm, I'm confused... ;-D


>Hope that helps.

Certainly. Thanks. 

Groete / Greetings
Elardus Engelbrecht

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

Re: CKD details

[Christopher Y. Blaicher]

See the following for how to calculate a sector
https://www.ibm.com/support/knowledgecenter/en/SSB27H_6.2.0/fa2mr_sectval.html

Question 2: why 20 sectors at a minimum.  It's a long answer.
We tend to think of a record as three unified parts, COUNT, KEY and DATA, but 
really they are three mini-records (for lack of a better description). Each 
part needs enough cells for the data, plus 9 cells of CRC and other control 
information that we can never see.

So, for a COUNT field it takes 10 cells; for a KEY field, if present, and a 
DATA field the calculation is:

SECTORS = 9 + (KL + (6 * KN) + 6) / 34)
Where KN = (KL + 6) / 232
  KL = Key length
Change KL to DL and do the same calculation for the data area.

Question 3: Are you running under VM and using a mini-disk?  VM formats their 
R0 differently, I believe.

Hope this helps.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, January 23, 2018 7:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

Another set of questions:

1. What is sector???
3390 specification says it has 224 sectors per track (3380 had 222 sectors per 
track).
I cannot find any explanation for that. Size of data cell is 34 bytes

2. In the 3390 reference I read the record can occupy 20 to 1729 data cells 
(excluding standard R0).
Why 20? For 3390 device 20 cells is 680 bytes. Is it minimum for any record, 
including i.e. very small Count plus 4 bytes of Data?


3. HA (Home Address)
I used File Manager to print it out and indeed it is 5-byte long, but it seems 
to be NOT in format of CCHHR.
IMHO it is xCCHH, where x is one byte with x'00' (in my case), but it is first 
byte.

Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-01-22 o 15:51, R.S. pisze:
> I'm looking for some reference describing track format of CKD disk.
>
> What I know is
> Index Point - Home Address - R0 - other Rn
>
> Some questions:
> 1. IP is just a "start of track", contains no data - Y/N ?
> 2. What is a format of HA?
> 3. What is a format of R0?
> 4. What is a format of Count field? How long is it? Is it 10 bytes?
> 5. What is maximum length of K and D?
>
> Any documentation?
>





==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

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


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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from 

Re: Update: Server Certificates Expiring - Sooner!

[Timothy Sipples]

You should be able to use Firefox to download the certificate file. Here
are the basic steps:

1. Navigate to the IBM Techdocs Web site and flash notice here:

http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10884

2. Click on the PDF file link ("Certificate Authority.pdf") from within
Firefox. Assuming you're using Firefox's built-in PDF viewer, that should
display the PDF. (If you aren't using Firefox's built-in PDF viewer,
configure it now for this particular task. You can switch back to your
alternative PDF viewer when you're done.)

3. Scroll down to page 2, and you should see the direct link to the
certificate file up near the top of the page.

4. *RIGHT CLICK* on the link, and select "Save Link As..."

5. Save the certificate file to a desired directory.

Hope that helps.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA


E-Mail: sipp...@sg.ibm.com

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

Re: CKD details

[R.S.]

Another set of questions:

1. What is sector???
3390 specification says it has 224 sectors per track (3380 had 222 
sectors per track).

I cannot find any explanation for that. Size of data cell is 34 bytes

2. In the 3390 reference I read the record can occupy 20 to 1729 data 
cells (excluding standard R0).
Why 20? For 3390 device 20 cells is 680 bytes. Is it minimum for any 
record, including i.e. very small Count plus 4 bytes of Data?



3. HA (Home Address)
I used File Manager to print it out and indeed it is 5-byte long, but it 
seems to be NOT in format of CCHHR.
IMHO it is xCCHH, where x is one byte with x'00' (in my case), but it is 
first byte.


Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-01-22 o 15:51, R.S. pisze:

I'm looking for some reference describing track format of CKD disk.

What I know is
Index Point - Home Address - R0 - other Rn

Some questions:
1. IP is just a "start of track", contains no data - Y/N ?
2. What is a format of HA?
3. What is a format of R0?
4. What is a format of Count field? How long is it? Is it 10 bytes?
5. What is maximum length of K and D?

Any documentation?







==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

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


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

Re: Please Read: Server Certificates Expiring - Soon!

[Vince Getgood]

I have that in a different keyring - always have had, and it's always worked 
before.

In my SMP/e ORDERSRVR data: -

keyring="userid/SMPEKeyring"
certificate="SMPE Client Certificate"

in my FTP data options: -

KEYRING   IBMUSER/FtpSecur

(don't blame me, this is the way it was set up when I got here!)

Thanks.

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

Re: Please Read: Server Certificates Expiring - Soon!

[Elardus Engelbrecht]

Vince Getgood wrote:

>I spoke too soon!

;-)

>I've added it to the keyring we use for smp/e recieves: -

>Certificate Label NameCert Owner   USAGE   DEFAULT 
>  ---  
> GeoTrust Global CACERTAUTH CERTAUTHYES
> DigiCert Global Root CA   CERTAUTH CERTAUTHNO 

Where is Cert nr 3? The one which you request from the zShop website?

You need to download that and then add that to your KeyRing.


>What have I missed?

You probably missed Cert nr 3 which you should receive from IBM in a PKCS #12 
format.

My ring (the 'One Ring to Rule Them all' ;-D ) is looking like this one (I like 
to use the CA names just as they are distributed.)

Ring:  >...<
Certificate Label Name Cert Owner USAGE  DEFAULT
         ---
.. ID(.)  CERTAUTH NO   
DigiCert Global Root CACERTAUTH   CERTAUTH NO   
GeoTrust GlobalCERTAUTH   CERTAUTH NO   

HTH!

Groete / Greetings
Elardus Engelbrecht

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

Re: Please Read: Server Certificates Expiring - Soon!

[Vince Getgood]

I spoke too soon!
I've followed the steps on the flash, and my RACF database shows: -

Label:DigiCert Global Root CA  
Certificate ID:2QiJmZmDhZmjgcSJh4nDhZmjQMeTloKBk0DZlpajQMPB
Status:TRUST   
Start Date:2006/11/10 00:30:00 
End Date:  2031/11/10 00:30:00 
Serial Number:083BE056904246B1A1756AC95991C74A 

Issuer's Name:CN=DigiCert Global Root CA.OU=www.digicert.com.O=DigiCert 
Inc.C=US

I've added it to the keyring we use for smp/e recieves: -

Ring:  
 FtpSecur  
   
   
   
   
Certificate Label NameCert Owner   USAGE   DEFAULT 
  ---  
 GeoTrust Global CACERTAUTH CERTAUTHYES
 DigiCert Global Root CA   CERTAUTH CERTAUTHNO 

I've refreshed DIGTCERT & DIGTRING - but my recieve still fails, telling me the 
certificate isn't trusted: -

javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building 
failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl 
could not build a valid CertPath.; 
internal cause is: java.security.cert.CertPathValidatorException: 
The certificate issued by CN=DigiCert Global Root CA, OU=www.digicert.com, 
O=DigiCert Inc, C=US is not trusted; 

What have I missed?

TIA

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

Re: Please Read: Server Certificates Expiring - Soon!

[Vince Getgood]

Excellent.  Thanks for that.  It worked for me.

They obviously didn't want to make it easy!!

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

Re: Please Read: Server Certificates Expiring - Soon!

[Elardus Engelbrecht]

Vince Getgood wrote:

>ok, stupid question time.

It is not a stupid question! Like with many others, this is can be sometimes a 
struggle!

>I've not done this before.  I'm attempting to follow the instructions in the 
>flash document, but fall at the first hurdle...
>How, exactly, do I "download" the certificate to my workstation?  

Look at Alva Nim's kind reply to the thread 'Re: Update: Server Certificates 
Expiring - Sooner!'.

(Watch the subject which is somewhat different to this thread.)
 
HTH!

Groete / Greetings
Elardus Engelbrecht

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

Re: Please Read: Server Certificates Expiring - Soon!

[Vince Getgood]

ok, stupid question time.

I've not done this before.  I'm attempting to follow the instructions in the 
flash document, but fall at the first hurdle...

How, exactly, do I "download" the certificate to my workstation?  

I tried to copy the text at the link and pasted to a .txt document, but when I 
binary FTP the resultant file up to my z/OS system, and then try to add it to 
the RACF database, I get: -

IRRD104I The input data set does not contain a valid certificate.

Which suggests to me that something went wrong in the copy / ftp process.

What's the correct method?  (yes, the file on my z/OS system is LRECL 256, and 
RECFM VB)

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

Re: Dynamic command to Activate NJE TCP

[Peter]

Hello Alan/All,

Initially I wanted to make the NJE TCP working with just a dynamic
commands. Once the dynamic command works I can update the JES deck.

Has anyone undergone this situation ?

Peter

On 23-Jan-2018 1:20 PM, "Alan(GMAIL)Watthey"  wrote:

> Peter,
>
> It's a while since I did this but I usually just copy/pasted whatever I
> had coded in the new startup options and added a few commas and issued it
> as a JES2 command.  You obviously need to add a $ADD or $T command as
> appropriate but I don't remember not being able to add anything new or
> change anything already there.  The $DEL command is a bit limited as some
> things cannot actually be deleted.  They just hang around until the next
> WARM start.  If I remember correctly the DESTIDs can be a bit of a pain as
> JES2 invents some of those itself so changing node names can run into them
> so you need to $DEL them first.  You might have to stop certain things
> before they can be changed but many can be changed whilst active.
>
> The JES2 manual is very good at telling you what can be changed with a
> HOT, WARM or COLD start.
>
> My next test was always a $PJES2,ABEND as that reads the new startup deck
> and tells me about any problems in it which I can quickly fix.  Do this at
> a quieter time obviously but I never got any complaints from anyone.  Some
> things won't work whilst JES2 is down (usually less than a minute for us)
> but these seem to be minimal and unimportant (perhaps TSO STATUS).
>
> The final test was the next IPL of course.
>
> Hope this helps.
>
> Regards,
> Alan Watthey
>
> -Original Message-
> From: Peter [mailto:dbajava...@gmail.com]
> Sent: 22 January 2018 6:00 pm
> Subject: Dynamic command to Activate NJE TCP
>
> Hello All,
>
> Cross Posted
>
> Is there anyone who have tried activating NJE TCP connections dynamically ?
>
> Any set of commands that can issued sequentially ?
>
> Could someone point me ?
>
> Peter
>
> --
> 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