Re: IBM open sources its JVM and JIT code

[Paul Gilmartin]

On Fri, 27 Oct 2017 11:32:31 -0500, John McKown wrote:

>On Fri, Oct 27, 2017 at 11:27 AM, Jack J. Woehr  wrote:
>>
>> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/
>> com.ibm.zos.v2r2.izua700/izuprog_API_StartApp.htm
>
>​Interesting. But that starts a TSO address space via the ZOSMF REST API to
>z/OSMF (which we don't run). I was more thinking of a Java package/library
>which would run a TSO command in the invoker's address space..​
> 
APF entanglements, similar to BPXBATSL/

-- gil

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

Re: Help needed: SYNCSORT issue with OUTFIL CONVERT

[Farley, Peter x23353]

Replying to my own post based on  subsequent experiments.

The answer to my question is "Yes, you MUST specify EXACTLY "LRECL" bytes of 
output for each line generated by the OUTREC parameter for an FB output file".

Annoying to have to count characters and add "nnX," at the  end of each 
generated line, but I am at least back in business.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, October 27, 2017 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Help needed: SYNCSORT issue with OUTFIL CONVERT

I am processing a VB input file with MMDD dates that I need to use to 
create a set of JCL to execute an application process for each unique date.  
SYNCSORT is giving me "SORTOUT  HAS INCOMPATIBLE LRECL" but i do not understand 
why.

I am trying to use the OUTFIL CONVERT parameter to generate RECFM=FB, LRECL=80 
output from the VB input file.

Doesn't the VLFILL parameter default provide the trailing spaces needed for 
each FB output record?  Or do I have to provide EXACTLY 80 output bytes for 
each output record in the OUTREC?

Any help you can provide is appreciated.

Peter


Here is the SYNCSORT JCL and listing output with some anonymization:

//GETDATES EXEC PGM=SORT,REGION=250M,
// PARM='EQUALS,MSGDD=SORTLIST,VLTEST=2,VLTESTI=2'
//SORTLIST DD  SYSOUT=*
//SORTIN   DD  DISP=SHR,DSN=TSOUSER.INPUT.VBFILE
//SORTOUT  DD DISP=(NEW,CATLG,CATLG),
//DSN=TSOUSER.OUTPUT.FBFILE,
//UNIT=TEST,SPACE=(CYL,(0010,0010),RLSE),
//DSORG=PS,RECFM=FB,LRECL=80,BLKSIZE=0,BUFNO=31
//SYSINDD  *

SYSIN :
  SORT FIELDS=(5,08,CH,A)
  OMIT COND=(5,1,CH,EQ,X'00',OR, IGNORE HDR/TRLR
 5,1,CH,EQ,X'FF')
  INREC BUILD=(1,4,5:885,8)  JUST THE MMDD DATE
  SUM FIELDS=NONEGET UNIQUE DATE
  OUTFIL CONVERT,FNAMES=SORTOUT,
  OUTREC=(C'//RUNONE   EXEC ONEPROC',/,
  C'//STEPONE.PARMS DD *',/,
  C'@DT=',5,8,/,
  C'@LP=',9,4,7,2,/,
  C'//*')
WER813I  INSTALLATION OPTIONS IN MFX LOAD LIBRARY WILL BE USED
WER276B  SYSDIAG= 2203984, 6164664, 6164664, 5599565
WER164B  65,540K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 156K BYTES RESERVE REQUESTED, 1,000K BYTES USED
WER146B  24K BYTES OF EMERGENCY SPACE ALLOCATED
WER108I  SORTIN   : RECFM=VB   ; LRECL=  8004; BLKSIZE= 27998
WER073I  SORTIN   : DSNAME=TSOUSER.INPUT.VBFILE
WER257I  INREC RECORD LENGTH =12
WER110I  SORTOUT  : RECFM=FB   ; LRECL=80; BLKSIZE= 27920
WER074I  SORTOUT  : DSNAME=TSOUSER.OUTPUT.FBFILE
WER247A  SORTOUT  HAS INCOMPATIBLE LRECL
WER211B  SYNCSMF  CALLED BY SYNCSORT; RC=

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT

[Steve Smith]

Being Friday, this is obligatory: https://xkcd.com/1172/

sas

On Fri, Oct 27, 2017 at 1:25 PM, Jim Mulder  wrote:
...
The ESP customer was very insistent that we change the
> implementation to default to old behavior, with a documented option in
> DIAGxx to request new behavior.
...

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

Sharing z/OS certificates

[Michael Babcock]

I’m trying to implement AT-TLS for otelnet on z/OS 2.2.   I want to share
TN3270U’s personal certificate.   PAGENT is up and running.  BPXROOT is
assigned to otelnet.  AT-TLS has its own Keyring and TN3270U’s personal
cert has been connected.  PAGENT owns the AT-TLS Keyring.

It won’t connect saying no private key.Is there a way to share the cert
between the two IDs (short of creating a SITE cert)?

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

Re: Batch TSO command (ADDUSER) tracing and diagnostics

[John McKown]

On Fri, Oct 27, 2017 at 1:45 PM, Tony Harminc  wrote:

> On 27 October 2017 at 13:06, John McKown 
> wrote:
>
> >
> > ​Coming in a bit sideways on this, and from another thread entirely. If I
> > wanted to do z/OS RACF work when I'm logged into a CICS region (though I
> > don't know why), then I think use the zOSMF REST API would be a much
> better
> > way to go. This could be done using the ZOSMF TSO services REST API to
> run
> > the RACF commands.
> > ref:
> > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.
> > 0/com.ibm.zos.v2r1.izua700/izuprog_API_TSOServices.htm
> >
> > This should not affect system integrity because it is simple HTTP over
> > TCPIP, which is native to CICS. ​
> >
>
> How would the caller authenticate to RACF to do this?
>

​Well, the REST API can use HTTP basic authentication. So the CICS
transaction would need to ask the user for the proper userid/password and
send that on to ZOSMF. And the signed on user would need proper RACF
authority to run the CICS transaction.​

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT

[Carmen Vitullo]

Lizzette, I just checked some parms from my last shop that was a very large DB2 
shop, 6 LPARS and we had USEZOSV1R9RULES( NO) set 
BMC - CONTROL-X product suite - no issues at all . hth's some 




Carmen 


- Original Message -

From: "Lizette Koehler"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, October 27, 2017 10:36:02 AM 
Subject: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT 

Dear List - 

I have been reviewing some parms that have been around in z/OS for a few 
years/decades? 

USEZOSV1R9RULES 

VSM USEZOSV1R9RULES(NO|YES): YES causes GETMAIN and STORAGE OBTAIN behavior to 
be unchanged from its historic behavior. NO causes GETMAIN and STORAGE OBTAIN 
behavior for user-region private area subpools that are both below and above 
the 
line to be implemented. Thus DQEs can be merged where possible. The default is 
YES to provide a seamless migration. However, IBM recommends that you specify 
USEZOSV1R9RULES(NO) to obtain a performance benefit for applications with long 
DQE/FQE chains for user-region private area subpools. 

To Display: D DIAG 

MEMDSENQMGT 

Allocation enhancement - MEMDSENQMGMT (Memory-based data set ENQ management) 
- ENQs managed in private storage instead of SWA blocks. Job will be 
non-restartable. 
- Enable via parmlib member or MVS command: 
. ALLOCxx: SYSTEM MEMDSENQMGMT(ENABLE) 
. SETALLOC SYSTEM,MEMDSENQMGMT=ENABLE 
- Exploit with DB2 APAR PM17542 (closed September 2010) 

To display: D ALLOC,OPTIONS 

I was wondering two things 

1) How many are using the new algorithms these two parms brought in? 
2) When you changed to the new functions, did you see any issues? Any products 
that need TLC? 


Are there any other that might also be helpful? 


Thank you 


Lizette Koehler 
statistics: A precise and logical method for stating a half-truth inaccurately 

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

Help needed: SYNCSORT issue with OUTFIL CONVERT

[Farley, Peter x23353]

I am processing a VB input file with MMDD dates that I need to use to 
create a set of JCL to execute an application process for each unique date.  
SYNCSORT is giving me "SORTOUT  HAS INCOMPATIBLE LRECL" but i do not understand 
why.

I am trying to use the OUTFIL CONVERT parameter to generate RECFM=FB, LRECL=80 
output from the VB input file.

Doesn't the VLFILL parameter default provide the trailing spaces needed for 
each FB output record?  Or do I have to provide EXACTLY 80 output bytes for 
each output record in the OUTREC?

Any help you can provide is appreciated.

Peter


Here is the SYNCSORT JCL and listing output with some anonymization:

//GETDATES EXEC PGM=SORT,REGION=250M,
// PARM='EQUALS,MSGDD=SORTLIST,VLTEST=2,VLTESTI=2'
//SORTLIST DD  SYSOUT=*
//SORTIN   DD  DISP=SHR,DSN=TSOUSER.INPUT.VBFILE
//SORTOUT  DD DISP=(NEW,CATLG,CATLG),
//DSN=TSOUSER.OUTPUT.FBFILE,
//UNIT=TEST,SPACE=(CYL,(0010,0010),RLSE),
//DSORG=PS,RECFM=FB,LRECL=80,BLKSIZE=0,BUFNO=31
//SYSINDD  *

SYSIN :
  SORT FIELDS=(5,08,CH,A)
  OMIT COND=(5,1,CH,EQ,X'00',OR, IGNORE HDR/TRLR
 5,1,CH,EQ,X'FF')
  INREC BUILD=(1,4,5:885,8)  JUST THE MMDD DATE
  SUM FIELDS=NONEGET UNIQUE DATE
  OUTFIL CONVERT,FNAMES=SORTOUT,
  OUTREC=(C'//RUNONE   EXEC ONEPROC',/,
  C'//STEPONE.PARMS DD *',/,
  C'@DT=',5,8,/,
  C'@LP=',9,4,7,2,/,
  C'//*')
WER813I  INSTALLATION OPTIONS IN MFX LOAD LIBRARY WILL BE USED
WER276B  SYSDIAG= 2203984, 6164664, 6164664, 5599565
WER164B  65,540K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 156K BYTES RESERVE REQUESTED, 1,000K BYTES USED
WER146B  24K BYTES OF EMERGENCY SPACE ALLOCATED
WER108I  SORTIN   : RECFM=VB   ; LRECL=  8004; BLKSIZE= 27998
WER073I  SORTIN   : DSNAME=TSOUSER.INPUT.VBFILE
WER257I  INREC RECORD LENGTH =12
WER110I  SORTOUT  : RECFM=FB   ; LRECL=80; BLKSIZE= 27920
WER074I  SORTOUT  : DSNAME=TSOUSER.OUTPUT.FBFILE
WER247A  SORTOUT  HAS INCOMPATIBLE LRECL
WER211B  SYNCSMF  CALLED BY SYNCSORT; RC=

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: IBM open sources its JVM and JIT code

[Kirk Wolf]

FWIW, the service that z/OSMF uses for starting TSO address spaces is:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieac100/cea-intro.htm

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Fri, Oct 27, 2017 at 11:52 AM, Jack J. Woehr  wrote:

> On 10/27/2017 10:32 AM, John McKown wrote:
>
>> z/OSMF (which we don't run). I was more thinking of a Java package/library
>> which would run a TSO command in the invoker's address space..​
>>
>
>
> There are many ways to exfoliate a feline. This sorta thing has been my
> main interest for some years.
>
> JTOpen on IBM i. SMAPI on z/VM. The VSE Java connector. OSMF.
>
> These external APIs are there waiting to be more full exploited. It's a
> more fertile field than "just another language" native on the host.
>
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
> --
> 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: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT

[Carmen Vitullo]

So, my question is, are there any repercussions changing to USEZOSV1R9RULES( 
NO) for shop running, lets say z/OS 2.2 + all OEM products up to date with 
compatibility? 
we're not a large DB2 shop be most of our workload is DB2, DB2 data sharing in 
a 3 system sysplex. 
any recommendations? 
I, we can test on one small LPAR, but it's not real life. 
Thanks 
Carmen 




- Original Message -

From: "Jim Mulder"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, October 27, 2017 12:25:55 PM 
Subject: Re: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT 

I implemented the VSM changes in z/OS 1.10. The original implementation 

used the new behavior by default, with an undocumented option in DIAGxx to 
allow 
a customer (under the direction of IBM support) to temporarily revert to 
the old 
behavior to bypass a latent bug in some application program or other 
product 
while waiting for a fix. 

One of the z/OS 1.10 ESP customers hit a latent bug in an authorized key 
0 
product, and the product ended up overlaying something important and 
crashing 
the system. The ESP customer was very insistent that we change the 
implementation to default to old behavior, with a documented option in 
DIAGxx to request new behavior. We (development) did not think this 
was the best thing to do, but we also wanted to avoid the scenario of 
an ESP customer giving a Share presentation about a bad z/OS 1.10 
migration experience, and IBM not meeting their requirements, so 
we created USEZOSV1R9RULES in an APAR. 

The impetus for the item was very bad performance when DB2 was 
opening a large number of data sets at startup (I think at the time, it 
was 
taking something like 45 minutes to open 100,000 data sets), and a lot 
of that was due to very long DQE/FQE chains due to fragmentation 
caused by Getmain/Freemain activity in OPEN processing. 

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. 
Poughkeepsie NY 

IBM Mainframe Discussion List  wrote on 
10/27/2017 11:36:02 AM: 

> From: Lizette Koehler  
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Date: 10/27/2017 12:41 PM 
> Subject: Question on some z/OS Tuning Parms USEZOSV1R9RULES and 
MEMDSENQMGT 
> Sent by: IBM Mainframe Discussion List  
> 
> Dear List - 
> 
> I have been reviewing some parms that have been around in z/OS for a few 
> years/decades? 
> 
> USEZOSV1R9RULES 
> 
> VSM USEZOSV1R9RULES(NO|YES): YES causes GETMAIN and STORAGE OBTAIN 
behavior to 
> be unchanged from its historic behavior. NO causes GETMAIN and STORAGE 
OBTAIN 
> behavior for user-region private area subpools that are both below 
> and above the 
> line to be implemented. Thus DQEs can be merged where possible. The 
default is 
> YES to provide a seamless migration. However, IBM recommends that you 
specify 
> USEZOSV1R9RULES(NO) to obtain a performance benefit for applicationswith 
long 
> DQE/FQE chains for user-region private area subpools. 
> 
> To Display: D DIAG 
> 
> MEMDSENQMGT 
> 
> Allocation enhancement - MEMDSENQMGMT (Memory-based data set ENQ 
management) 
> - ENQs managed in private storage instead of SWA blocks. Job will be 
> non-restartable. 
> - Enable via parmlib member or MVS command: 
> . ALLOCxx: SYSTEM MEMDSENQMGMT(ENABLE) 
> . SETALLOC SYSTEM,MEMDSENQMGMT=ENABLE 
> - Exploit with DB2 APAR PM17542 (closed September 2010) 
> 
> To display: D ALLOC,OPTIONS 
> 
> I was wondering two things 
> 
> 1) How many are using the new algorithms these two parms brought in? 
> 2) When you changed to the new functions, did you see any issues? 
> Any products 
> that need TLC? 
> 
> 
> Are there any other that might also be helpful? 
> 
> 
> Thank you 
> 
> 
> Lizette Koehler 
> statistics: A precise and logical method for stating a half-truth 
inaccurately 
> 
> -- 
> 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: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT

[Jim Mulder]

  I implemented the VSM changes in z/OS 1.10.  The original implementation 

used the new behavior by default, with an undocumented option in DIAGxx to 
allow 
a customer  (under the direction of IBM support) to temporarily revert to 
the old 
behavior to bypass a latent bug in some application program or other 
product 
while waiting for a fix. 

  One of the z/OS 1.10 ESP customers hit a latent bug in an authorized key 
0 
product,  and the product ended up overlaying something important and 
crashing 
the system.  The ESP customer was very insistent that we change the 
implementation to default to old behavior, with a documented option in
DIAGxx to request new behavior.  We (development) did not think this
was the best thing to do, but we also wanted to avoid the scenario of
an ESP customer giving a Share presentation about a bad z/OS 1.10
migration experience, and IBM not meeting their requirements, so 
we created USEZOSV1R9RULES in an APAR. 

  The impetus for the item was very bad performance when DB2 was
opening a large number of data sets at startup (I think at the time, it 
was
taking something like 45 minutes to open 100,000 data sets), and a lot
of that was due to very long DQE/FQE chains due to fragmentation
caused by Getmain/Freemain activity in OPEN processing. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

IBM Mainframe Discussion List  wrote on 
10/27/2017 11:36:02 AM:

> From: Lizette Koehler 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 10/27/2017 12:41 PM
> Subject: Question on some z/OS Tuning Parms  USEZOSV1R9RULES and 
MEMDSENQMGT
> Sent by: IBM Mainframe Discussion List 
> 
> Dear List -
> 
> I have been reviewing some parms that have been around in z/OS for a few
> years/decades?
> 
> USEZOSV1R9RULES
> 
> VSM USEZOSV1R9RULES(NO|YES): YES causes GETMAIN and STORAGE OBTAIN 
behavior to
> be unchanged from its historic behavior. NO causes GETMAIN and STORAGE 
OBTAIN
> behavior for user-region private area subpools that are both below 
> and above the
> line to be implemented. Thus DQEs can be merged where possible. The 
default is
> YES to provide a seamless migration. However, IBM recommends that you 
specify
> USEZOSV1R9RULES(NO) to obtain a performance benefit for applicationswith 
long
> DQE/FQE chains for user-region private area subpools.
> 
> To Display:  D DIAG
> 
> MEMDSENQMGT
> 
> Allocation enhancement - MEMDSENQMGMT (Memory-based data set ENQ 
management)
> - ENQs managed in private storage instead of SWA blocks. Job will be
> non-restartable.
> - Enable via parmlib member or MVS command:
> . ALLOCxx: SYSTEM MEMDSENQMGMT(ENABLE)
> . SETALLOC SYSTEM,MEMDSENQMGMT=ENABLE
> - Exploit with DB2 APAR PM17542 (closed September 2010)
> 
> To display:  D ALLOC,OPTIONS
> 
> I was wondering two things
> 
> 1) How many are using the new algorithms these two parms brought in?
> 2) When you changed to the new functions, did you see any issues? 
> Any products
> that need TLC?
> 
> 
> Are there any other that might also be helpful?
> 
> 
> Thank you
> 
> 
> Lizette Koehler
> statistics: A precise and logical method for stating a half-truth 
inaccurately
> 
> --
> 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: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT

[Pommier, Rex]

we have the defaults, so 
VSM USEZOSV1R9RULES(YES) 
MEMDSENQMGMT: DISABLE 

Rex

- Original Message -

From: "Lizette Koehler"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, October 27, 2017 10:36:02 AM 
Subject: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT 

Dear List - 

I have been reviewing some parms that have been around in z/OS for a few 
years/decades? 

USEZOSV1R9RULES 

VSM USEZOSV1R9RULES(NO|YES): YES causes GETMAIN and STORAGE OBTAIN behavior to 
be unchanged from its historic behavior. NO causes GETMAIN and STORAGE OBTAIN 
behavior for user-region private area subpools that are both below and above 
the 
line to be implemented. Thus DQEs can be merged where possible. The default is 
YES to provide a seamless migration. However, IBM recommends that you specify 
USEZOSV1R9RULES(NO) to obtain a performance benefit for applications with long 
DQE/FQE chains for user-region private area subpools. 

To Display: D DIAG 

MEMDSENQMGT 

Allocation enhancement - MEMDSENQMGMT (Memory-based data set ENQ management) 
- ENQs managed in private storage instead of SWA blocks. Job will be 
non-restartable. 
- Enable via parmlib member or MVS command: 
. ALLOCxx: SYSTEM MEMDSENQMGMT(ENABLE) 
. SETALLOC SYSTEM,MEMDSENQMGMT=ENABLE 
- Exploit with DB2 APAR PM17542 (closed September 2010) 

To display: D ALLOC,OPTIONS 

I was wondering two things 

1) How many are using the new algorithms these two parms brought in? 
2) When you changed to the new functions, did you see any issues? Any products 
that need TLC? 


Are there any other that might also be helpful? 


Thank you 


Lizette Koehler 
statistics: A precise and logical method for stating a half-truth inaccurately 

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: Batch TSO command (ADDUSER) tracing and diagnostics

[John McKown]

On Fri, Oct 27, 2017 at 11:57 AM, Jim Mulder  wrote:

>   The TSO TMP is designed to be attached only by EXEC PGM=IKJEFTxx,
> or by the TSO/E Session Manager (when Session Manager is the EXEC PGM= on
> the logon proc).
> Attaching the TMP by any other program is unsupported.
>
>   Attaching the TMP in an IMS dependent region or a CICS AOR will
> violate the System Integrity and thus the security of your system, since
> it will allow
> the unauthorized transaction programs in those regions to take over the
> system
> in anyway that they desire.
>
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> Poughkeepsie NY
>
>
​Coming in a bit sideways on this, and from another thread entirely. If I
wanted to do z/OS RACF work when I'm logged into a CICS region (though I
don't know why), then I think use the zOSMF REST API would be a much better
way to go. This could be done using the ZOSMF TSO services REST API to run
the RACF commands.
ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.izua700/izuprog_API_TSOServices.htm

This should not affect system integrity because it is simple HTTP over
TCPIP, which is native to CICS. ​


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT

[Larre Shiller]

Hi Lizette -

I would say that we are a fairly large DB2 shop and we are using both of those 
functions... that is, USEZOSV1R9RULES(NO) and MEMDSENQMGMT(ENABLE) and we have 
been using them since they were first available.  I think we may have opened a 
PMR for a problem that we initially had with MEMDSENQMGMT, but since then, we 
have not had any issues related to these 2 functions.

You asked about other parameters... we are also using VSM BESTFITCSA(YES).  
Again... as far as I know, we have had no issues with it.

In all cases, I'm not sure that I have any way to quantify the potential 
performance or functional improvements associated with these parameters.  And I 
cannot remember any specific software products that needed to be updated as a 
result of activating these functions--but again, that was a long time ago... 
I'm sure at this point, any changes required would have already been 
implemented.

Larre Shiller
US Social Security Administration
“The opinions expressed in this e-mail are mine personally and do not 
necessarily reflect the opinion of the US Social Security Administration and/or 
the US Government.”

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

Re: Batch TSO command (ADDUSER) tracing and diagnostics

[Jim Mulder]

  The TSO TMP is designed to be attached only by EXEC PGM=IKJEFTxx,
or by the TSO/E Session Manager (when Session Manager is the EXEC PGM= on 
the logon proc).
Attaching the TMP by any other program is unsupported.

  Attaching the TMP in an IMS dependent region or a CICS AOR will 
violate the System Integrity and thus the security of your system, since 
it will allow
the unauthorized transaction programs in those regions to take over the 
system
in anyway that they desire. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


IBM Mainframe Discussion List  wrote on 
10/27/2017 03:39:00 AM:

> From: "Baguley, Nicholas: Absa" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 10/27/2017 12:41 PM
> Subject: Re: Batch TSO command (ADDUSER) tracing and diagnostics
> Sent by: IBM Mainframe Discussion List 
> 
> Hi List
> 
> Wow - thanks for input List
> Lots of ideas , suggestions and questions.
> 
> When you use PARM and not SYSTSIN it doesn?t seem to ECHO input/
> command. I tried it before posting so as not to incur wrath of LIST
> Walt - correct.. the userid of the mother task is not authorised to 
> ADDUSER. The ATTACH is done in supervisor state. Don?t try this at 
> home type stuff
> Tony - attach worked fine as you stated. See code snippet below.
> 
> LIST - I assume if I "front-end" this process it would have to keep 
> the authorised chain alive? Taking Walts suggestion (but via asm pgm
> and nor rexx) and extending it to creating a IKJEFT1X ac(1)?
> 
> At risk of being off topic - It raises the question of opening up 
> functionality via transactional processing(CICS/IMS) to allow RACF 
> users to be added.
> Business wants it but by the time you have solved all the auth and 
> audit stuff you have a monster. (getting from problem state running 
> in an IMS dep region or CICS AOR to supervisor attaching an auth 
> subtask etc etc and getting v messy) 
> 
> 
> ATTACH PARAM=(TASKPRM),ECB=TASKECB, 
>   MF=(E,TASKPMA),SF=(E,TASKATT) 
> STR1,TASKTCB 
> LRR3,R15  SAVE I
> 
> BAL   R8,AUTHRES  RESET 
> 
> LTR   R3,R3   IKJEFT
> BNZ   ATTFAIL NO - D
> WAIT  ECB=TASKECB 
> DETACH TASKTCB 
> L R3,TASKECB  ISOLAT
> N R3,=X'3FFF' 
> LTR   R3,R3   TASK R
> BNZ   CMDFAIL NO - D
> 
> Thanks again List



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

Re: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT

[Steve Smith]

I appears to me that some are confused by the clumsily named
USZOSV1R9RULES option.  Note that you have to set it to NO to get the
new and wonderful behavior.

I really think IBM needs to take some action to bring better awareness
to their customer base of what the myriad function options "should" be
set to if you're not as paranoid as they are about changing anything.
.
sas

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

Re: IBM open sources its JVM and JIT code

[Jack J. Woehr]

On 10/27/2017 10:32 AM, John McKown wrote:

z/OSMF (which we don't run). I was more thinking of a Java package/library
which would run a TSO command in the invoker's address space..​



There are many ways to exfoliate a feline. This sorta thing has been my 
main interest for some years.


JTOpen on IBM i. SMAPI on z/VM. The VSE Java connector. OSMF.

These external APIs are there waiting to be more full exploited. It's a 
more fertile field than "just another language" native on the host.


--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT

[Mark Zelden]

On Fri, 27 Oct 2017 08:36:02 -0700, Lizette Koehler  
wrote:

>Dear List -
>
>I have been reviewing some parms that have been around in z/OS for a few
>years/decades?
>
>USEZOSV1R9RULES
>
>VSM USEZOSV1R9RULES(NO|YES): YES causes GETMAIN and STORAGE OBTAIN behavior to
>be unchanged from its historic behavior. NO causes GETMAIN and STORAGE OBTAIN
>behavior for user-region private area subpools that are both below and above 
>the
>line to be implemented. Thus DQEs can be merged where possible. The default is
>YES to provide a seamless migration. However, IBM recommends that you specify
>USEZOSV1R9RULES(NO) to obtain a performance benefit for applications with long
>DQE/FQE chains for user-region private area subpools.
>
>To Display:  D DIAG
>

Wow, this is a very old item I forgot about.  I never revisited USZOSV1R9RULES 
after
z/OS 1.10 so it is defaulting to YES.   I wonder what benefit it would be in 
some of my
sysplexes with very large DB2 subsystems. 

I'm surprised there hasn't been a health check written for it by now since it 
came in a
t z/OS 1.10, but I do recall hearing of some problems from people changing the 
option to
NO, probably some of them on this LISTSERV.   Maybe that's why the default 
hasn't change
yet and there is no health check recommending the change.  It may be one of 
those parms 
that you know you have a problem or when IBM support recommends changing it.   

Curious now to see what others say about it.   If changing it to NO would save 
CPU cycles from DB2 on our large sysplexes, I'm all for it!

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources its JVM and JIT code

[John McKown]

On Fri, Oct 27, 2017 at 11:27 AM, Jack J. Woehr  wrote:

> On 10/27/2017 10:07 AM, David Crayford wrote:
>
>> But I
>> don't see any Java library to invoke a TSO command. ​
>>
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/
> com.ibm.zos.v2r2.izua700/izuprog_API_StartApp.htm


​Interesting. But that starts a TSO address space via the ZOSMF REST API to
z/OSMF (which we don't run). I was more thinking of a Java package/library
which would run a TSO command in the invoker's address space..​


>
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: IBM open sources its JVM and JIT code

[Jack J. Woehr]

On 10/27/2017 10:07 AM, David Crayford wrote:

But I
don't see any Java library to invoke a TSO command. ​ 


https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.izua700/izuprog_API_StartApp.htm

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: IBM open sources its JVM and JIT code

[Rob Schramm]

Sure.. the JNI portion is unavoidable.   But wouldn't it depend on what was
being done?.. is the switch back and forth worse than the whole unit as
regular Rexx.  And doesn't the additional capabilities of being able to use
Java / utilities add enough value?

Rob Schramm

On Fri, Oct 27, 2017, 12:07 PM David Crayford  wrote:

> On 28/10/2017 12:02 AM, John McKown wrote:
> > On Fri, Oct 27, 2017 at 10:43 AM, Rob Schramm 
> wrote:
> >
> >> Has anyone looked or asked the NetRexx guys if there is a way to use TSO
> >> type of commands in NetRexx?
> >>
> > ​I can't see any way to run a TSO command using NetRexx. But, in a more
> > general sense, I don't see any way to run a TSO command from a Java
> > program. NetRexx, being a JVM based language, can do anything that Java
> can
> > do. In particular, a NetRexx program can use JCICS and so be used to
> write
> > CICS programs. Or it can use JZOS / JRIO to do "batch" type work. But I
> > don't see any Java library to invoke a TSO command. ​
> >
>
> And as Martin pointed out to do so would require JNI which would burn
> CPU cycles and be pointless. Crossing a JNI boundary is expensive.
>
> >
> >> Rob Schramm
> >>
> >>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

Working copy of the CICS Global exit XMNOUT

[Tracy Adams]

Posting here and posting on the CICS-Listserv:

Does anyone have a working copy of the CICS exit XMNOUT that would share?  I 
just want to suppress SMF records from the QMSG transaction.  

TIA, Tracy

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

Re: ICETOOL - Question regarding a statement in the ICETOOL Guide

[George, William@FTB]

Thanks Sri!
I'll check this out. I have saved a link to the most recent DFSORT A.P.G. and 
looked at JOINKEYS.  At first glance it seems somewhat daunting but I'll study 
it and try it out.

Bill


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: Friday, October 27, 2017 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ICETOOL - Question regarding a statement in the ICETOOL Guide

Bill,

Here is a DFSORT JOINKEYS job which will give you the desired results similar 
to splice


//STEP0100 EXEC PGM=SORT 
//SYSOUT   DD SYSOUT=* 
//INA  DD * 
VICKY 
FRANK 
CARRIE 
HOLLY 
PAUL 
//INB  DD * 
KAREN 
HOLLY 
CARRIE 
VICKY 
MARY 
//OUT12DD SYSOUT=* 
//OUT1 DD SYSOUT=* 
//OUT2 DD SYSOUT=* 
//SYSINDD * 
  OPTION COPY 
  JOINKEYS F1=INA,FIELDS=(1,10,A) 
  JOINKEYS F2=INB,FIELDS=(1,10,A) 
  JOIN UNPAIRED 
  REFORMAT FIELDS=(F1:1,10,?,F2:1,10) 

  OUTFIL FNAMES=OUT12,INCLUDE=(11,1,CH,EQ,C'B'),BUILD=(1,10) 
  OUTFIL FNAMES=OUT1,INCLUDE=(11,1,CH,EQ,C'1'),BUILD=(1,10) 
  OUTFIL FNAMES=OUT2,INCLUDE=(11,1,CH,EQ,C'2'),BUILD=(12,10) 
//* 


Joinkeys is explained in detail here

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.icea100/joinkeys.htm

Also here are the examples (look up example 5 )

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icea100/ice2ca_JOINKEYS_application_examples.htm


Further if you have any questions please send an email to our hotline 
(dfs...@us.ibm.com) or you can mail me directly.

Thanks,
Sri Hari Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on 
10/26/2017 11:41:15 PM:

> From: "George, William@FTB" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 10/26/2017 11:41 PM
> Subject: Re: ICETOOL - Question regarding a statement in the ICETOOL 
Guide
> Sent by: IBM Mainframe Discussion List 
> 
> Thanks Sri!
> JOINKEYS... that's a new one on me.  I guess I have an outdated DFSORT 
manual.
> Here's the link I have: 
http://publibz.boulder.ibm.com/epubs/pdf/ice1ca30.pdf
> 
> Thanks again
> Bill
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of Sri h Kolusu
> Sent: Thursday, October 26, 2017 10:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ICETOOL - Question regarding a statement in the ICETOOL 
Guide
> 
> George,
> 
> It was a typo in our publications, it should be 1-10 instead of 1-3.
> The sorting of 1-10 bytes is done with ON statement on SPLICE. 
> Please look at the DFSMSG dataset and you will see the SPLICE 
> control cards generates the SORT statement with 1,10,CH,A
> 
> We will update our pubs. Thanks for bringing it to our attention.
> 
> 
>  "We sort the records of T1 on positions 1-10 and splice the second 
> id byte for matching records. We use KEEPNODUPS to keep non-
> duplicate records. 
> 
> 
> Just an fyi, SPLICE is an Older technique to find the matching records. 
> Ideally we suggest using JOINKEYS
> 
> 
> Thanks,
> Sri Hari Kolusu
> DFSORT Development
> IBM Corporation
> 
> IBM Mainframe Discussion List  wrote on
> 10/26/2017 03:09:04 AM:
> 
> > From: "George, William@FTB" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 10/26/2017 03:09 AM
> > Subject: ICETOOL - Question regarding a statement in the ICETOOL Guide 

> > Sent by: IBM Mainframe Discussion List 
> > 
> > I am confused about a statement I'm seeing in the DFSORT - ICETOOL 
> > Chapter and its example:
> > Example 3 - Create files with matching and non-matching records I've 
> > copied the example below and my question is regarding the last line 
> > below and it statement on sorting:
> > We sort the records of T1 on positions 1-3 and splice the second id 
> > byte for matching records.
> > 
> > Where in the JCL code does it state to sort the T1 records on 
> > positions
> 1-3??
> > 
> > //S3 EXEC PGM=ICETOOL
> > //TOOLMSG DD SYSOUT=*
> > //DFSMSG DD SYSOUT=*
> > //IN1 DD *
> > Vicky
> > Frank
> > Carrie
> > Holly
> > Paul
> > /*
> > //IN2 DD *
> > Karen
> > Holly
> > Carrie
> > Vicky
> > Mary
> > /*
> > //OUT12 DD SYSOUT=*
> > //OUT1 DD SYSOUT=*
> > //OUT2 DD SYSOUT=*
> > //T1 DD DSN=&,DISP=(MOD,PASS),UNIT=SYSDA,SPACE=(TRK,(5,5))
> > //TOOLIN DD *
> >COPY FROM(IN1) TO(T1) USING(CTL1)
> >COPY FROM(IN2) TO(T1) USING(CTL2)
> >SPLICE FROM(T1) TO(OUT12) ON(1,10,CH) WITH(13,1) USING(CTL3)
> KEEPNODUPS
> > /*
> > //CTL1CNTL DD *
> >OUTREC FIELDS=(1,10,12:C'11')
> > /*
> > //CTL2CNTL DD *
> >OUTREC FIELDS=(1,10,12:C'22')
> > /*
> > //CTL3CNTL DD *
> >OUTFIL FNAMES=OUT12,INCLUDE=(12,2,CH,EQ,C'12'),OUTREC=(1,10)
> >OUTFIL FNAMES=OUT1,INCLUDE=(12,2,CH,EQ,C'11'),OUTREC=(1,10)
> >OUTFIL FNAMES=OUT2,INCLUDE=(12,2,CH,EQ,C'22'),OUTREC=(1,10)
> > /*
> > 
> > We copy the IN1 records to the T1 data set and 

Re: ICETOOL - Question regarding a statement in the ICETOOL Guide

[Sri h Kolusu]

Bill,

Here is a DFSORT JOINKEYS job which will give you the desired results 
similar to splice


//STEP0100 EXEC PGM=SORT 
//SYSOUT   DD SYSOUT=* 
//INA  DD * 
VICKY 
FRANK 
CARRIE 
HOLLY 
PAUL 
//INB  DD * 
KAREN 
HOLLY 
CARRIE 
VICKY 
MARY 
//OUT12DD SYSOUT=* 
//OUT1 DD SYSOUT=* 
//OUT2 DD SYSOUT=* 
//SYSINDD * 
  OPTION COPY 
  JOINKEYS F1=INA,FIELDS=(1,10,A) 
  JOINKEYS F2=INB,FIELDS=(1,10,A) 
  JOIN UNPAIRED 
  REFORMAT FIELDS=(F1:1,10,?,F2:1,10) 

  OUTFIL FNAMES=OUT12,INCLUDE=(11,1,CH,EQ,C'B'),BUILD=(1,10) 
  OUTFIL FNAMES=OUT1,INCLUDE=(11,1,CH,EQ,C'1'),BUILD=(1,10) 
  OUTFIL FNAMES=OUT2,INCLUDE=(11,1,CH,EQ,C'2'),BUILD=(12,10) 
//* 


Joinkeys is explained in detail here

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.icea100/joinkeys.htm

Also here are the examples (look up example 5 )

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icea100/ice2ca_JOINKEYS_application_examples.htm


Further if you have any questions please send an email to our hotline 
(dfs...@us.ibm.com) or you can mail me directly.

Thanks,
Sri Hari Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on 
10/26/2017 11:41:15 PM:

> From: "George, William@FTB" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 10/26/2017 11:41 PM
> Subject: Re: ICETOOL - Question regarding a statement in the ICETOOL 
Guide
> Sent by: IBM Mainframe Discussion List 
> 
> Thanks Sri!
> JOINKEYS... that's a new one on me.  I guess I have an outdated DFSORT 
manual.
> Here's the link I have: 
http://publibz.boulder.ibm.com/epubs/pdf/ice1ca30.pdf
> 
> Thanks again
> Bill
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of Sri h Kolusu
> Sent: Thursday, October 26, 2017 10:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ICETOOL - Question regarding a statement in the ICETOOL 
Guide
> 
> George,
> 
> It was a typo in our publications, it should be 1-10 instead of 1-3.
> The sorting of 1-10 bytes is done with ON statement on SPLICE. 
> Please look at the DFSMSG dataset and you will see the SPLICE 
> control cards generates the SORT statement with 1,10,CH,A
> 
> We will update our pubs. Thanks for bringing it to our attention.
> 
> 
>  "We sort the records of T1 on positions 1-10 and splice the second 
> id byte for matching records. We use KEEPNODUPS to keep non-
> duplicate records. 
> 
> 
> Just an fyi, SPLICE is an Older technique to find the matching records. 
> Ideally we suggest using JOINKEYS
> 
> 
> Thanks,
> Sri Hari Kolusu
> DFSORT Development
> IBM Corporation
> 
> IBM Mainframe Discussion List  wrote on
> 10/26/2017 03:09:04 AM:
> 
> > From: "George, William@FTB" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 10/26/2017 03:09 AM
> > Subject: ICETOOL - Question regarding a statement in the ICETOOL Guide 

> > Sent by: IBM Mainframe Discussion List 
> > 
> > I am confused about a statement I'm seeing in the DFSORT - ICETOOL 
> > Chapter and its example:
> > Example 3 - Create files with matching and non-matching records I've 
> > copied the example below and my question is regarding the last line 
> > below and it statement on sorting:
> > We sort the records of T1 on positions 1-3 and splice the second id 
> > byte for matching records.
> > 
> > Where in the JCL code does it state to sort the T1 records on 
> > positions
> 1-3??
> > 
> > //S3 EXEC PGM=ICETOOL
> > //TOOLMSG DD SYSOUT=*
> > //DFSMSG DD SYSOUT=*
> > //IN1 DD *
> > Vicky
> > Frank
> > Carrie
> > Holly
> > Paul
> > /*
> > //IN2 DD *
> > Karen
> > Holly
> > Carrie
> > Vicky
> > Mary
> > /*
> > //OUT12 DD SYSOUT=*
> > //OUT1 DD SYSOUT=*
> > //OUT2 DD SYSOUT=*
> > //T1 DD DSN=&,DISP=(MOD,PASS),UNIT=SYSDA,SPACE=(TRK,(5,5))
> > //TOOLIN DD *
> >COPY FROM(IN1) TO(T1) USING(CTL1)
> >COPY FROM(IN2) TO(T1) USING(CTL2)
> >SPLICE FROM(T1) TO(OUT12) ON(1,10,CH) WITH(13,1) USING(CTL3)
> KEEPNODUPS
> > /*
> > //CTL1CNTL DD *
> >OUTREC FIELDS=(1,10,12:C'11')
> > /*
> > //CTL2CNTL DD *
> >OUTREC FIELDS=(1,10,12:C'22')
> > /*
> > //CTL3CNTL DD *
> >OUTFIL FNAMES=OUT12,INCLUDE=(12,2,CH,EQ,C'12'),OUTREC=(1,10)
> >OUTFIL FNAMES=OUT1,INCLUDE=(12,2,CH,EQ,C'11'),OUTREC=(1,10)
> >OUTFIL FNAMES=OUT2,INCLUDE=(12,2,CH,EQ,C'22'),OUTREC=(1,10)
> > /*
> > 
> > We copy the IN1 records to the T1 data set and add an identifier of 
> > '11' to show they come from FILE1.
> >  We copy the IN2 records to the end (MOD) of the T1 data set and add 
> > an identifier of '22' to show they come from FILE2.
> >  We sort the records of T1 on positions 1-3 and splice the second id 
> > byte for matching records.
> > 
> > 
> > Thanks for any insights
> > Bill
> > 
> > __
> > CONFIDENTIALITY NOTICE: This email from 

Re: IBM open sources its JVM and JIT code

[David Crayford]

On 28/10/2017 12:02 AM, John McKown wrote:

On Fri, Oct 27, 2017 at 10:43 AM, Rob Schramm  wrote:


Has anyone looked or asked the NetRexx guys if there is a way to use TSO
type of commands in NetRexx?


​I can't see any way to run a TSO command using NetRexx. But, in a more
general sense, I don't see any way to run a TSO command from a Java
program. NetRexx, being a JVM based language, can do anything that Java can
do. In particular, a NetRexx program can use JCICS and so be used to write
CICS programs. Or it can use JZOS / JRIO to do "batch" type work. But I
don't see any Java library to invoke a TSO command. ​



And as Martin pointed out to do so would require JNI which would burn 
CPU cycles and be pointless. Crossing a JNI boundary is expensive.





Rob Schramm




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

Re: IBM open sources its JVM and JIT code

[John McKown]

On Fri, Oct 27, 2017 at 10:43 AM, Rob Schramm  wrote:

> Has anyone looked or asked the NetRexx guys if there is a way to use TSO
> type of commands in NetRexx?
>

​I can't see any way to run a TSO command using NetRexx. But, in a more
general sense, I don't see any way to run a TSO command from a Java
program. NetRexx, being a JVM based language, can do anything that Java can
do. In particular, a NetRexx program can use JCICS and so be used to write
CICS programs. Or it can use JZOS / JRIO to do "batch" type work. But I
don't see any Java library to invoke a TSO command. ​



>
> Rob Schramm
>
>

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: IBM open sources its JVM and JIT code

[Rob Schramm]

Has anyone looked or asked the NetRexx guys if there is a way to use TSO
type of commands in NetRexx?

Rob Schramm

On Fri, Oct 27, 2017, 11:30 AM David Crayford  wrote:

> On 27/10/2017 11:18 PM, John McKown wrote:
> >> Best post in this thread! We want a JIT for classic REXX so it can run
> at
> >> speeds similar to compiled languages.
> >>
> >>
> > ​I'd vote "for" that. Of course, the standard IBM response will be given:
> > "How much are you willing to pay us to do that?" ​and "What do you want
> us
> > to_not_  do in order to free up the resources to re-architect and rewrite
> > classic z/OS TSO REXX from ??? into C++ and use a virtual machine in
> order
> > to be able to use the JIT?"
>
> We all know it wont happen so it's a moot point...
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT

[Lizette Koehler]

Dear List -

I have been reviewing some parms that have been around in z/OS for a few
years/decades?

USEZOSV1R9RULES

VSM USEZOSV1R9RULES(NO|YES): YES causes GETMAIN and STORAGE OBTAIN behavior to
be unchanged from its historic behavior. NO causes GETMAIN and STORAGE OBTAIN
behavior for user-region private area subpools that are both below and above the
line to be implemented. Thus DQEs can be merged where possible. The default is
YES to provide a seamless migration. However, IBM recommends that you specify
USEZOSV1R9RULES(NO) to obtain a performance benefit for applications with long
DQE/FQE chains for user-region private area subpools.

To Display:  D DIAG

MEMDSENQMGT

Allocation enhancement - MEMDSENQMGMT (Memory-based data set ENQ management)
- ENQs managed in private storage instead of SWA blocks. Job will be
non-restartable.
- Enable via parmlib member or MVS command:
. ALLOCxx: SYSTEM MEMDSENQMGMT(ENABLE)
. SETALLOC SYSTEM,MEMDSENQMGMT=ENABLE
- Exploit with DB2 APAR PM17542 (closed September 2010)

To display:  D ALLOC,OPTIONS

I was wondering two things

1) How many are using the new algorithms these two parms brought in?
2) When you changed to the new functions, did you see any issues?   Any products
that need TLC?


Are there any other that might also be helpful?


Thank you


Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately

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

Re: IBM open sources its JVM and JIT code

[David Crayford]

On 27/10/2017 11:18 PM, John McKown wrote:

Best post in this thread! We want a JIT for classic REXX so it can run at
speeds similar to compiled languages.



​I'd vote "for" that. Of course, the standard IBM response will be given:
"How much are you willing to pay us to do that?" ​and "What do you want us
to_not_  do in order to free up the resources to re-architect and rewrite
classic z/OS TSO REXX from ??? into C++ and use a virtual machine in order
to be able to use the JIT?"


We all know it wont happen so it's a moot point...

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

Re: IBM open sources its JVM and JIT code

[David Crayford]

Good point, but if you can reduce your REXX CPU using a JIT by at least 
a half you don't care about zIIP elibility. The same applies for using 
faster languages.



On 27/10/2017 11:16 PM, Martin Packer wrote:

And we didn't discuss zIIP-eligibility...

... It's a bit like compiling REXX...

... Don't expect it to buy you much if the things being scripted are heavy
compared to the things scripting them. Effectively the command processors
are JNI.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

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

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




From:   David Crayford 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   27/10/2017 16:12
Subject:Re: IBM open sources its JVM and JIT code
Sent by:IBM Mainframe Discussion List 



On 27/10/2017 9:47 PM, Walt Farrell wrote:

Did we somehow arrive at a generalized requirement to be able to access
particular TSO/ISPF features from*other*  programming languages that

are

not REXX, in a discussion about JITs, because of the functional utility
some z/OS system programmers desire to use other programming languages
besides REXX for scripts in TSO/ISPF?

I think we arrived at this idea because someone suggested it would be

nice if the open-sourced JIT technology that started this thread could be
applied to REXX. Then someone else said we don't really need that, because
NetREXX fulfills the desire to have REXX code that can be JITted. But then
someone else pointed out that NetREXX can't do all the same kinds of
things that REXX can, especially with respect to TSO and ISPF integration.

Therefore, as NetREXX can't substitute for REXX, we still have the

desire (if, perhaps, not the need) for a true classic REXX that can make
use of the JIT technology.

Best post in this thread! We want a JIT for classic REXX so it can run
at speeds similar to compiled languages.

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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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


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

Re: IBM open sources its JVM and JIT code

[John McKown]

On Fri, Oct 27, 2017 at 10:12 AM, David Crayford 
wrote:

> On 27/10/2017 9:47 PM, Walt Farrell wrote:
>
>> Did we somehow arrive at a generalized requirement to be able to access
>>> particular TSO/ISPF features from*other*  programming languages that are
>>> not REXX, in a discussion about JITs, because of the functional utility
>>> some z/OS system programmers desire to use other programming languages
>>> besides REXX for scripts in TSO/ISPF?
>>>
>> I think we arrived at this idea because someone suggested it would be
>> nice if the open-sourced JIT technology that started this thread could be
>> applied to REXX. Then someone else said we don't really need that, because
>> NetREXX fulfills the desire to have REXX code that can be JITted. But then
>> someone else pointed out that NetREXX can't do all the same kinds of things
>> that REXX can, especially with respect to TSO and ISPF integration.
>>
>> Therefore, as NetREXX can't substitute for REXX, we still have the desire
>> (if, perhaps, not the need) for a true classic REXX that can make use of
>> the JIT technology.
>>
>
> Best post in this thread! We want a JIT for classic REXX so it can run at
> speeds similar to compiled languages.
>
>
​I'd vote "for" that. Of course, the standard IBM response will be given:
"How much are you willing to pay us to do that?" ​and "What do you want us
to _not_ do in order to free up the resources to re-architect and rewrite
classic z/OS TSO REXX from ??? into C++ and use a virtual machine in order
to be able to use the JIT?"


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: IBM open sources its JVM and JIT code

[Martin Packer]

And we didn't discuss zIIP-eligibility...

... It's a bit like compiling REXX...

... Don't expect it to buy you much if the things being scripted are heavy 
compared to the things scripting them. Effectively the command processors 
are JNI.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

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

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



From:   David Crayford 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   27/10/2017 16:12
Subject:Re: IBM open sources its JVM and JIT code
Sent by:IBM Mainframe Discussion List 



On 27/10/2017 9:47 PM, Walt Farrell wrote:
>> Did we somehow arrive at a generalized requirement to be able to access
>> particular TSO/ISPF features from*other*  programming languages that 
are
>> not REXX, in a discussion about JITs, because of the functional utility
>> some z/OS system programmers desire to use other programming languages
>> besides REXX for scripts in TSO/ISPF?
> I think we arrived at this idea because someone suggested it would be 
nice if the open-sourced JIT technology that started this thread could be 
applied to REXX. Then someone else said we don't really need that, because 
NetREXX fulfills the desire to have REXX code that can be JITted. But then 
someone else pointed out that NetREXX can't do all the same kinds of 
things that REXX can, especially with respect to TSO and ISPF integration.
>
> Therefore, as NetREXX can't substitute for REXX, we still have the 
desire (if, perhaps, not the need) for a true classic REXX that can make 
use of the JIT technology.

Best post in this thread! We want a JIT for classic REXX so it can run 
at speeds similar to compiled languages.

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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: IBM open sources its JVM and JIT code

[David Crayford]

On 27/10/2017 9:47 PM, Walt Farrell wrote:

Did we somehow arrive at a generalized requirement to be able to access
particular TSO/ISPF features from*other*  programming languages that are
not REXX, in a discussion about JITs, because of the functional utility
some z/OS system programmers desire to use other programming languages
besides REXX for scripts in TSO/ISPF?

I think we arrived at this idea because someone suggested it would be nice if 
the open-sourced JIT technology that started this thread could be applied to 
REXX. Then someone else said we don't really need that, because NetREXX 
fulfills the desire to have REXX code that can be JITted. But then someone else 
pointed out that NetREXX can't do all the same kinds of things that REXX can, 
especially with respect to TSO and ISPF integration.

Therefore, as NetREXX can't substitute for REXX, we still have the desire (if, 
perhaps, not the need) for a true classic REXX that can make use of the JIT 
technology.


Best post in this thread! We want a JIT for classic REXX so it can run 
at speeds similar to compiled languages.


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

Re: IBM open sources its JVM and JIT code

[Paul Gilmartin]

On Fri, 27 Oct 2017 08:47:16 -0500, Walt Farrell wrote:
>
>I think we arrived at this idea because someone suggested it would be nice if 
>the open-sourced JIT technology that started this thread could be applied to 
>REXX. Then someone else said we don't really need that, because NetREXX 
>fulfills the desire to have REXX code that can be JITted. But then someone 
>else pointed out that NetREXX can't do all the same kinds of things that REXX 
>can, especially with respect to TSO and ISPF integration.
>
>Therefore, as NetREXX can't substitute for REXX, we still have the desire (if, 
>perhaps, not the need) for a true classic REXX that can make use of the JIT 
>technology.
> 
That's two out of three (perhaps of four):

o JIT optimization

o Drop-in compatibility with classic Rexx

o Functional extensions of NetRexx or OoRexx.

About a half-century ago, before I had brushed against an s/360, a graduate
student fresh out of Yale lauded OS (MVT?) for a design integrity: any program
in any language could seamlessly call a subroutine in any other language; even
the OS invoking main programs.  All used the same CALL interface.  I asked,
SNOBOL4?  LISP?  "Why, of course!"  I was skeptical even then.  TSO with its
CPPL, and Rexx have surely broken the mold.

-- gil

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

Re: TWS on ZOS Help / Educational Resources

[Philippe TESSIER]

Hi Len

We didn't do this kind of migration in the pass but the engine can be adapted 
to ZEKE or other scheduler we don't see onetime.

Our need is to have the brochure of the scheduler to migrate and a consultant 
with skill on ZEKE.

Best Regards

Philippe TESSIER

>> 
>> What about Migrating from ASG ZEKE & ZEBB to IWS?
>> 
>> 
>> Thank You,
>> Len Sasso
>> System Administrator
>> TEAM: Together Everyone Achieves More
>> 
>> RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
>> t: +1.518.257.4209 | m: +1.518.894.0879
>> len.sa...@csra.com  | www.csra.com 
>>  Follow us on Facebook | Twitter | LinkedIn
>> CSRA
>> Think Next. Now.
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU 
>> ] On Behalf Of TESSIER Philippe
>> Sent: Friday, October 27, 2017 2:11 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU 
>> Subject: Re: TWS on ZOS Help / Educational Resources
>> 
>> Hi Steve
>> 
>> I'm teatcher since 1989 on TWS z/OS user and systems but also teatcher on 
>> TWS distributed since 2012.
>> 
>> I can propose many services around TWS
>> 
>> 1) training
>> 2) Audit
>> 3) Upgrade
>> 4) architecture
>> 5) Migrating from any scheduler to any scheduler ( $U, CM, Autosys, TWS ZOS, 
>> TWS D, Cortex, CA7, CA-scheduler,...)
>> 6) Beta tester of TWS z and D
>> 
>> I have at least 40 differents TWS on my machine.
>> 
>> Philippe TESSIER
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu  
>> with the message: INFO IBM-MAIN
>> 
>> This electronic message transmission contains information from CSRA that may 
>> be attorney-client privileged, proprietary or confidential. The information 
>> in this message is intended only for use by the individual(s) to whom it is 
>> addressed. If you believe you have received this message in error, please 
>> contact me immediately and be aware that any use, disclosure, copying or 
>> distribution of the contents of this message is strictly prohibited. NOTE: 
>> Regardless of content, this email shall not operate to bind CSRA to any 
>> order or other contract unless pursuant to explicit written agreement or 
>> government initiative expressly permitting the use of email for such purpose.
>> 
>> --
>> 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: Batch TSO command (ADDUSER) tracing and diagnostics

[Walt Farrell]

On Fri, 27 Oct 2017 07:39:00 +, Baguley, Nicholas: Absa 
 wrote:

>When you use PARM andonot SYSTSIN it doesn’t seem to ECHO input/command. I 
>tried it before posting so as not to incur wrath of LIST

After John also confirmed that, I thought some more and realized that it 
probably works that way so that a TSO logon proc can invoke some 
"pre-processing" CLIST or REXX exec to perform setup, without the setup command 
echoing to the user's screen.

>Walt - correct.. the userid of the mother task is not authorised to ADDUSER. 
>The ATTACH is done in supervisor state. Don’t try this at home type stuff

But that doesn't resolve all the problems. Presumably, you're creating an ACEE 
for the user that you want to use for running the command. But how do you get 
that ACEE attached to the TCB that runs the ADDUSER command? Attaching the ACEE 
to the TCB for the TMP TCB that you attached won't do the job, as task-level 
ACEEs don't propagate to subtasks except in one very specific circumstance (WLM 
servants processing requests from a WLM queue) and you haven't mentioned WLM. 
Or at least, you haven't mentioned it yet :)

So if you're not in that situation (WLM servant, WLM request queueing) then the 
ADDUSER will run under the address space ACEE as far as I know, and will 
probably fail for lack of authority, giving you an RC=8.

-- 
Walt

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

Re: IBM open sources its JVM and JIT code

[Walt Farrell]

On Fri, 27 Oct 2017 14:48:32 +0800, Timothy Sipples  wrote:


>Did we somehow arrive at a generalized requirement to be able to access
>particular TSO/ISPF features from *other* programming languages that are
>not REXX, in a discussion about JITs, because of the functional utility
>some z/OS system programmers desire to use other programming languages
>besides REXX for scripts in TSO/ISPF?

I think we arrived at this idea because someone suggested it would be nice if 
the open-sourced JIT technology that started this thread could be applied to 
REXX. Then someone else said we don't really need that, because NetREXX 
fulfills the desire to have REXX code that can be JITted. But then someone else 
pointed out that NetREXX can't do all the same kinds of things that REXX can, 
especially with respect to TSO and ISPF integration.

Therefore, as NetREXX can't substitute for REXX, we still have the desire (if, 
perhaps, not the need) for a true classic REXX that can make use of the JIT 
technology.

-- 
Walt

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

Re: TWS on ZOS Help / Educational Resources

[Sasso, Leonard]

What about Migrating from ASG ZEKE & ZEBB to IWS?


Thank You,
Len Sasso
System Administrator
TEAM: Together Everyone Achieves More

RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn
CSRA
Think Next. Now.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of TESSIER Philippe
Sent: Friday, October 27, 2017 2:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TWS on ZOS Help / Educational Resources

Hi Steve

I'm teatcher since 1989 on TWS z/OS user and systems but also teatcher on TWS 
distributed since 2012.

I can propose many services around TWS

1) training
2) Audit
3) Upgrade
4) architecture
5) Migrating from any scheduler to any scheduler ( $U, CM, Autosys, TWS ZOS, 
TWS D, Cortex, CA7, CA-scheduler,...)
6) Beta tester of TWS z and D

I have at least 40 differents TWS on my machine.

Philippe TESSIER

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

This electronic message transmission contains information from CSRA that may be 
attorney-client privileged, proprietary or confidential. The information in 
this message is intended only for use by the individual(s) to whom it is 
addressed. If you believe you have received this message in error, please 
contact me immediately and be aware that any use, disclosure, copying or 
distribution of the contents of this message is strictly prohibited. NOTE: 
Regardless of content, this email shall not operate to bind CSRA to any order 
or other contract unless pursuant to explicit written agreement or government 
initiative expressly permitting the use of email for such purpose.

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

Re: CA1 to RMM conversion

[Ed Jaffe]

On 10/26/2017 8:21 PM, Longnecker, Dennis wrote:

I miss CA-1.  I found it much easier to use than RMM.  I am constantly trying 
to remember how to find things in RMM that were so simple to find in CA-1.  
What I especially miss is the reporting in CA-1.  They were so simple to 
create.  I find that I have to utilize FDR/ABR reporting to give me the RMM 
reports I want.


There are two main reasons people use one product over another: 
functionality and cost. You miss CA-1's functionality over RMM.


It's highly unusual for support to be much of a factor in product 
decisions unless the customer has encountered an ongoing pattern of 
serious problems that never get resolved. That's what makes Ed Gould's 
line of reasoning in this thread so bewildering...


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

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

Re: IBM open sources its JVM and JIT code

[David Crayford]

Agreed, that would be great. I've had a crack at porting ooRexx but the 
integration into TSO/ISPF was a major issue. Getting it to work outside 
of the z/OS UNIX file system is challenging as it doesn't use fopen(). 
It also uses threads which may interesting when running in TSO and 
especially ISPF environments. I put it in the too hard basket. Getting 
Lua to load scripts and modules from MVS data sets was trivial. All I 
had to do was patch the loader with //DD:LUA(%s) in the chain and 
fopen() did the rest. There were other benefits to switching languages 
such as modern features like duck typing, co-routines, closures, 
functions as first class objects etc, etc not to mention execution speed.



On 27/10/2017 2:51 PM, Martin Packer wrote:

I’ve always said that what we need on TSO is Open ObjectREXX - but with the 
strong proviso it can be used as a drop-in for traditional REXX. That means:

1) It can script commands.

2) Things that invoke the REXX interpreter can invoke it in the same way.

Note: I’m not sure NetRexx is actually required.

Cheers, Martin

Sent from my iPad


On 27 Oct 2017, at 07:48, Timothy Sipples  wrote:

Peter Farley wrote:

IMHO it isn't "... consuming non-trivial peak resources running their REXX
scripts in TSO/ISPF" that is the issue for alternatives like Netrexx.

OK, then what *is* the requirement?


It is the ability to use TSO facilities (like EXECIO, LISTDSI, etc.) and

ISPF

utilities like the LMM routines and other "command" environments that

is

the issue.

Yes, and we have REXX for that, interpreted and compiled, and it's lovely
or at least lovable. There's even some REXX support in IBM Developer for Z,
as a notable example. Where's the unmet need, the gap?

Did we somehow arrive at a generalized requirement to be able to access
particular TSO/ISPF features from *other* programming languages that are
not REXX, in a discussion about JITs, because of the functional utility
some z/OS system programmers desire to use other programming languages
besides REXX for scripts in TSO/ISPF?

OK, if I've understood so far, which other programming language(s)? Python,
Perl, Java, JavaScript, something else?

I'm just asking the "Why?" questions, that's all. Not opposed! I'm
intrigued, actually, which is why I'm asking.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, 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


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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


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

Re: Batch TSO command (ADDUSER) tracing and diagnostics

[Robert S. Hansel (RSH)]

Hi Nick,

As a way to avoid problems to begin with, does your routine first check to see 
if there is an existing user ID or group that matches the ID it is about to 
create, that the ID is syntactically correct, and that the default group exists?

What RACF authority is the IMS address space using to create IDs? What if any 
segments is it creating along with the ID? There may be other pre-command 
checks we can recommend.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc. *** Celebrating our 25th Year ***
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

Upcoming RSH RACF Training - WebEx
- RACF Audit & Compliance Roadmap - FEB 5-9, 2018
- RACF Level I Administration - DEC 5-8, 2017
- RACF Level II Administration - NOV 13-17, 2017
- RACF Level III Admin, Audit, & Compliance - OCT 2-6, 2017
- RACF - Securing z/OS UNIX  - OCT 23-27, 2017


-Original Message-
Date:Thu, 26 Oct 2017 07:30:07 +
From:"Baguley, Nicholas: Absa" 
Subject: Batch TSO command (ADDUSER) tracing and diagnostics

Hi List

We need to echo or trace the TSO commands processed in a batch TSO process...
We are issuing an ADDUSER command under TSO and it returns a RC=8.
In itself not a "biggie". We run TSO via an ATTACH of IKJEFTnn(1B in this case) 
so it is a subtask of an IMS address space.
The ADDUSER command is passed to IKJEFT as a PARM on the attach svc/macro as 
opposed to SYSTSIN.

We don't see the command "echoed" to SYSTSPRT as you "normally" do when using 
SYSTSIN.
Is anyone aware of a mechanism of switching on tracing or diagnosing PARM= 
input to IKJ?

NB - this works fine in 99% of cases. We suspect either we are not building up 
the ADDUSER command correctly(syntax error) or we have a RACF issue.
Unfortunately my next opportunity to make a program change and  the 
command to the syslog is a couple of weeks away.
Maybe the assumption within the the bowels of TSO was that if input is via PARM 
then there would be a jcl deck or job output to inspect.

TIA

Nick

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

Re: Batch TSO command (ADDUSER) tracing and diagnostics

[Baguley, Nicholas: Absa]

Hi List

Wow - thanks for input List
Lots of ideas , suggestions and questions.

When you use PARM and not SYSTSIN it doesn’t seem to ECHO input/command. I 
tried it before posting so as not to incur wrath of LIST
Walt - correct.. the userid of the mother task is not authorised to ADDUSER. 
The ATTACH is done in supervisor state. Don’t try this at home type stuff
Tony - attach worked fine as you stated. See code snippet below.

LIST - I assume if I "front-end" this process it would have to keep the 
authorised chain alive? Taking Walts suggestion (but via asm pgm and nor rexx) 
and extending it to creating a IKJEFT1X ac(1)?

At risk of being off topic - It raises the question of opening up functionality 
via transactional processing(CICS/IMS) to allow RACF users to be added.
Business wants it but by the time you have solved all the auth and audit stuff 
you have a monster. (getting from problem state running in an IMS dep region or 
CICS AOR to supervisor attaching an auth subtask etc etc and getting v messy) 
 

ATTACH PARAM=(TASKPRM),ECB=TASKECB, 
  MF=(E,TASKPMA),SF=(E,TASKATT) 
STR1,TASKTCB
LRR3,R15  SAVE I

BAL   R8,AUTHRES  RESET 

LTR   R3,R3   IKJEFT
BNZ   ATTFAIL NO - D
WAIT  ECB=TASKECB   
DETACH TASKTCB  
L R3,TASKECB  ISOLAT
N R3,=X'3FFF'   
LTR   R3,R3   TASK R
BNZ   CMDFAIL NO - D

Thanks again List
Walt, John, Tony, ITschak, Elardus, et al

-Original Message-
From: Tony Harminc [mailto:t...@harminc.net] 
Sent: 26 October 2017 08:28 PM
Subject: Re: Batch TSO command (ADDUSER) tracing and diagnostics

On 26 October 2017 at 03:30, Baguley, Nicholas: Absa < 
nicholas.bagu...@absa.co.za> wrote:

> Hi List
>
> We need to echo or trace the TSO commands processed in a batch TSO 
> process...
> We are issuing an ADDUSER command under TSO and it returns a RC=8.
> In itself not a "biggie". We run TSO via an ATTACH of IKJEFTnn(1B in 
> this
> case) so it is a subtask of an IMS address space.
>

As Walt points out, I don't believe this is a supported thing to do. Unless you 
are ATTACHing a new job step task, which raises plenty of other issues.

The ADDUSER command is passed to IKJEFT as a PARM on the attach svc/macro
> as opposed to SYSTSIN.
>
> We don't see the command "echoed" to SYSTSPRT as you "normally" do 
> when using SYSTSIN.
> Is anyone aware of a mechanism of switching on tracing or diagnosing 
> PARM= input to IKJ?
>

Not directly. But why not invoke a little REXX program from the PARM=, and have 
that program report back on the results, return codes, and so on of the actual 
command(s) you issue? You'd need access to this REXX program, but thst'a easily 
done with a SYSEXEC or  SYSPROC DD.

>
> NB - this works fine in 99% of cases.


Which suggests that your TMP is working via your ATTACH. Curious...

Tony H.

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

Important Notice:
Absa is an Authorised Financial Services Provider and Registered Credit 
Provider, 
registration number: NCRCP7. This e-mail and any files transmitted with it may 
contain information that is confidential, privileged or otherwise protected 
from 
disclosure. If you are not an intended recipient of this e-mail, do not 
duplicate 
or redistribute it by any means. Please delete it and any attachments and 
notify 
the sender that you have received it in error. Unless specifically indicated, 
this 
e-mail is not an offer to buy or sell or a solicitation to buy or sell any 
securities, 
investment products or other financial product or service, an official 
confirmation of 
any transaction, or an official statement of Absa. Any views or opinions 
presented 
are solely those of the author and do not necessarily represent those of Absa. 
This e-mail is subject to terms available at the following link: 
http://www.absa.co.za/disclaimer. 
The Disclaimer forms part of the content of this email. If you are unable to 
access 
the Disclaimer, send a blank e-mail to disclai...@absa.co.za and we will send 
you a 
copy of the Disclaimer. By messaging with Absa you consent to the foregoing. 
By emailing Absa you consent to the terms herein. This email may relate to or 
be sent 
from other members of the Absa Group.

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

Re: IBM open sources its JVM and JIT code

[Martin Packer]

I’ve always said that what we need on TSO is Open ObjectREXX - but with the 
strong proviso it can be used as a drop-in for traditional REXX. That means:

1) It can script commands.

2) Things that invoke the REXX interpreter can invoke it in the same way.

Note: I’m not sure NetRexx is actually required.

Cheers, Martin 

Sent from my iPad

> On 27 Oct 2017, at 07:48, Timothy Sipples  wrote:
> 
> Peter Farley wrote:
>> IMHO it isn't "... consuming non-trivial peak resources running their REXX
>> scripts in TSO/ISPF" that is the issue for alternatives like Netrexx.
> 
> OK, then what *is* the requirement?
> 
>> It is the ability to use TSO facilities (like EXECIO, LISTDSI, etc.) and
> ISPF
>> utilities like the LMM routines and other "command" environments that
> is
>> the issue.
> 
> Yes, and we have REXX for that, interpreted and compiled, and it's lovely
> or at least lovable. There's even some REXX support in IBM Developer for Z,
> as a notable example. Where's the unmet need, the gap?
> 
> Did we somehow arrive at a generalized requirement to be able to access
> particular TSO/ISPF features from *other* programming languages that are
> not REXX, in a discussion about JITs, because of the functional utility
> some z/OS system programmers desire to use other programming languages
> besides REXX for scripts in TSO/ISPF?
> 
> OK, if I've understood so far, which other programming language(s)? Python,
> Perl, Java, JavaScript, something else?
> 
> I'm just asking the "Why?" questions, that's all. Not opposed! I'm
> intrigued, actually, which is why I'm asking.
> 
> 
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM z Systems, 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
> 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: IBM open sources its JVM and JIT code

[Timothy Sipples]

Peter Farley wrote:
>IMHO it isn't "... consuming non-trivial peak resources running their REXX
>scripts in TSO/ISPF" that is the issue for alternatives like Netrexx.

OK, then what *is* the requirement?

>It is the ability to use TSO facilities (like EXECIO, LISTDSI, etc.) and
ISPF
>utilities like the LMM routines and other "command" environments that
is
>the issue.

Yes, and we have REXX for that, interpreted and compiled, and it's lovely
or at least lovable. There's even some REXX support in IBM Developer for Z,
as a notable example. Where's the unmet need, the gap?

Did we somehow arrive at a generalized requirement to be able to access
particular TSO/ISPF features from *other* programming languages that are
not REXX, in a discussion about JITs, because of the functional utility
some z/OS system programmers desire to use other programming languages
besides REXX for scripts in TSO/ISPF?

OK, if I've understood so far, which other programming language(s)? Python,
Perl, Java, JavaScript, something else?

I'm just asking the "Why?" questions, that's all. Not opposed! I'm
intrigued, actually, which is why I'm asking.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, 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: CA1 to RMM conversion

[Edward Gould]

> On 10/25/2017 10:35 PM, Edward Gould wrote:
>> 
>> The real question should be is how is IBM support for RMM?
> 
> I don't know in the general case, but anecdotally I once I had a situation 
> where RMM was *DOWN* (SEV 1) abending at startup. The support folks on the 
> other end seemed unable to glean much from the SVC dump I'd sent, so they 
> asked a bunch of rudimentary questions, made one useless suggestion after 
> another, asked for this and that trace, and generally "dinked" around until I 
> was ready to pull my hair out. (We were dead in the water for a couple of 
> days.)

All, I am not excusing IBM, but I have had similar issues with an OEM vendor 
and it is frustrating and exasperating. I have had one vendor wanting to delve 
into the listings of installation while the system was down.
After seeing that the session was going nowhere my mind started to go through 
sequences (the product had worked fine for 5 years). I was listening to the 
support person and looking what had changed on the system. My memory is iffy 
here but I think a PTF had hit IEFW21SD. It turned out that the blankety blank 
product interfaced. I told the guy that the mobile got hit by such and such PTF 
. It went over his head. I asked again did you know about ptfxx? He said 
why are you telling me this are you trying to confuse me? One last time I 
reminded him of the dependancy. I said I would back out the PTF and expect a 
call to his boss in the AM.
Its been ages but I do remember that the boss gave orders shortly thereafter to 
find a replacement. We did and never had an issue with it. 

Ed   
> 
> In desperation, I wrote to Mike Wood (now retired) and sent him my PMR 
> number. He was _astonished_ at the (lack of good) support I was getting! 
> He scolded his support team and told them straight away what the problem 
> likely was.
> 
> Thanks to Mike's help, my systems were up within the hour...
> 
> -

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

Re: TWS on ZOS Help / Educational Resources

[TESSIER Philippe]

Hi Steve

I'm teatcher since 1989 on TWS z/OS user and systems but also teatcher on TWS 
distributed since 2012.

I can propose many services around TWS

1) training
2) Audit
3) Upgrade
4) architecture 
5) Migrating from any scheduler to any scheduler ( $U, CM, Autosys, TWS ZOS, 
TWS D, Cortex, CA7, CA-scheduler,...) 
6) Beta tester of TWS z and D

I have at least 40 differents TWS on my machine.

Philippe TESSIER

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