Re: SDSF API question -- why only REXX & Java?

2019-05-24 Thread Clark Morris 
[Default] On 24 May 2019 13:01:40 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>Well, REXX has an interface for a routine to set REXX variables. There is no 
>equivalent for, e.g., COBOL.
>
>It's not a question of compiled versus not compiled; it's a question of what 
>interfaces are available to the called program. A compiled REXX program can 
>call SDSF; a COBOL program running in a COBOL interpreter would not be able to 
>do so.
>
Given that in Enterprise 4.2 and later you can issue a CALL data-name/
literal USING BY REFERENCE / CONTENT / VALUE  RETURNING, why can't
a COBOL program call the SDSF routine?  Why couldn't a COBOL program
conforming to the 2002 standard or later running in an interpreter
call SDSF?

Clark Morris
> 
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>John McKown 
>Sent: Thursday, May 23, 2019 3:05 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: SDSF API question -- why only REXX & Java?
>
>This is just a curiosity question. The SDSF book shows an API for using it
>in REXX and Java. Anybody know why no other languages? Or are we supposed
>to use SAPI for compiled languages instead of the SDSF API? Or is it SPOOL
>Dataset Browser that we are supposed to use?
>
>https://secure-web.cisco.com/1Cyt5vo8aV4_qK2suQCO_GWm_QmJIDuKVD1C8rfk1n4g638ku6ucLVwv4s4YlkBtaC0hsyyR_CQuojt3RVXCbUSxCA_FJYEM4JPpiZqKG_mrzHhdEpkC-KCMfKlxdGBuIVbFO2uR3Etk_ATGNSK4F5kf2ZnLZT4bNQ87CU-09l7bkTgENQXo5DFXjFyxYeK9128nFQxi-YnO7E_LrTzLvo0Imniw628DF-VgOqQdmTEO7jnqfM4mDtfw-QOtQO4YBG81AEJMXH1OmDSMW9sNFq2J1zK0kfo0mBxAA0CW4bPBDKNgakK64nke4s9kI3HOzeRNLGrhSeSqPHUA0jDQgU1Ci7-PWeEnivPOkFEBg_wZf2yrgKxG_ibLLsJqvaJ-Lprm4N3ZRs5nRRVNlNZKW-2ZuWbhm9okzzDuLdXpKHFWWk4OleXBT8YfArhbJMUqz/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.isfa600%2Frexx.htm
>
>https://secure-web.cisco.com/1hSr4kg3404Net4sgvUUKBkObpOfAi-doK-a25Ywyd_DA3sg7IIowuk6r-jkqsGJN0vxPNXDG2PTF2ebREfXfAaRZYfEl_85XL9Z2EfkNHufGIs7c_qMw-dwvKkBqvc42qIu5KEPjwSmfYXLuWOMjJf6YHwvhRwBuEalacziPkzDXVMrCUyeJvEBsG9WahktYSrwbggfqsO4NXx5OskbS8JkVbrvVj37VtFr-MwSQRzXbAWyrUVxVtQSM3dO0vXTrgZ-VT9FM96pMsdDVd2zKa07aFCilOc-R8qwQ2HHbwKRI_QMMF6qOBMXGtuUNptDw9gyKwmu5AFfjN95MSNpVYwzqx4NwowvLZY4orH2cC7u-On__y8RKAJaY-QmGX6DVwX41J767lxccGzQy_JtW1hdGURMG9Ww1Dx3INU5zFJhWFvhE-m7iGISdU7pHgz8m/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.isfa600%2Fjavapl.htm
>https://secure-web.cisco.com/1zFANvxnN-Dhuwa935zAHZy-EGDHensMOypnd8RTMRlIS2WOp6sJoAvN0usO3YOYTJIFrk-bToHx2WW5fYmSf53aLyPb_TehXxME3Na1bX_OFsla8mbzMX0j25OuLa3gdQGpXqfZYnHASU2hgV0IkHK3r9qX9jSLRX0fV9JRbp0MkOV65v6T7UEcb1z_ESO8fbdUER3o8ZNAiJkgvi-InFvmwOUoMbtQx-8BSgZV2LjMOdVZPQFz5xICFGhj1FtGsl5G-3GS2db1oaZhFZD1Wr8omFKQWw42zEYn5evCPT6GBKshQihzfYg4ykVeYJEOg4IXCNgu5v7kXGjCO5gEMT2WXeUGlOA8Q3vd3lytzQFYhIE_P2fJe4ohCvol_LuDOMlQJZjX9sZmOXWLalgeYWuEOin3w9SeXWpQkQ3j6b5VFqo-1aJL40kQ4aLmakOa0/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.ieaf200%2Fsapi.htm
>
>https://secure-web.cisco.com/1BvTJtcZPW2rTFWUIdWuFSoMzmrGIK0tGrqB3zg19Vs0zAdwRI9qiAYzym6TbaZqh4UItlBjYBN7fLffyFis9WEGzfrcovQ63tl8HNbHWD6fgCVIK188e3Ryf2d0cXb5r4tlcfY6S0n93mocduVeaAd8rg9LvjNqTkAXlQh1K34pYUCQbdIbFyquSFblsMxA3_4x2fSvzoiidnjCNtKStD8REt_rDsyTA-LFcBKyWsmz0DcEgBFhPx7ZB3pejGwykHkWuX0mk9k0nplYG1tlwd4Pk_uU92m6eWwNvAU0eoHCJFkQ06Lzt0-EJYEIM3H7lUHrA28uzMMUgqCBT-9zEuYrDxB2QGOKVbb2iLsSggVrHllgugbSfOKuvQzP-IjiwNae9wiX7yGQGGnLLZ0Pfu3r0-rxU7j1T-VFdQBTI7_ie1Rgo30td5A9AlEjT1Vax/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.hasc300%2Fspbrowse.htm

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

Re: Queue-less | Shark Tank Computerworld

2019-05-24 Thread Paul Gilmartin 
On Fri, 24 May 2019 19:18:57 +, Seymour J Metz wrote:

>Possible, but there are some discrepancies.
>
> 1. Why would he write a program instead of using an IBM utility?
> 
I did that once on a 1401 where there was no IBM utility.  It was to print
a CDC tape with idiosyncratic blocking.  I shared it with Ops, who immediately
cherished it because it printed a page count at end-of-job, needed for supplies
chargeback.

The only alternative format CDC supported was one block per line.

> 2. Have you ever seen an EAM shop that didn't have an 80-80 board already 
> wired? 

-- gil

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

Re: SDSF API question -- why only REXX & Java?

2019-05-24 Thread Tony Thigpen 

Someone spent a lot of time to figure that method out.

Tony Thigpen

Alan Young wrote on 5/24/19 8:33 PM:

The Implementing REXX Support in SDSF redbook ( 
http://www.redbooks.ibm.com/abstracts/sg247419.html?Open ) has some sample code 
for COBOL to call the SDSF interface via REXX.

-Original Message-

From: Seymour J Metz
Sent: May 24, 2019 1:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF API question -- why only REXX & Java?

Well, REXX has an interface for a routine to set REXX variables. There is no 
equivalent for, e.g., COBOL.

It's not a question of compiled versus not compiled; it's a question of what 
interfaces are available to the called program. A compiled REXX program can 
call SDSF; a COBOL program running in a COBOL interpreter would not be able to 
do so.


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


From: IBM Mainframe Discussion List  on behalf of John McKown
Sent: Thursday, May 23, 2019 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF API question -- why only REXX & Java?

This is just a curiosity question. The SDSF book shows an API for using it
in REXX and Java. Anybody know why no other languages? Or are we supposed
to use SAPI for compiled languages instead of the SDSF API? Or is it SPOOL
Dataset Browser that we are supposed to use?

https://secure-web.cisco.com/1Cyt5vo8aV4_qK2suQCO_GWm_QmJIDuKVD1C8rfk1n4g638ku6ucLVwv4s4YlkBtaC0hsyyR_CQuojt3RVXCbUSxCA_FJYEM4JPpiZqKG_mrzHhdEpkC-KCMfKlxdGBuIVbFO2uR3Etk_ATGNSK4F5kf2ZnLZT4bNQ87CU-09l7bkTgENQXo5DFXjFyxYeK9128nFQxi-YnO7E_LrTzLvo0Imniw628DF-VgOqQdmTEO7jnqfM4mDtfw-QOtQO4YBG81AEJMXH1OmDSMW9sNFq2J1zK0kfo0mBxAA0CW4bPBDKNgakK64nke4s9kI3HOzeRNLGrhSeSqPHUA0jDQgU1Ci7-PWeEnivPOkFEBg_wZf2yrgKxG_ibLLsJqvaJ-Lprm4N3ZRs5nRRVNlNZKW-2ZuWbhm9okzzDuLdXpKHFWWk4OleXBT8YfArhbJMUqz/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.isfa600%2Frexx.htm

https://secure-web.cisco.com/1hSr4kg3404Net4sgvUUKBkObpOfAi-doK-a25Ywyd_DA3sg7IIowuk6r-jkqsGJN0vxPNXDG2PTF2ebREfXfAaRZYfEl_85XL9Z2EfkNHufGIs7c_qMw-dwvKkBqvc42qIu5KEPjwSmfYXLuWOMjJf6YHwvhRwBuEalacziPkzDXVMrCUyeJvEBsG9WahktYSrwbggfqsO4NXx5OskbS8JkVbrvVj37VtFr-MwSQRzXbAWyrUVxVtQSM3dO0vXTrgZ-VT9FM96pMsdDVd2zKa07aFCilOc-R8qwQ2HHbwKRI_QMMF6qOBMXGtuUNptDw9gyKwmu5AFfjN95MSNpVYwzqx4NwowvLZY4orH2cC7u-On__y8RKAJaY-QmGX6DVwX41J767lxccGzQy_JtW1hdGURMG9Ww1Dx3INU5zFJhWFvhE-m7iGISdU7pHgz8m/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.isfa600%2Fjavapl.htm
https://secure-web.cisco.com/1zFANvxnN-Dhuwa935zAHZy-EGDHensMOypnd8RTMRlIS2WOp6sJoAvN0usO3YOYTJIFrk-bToHx2WW5fYmSf53aLyPb_TehXxME3Na1bX_OFsla8mbzMX0j25OuLa3gdQGpXqfZYnHASU2hgV0IkHK3r9qX9jSLRX0fV9JRbp0MkOV65v6T7UEcb1z_ESO8fbdUER3o8ZNAiJkgvi-InFvmwOUoMbtQx-8BSgZV2LjMOdVZPQFz5xICFGhj1FtGsl5G-3GS2db1oaZhFZD1Wr8omFKQWw42zEYn5evCPT6GBKshQihzfYg4ykVeYJEOg4IXCNgu5v7kXGjCO5gEMT2WXeUGlOA8Q3vd3lytzQFYhIE_P2fJe4ohCvol_LuDOMlQJZjX9sZmOXWLalgeYWuEOin3w9SeXWpQkQ3j6b5VFqo-1aJL40kQ4aLmakOa0/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.ieaf200%2Fsapi.htm

https://secure-web.cisco.com/1BvTJtcZPW2rTFWUIdWuFSoMzmrGIK0tGrqB3zg19Vs0zAdwRI9qiAYzym6TbaZqh4UItlBjYBN7fLffyFis9WEGzfrcovQ63tl8HNbHWD6fgCVIK188e3Ryf2d0cXb5r4tlcfY6S0n93mocduVeaAd8rg9LvjNqTkAXlQh1K34pYUCQbdIbFyquSFblsMxA3_4x2fSvzoiidnjCNtKStD8REt_rDsyTA-LFcBKyWsmz0DcEgBFhPx7ZB3pejGwykHkWuX0mk9k0nplYG1tlwd4Pk_uU92m6eWwNvAU0eoHCJFkQ06Lzt0-EJYEIM3H7lUHrA28uzMMUgqCBT-9zEuYrDxB2QGOKVbb2iLsSggVrHllgugbSfOKuvQzP-IjiwNae9wiX7yGQGGnLLZ0Pfu3r0-rxU7j1T-VFdQBTI7_ie1Rgo30td5A9AlEjT1Vax/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.hasc300%2Fspbrowse.htm


--
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


Maranatha! <><
John McKown

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

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


--
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: SDSF API question -- why only REXX & Java?

2019-05-24 Thread Alan Young 
The Implementing REXX Support in SDSF redbook ( 
http://www.redbooks.ibm.com/abstracts/sg247419.html?Open ) has some sample code 
for COBOL to call the SDSF interface via REXX.

-Original Message-
>From: Seymour J Metz 
>Sent: May 24, 2019 1:01 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: SDSF API question -- why only REXX & Java?
>
>Well, REXX has an interface for a routine to set REXX variables. There is no 
>equivalent for, e.g., COBOL.
>
>It's not a question of compiled versus not compiled; it's a question of what 
>interfaces are available to the called program. A compiled REXX program can 
>call SDSF; a COBOL program running in a COBOL interpreter would not be able to 
>do so.
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on behalf of John McKown 
>Sent: Thursday, May 23, 2019 3:05 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: SDSF API question -- why only REXX & Java?
>
>This is just a curiosity question. The SDSF book shows an API for using it
>in REXX and Java. Anybody know why no other languages? Or are we supposed
>to use SAPI for compiled languages instead of the SDSF API? Or is it SPOOL
>Dataset Browser that we are supposed to use?
>
>https://secure-web.cisco.com/1Cyt5vo8aV4_qK2suQCO_GWm_QmJIDuKVD1C8rfk1n4g638ku6ucLVwv4s4YlkBtaC0hsyyR_CQuojt3RVXCbUSxCA_FJYEM4JPpiZqKG_mrzHhdEpkC-KCMfKlxdGBuIVbFO2uR3Etk_ATGNSK4F5kf2ZnLZT4bNQ87CU-09l7bkTgENQXo5DFXjFyxYeK9128nFQxi-YnO7E_LrTzLvo0Imniw628DF-VgOqQdmTEO7jnqfM4mDtfw-QOtQO4YBG81AEJMXH1OmDSMW9sNFq2J1zK0kfo0mBxAA0CW4bPBDKNgakK64nke4s9kI3HOzeRNLGrhSeSqPHUA0jDQgU1Ci7-PWeEnivPOkFEBg_wZf2yrgKxG_ibLLsJqvaJ-Lprm4N3ZRs5nRRVNlNZKW-2ZuWbhm9okzzDuLdXpKHFWWk4OleXBT8YfArhbJMUqz/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.isfa600%2Frexx.htm
>
>https://secure-web.cisco.com/1hSr4kg3404Net4sgvUUKBkObpOfAi-doK-a25Ywyd_DA3sg7IIowuk6r-jkqsGJN0vxPNXDG2PTF2ebREfXfAaRZYfEl_85XL9Z2EfkNHufGIs7c_qMw-dwvKkBqvc42qIu5KEPjwSmfYXLuWOMjJf6YHwvhRwBuEalacziPkzDXVMrCUyeJvEBsG9WahktYSrwbggfqsO4NXx5OskbS8JkVbrvVj37VtFr-MwSQRzXbAWyrUVxVtQSM3dO0vXTrgZ-VT9FM96pMsdDVd2zKa07aFCilOc-R8qwQ2HHbwKRI_QMMF6qOBMXGtuUNptDw9gyKwmu5AFfjN95MSNpVYwzqx4NwowvLZY4orH2cC7u-On__y8RKAJaY-QmGX6DVwX41J767lxccGzQy_JtW1hdGURMG9Ww1Dx3INU5zFJhWFvhE-m7iGISdU7pHgz8m/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.isfa600%2Fjavapl.htm
>https://secure-web.cisco.com/1zFANvxnN-Dhuwa935zAHZy-EGDHensMOypnd8RTMRlIS2WOp6sJoAvN0usO3YOYTJIFrk-bToHx2WW5fYmSf53aLyPb_TehXxME3Na1bX_OFsla8mbzMX0j25OuLa3gdQGpXqfZYnHASU2hgV0IkHK3r9qX9jSLRX0fV9JRbp0MkOV65v6T7UEcb1z_ESO8fbdUER3o8ZNAiJkgvi-InFvmwOUoMbtQx-8BSgZV2LjMOdVZPQFz5xICFGhj1FtGsl5G-3GS2db1oaZhFZD1Wr8omFKQWw42zEYn5evCPT6GBKshQihzfYg4ykVeYJEOg4IXCNgu5v7kXGjCO5gEMT2WXeUGlOA8Q3vd3lytzQFYhIE_P2fJe4ohCvol_LuDOMlQJZjX9sZmOXWLalgeYWuEOin3w9SeXWpQkQ3j6b5VFqo-1aJL40kQ4aLmakOa0/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.ieaf200%2Fsapi.htm
>
>https://secure-web.cisco.com/1BvTJtcZPW2rTFWUIdWuFSoMzmrGIK0tGrqB3zg19Vs0zAdwRI9qiAYzym6TbaZqh4UItlBjYBN7fLffyFis9WEGzfrcovQ63tl8HNbHWD6fgCVIK188e3Ryf2d0cXb5r4tlcfY6S0n93mocduVeaAd8rg9LvjNqTkAXlQh1K34pYUCQbdIbFyquSFblsMxA3_4x2fSvzoiidnjCNtKStD8REt_rDsyTA-LFcBKyWsmz0DcEgBFhPx7ZB3pejGwykHkWuX0mk9k0nplYG1tlwd4Pk_uU92m6eWwNvAU0eoHCJFkQ06Lzt0-EJYEIM3H7lUHrA28uzMMUgqCBT-9zEuYrDxB2QGOKVbb2iLsSggVrHllgugbSfOKuvQzP-IjiwNae9wiX7yGQGGnLLZ0Pfu3r0-rxU7j1T-VFdQBTI7_ie1Rgo30td5A9AlEjT1Vax/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.hasc300%2Fspbrowse.htm
>
>
>--
>This is clearly another case of too many mad scientists, and not enough
>hunchbacks.
>
>
>Maranatha! <><
>John McKown
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SDSF API question -- why only REXX & Java?

2019-05-24 Thread Seymour J Metz 
Well, REXX has an interface for a routine to set REXX variables. There is no 
equivalent for, e.g., COBOL.

It's not a question of compiled versus not compiled; it's a question of what 
interfaces are available to the called program. A compiled REXX program can 
call SDSF; a COBOL program running in a COBOL interpreter would not be able to 
do so.




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


From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Thursday, May 23, 2019 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF API question -- why only REXX & Java?

This is just a curiosity question. The SDSF book shows an API for using it
in REXX and Java. Anybody know why no other languages? Or are we supposed
to use SAPI for compiled languages instead of the SDSF API? Or is it SPOOL
Dataset Browser that we are supposed to use?

https://secure-web.cisco.com/1Cyt5vo8aV4_qK2suQCO_GWm_QmJIDuKVD1C8rfk1n4g638ku6ucLVwv4s4YlkBtaC0hsyyR_CQuojt3RVXCbUSxCA_FJYEM4JPpiZqKG_mrzHhdEpkC-KCMfKlxdGBuIVbFO2uR3Etk_ATGNSK4F5kf2ZnLZT4bNQ87CU-09l7bkTgENQXo5DFXjFyxYeK9128nFQxi-YnO7E_LrTzLvo0Imniw628DF-VgOqQdmTEO7jnqfM4mDtfw-QOtQO4YBG81AEJMXH1OmDSMW9sNFq2J1zK0kfo0mBxAA0CW4bPBDKNgakK64nke4s9kI3HOzeRNLGrhSeSqPHUA0jDQgU1Ci7-PWeEnivPOkFEBg_wZf2yrgKxG_ibLLsJqvaJ-Lprm4N3ZRs5nRRVNlNZKW-2ZuWbhm9okzzDuLdXpKHFWWk4OleXBT8YfArhbJMUqz/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.isfa600%2Frexx.htm

https://secure-web.cisco.com/1hSr4kg3404Net4sgvUUKBkObpOfAi-doK-a25Ywyd_DA3sg7IIowuk6r-jkqsGJN0vxPNXDG2PTF2ebREfXfAaRZYfEl_85XL9Z2EfkNHufGIs7c_qMw-dwvKkBqvc42qIu5KEPjwSmfYXLuWOMjJf6YHwvhRwBuEalacziPkzDXVMrCUyeJvEBsG9WahktYSrwbggfqsO4NXx5OskbS8JkVbrvVj37VtFr-MwSQRzXbAWyrUVxVtQSM3dO0vXTrgZ-VT9FM96pMsdDVd2zKa07aFCilOc-R8qwQ2HHbwKRI_QMMF6qOBMXGtuUNptDw9gyKwmu5AFfjN95MSNpVYwzqx4NwowvLZY4orH2cC7u-On__y8RKAJaY-QmGX6DVwX41J767lxccGzQy_JtW1hdGURMG9Ww1Dx3INU5zFJhWFvhE-m7iGISdU7pHgz8m/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.isfa600%2Fjavapl.htm
https://secure-web.cisco.com/1zFANvxnN-Dhuwa935zAHZy-EGDHensMOypnd8RTMRlIS2WOp6sJoAvN0usO3YOYTJIFrk-bToHx2WW5fYmSf53aLyPb_TehXxME3Na1bX_OFsla8mbzMX0j25OuLa3gdQGpXqfZYnHASU2hgV0IkHK3r9qX9jSLRX0fV9JRbp0MkOV65v6T7UEcb1z_ESO8fbdUER3o8ZNAiJkgvi-InFvmwOUoMbtQx-8BSgZV2LjMOdVZPQFz5xICFGhj1FtGsl5G-3GS2db1oaZhFZD1Wr8omFKQWw42zEYn5evCPT6GBKshQihzfYg4ykVeYJEOg4IXCNgu5v7kXGjCO5gEMT2WXeUGlOA8Q3vd3lytzQFYhIE_P2fJe4ohCvol_LuDOMlQJZjX9sZmOXWLalgeYWuEOin3w9SeXWpQkQ3j6b5VFqo-1aJL40kQ4aLmakOa0/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.ieaf200%2Fsapi.htm

https://secure-web.cisco.com/1BvTJtcZPW2rTFWUIdWuFSoMzmrGIK0tGrqB3zg19Vs0zAdwRI9qiAYzym6TbaZqh4UItlBjYBN7fLffyFis9WEGzfrcovQ63tl8HNbHWD6fgCVIK188e3Ryf2d0cXb5r4tlcfY6S0n93mocduVeaAd8rg9LvjNqTkAXlQh1K34pYUCQbdIbFyquSFblsMxA3_4x2fSvzoiidnjCNtKStD8REt_rDsyTA-LFcBKyWsmz0DcEgBFhPx7ZB3pejGwykHkWuX0mk9k0nplYG1tlwd4Pk_uU92m6eWwNvAU0eoHCJFkQ06Lzt0-EJYEIM3H7lUHrA28uzMMUgqCBT-9zEuYrDxB2QGOKVbb2iLsSggVrHllgugbSfOKuvQzP-IjiwNae9wiX7yGQGGnLLZ0Pfu3r0-rxU7j1T-VFdQBTI7_ie1Rgo30td5A9AlEjT1Vax/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.hasc300%2Fspbrowse.htm


--
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


Maranatha! <><
John McKown

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

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

Re: Queue-less | Shark Tank Computerworld

2019-05-24 Thread Seymour J Metz 
Possible, but there are some discrepancies.

 1. Why would he write a program instead of using an IBM utility?

 2. Have you ever seen an EAM shop that didn't have an 80-80 board already 
wired? 


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


From: IBM Mainframe Discussion List  on behalf of 
Mark Regan 
Sent: Friday, May 24, 2019 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Queue-less | Shark Tank Computerworld

https://secure-web.cisco.com/1UFR-0jj4L-UZaX3jz8HMAXlESyDJLkfxR6T5amXqslvEFOBSqryCaynCS7oIzbQyjnl0jhdAxByybfVHcBRC8G6tffkqicUPAvQTsHgdPkTaM2hk7HPGOzD8MdC6PAdIriff7_8gRlhWp96YrXNY4GpQzvjrQVzxMyu3ITXStcugsIrQdQPiS6AVyNmkQmbdGxtXQm3FAeDGFXjUNksHDvO9MS7jDKBXGzeourfOZyShEorUVgHkFG1UXHvdBzvvF041cYNKOpTV-yzhH3-O3tvhjEkMZFVAH_BG5qGD1mnCKKYbvnTiy6JHYWcTAz8eQ1R39QkZbDAcgNUCeq7IqF89bTem0Mge8qc8_GUdCld4GKTWPpf9WotrPJRFDWgoKA9xO_Oukf_IxuK2OWR-3g/https%3A%2F%2Fwww.computerworld.com%2Farticle%2F3396127%2Fqueue-less.html

Regards,

Mark Regan, USNR-Retired, Nationwide Insurance, Retired

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

CBT File 120 revisited

2019-05-24 Thread Sam Golob 

Hi Folks,

    For almost 20 years, I wrote a monthly column for NaSPA's magazine 
"Technical Support", which was entitled "MVS Tools and Tricks of the 
Trade".  The administrators of NaSPA had kindly allowed me to distribute 
these articles on File 120 of the CBT Tape.  (See www.cbttape.org 
Updates page, File 120.).  I am very grateful to Scott Sherer and to all 
of their officers (from that time) for giving their permission.


    A few years have passed since I touched this file, and upon looking 
there, I noticed that time has brought some changes.


    First, at the time many of the articles were written, you had to 
order the CBT Tapes, in physical form, from NaSPA.  Now, you just have 
to go to www.cbttape.org and download what you want (check the Updates 
Page first!!!)


    A few other changes have also occurred, such as my contact address, 
and so forth.  So I tried to fix File 120 accordingly, at least a bit.


    Nevertheless, a lot has not changed.  Many of these articles are 
just as relevant today, as they were the day they were written.  
Therefore I'm bringing this file to your attention, so you can see what 
you can glean from it.


    Hope it helps

    All the best of everything to all of you..

Sincerely,    Sam

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

Moving ECKD to FCP

2019-05-24 Thread Ken Bloom 
question.  Need to move ECKD Linux to FCP.  is there a simple way to copy the 
volumes or do we need to reinstall as FCP?   Currently running as a VM. Guest. 

Thanks
Ken

Kenneth A. Bloom
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com


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

Re: RSUs

2019-05-24 Thread Jousma, David 
Bob,

I'm not exactly sure what you are asking but if you just run this, it 
automatically uploads the bitmap to IBM before the order is built.  The manual 
process is only needed if you are actually logging on to ShopZ website to place 
orders.I only use that when I want to update ShopZ to correctly filter all 
my installed product versions when ordering PDO's for individual product 
refreshes between z/OS Serverpac orders.   The only requirement for this to run 
is that you have to be able to communicate with IBM servers from the mainframe 
you are running from.Here, they let me open the firewall for outbound 
connections to IBM only on-demand. 

  SETBOUNDARY (GLOBAL) .  
  RECEIVE ORDER   (CLIENT  (CLIENT)   
   CONTENT (ALL)  
   ORDERSERVER (SERVER)   
   FORTGTZONES (MVSTZN MVSCBT)
   WAIT(120)) 
  DELETEPKG.  

_
Dave Jousma
AVP | Manager, Systems Engineering  

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Richards, Robert B.
Sent: Friday, May 24, 2019 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

**CAUTION EXTERNAL EMAIL**

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

Dave,

There's my first problem!  I have been using Shopz's RFN with the package they 
create.  :-(

I had already stopped using Shopz for daily PTFs orders indicated by Missing 
Fix, etc., using RECEIVE ORDER processing instead.

I saw your example for the inventory. Can the two steps be automatically 
combined in a batch job and not use SHOPz at all?

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, May 24, 2019 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

Bob,  I'm sure Kurt will give a more complete answer, but the RECEIVE ORDER 
Process first uploads an inventory to IBM.  Then the order process only sends 
you what you don’t have.



_
Dave Jousma
AVP | Manager, Systems Engineering  

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Richards, Robert B.
Sent: Friday, May 24, 2019 10:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

**CAUTION EXTERNAL EMAIL**

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

Kurt,

Speaking of RSUs, is there a way to provide an inventory of PTFs already 
received so that I don't end up reordering and transmitting gigabytes of PTFs 
that have already been ordered, downloaded and received? As it is now, I am 
forced to run the RSU job on the weekend so that I stop getting the "17 of 20" 
failures after hours of wall clock time.

And while I am thinking of enhancements, how about an optional check of a mask 
against a mask of the DDDEF volser that would flag a difference? Yeah, I know, 
the file allocation report is supposed to be the last line of defense, but 
sometimes it is tough to spot a one character difference. Ask me how I know. 
Still not sure why a coworker changed it without letting others know.  

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Friday, May 24, 2019 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote:

> We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the 
> "New Service Levels" email), and got a number of fixes for RSU1903. Over the 
> last couple of days, it's been discovered that we are missing a few PTFs that 
> would be part of RSU1903 - or earlier.
> 
> Yesterday, I therefore as an exercise did another RECEIVE ORDER 
> CONTENT(RECOMMENDED), and this time got more fixes for RSU1903.
> 
> Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU 
> date?
No, IBM does NOT assign RSU sourceids to PTFs retroactively after the published 
RSU date.  At least its not supposed to work that way.  Are you sure on your 
second RECEIVE ORDER one or more ASSIGN statements for
RSU1903 were received?  Or did you specify the RSU1903 SOURCEID on the RECEIVE 
command your self?  If you did receive such ASSIGN statements, and if you still 
have it, I'd like to see the RECEIVE command output for both jobs please.

BTW, as already mentioned, consider using CONTENT(ALL) instead of

Numerous notifications from Broadcom...

2019-05-24 Thread Brian France 
Anyone else out there getting numerous notifications, around 300 now,
from Broadcom regarding the release of CAIRIM 2.2? I've contacted them
but I really don't think the person on the other end understands that
something happened yesterday around 11am and hasn't stopped. Got bug
somewhere they do.

On 5/24/19 10:14 AM, Richards, Robert B. wrote:
> Kurt,
>
> Speaking of RSUs, is there a way to provide an inventory of PTFs already 
> received so that I don't end up reordering and transmitting gigabytes of PTFs 
> that have already been ordered, downloaded and received? As it is now, I am 
> forced to run the RSU job on the weekend so that I stop getting the "17 of 
> 20" failures after hours of wall clock time.
>
> And while I am thinking of enhancements, how about an optional check of a 
> mask against a mask of the DDDEF volser that would flag a difference? Yeah, I 
> know, the file allocation report is supposed to be the last line of defense, 
> but sometimes it is tough to spot a one character difference. Ask me how I 
> know. Still not sure why a coworker changed it without letting others know.  
>
> Bob
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Kurt Quackenbush
> Sent: Friday, May 24, 2019 9:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RSUs
>
> On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote:
>
>> We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the 
>> "New Service Levels" email), and got a number of fixes for RSU1903. Over the 
>> last couple of days, it's been discovered that we are missing a few PTFs 
>> that would be part of RSU1903 - or earlier.
>>
>> Yesterday, I therefore as an exercise did another RECEIVE ORDER 
>> CONTENT(RECOMMENDED), and this time got more fixes for RSU1903.
>>
>> Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU 
>> date?
> No, IBM does NOT assign RSU sourceids to PTFs retroactively after the 
> published RSU date.  At least its not supposed to work that way.  Are 
> you sure on your second RECEIVE ORDER one or more ASSIGN statements for 
> RSU1903 were received?  Or did you specify the RSU1903 SOURCEID on the 
> RECEIVE command your self?  If you did receive such ASSIGN statements, 
> and if you still have it, I'd like to see the RECEIVE command output for 
> both jobs please.
>
> BTW, as already mentioned, consider using CONTENT(ALL) instead of 
> CONTENT(RECOMMENDED) in the future.  I'm hard pressed to think of a good 
> reason to only obtain recommended PTFs these days.
>
> Kurt Quackenbush -- IBM, SMP/E Development
> Chuck Norris never uses CHECK when he applies PTFs.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

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

Binder control statements and `ld'

2019-05-24 Thread Pew, Curtis G 
Cross-posted to IBM-MAIN and MVS-OE.

I’m trying to convert some existing programming and installation tasks to use 
`make’ instead of having to maintain JCL. However, in some cases we are 
currently using the REPLACE and RENAME binder control statements, and I can’t 
see a way to pass those the the `ld’ command. The entry for `ld’ in “Unix 
System Services Command Reference” only tells how to pass object modules, 
archives, and side decks, but not control statements. Am I missing something, 
or is this just not possible?

--
Pew, Curtis G
curtis@austin.utexas.edu






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

Re: RSUs

2019-05-24 Thread Richards, Robert B. 
Dave,

There's my first problem!  I have been using Shopz's RFN with the package they 
create.  :-(

I had already stopped using Shopz for daily PTFs orders indicated by Missing 
Fix, etc., using RECEIVE ORDER processing instead.

I saw your example for the inventory. Can the two steps be automatically 
combined in a batch job and not use SHOPz at all?

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, May 24, 2019 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

Bob,  I'm sure Kurt will give a more complete answer, but the RECEIVE ORDER 
Process first uploads an inventory to IBM.  Then the order process only sends 
you what you don’t have.



_
Dave Jousma
AVP | Manager, Systems Engineering  

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Richards, Robert B.
Sent: Friday, May 24, 2019 10:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

**CAUTION EXTERNAL EMAIL**

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

Kurt,

Speaking of RSUs, is there a way to provide an inventory of PTFs already 
received so that I don't end up reordering and transmitting gigabytes of PTFs 
that have already been ordered, downloaded and received? As it is now, I am 
forced to run the RSU job on the weekend so that I stop getting the "17 of 20" 
failures after hours of wall clock time.

And while I am thinking of enhancements, how about an optional check of a mask 
against a mask of the DDDEF volser that would flag a difference? Yeah, I know, 
the file allocation report is supposed to be the last line of defense, but 
sometimes it is tough to spot a one character difference. Ask me how I know. 
Still not sure why a coworker changed it without letting others know.  

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Friday, May 24, 2019 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote:

> We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the 
> "New Service Levels" email), and got a number of fixes for RSU1903. Over the 
> last couple of days, it's been discovered that we are missing a few PTFs that 
> would be part of RSU1903 - or earlier.
> 
> Yesterday, I therefore as an exercise did another RECEIVE ORDER 
> CONTENT(RECOMMENDED), and this time got more fixes for RSU1903.
> 
> Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU 
> date?
No, IBM does NOT assign RSU sourceids to PTFs retroactively after the published 
RSU date.  At least its not supposed to work that way.  Are you sure on your 
second RECEIVE ORDER one or more ASSIGN statements for
RSU1903 were received?  Or did you specify the RSU1903 SOURCEID on the RECEIVE 
command your self?  If you did receive such ASSIGN statements, and if you still 
have it, I'd like to see the RECEIVE command output for both jobs please.

BTW, as already mentioned, consider using CONTENT(ALL) instead of
CONTENT(RECOMMENDED) in the future.  I'm hard pressed to think of a good reason 
to only obtain recommended PTFs these days.

Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when 
he applies PTFs.

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

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

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


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

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

Re: RSUs

2019-05-24 Thread Styles, Andy (ITS zPlatform Services) 
Classification: Public
I have the SMPGLOG (GLOBAL log), but not the jobs. I'm reluctant to post a 
large amount of SMPLOG output here, but here (hopefully relevant) snippets:

RECEIVE  
  ORDER(ORDERSERVER(ORDRINFO)
CONTENT(RECOMMENDED) 
CLIENT(CLNTINFO) 
  )  
 .   

ORDER ORD00018 HAS BEEN SENT TO THE SERVER AT 
https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/.

ENQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF ORD00018-05April2019-08.45.34.407 FOR 
RECEIVE PROCESSING.

We then received a bunch of PTFs as a result - I can list them if you wish. 
Now, yesterday I noticed that I didn't specify a target zone here. There are 
two target zones in the GLOBAL zone - the previous iteration of this process, 
and a clone of it (which is the one RSU1903 was eventually applied to), so we 
can look across multiple target zones to see if/where a PTF is applied. 

When I re-did the RECEIVE ORDER, I added FORTGTZONE, though to me, that should 
have made no difference. 

I then ended up with this:

RECEIVE  
  ORDER(ORDERSERVER(ORDRINFO)
CONTENT(RECOMMENDED) 
CLIENT(CLNTINFO) 
FORTGTZONES(TGTD)
  )  
 .   

ORDER ORD00020 HAS BEEN SENT TO THE SERVER AT 
https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/.

ENQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF ORD00020-22May2019-17.19.02.141 FOR 
RECEIVE PROCESSING.

And then received the following fixes:

SYSMOD ENTRY UA98295 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98305 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98317 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98340 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98341 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98707 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98723 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98804 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98840 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98845 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98920 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98954 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA98965 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99018 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99029 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99050 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99059 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99094 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99149 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99208 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99224 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99278 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99283 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UA99306 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI60691 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI61245 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI61642 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI61783 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI62355 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI62458 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI62648 WAS STORED IN THE GLOBAL ZONE.
SYSMOD ENTRY UI63041 WAS STORED IN THE GLOBAL ZONE.

Now, looking back through the log, I can also see quite a few messages like 
this:

MCS UA98840 WAS DELETED FROM THE SMPPTS LIBRARY.
MCS UA98840 WAS DELETED FROM THE SMPPTS1 LIBRARY.   
MCS ENTRY UA98840 WAS STORED IN THE SMPPTS LIBRARY. 
SYSMOD ENTRY UA98840 WAS STORED IN THE GLOBAL ZONE. 
RECEIVE PROCESSING WAS SUCCESSFUL FOR SYSMOD UA98840.   

Which confuses me (not difficult) - why is it already in the SMPPTS dataset? 
Nonetheless, I didn't do a REJECT of anything first, so it was RECEIVEd ok.

Andy Styles
z/Series System Programmer




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: 24 May 2019 14:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

-- This email has reached the Bank via an external source --
 

On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote:

> We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the 
> "New Service Levels" email), and got a number of fixes for RSU1903. Over the 
> last couple of days, it's been discovered that we are missing a few PTFs that 
> would be part of RSU1903 - or earlier.
> 
> Yesterday, I therefore as an exercise did another RECEIVE ORDER 
> CONTENT(RECOMMENDED), and this time got more fixes for RSU1903.
> 
> Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU 
> date?
No, IBM does NOT assign RSU sourceids to PTFs retroactively after the published 
RSU date.  At least its not supposed to work that way.  Are you sure on your 
second RECEIVE ORDER one or more ASSIGN statements for
RSU1903 were received?  Or did you specify the RSU1903 SOURCEID on the RECEIVE 
command

Re: RSUs

2019-05-24 Thread Jousma, David 
I think that the process is similar if ordering manually via ShopZ.  The only 
difference is you have run the inventory job against your zones first, upload 
that to ShopZ, and use that uploaded report when placing your order for 
maintenance.

//STEP1EXEC PGM=GIMXSID,PARM='WAIT=10MIN,L=ENU' 
//SYSPRINT DD SYSOUT=*  
//SMPOUT   DD SYSOUT=*  
//SMPXTOUT DD PATH='/tmp/smpefeatures23',   
//PATHOPTS=(OWRONLY,OCREAT,OTRUNC), 
//FILEDATA=BINARY,PATHMODE=(SIRWXU,SIRWXG,SIRWXO)   
//SYSINDD DATA,DLM=$$   
CSI=SMPE.ZOS23.GLOBAL.CSI   
TARGET=MVSTZN   

_
Dave Jousma
AVP | Manager, Systems Engineering  

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



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Friday, May 24, 2019 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

**CAUTION EXTERNAL EMAIL**

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

Bob,  I'm sure Kurt will give a more complete answer, but the RECEIVE ORDER 
Process first uploads an inventory to IBM.  Then the order process only sends 
you what you don’t have.



_
Dave Jousma
AVP | Manager, Systems Engineering  

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Richards, Robert B.
Sent: Friday, May 24, 2019 10:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

**CAUTION EXTERNAL EMAIL**

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

Kurt,

Speaking of RSUs, is there a way to provide an inventory of PTFs already 
received so that I don't end up reordering and transmitting gigabytes of PTFs 
that have already been ordered, downloaded and received? As it is now, I am 
forced to run the RSU job on the weekend so that I stop getting the "17 of 20" 
failures after hours of wall clock time.

And while I am thinking of enhancements, how about an optional check of a mask 
against a mask of the DDDEF volser that would flag a difference? Yeah, I know, 
the file allocation report is supposed to be the last line of defense, but 
sometimes it is tough to spot a one character difference. Ask me how I know. 
Still not sure why a coworker changed it without letting others know.  

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Friday, May 24, 2019 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote:

> We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the 
> "New Service Levels" email), and got a number of fixes for RSU1903. Over the 
> last couple of days, it's been discovered that we are missing a few PTFs that 
> would be part of RSU1903 - or earlier.
> 
> Yesterday, I therefore as an exercise did another RECEIVE ORDER 
> CONTENT(RECOMMENDED), and this time got more fixes for RSU1903.
> 
> Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU 
> date?
No, IBM does NOT assign RSU sourceids to PTFs retroactively after the published 
RSU date.  At least its not supposed to work that way.  Are you sure on your 
second RECEIVE ORDER one or more ASSIGN statements for
RSU1903 were received?  Or did you specify the RSU1903 SOURCEID on the RECEIVE 
command your self?  If you did receive such ASSIGN statements, and if you still 
have it, I'd like to see the RECEIVE command output for both jobs please.

BTW, as already mentioned, consider using CONTENT(ALL) instead of
CONTENT(RECOMMENDED) in the future.  I'm hard pressed to think of a good reason 
to only obtain recommended PTFs these days.

Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when 
he applies PTFs.

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

Re: RSUs

2019-05-24 Thread Tom Marchant 
On Fri, 24 May 2019 09:38:22 -0400, Kurt Quackenbush wrote:

> If you did receive such ASSIGN statements,
>and if you still have it, I'd like to see the RECEIVE command output for
>both jobs please.

If he doesn't have the jobs, will the data from the SMPLOG for that period help?

-- 
Tom Marchant

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

Re: RSUs

2019-05-24 Thread Jousma, David 
Bob,  I'm sure Kurt will give a more complete answer, but the RECEIVE ORDER 
Process first uploads an inventory to IBM.  Then the order process only sends 
you what you don’t have.



_
Dave Jousma
AVP | Manager, Systems Engineering  

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Richards, Robert B.
Sent: Friday, May 24, 2019 10:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

**CAUTION EXTERNAL EMAIL**

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

Kurt,

Speaking of RSUs, is there a way to provide an inventory of PTFs already 
received so that I don't end up reordering and transmitting gigabytes of PTFs 
that have already been ordered, downloaded and received? As it is now, I am 
forced to run the RSU job on the weekend so that I stop getting the "17 of 20" 
failures after hours of wall clock time.

And while I am thinking of enhancements, how about an optional check of a mask 
against a mask of the DDDEF volser that would flag a difference? Yeah, I know, 
the file allocation report is supposed to be the last line of defense, but 
sometimes it is tough to spot a one character difference. Ask me how I know. 
Still not sure why a coworker changed it without letting others know.  

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Friday, May 24, 2019 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote:

> We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the 
> "New Service Levels" email), and got a number of fixes for RSU1903. Over the 
> last couple of days, it's been discovered that we are missing a few PTFs that 
> would be part of RSU1903 - or earlier.
> 
> Yesterday, I therefore as an exercise did another RECEIVE ORDER 
> CONTENT(RECOMMENDED), and this time got more fixes for RSU1903.
> 
> Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU 
> date?
No, IBM does NOT assign RSU sourceids to PTFs retroactively after the published 
RSU date.  At least its not supposed to work that way.  Are you sure on your 
second RECEIVE ORDER one or more ASSIGN statements for
RSU1903 were received?  Or did you specify the RSU1903 SOURCEID on the RECEIVE 
command your self?  If you did receive such ASSIGN statements, and if you still 
have it, I'd like to see the RECEIVE command output for both jobs please.

BTW, as already mentioned, consider using CONTENT(ALL) instead of
CONTENT(RECOMMENDED) in the future.  I'm hard pressed to think of a good reason 
to only obtain recommended PTFs these days.

Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when 
he applies PTFs.

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

2019-05-24 Thread Richards, Robert B. 
Kurt,

Speaking of RSUs, is there a way to provide an inventory of PTFs already 
received so that I don't end up reordering and transmitting gigabytes of PTFs 
that have already been ordered, downloaded and received? As it is now, I am 
forced to run the RSU job on the weekend so that I stop getting the "17 of 20" 
failures after hours of wall clock time.

And while I am thinking of enhancements, how about an optional check of a mask 
against a mask of the DDDEF volser that would flag a difference? Yeah, I know, 
the file allocation report is supposed to be the last line of defense, but 
sometimes it is tough to spot a one character difference. Ask me how I know. 
Still not sure why a coworker changed it without letting others know.  

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Friday, May 24, 2019 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSUs

On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote:

> We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the 
> "New Service Levels" email), and got a number of fixes for RSU1903. Over the 
> last couple of days, it's been discovered that we are missing a few PTFs that 
> would be part of RSU1903 - or earlier.
> 
> Yesterday, I therefore as an exercise did another RECEIVE ORDER 
> CONTENT(RECOMMENDED), and this time got more fixes for RSU1903.
> 
> Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU 
> date?
No, IBM does NOT assign RSU sourceids to PTFs retroactively after the 
published RSU date.  At least its not supposed to work that way.  Are 
you sure on your second RECEIVE ORDER one or more ASSIGN statements for 
RSU1903 were received?  Or did you specify the RSU1903 SOURCEID on the 
RECEIVE command your self?  If you did receive such ASSIGN statements, 
and if you still have it, I'd like to see the RECEIVE command output for 
both jobs please.

BTW, as already mentioned, consider using CONTENT(ALL) instead of 
CONTENT(RECOMMENDED) in the future.  I'm hard pressed to think of a good 
reason to only obtain recommended PTFs these days.

Kurt Quackenbush -- IBM, SMP/E Development
Chuck Norris never uses CHECK when he applies PTFs.

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

Re: Queue-less | Shark Tank Computerworld

2019-05-24 Thread Mike Schwab 
The computer museum is still waiting to receive Sparkler FIlter's IBM 402.

https://mainframe.typepad.com/blog/2013/04/manufacturer-in-texas-still-relies-on-their-ibm-402.html

http://ibm-1401.info/402.html

On Fri, May 24, 2019 at 1:48 PM Mark Regan  wrote:
>
> https://www.computerworld.com/article/3396127/queue-less.html
>
> Regards,
>
> Mark Regan, USNR-Retired, Nationwide Insurance, Retired
>
> --
> 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

Queue-less | Shark Tank Computerworld

2019-05-24 Thread Mark Regan 
https://www.computerworld.com/article/3396127/queue-less.html

Regards,

Mark Regan, USNR-Retired, Nationwide Insurance, Retired

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

Re: RSUs

2019-05-24 Thread Kurt Quackenbush 

On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote:


We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the "New 
Service Levels" email), and got a number of fixes for RSU1903. Over the last couple 
of days, it's been discovered that we are missing a few PTFs that would be part of 
RSU1903 - or earlier.

Yesterday, I therefore as an exercise did another RECEIVE ORDER 
CONTENT(RECOMMENDED), and this time got more fixes for RSU1903.

Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU date?
No, IBM does NOT assign RSU sourceids to PTFs retroactively after the 
published RSU date.  At least its not supposed to work that way.  Are 
you sure on your second RECEIVE ORDER one or more ASSIGN statements for 
RSU1903 were received?  Or did you specify the RSU1903 SOURCEID on the 
RECEIVE command your self?  If you did receive such ASSIGN statements, 
and if you still have it, I'd like to see the RECEIVE command output for 
both jobs please.


BTW, as already mentioned, consider using CONTENT(ALL) instead of 
CONTENT(RECOMMENDED) in the future.  I'm hard pressed to think of a good 
reason to only obtain recommended PTFs these days.


Kurt Quackenbush -- IBM, SMP/E Development
Chuck Norris never uses CHECK when he applies PTFs.

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

Re: ICHRDSNT Table. RACF in sysplex communications mode

2019-05-24 Thread Mark Jacobs 
Yep. Got that. My confusion was that it wasn't immediately obvious that once 
the system was IPLed it was in Sysplex communications mode.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

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

‐‐‐ Original Message ‐‐‐
On Friday, May 24, 2019 8:56 AM, Allan Staller  wrote:

> I just went through this. There are 2 "levels" of RACF sharing
> SYSPLEX Data Sharing (CF required) and SYSPLEX Communications (no CF 
> required).
>
> SYSPLEX Data Sharing is b'10001100' (x'8C')
> SYSPLEX Communication is b'10001000' (x'88').
>
> What you have set up is SYSPLEX Communication. RACF will not be using the CF 
> in this mode.
> I believe the bits are described in the data areas manual for ICHRDSNT.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of 
> Mark Jacobs
> Sent: Thursday, May 23, 2019 5:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ICHRDSNT Table. RACF in sysplex communications mode
>
> Since there's more activity here than in the RACF mailing list, thought I'd 
> ask here first. I changed the flag byte in the RACF dataset names table to 
> enable sysplex communications today, and ipled the first system with the 
> changed table. Even though it's not talking to another system yet via XCF, I 
> had thought the RVARY LIST command issued on that system would have told me 
> that it's enabled for sysplex communications. I've verified that this system 
> is using the updated load module.
>
> rvary list
> ICH15013I RACF DATABASE STATUS:
> ACTIVE USE NUM VOLUME DATASET
>
> YES PRIM 1 SYS001 SYS1.PROD.RACF
> YES BACK 1 SYS011 SYS1.PROD.RACF.BACKUP
> ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.
> READY
>
> Here's what I set in the table;
>
> ICHRDSNT CSECT
> DC AL1(1) INDICATES ONE RACF DATA SET
> DC CL44'SYS1.PROD.RACF' PRIMARY RACF DS NAME
> DC CL44'SYS1.PROD.RACF.BACKUP' BACKUP RACF DS NAME
> DC AL1(255) # OF RESIDENT DATA BLOCKS
>
> -  DCB'01234567'  BIT COUNT
>DCB'10001000'  SYSPLEX, NON DATASHARING
>END
>
>
>
> Any ideas?
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key - 
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com=02|01|allan.staller%40HCL.COM|93996759aae54386463508d6dfcf5db6|189de737c93a4f5a8b686f4ca9941912|0|0|636942479084451598=%2FHIUk2TQxS0YeB15GLXH%2BkeBg6%2FAJTzJyp%2FjKrzEJ0s%3D=0
>
> 
>
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
>
> --
>
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, presented in this email are solely 
> those of the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL is 
> strictly prohibited. If you have received this email in error please delete 
> it and notify the sender immediately. Before opening any email and/or 
> attachments, please check them for viruses and other defects.
>
>

Re: ICHRDSNT Table. RACF in sysplex communications mode

2019-05-24 Thread Allan Staller 
I just went through this. There are 2 "levels" of RACF sharing
SYSPLEX Data Sharing (CF required) and SYSPLEX Communications (no CF required).

SYSPLEX Data Sharing is b'10001100'  (x'8C')
SYSPLEX Communication is b'10001000' (x'88').

What you have set up is SYSPLEX Communication. RACF will not be using the CF in 
this mode.
I believe the bits are described in the data areas manual for ICHRDSNT.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Thursday, May 23, 2019 5:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ICHRDSNT Table. RACF in sysplex communications mode

Since there's more activity here than in the RACF mailing list, thought I'd ask 
here first. I changed the flag byte in the RACF dataset names table to enable 
sysplex communications today, and ipled the first system with the changed 
table. Even though it's not talking to another system yet via XCF, I had 
thought the RVARY LIST command issued on that system would have told me that 
it's enabled for sysplex communications. I've verified that this system is 
using the updated load module.

rvary list
ICH15013I RACF DATABASE STATUS:
ACTIVE USE  NUM VOLUME   DATASET
-- ---  --- --   ---
  YES   PRIM   1 SYS001   SYS1.PROD.RACF
  YES   BACK   1 SYS011   SYS1.PROD.RACF.BACKUP
ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.
READY

Here's what I set in the table;

ICHRDSNT CSECT
 DCAL1(1)   INDICATES ONE RACF DATA SET
 DCCL44'SYS1.PROD.RACF' PRIMARY RACF DS NAME
 DCCL44'SYS1.PROD.RACF.BACKUP'  BACKUP  RACF DS NAME
 DCAL1(255) # OF RESIDENT DATA BLOCKS
*DCB'01234567'  BIT COUNT
 DCB'10001000'  SYSPLEX, NON DATASHARING
 END

Any ideas?

Sent from 
[ProtonMail](https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotonmail.comdata=02%7C01%7Callan.staller%40HCL.COM%7C93996759aae54386463508d6dfcf5db6%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636942479084451598sdata=2L65kcSXzRAvREzt6rUY2bgAWxqdHRQ%2F4Ln%2FphzAytM%3Dreserved=0),
 Swiss-based encrypted email.

GPG Public Key - 
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.comdata=02%7C01%7Callan.staller%40HCL.COM%7C93996759aae54386463508d6dfcf5db6%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636942479084451598sdata=%2FHIUk2TQxS0YeB15GLXH%2BkeBg6%2FAJTzJyp%2FjKrzEJ0s%3Dreserved=0

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: ICHRDSNT Table. RACF in sysplex communications mode

2019-05-24 Thread Mark Jacobs 
Structures are setup, but since datasharing isn't yet activated they're not 
allocated.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

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

‐‐‐ Original Message ‐‐‐
On Friday, May 24, 2019 6:42 AM, Elardus Engelbrecht 
 wrote:

> Mark Jacobs wrote:
>
> > Since there's more activity here than in the RACF mailing list, thought I'd 
> > ask here first. I changed the flag byte in the RACF dataset names table to 
> > enable sysplex communications today, and ipled the first system with the 
> > changed table. Even though it's not talking to another system yet via XCF, 
> > I had thought the RVARY LIST command issued on that system would have told 
> > me that it's enabled for sysplex communications. I've verified that this 
> > system is using the updated load module.
>
> Are your structures setup and activated?
>
> Do a D XCF,STRUCTURE to see them.
>
> ... also issue D XCF,STRUCTURE,STRNAME=
>
> Check these output:
>
> .
>
> STATUS: ALLOCATED
> .
>
> CONNECTION NAME ID VERSION SYSNAME JOBNAME ASID STATE
>
> IRRP001@ 02 00020058  RACFDS 0017 ACTIVE
>
> If you don't see it, check your setup of the CF structure.
>
> > rvary list
> > ICH15013I ACCF DATABASE STATUS:
> > ACTIVE USE NUM VOLUME DATASET
> >
> > YES PRIM 1 SYS001 SYS1.PROD.RACF
> > YES BACK 1 SYS011 SYS1.PROD.RACF.BACKUP
> > ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.
>
> > Here's what I set in the table;
>
> > ICHRDSNT CSECT
> > DC AL1(1) INDICATES ONE RACF DATA SET
> > DC CL44'SYS1.PROD.RACF' PRIMARY RACF DS NAME
> > DC CL44'SYS1.PROD.RACF.BACKUP' BACKUP RACF DS NAME
> > DC AL1(255) # OF RESIDENT DATA BLOCKS
> >
> > -  DCB'01234567'  BIT COUNT
> >   DCB'10001000'  SYSPLEX, NON DATASHARING
> >   END
> >
> >
>
> AL1(1) is easy ... ;-)
>
> > Any ideas?
>
> I have first X'C8' - 1100 1000 during all the initial setup of CF and the 
> structures.
>
> Then IPL, etc. where you get SysPlex and NON DATASHARING.
>
> Then after verifying all is Ok and you can get DATASHARING working, then I 
> code in X'CC' - 1100 1100 (and then IPL at a convenient time)
>
> If all is working you should get this:
>
> MEMBER  IS SYSPLEX COMMUNICATIONS ENABLED & IN DATA SHARING MODE.
>
> Ok, above is perhaps too elaborate, but I was just very cautious and have 
> practised on a sandbox SysPlex.
>
> Good luck!
>
> 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

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

Re: ICHRDSNT Table. RACF in sysplex communications mode

2019-05-24 Thread Elardus Engelbrecht 
Mark Jacobs wrote:

>Since there's more activity here than in the RACF mailing list, thought I'd 
>ask here first. I changed the flag byte in the RACF dataset names table to 
>enable sysplex communications today, and ipled the first system with the 
>changed table. Even though it's not talking to another system yet via XCF, I 
>had thought the RVARY LIST command issued on that system would have told me 
>that it's enabled for sysplex communications. I've verified that this system 
>is using the updated load module.

Are your structures setup and activated?

Do a D XCF,STRUCTURE to see them.

... also issue D XCF,STRUCTURE,STRNAME=

Check these output:

.

STATUS: ALLOCATED 
.

CONNECTION NAME  ID VERSION  SYSNAME  JOBNAME  ASID STATE 
 --     --
IRRP001@ 02 00020058  RACFDS   0017 ACTIVE

If you don't see it, check your setup of the CF structure.


>rvary list
>ICH15013I ACCF DATABASE STATUS:
>ACTIVE USE  NUM VOLUME   DATASET
>-- ---  --- --   ---
>  YES   PRIM   1 SYS001   SYS1.PROD.RACF
>  YES   BACK   1 SYS011   SYS1.PROD.RACF.BACKUP
>ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.

>Here's what I set in the table;

>ICHRDSNT CSECT
> DCAL1(1)   INDICATES ONE RACF DATA SET
> DCCL44'SYS1.PROD.RACF' PRIMARY RACF DS NAME
> DCCL44'SYS1.PROD.RACF.BACKUP'  BACKUP  RACF DS NAME
> DCAL1(255) # OF RESIDENT DATA BLOCKS
>*DCB'01234567'  BIT COUNT
> DCB'10001000'  SYSPLEX, NON DATASHARING
> END

AL1(1) is easy ... ;-)


>Any ideas?

I have first X'C8' - 1100 1000 during all the initial setup of CF and the 
structures.

Then IPL, etc. where you get SysPlex and NON DATASHARING.

Then after verifying all is Ok and you can get DATASHARING working, then I code 
in X'CC' - 1100 1100 (and then IPL at a convenient time)

If all is working you should get this:

MEMBER   IS SYSPLEX COMMUNICATIONS ENABLED & IN DATA SHARING MODE.

Ok, above is perhaps too elaborate, but I was just very cautious and have 
practised on a sandbox SysPlex.

Good luck!

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: DFDSS copy to pre-allocated dsn

2019-05-24 Thread Richards, Robert B. 
> IGD01008I STORAGE ADMIN HAS TARGETED STORCLAS STDSYS  IGD01014I DATA SET 
> ALLOCATION REQUEST FAILED -  SPECIFIED STORCLAS STDSYS DOES NOT EXIST

Doesn't Elaine need to resolve the non-existent storclas (STDSYS) first? The 
rest of the recommendation are nice too! :-)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Thursday, May 23, 2019 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

STORCLAS(desired storclas) BYPASSACS(**)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elaine Beal
Sent: Thursday, May 23, 2019 11:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

I'm copying disk to disk.
source file is 2 volumes and I want to copy (expand) to pre-allocated, 
catalogued 3 volume file.
I modified the  OUTDDNAME(DASD2) to include all 3 (new) volumes.

The issue (now) is that the copy is trying to use the original STORCLAS but the 
new file is a different STORCLAS

ADR709E (001)-ACS  (01), AN ERROR OCCURRED IN THE STORAGE MANAGEMENT SUBSYSTEM 
WHILE DETERMINING SMS CONSTRUCTS FOR DATA SET
 SYS7.R30.V22.ROOT.HFS WITH NEWNAME 
SYS7.R30.V22.RSU.ROOT.HFS. SMS MESSAGES FOLLOW.
 IGD01008I STORAGE ADMIN HAS TARGETED STORCLAS STDSYS  IGD01014I DATA SET 
ALLOCATION REQUEST FAILED -  SPECIFIED STORCLAS STDSYS DOES NOT EXIST


JCL -

//COPYSTEP EXEC PGM=ADRDSSU
//SYSPRINT DD   SYSOUT=*
//DASD1DD   DISP=SHR,UNIT=3390,VOL=SER=(SSS050,SSS051)
//DASD2DD   DISP=SHR,UNIT=3390,VOL=SER=(SSS052,SSS053,SSS054)
//SYSINDD   *
   COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS))  -
   LOGINDDNAME(DASD1)  -
   OUTDDNAME(DASD2)  -
   SELECTMULTI(ANY)  -
   RENAMEU((SYS7.R30.V22.ROOT.HFS,   -
   SYS7.R30.V22.RSU.ROOT.HFS)) -
REPLACEUNCONDITIONAL   -
   ALLDATA(*) ALLEXCP CANCELERROR -
   SHARE -
   WRITECHECK

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

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