Rule 1 implies (or is implied by) Rule 3?

[William W. Collier]

On Mon, 4 Apr 2016 09:30:47 -0700, Greg Dyck wrote:

What does rule 3 require that isn't equally implied by rule 1? 

  
  Here is a program execution which is MCWA, but which
violates program order.  Consequently, Rule 3 does not
imply Rule 1.

  Initially, A = B = X = Y = 0.
   
  T0T1
  L1: A = 1;   L1: B = 1;
  L2: X = B;   L2: Y = A;

  Terminally, A = B = 1, X = Y = 0.
  
  
  Here is a program execution which, if it read ordered, is not
MCWA.  Consequently, Rule 1 does not imply Rule 3.
  
  Initially, A = B = X = Y = 0.
   
   T0   T1   T2
  L1: A = 1;   L1: B = A;   L1: X = B;
L2: Y = A;

  Terminally, A = B = X = 1, Y = 0.


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

Re: How force dataset non-SMS?

[Jesse 1 Robinson]

Many SMS-based changes require reallocating the affected data set after any 
rule changes have been applied. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, April 05, 2016 10:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: How force dataset non-SMS?

Good thought but the ALTER ran to a zero completion and the darned dataset was 
still only one volume.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Shirey
Sent: Tuesday, April 05, 2016 11:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How force dataset non-SMS?

You can only bypass SMS if the ACS routines allow you to bypass SMS.  

You might be able to add two candidate volumes after allocation: 
ALTER data.set.name ADDVOLUMES(* *)

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

Re: Markdown Processor For z/OS

[David Crayford]

On 5/04/2016 9:32 PM, David Griffiths1 wrote:

Hi Martin, you could just use one of the free Java implementations. Or one
of the python ones might work with Jython.


You will have to use on of the older Python markdown packages as the 
newer ones tend to use Python 3.


Is Jython still being maintained?


Cheers,

Dave Griffiths
IBM Operational Decision Manager
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
Tel: +44 1962 816478 Mobile: 07590 195531
dgr...@uk.ibm.com
  




From:   Martin Packer/UK/IBM@IBMGB
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   27/03/2016 16:12
Subject:Markdown Processor For z/OS
Sent by:IBM Mainframe Discussion List 



Does anyone know of a processor for any flavour of Markdown available on
z/OS?

(I've an awful feeling I've asked this before - but haven't found the
question or the answer, so maybe not.)

It's tempting to write some REXX... :-)

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


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

Sharing and security was Re: Advice needed - GRS across 2 sysplexes with shared dasd

[Clark Morris]

[Default] On 5 Apr 2016 08:52:09 -0700, in bit.listserv.ibm-main
000a2a8c2020-dmarc-requ...@listserv.ua.edu (Tom Marchant) wrote:

>On Tue, 5 Apr 2016 14:24:37 +, Jesse 1 Robinson wrote:
>
>>None of those functions requires a coupling facility. We have both 
>>XCF and GRS (ring). And our basic sysplex has full PDSE support:
>
>Right, but IIRC, the OP has two sysplexes and wants to share between 
>them. As he noted, he will have to combine them into one.

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

Re: How force dataset non-SMS?

[Charles Mills]

PUT 10,000 records and then do 100 PUT/FEOV pairs.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sam Siegel
Sent: Tuesday, April 05, 2016 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How force dataset non-SMS?

Use the following JCL and Assembler program to force a multi-volume dataset 
under SMS control.

//DV55686X JOB ABC,'J: A11J',

// CLASS=A,

// MSGCLASS=9,

// NOTIFY=

//*

//JSDELEXEC PGM=IEFBR14

//DS010DD DSN=TEST.ABC.A11.MULTIVOL,

//DISP=(MOD,DELETE,DELETE),UNIT=3390,SPACE=(TRK,0)

//*

//JS010EXEC PGM=A11

//STEPLIB  DD DSN=DV55686.TSO.LOAD,DISP=SHR

//OUT  DD DSN=TEST.ABC.A11.MULTIVOL,

//DISP=(NEW,CATLG,CATLG),

//UNIT=(TEST,3),

//SPACE=(TRK,(2,1),RLSE),

//DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)



*

A11  AMODE 24

A11  RMODE 24

A11  CSECT

 USING *,R15

 STM   R14,R12,12(R13)ENTRY LOGIC

 LAR1,SA

 STR1,8(R13)

 STR13,4(R1)

 LRR13,R1

 LAR12,0(R15)

 DROP  R15

 USING A11,R12

*

 OPEN  (OUT,(OUTPUT)) OPEN DATASETS

 LTR   R15,R15OPEN OK?

 JZMAIN_010T-CONTINUE

*

 WTO   'A11 - OPEN ERROR',ROUTCDE=11  ISSUE ERROR MSG

 ABEND 1,DUMP,STEPABEND

*

MAIN_010 DS0H

 PUT   OUT,OUTPUT WRITE STATUS MSG

 APPL8,=P'1'

 CPPL8,=P'1'

 JHMAIN_020

 J MAIN_010   LOOP

*

MAIN_020 DS0H

 ZAP   PL8,=P'0'

*

MAIN_030 DS0H

 PUT   OUT,OUTPUT WRITE STATUS MSG

 FEOV  OUT

 APPL8,=P'1'

 CPPL8,=P'100'

 JHMAIN_040

 J MAIN_030   LOOP

*

MAIN_040 DS0H

 CLOSE (OUT)  EOF: CLOSE FILES

*

 L R13,4(R13) EXIT LOGIC

 LMR14,R12,12(R13)

 XRR15,R15

 BRR14

*

SA   DC18F'0' REGISTER SA

PL8  DCPL8'0'

*

OUTPUT   DCCL80'X'

*

*OUTPUT MESSAGE DD

OUT  DCB   DSORG=PS,MACRF=PM,RECFM=FB,LRECL=80,X

   DDNAME=OUT

*

 YREGS ,

 END   A11

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

Re: Markdown Processor For z/OS

[Martin Packer]

Thanks Dave! You're right. Do you have a view as to which one is really 
good?

I see, for example, https://code.google.com/archive/p/markdown4j/ , and I 
might well try it on my z/OS system.

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/category/mpt/



From:   David Griffiths1/UK/IBM@IBMGB
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   05/04/2016 14:32
Subject:Re: Markdown Processor For z/OS
Sent by:IBM Mainframe Discussion List 



Hi Martin, you could just use one of the free Java implementations. Or one 

of the python ones might work with Jython.

Cheers,

Dave Griffiths
IBM Operational Decision Manager
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
Tel: +44 1962 816478 Mobile: 07590 195531
dgr...@uk.ibm.com
 



From:   Martin Packer/UK/IBM@IBMGB
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   27/03/2016 16:12
Subject:Markdown Processor For z/OS
Sent by:IBM Mainframe Discussion List 



Does anyone know of a processor for any flavour of Markdown available on 
z/OS?

(I've an awful feeling I've asked this before - but haven't found the 
question or the answer, so maybe not.)

It's tempting to write some REXX... :-)

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



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: Advice needed - GRS across 2 sysplexes with shared dasd

[Cannaerts, Jan]

Thank you for the conclusive answer, Joe.

Didn't see the docs mention it, but like I said, I highly doubt anyone
is having, or will have this problem.

--
Jan



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph W Gentile
Sent: dinsdag 5 april 2016 9:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Advice needed - GRS across 2 sysplexes with shared dasd

With ACCELSYS, it is technically possible (for any resource) but highly 
unlikely given the small window. To mitigate the risk, you can use GRS 
Star mode. In lieu of that, an ACCELSYS value of at least half the complex 
size will make it very difficult for two systems to independently obtain 
the same ENQ at the same time, without their neighboring systems in the 
Ring seeing the conflict. 
 
-Joe

Joe Gentile
z/OS GRS Lead
jwgen...@us.ibm.com


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

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

Re: Advice needed - GRS across 2 sysplexes with shared dasd

[Joseph W Gentile]

With ACCELSYS, it is technically possible (for any resource) but highly 
unlikely given the small window. To mitigate the risk, you can use GRS 
Star mode. In lieu of that, an ACCELSYS value of at least half the complex 
size will make it very difficult for two systems to independently obtain 
the same ENQ at the same time, without their neighboring systems in the 
Ring seeing the conflict. 
 
-Joe

Joe Gentile
z/OS GRS Lead
jwgen...@us.ibm.com


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

Re: How to find where a module has been dynamically loaded from?

[Edward Finnell]

google 'ISPF Hidden Treasures' Several of Peter van Dyke's excellent SHARE  
papers(.pdf) should pop-up for download. Or if you're SHARE enabled can 
search  youownself 
 
 
In a message dated 4/5/2016 1:37:19 P.M. Central Daylight Time,  
ren.bren...@bkfs.com writes:

And,  although I've never tried it, you should be able to invoke ISRDDN 
from a batch  TSO session as well.


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

Re: How force dataset non-SMS?

[Sam Siegel]

Use the following JCL and Assembler program to force a multi-volume dataset
under SMS control.

//DV55686X JOB ABC,'J: A11J',

// CLASS=A,

// MSGCLASS=9,

// NOTIFY=

//*

//JSDELEXEC PGM=IEFBR14

//DS010DD DSN=TEST.ABC.A11.MULTIVOL,

//DISP=(MOD,DELETE,DELETE),UNIT=3390,SPACE=(TRK,0)

//*

//JS010EXEC PGM=A11

//STEPLIB  DD DSN=DV55686.TSO.LOAD,DISP=SHR

//OUT  DD DSN=TEST.ABC.A11.MULTIVOL,

//DISP=(NEW,CATLG,CATLG),

//UNIT=(TEST,3),

//SPACE=(TRK,(2,1),RLSE),

//DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)



*

A11  AMODE 24

A11  RMODE 24

A11  CSECT

 USING *,R15

 STM   R14,R12,12(R13)ENTRY LOGIC

 LAR1,SA

 STR1,8(R13)

 STR13,4(R1)

 LRR13,R1

 LAR12,0(R15)

 DROP  R15

 USING A11,R12

*

 OPEN  (OUT,(OUTPUT)) OPEN DATASETS

 LTR   R15,R15OPEN OK?

 JZMAIN_010T-CONTINUE

*

 WTO   'A11 - OPEN ERROR',ROUTCDE=11  ISSUE ERROR MSG

 ABEND 1,DUMP,STEPABEND

*

MAIN_010 DS0H

 PUT   OUT,OUTPUT WRITE STATUS MSG

 APPL8,=P'1'

 CPPL8,=P'1'

 JHMAIN_020

 J MAIN_010   LOOP

*

MAIN_020 DS0H

 ZAP   PL8,=P'0'

*

MAIN_030 DS0H

 PUT   OUT,OUTPUT WRITE STATUS MSG

 FEOV  OUT

 APPL8,=P'1'

 CPPL8,=P'100'

 JHMAIN_040

 J MAIN_030   LOOP

*

MAIN_040 DS0H

 CLOSE (OUT)  EOF: CLOSE FILES

*

 L R13,4(R13) EXIT LOGIC

 LMR14,R12,12(R13)

 XRR15,R15

 BRR14

*

SA   DC18F'0' REGISTER SA

PL8  DCPL8'0'

*

OUTPUT   DCCL80'X'

*

*OUTPUT MESSAGE DD

OUT  DCB   DSORG=PS,MACRF=PM,RECFM=FB,LRECL=80,X

   DDNAME=OUT

*

 YREGS ,

 END   A11

On Tue, Apr 5, 2016 at 10:51 AM, Charles Mills  wrote:

> Yup.
>
> VOLUMES
>   VOLSERLS0502 DEVTYPE--X'3010200F'
>   VOLSER-* DEVTYPE--X''
>   VOLSER-* DEVTYPE--X''
>   VOLSER-* DEVTYPE--X''
>   VOLSER-* DEVTYPE--X''
>
> SMS is too darned smart!
>
> I *really* don't want to figure out some IEBGENER or Rexx to load a
> zillion tracks of data into it.
>
> Maybe I will try to figure out some other way to solve the original
> problem.
>
> I will ask the SMS guys I guess. Wanted to avoid that.
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John Clifford
> Sent: Tuesday, April 05, 2016 1:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How force dataset non-SMS?
>
> I you got it out of SMS, and not enough data gets loaded so a 2nd or third
> vol is needed, it will only show a single vol-ser.  If you run a listcat of
> the dataset does it show an '*" for the 2 volumes not used yet ??
> (Candidate volumes)???
>
> --
> 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: COBOL 5.2 and VS Cobol questions

[Staller, Allan]

".  Were currently running COBOL 4.2 and i'm curious if we can run the linkedit 
on 4.2 or do we need to wait and run the relink under 5.2." 

You *ARE NOT* invoking the compiler. You are only dealing with load modules 
here. The question above is a non-sequitor.


We're preparing to upgrade to COBOL 5.2 and need to update our VS COBOL 
programs before doing so to replace IGZEBST. Please see below for a sample 
relink that we're using.  Were currently running COBOL 4.2 and i'm curious if 
we can run the linkedit on 4.2 or do we need to wait and run the relink under 
5.2. We're currently using LE for z/OS 2.1.

//LINK   EXEC  PGM=IEWL,PARM='LIST,MAP,XREF'
//SYSPRINT DD  SYSOUT=* 
//SYSLIB   DD  DSN=CEE.SCEELKED,DISP=SHR
//LOADLIB  DD  DSN=TKTH000.PROD.LOAD.S6000,DISP=SHR 
//SYSLMOD  DD  DSN=TKTH000.SYS2.LINKLIB,DISP=SHR
//SYSUT1   DD  UNIT=SYSDA,SPACE=(CYL,(2,2)),DISP=NEW
//SYSLIN   DD  * 
  REPLACE IGZEBST
  INCLUDE LOADLIB(IAD028)
  ENTRY   IAD028 
  NAMEIAD028(R)  


This email � including attachments � may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

Re: How to find where a module has been dynamically loaded from?

[Brenton, Ren]

The LINKLIST is the LINKLIST, regardless if you are processing in BATCH, or 
TSO/ISPF.  So if you fire up ISRDDN from TSO, you should be able to find your 
module, and it should be loaded from the same place in your batch job.

And, although I've never tried it, you should be able to invoke ISRDDN from a 
batch TSO session as well.

Ren
Ext 1448


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, April 05, 2016 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to find where a module has been dynamically loaded from?

On Tue, 5 Apr 2016 08:45:14 -0500, Elardus Engelbrecht wrote:
>
>In batch job or in a session? If in TSO, you already got the answer from Ren 
>Brenton about ISRDDN.
> 
Can ISRDDN be invoked in batch?  It's a shame if so useful a facility is 
available only from a TSO LOGON.  (I can run ISPF in batch, with restrictions.)

Either way, you need to replicate your TASKLIB, STEPLIB, JOBLIB, LINKLIST 
search order.
That chore is manageable because ISRDDN MEMBER returns all candidates; you need 
only choose the most promising one.  In the worst case, a child task can 
allocate an unknown TASKLIB before LOADing the grandchild module.  That 
requires more detective work.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


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

COBOL 5.2 and VS Cobol questions

[Keith Haynes]

We're preparing to upgrade to COBOL 5.2 and need to update our VS COBOL 
programs before doing so to replace IGZEBST. Please see below for a sample 
relink that we're using.  Were currently running COBOL 4.2 and i'm curious if 
we can run the linkedit on 4.2 or do we need to wait and run the relink under 
5.2. We're currently using LE for z/OS 2.1.

//LINK   EXEC  PGM=IEWL,PARM='LIST,MAP,XREF'
//SYSPRINT DD  SYSOUT=* 
//SYSLIB   DD  DSN=CEE.SCEELKED,DISP=SHR
//LOADLIB  DD  DSN=TKTH000.PROD.LOAD.S6000,DISP=SHR 
//SYSLMOD  DD  DSN=TKTH000.SYS2.LINKLIB,DISP=SHR
//SYSUT1   DD  UNIT=SYSDA,SPACE=(CYL,(2,2)),DISP=NEW
//SYSLIN   DD  * 
  REPLACE IGZEBST
  INCLUDE LOADLIB(IAD028)
  ENTRY   IAD028 
  NAMEIAD028(R)  

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

Re: How force dataset non-SMS?

[Charles Mills]

Yup.

VOLUMES  
  VOLSERLS0502 DEVTYPE--X'3010200F'  
  VOLSER-* DEVTYPE--X''  
  VOLSER-* DEVTYPE--X''  
  VOLSER-* DEVTYPE--X''  
  VOLSER-* DEVTYPE--X''  

SMS is too darned smart!

I *really* don't want to figure out some IEBGENER or Rexx to load a zillion 
tracks of data into it.

Maybe I will try to figure out some other way to solve the original problem.

I will ask the SMS guys I guess. Wanted to avoid that.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Clifford
Sent: Tuesday, April 05, 2016 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How force dataset non-SMS?

I you got it out of SMS, and not enough data gets loaded so a 2nd or third vol 
is needed, it will only show a single vol-ser.  If you run a listcat of the 
dataset does it show an '*" for the 2 volumes not used yet ??
(Candidate volumes)???

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

Re: How force dataset non-SMS?

[John Clifford]

I you got it out of SMS, and not enough data gets loaded so a 2nd or third
vol is needed, it will only show a single vol-ser.  If you run a listcat of
the dataset does it show an '*" for the 2 volumes not used yet ??
(Candidate volumes)???

John Clifford


On Tue, Apr 5, 2016 at 1:16 PM, Charles Mills  wrote:

> Good thought but the ALTER ran to a zero completion and the darned dataset
> was still only one volume.
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Greg Shirey
> Sent: Tuesday, April 05, 2016 11:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How force dataset non-SMS?
>
> You can only bypass SMS if the ACS routines allow you to bypass SMS.
>
> You might be able to add two candidate volumes after allocation:
> ALTER data.set.name ADDVOLUMES(* *)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: How force dataset non-SMS?

[Charles Mills]

Good thought but the ALTER ran to a zero completion and the darned dataset
was still only one volume.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Greg Shirey
Sent: Tuesday, April 05, 2016 11:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How force dataset non-SMS?

You can only bypass SMS if the ACS routines allow you to bypass SMS.  

You might be able to add two candidate volumes after allocation: 
ALTER data.set.name ADDVOLUMES(* *)

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

Re: How to find where a module has been dynamically loaded from?

[Lindy Mayfield]

Or you can also use ISRFIND.  

Put in the Member Name and LOADMOD Y.

It will find anything, including SVC's.  

Br,
Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Griffiths1
Sent: tiistaina 5. huhtikuuta 2016 16.31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to find where a module has been dynamically loaded from?

Hey, that's just the kind of thing I was after, thanks!

Cheers,

Dave Griffiths
IBM Operational Decision Manager
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
Tel: +44 1962 816478 Mobile: 07590 195531 dgr...@uk.ibm.com
 

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

Re: Advice needed - GRS across 2 sysplexes with shared dasd

[R.S.]

W dniu 2016-04-05 o 15:52, Tom Marchant pisze:

On Mon, 4 Apr 2016 23:33:48 +, Jesse 1 Robinson wrote:


We've had a three-member basic sysplex for 15 years. Supported only
by CTCs. I can't speak to scaling, although I would expect GRS ring to be
the main inhibitor to serious upsizing. Give it a try. It should give you the
PDSE protection you need.

Maybe, but only for PDSESHARING(NORMAL).
PDSESHARING(EXTENDED) requires XCF as well as GRS connectivity.




Again: any PDSE sharing requires XCF communication, which means monoplex 
or sysplex. The sysplex can be basic or parallel.

No GRS configuration can replace the above requirement.
(It doesn't matter GRS is not important, but any supported configuration 
do require GRS).



--
Radoslaw Skorupka
Lodz, Poland






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

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

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


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

Re: How to find where a module has been dynamically loaded from?

[Nims,Alva John (Al)]

Not ISRDDN, but Mark Zelden has a REXX utility called FINDMOD that might 
accomplish it.
Mark's web: http://mzelden.com/mvsutil.html

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, April 05, 2016 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to find where a module has been dynamically loaded from?

On Tue, 5 Apr 2016 08:45:14 -0500, Elardus Engelbrecht wrote:
>
>In batch job or in a session? If in TSO, you already got the answer from Ren 
>Brenton about ISRDDN.
> 
Can ISRDDN be invoked in batch?  It's a shame if so useful a facility is 
available only from a TSO LOGON.  (I can run ISPF in batch, with restrictions.)

Either way, you need to replicate your TASKLIB, STEPLIB, JOBLIB, LINKLIST 
search order.
That chore is manageable because ISRDDN MEMBER returns all candidates; you need 
only choose the most promising one.  In the worst case, a child task can 
allocate an unknown TASKLIB before LOADing the grandchild module.  That 
requires more detective work.

-- gil

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

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

Re: Advice needed - GRS across 2 sysplexes with shared dasd

[Tom Marchant]

On Tue, 5 Apr 2016 14:24:37 +, Jesse 1 Robinson wrote:

>None of those functions requires a coupling facility. We have both 
>XCF and GRS (ring). And our basic sysplex has full PDSE support:

Right, but IIRC, the OP has two sysplexes and wants to share between 
them. As he noted, he will have to combine them into one.

-- 
Tom Marchant

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

Re: How to find where a module has been dynamically loaded from?

[Paul Gilmartin]

On Tue, 5 Apr 2016 08:45:14 -0500, Elardus Engelbrecht wrote:
>
>In batch job or in a session? If in TSO, you already got the answer from Ren 
>Brenton about ISRDDN.
> 
Can ISRDDN be invoked in batch?  It's a shame if so useful a facility is 
available only from a
TSO LOGON.  (I can run ISPF in batch, with restrictions.)

Either way, you need to replicate your TASKLIB, STEPLIB, JOBLIB, LINKLIST 
search order.
That chore is manageable because ISRDDN MEMBER returns all candidates; you need 
only
choose the most promising one.  In the worst case, a child task can allocate an 
unknown
TASKLIB before LOADing the grandchild module.  That requires more detective 
work.

-- gil

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

Re: How force dataset non-SMS?

[Greg Shirey]

You can only bypass SMS if the ACS routines allow you to bypass SMS.  

You might be able to add two candidate volumes after allocation: 
ALTER data.set.name ADDVOLUMES(* *)

Regards,
Greg Shirey
Ben E. Keith Company 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, April 05, 2016 9:46 AM

For a test of something relatively unrelated, I want to bypass SMS when 
allocating a dataset with DD. Is there an easy way to get SMS out of the way?

Specifically, I am trying to force a dataset to three volumes. I have coded
UNIT=(SYSDA,3) but SMS has concluded that I only need one. Is there an easy 
bypass?

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

Re: How force dataset non-SMS?

[Charles Mills]

Thanks all. Let me be a little clearer:

1. This is just for a one-off test. This does not have to work at customers or 
anything like that, nor is it some "permanent solution" to allow others to do 
this going forward.
2. I am not an SMS administrator and for political reasons I am trying not to 
involve the SMS administrators. I don't have the ability to change the SMS 
rules. (No, I am not going to make a mess: the test job allocates the dataset 
in step one and deletes it in step two -- both IEFBR14).

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Clifford
Sent: Tuesday, April 05, 2016 11:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How force dataset non-SMS?

Ed Jaffe's answer is the way we did it and it worked perfectly.

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

Re: COBOL 5.2 Programs too large to compile?

[Clark Morris]

[Default] On 5 Apr 2016 06:49:29 -0700, in bit.listserv.ibm-main
conac...@gmail.com (Cameron Conacher) wrote:

>I am not sure just yet, but I suspect that I will find out that first the
>INDEX went one past the number of items in the array, and something was
>stored in the item which would step on top of the INDEX itself, and then
>when they tried to increment the INDEX again, it died on a S0C7.

The SET INDEX is a binary add so you would not get a S0C7 unless the
statement was SET index-name UP BY variable-name and the conversion to
binary triggered the S0C7.

Clark Morris
>
>Still hunting..
>
>On Tue, Apr 5, 2016 at 9:29 AM, Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)
> wrote:
>
>> It's been a while for me on COBOL - but I would not think that setting the
>> index higher than the occurs value should cause a S0C7.  Now if you are
>> accessing data in a table with the INDEX and the values in the table are
>> numeric - AND when you hit the ninth value as stated below and the data is
>> not numeric - then that would be a valid S0C7 premise.
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Cameron Conacher
>> Sent: Tuesday, April 05, 2016 9:25 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: COBOL 5.2 Programs too large to compile?
>>
>> Thank you Mike,
>> However, we seem to see a problem with INDEX.
>> Specifically when SETting the INDEX value greater than the number of
>> OCCURs.
>> We did not yet get to the point of accessing the n+1th array item.
>> So, if there are eight items in the array, then SET INDEX UP BY +1 when
>> INDEX is already eight, appears to have caused a S0C7.
>> I say appears, because I did not do the test myself.
>> I can see there would be aa problem with trying to access a ninth item in
>> an array of eight items, but setting the INDEX to 9 causing an error?
>> Hm seems odd to me.
>>
>> On Mon, Apr 4, 2016 at 8:08 PM, Mike Schwab 
>> wrote:
>>
>> >
>> > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v
>> > 2r1.ceea100/ceea1mst83.htm
>> >
>> >
>> > On Mon, Apr 4, 2016 at 7:01 PM, Cameron Conacher 
>> > wrote:
>> > > We need up turning off optimization and the program compiled.
>> > > We are now seeing some coding issues. We have programs that SET
>> > INDEX-ITEM UP BY +1 where the value would would be larger than the
>> > OCCURS clause defined. Resulting in 0C7.
>> > > We do not see this with previous versions if COBOL.
>> > >
>> > > Sent from my iPhone
>> > >
>> > >> On Apr 1, 2016, at 11:06 AM, Tom Marchant <
>> > 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>> > >>
>> > >>> On Fri, 1 Apr 2016 08:47:14 -0400, Scott Ford wrote:
>> > >>>
>> > >>> Tom,
>> > >>>
>> > >>> It would be nice to run/use 64 bit addressing...second comment
>> > >>> about
>> > time
>> > >>> geez IBM...
>> > >>
>> > >> Maybe yes, maybe no. IBM's stated direction for 64-bit applications
>> > generated by Cobol is that they will be XPLINK-64. AFAIK, if you want
>> > a non-XPLINK LE-enabled program to call an XPLINK program, you have to
>> > create a new enclave. Same with XPLINK-64 calling XPLINK or XPLINK
>> > calling XPLINK-64.
>> > >>
>> > >> XPLINK programs can call non-XPLINK programs that are not LE
>> > >> enabled,
>> > but the overhead of the call is rather high. And if you have a Cobol
>> > program you probably make quite a few non-XPLINK calls. For example,
>> > GET and PUT routines.
>> > >>
>> > >>>
>> > >>> Scott
>> > >>>
>> > >>> On Thursday, March 31, 2016, Tom Marchant <
>> > >>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>> > >>>
>> >  On Thu, 31 Mar 2016 22:17:40 -0400, Don Poitras > >  > wrote:
>> > 
>> > > In article <
>> > 2614843154288992.wa.bill.woodgergmail@listserv.ua.edu
>> >  > you wrote:
>> > >
>> > >> Yes, it uses 64-bit addressing, so has much more available
>> > >> space,
>> >  specifically for large programs, including generated ones.
>> > >
>> > > If so, they didn't make it obvious in the announcement. I don't
>> > > see anything about 64-bit.
>> > 
>> >  I think Bill means that the compiler runs AMODE(64), not that it
>> >  can generate AMODE(64) programs.
>> > 
>> >  --
>> >  Tom Marchant
>> > 
>> >  -
>> >  - For IBM-MAIN subscribe / signoff / archive access
>> >  instructions, send email to lists...@listserv.ua.edu
>> >   with the
>> > message:
>> >  INFO IBM-MAIN
>> > >>>
>> > >>> --
>> > >>>  For IBM-MAIN subscribe / signoff / archive access
>> > >>> instructions, send email to lists...@listserv.ua.edu with the
>> > >>> message: INFO IBM-MAIN
>> > >>
>> > >> 

Re: How force dataset non-SMS?

[John Clifford]

Ed Jaffe's answer is the way we did it and it worked perfectly.

John Clifford

On Tue, Apr 5, 2016 at 10:45 AM, Charles Mills  wrote:

> For a test of something relatively unrelated, I want to bypass SMS when
> allocating a dataset with DD. Is there an easy way to get SMS out of the
> way?
>
> Specifically, I am trying to force a dataset to three volumes. I have coded
> UNIT=(SYSDA,3) but SMS has concluded that I only need one. Is there an easy
> bypass?
>
> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: How force dataset non-SMS?

[Vernooij, CP (ITOPT1) - KLM]

By DDNAME: only if the ACS routines allow it and you have to know what to 
specify for them to let you do it.
Utilities, like DSS, have parameters to force this, but you must be authorized 
to use them.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: 05 April, 2016 16:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How force dataset non-SMS?

For a test of something relatively unrelated, I want to bypass SMS when
allocating a dataset with DD. Is there an easy way to get SMS out of the
way?

Specifically, I am trying to force a dataset to three volumes. I have coded
UNIT=(SYSDA,3) but SMS has concluded that I only need one. Is there an easy
bypass?

Charles 

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: Advice needed - GRS across 2 sysplexes with shared dasd

[Cannaerts, Jan]

Not that it matters (to me), but out of genuine curiosity;

Can a PDSE, that is accessed by multiple systems in the same sysplex, whose
GRS is of the Accelerated Ring type with an ACCELSYS lower than the number
of systems in the ring, become corrupted?

Perhaps I am misunderstanding the shoulder-tapping process, but the way I
see it, a system in an Accelerated Ring can think it has a GRS ENQ on a 
resource while there are other systems in the ring who have not registered
this ENQ.

Given enough systems in the Ring and a low enough ACCELSYS, two systems could
hold the same ENQ (?), and thusly two systems could be editing the same PDSE.

Given extended PDSE sharing, which uses XCF, would this be caught by said XCF
communication between the different systems' PDSE address spaces?

And given normal PDSE sharing, which does not communicate through XCF, could
two systems (in the same GRS Ring!) unknowingly be editing the same PSDE,
potentially corrupting it?


A quick search in the PDSE Usage Guide doesn't bring up anything for the word
'accelerated'.


--
Jan

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

Re: How force dataset non-SMS?

[Ed Jaffe]

On 4/5/2016 7:45 AM, Charles Mills wrote:

For a test of something relatively unrelated, I want to bypass SMS when
allocating a dataset with DD. Is there an easy way to get SMS out of the
way?

Specifically, I am trying to force a dataset to three volumes. I have coded
UNIT=(SYSDA,3) but SMS has concluded that I only need one. Is there an easy
bypass?


We have this in our STORCLAS ACS routine:

WHEN ( = 'NONSMS')
  SET  = ''

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

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

Re: How to find where a module has been dynamically loaded from?

[David Griffiths1]

Hey, that's just the kind of thing I was after, thanks!

Cheers,

Dave Griffiths
IBM Operational Decision Manager
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
Tel: +44 1962 816478 Mobile: 07590 195531
dgr...@uk.ibm.com
 



From:   "Brenton, Ren" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   05/04/2016 14:35
Subject:Re: How to find where a module has been dynamically loaded 
from?
Sent by:IBM Mainframe Discussion List 



Did you try:
TSO ISRDDN LINKLIST
Then member xxx

Ren
Ext 1448


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of David Griffiths1
Sent: Tuesday, April 05, 2016 9:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to find where a module has been dynamically loaded from?

Hi, I've got a module which has been dynamically loaded but I'm not sure 
where from. I can override in the STEPLIB but because it gets loaded even 
when the STEPLIB entry isn't there I'd like to discover where this other 
copy is coming from. Our LNKLST is rather large and I'd rather not 
manually search every one of them.

So I just wondered if there is an easy way to search the default search 
order for a module? Or is there some trace that I can turn on that will 
appear in the job output, similar to "-verbose:class" in Java?

Cheers,

Dave Griffiths

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email 
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The information contained in this message is proprietary and/or 
confidential. If you are not the intended recipient, please: (i) delete 
the message and all copies; (ii) do not disclose, distribute or use the 
message in any manner; and (iii) notify the sender immediately. In 
addition, please be aware that any message addressed to our domain is 
subject to archiving and review by persons other than the intended 
recipient. Thank you.

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

How force dataset non-SMS?

[Charles Mills]

For a test of something relatively unrelated, I want to bypass SMS when
allocating a dataset with DD. Is there an easy way to get SMS out of the
way?

Specifically, I am trying to force a dataset to three volumes. I have coded
UNIT=(SYSDA,3) but SMS has concluded that I only need one. Is there an easy
bypass?

Charles 

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

Re: Advice needed - GRS across 2 sysplexes with shared dasd

[Vernooij, CP (ITOPT1) - KLM]

Maybe the confusion comes from the (mis)assumption that PDSESSHRING(EXTENDED) 
needs a CF. 
It needs XCF and GRS and both XCF and GRS don't need a CF, they are equally 
happy with CTC connectivity.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: 05 April, 2016 16:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Advice needed - GRS across 2 sysplexes with shared dasd

None of those functions requires a coupling facility. We have both XCF and GRS 
(ring). And our basic sysplex has full PDSE support:

PDSESHARING(EXTENDED) 
PDSE_RESTARTABLE_AS(YES)  
PDSE1_MONITOR(YES,120,30)  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, April 05, 2016 6:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Advice needed - GRS across 2 sysplexes with shared dasd

On Mon, 4 Apr 2016 23:33:48 +, Jesse 1 Robinson wrote:

>We've had a three-member basic sysplex for 15 years. Supported only 
>by CTCs. I can't speak to scaling, although I would expect GRS ring to 
>be the main inhibitor to serious upsizing. Give it a try. It should 
>give you the PDSE protection you need.

Maybe, but only for PDSESHARING(NORMAL).
PDSESHARING(EXTENDED) requires XCF as well as GRS connectivity.

--
Tom Marchant


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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




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

Hillgang reminder 13 Apr

[Neale Ferguson]

A reminder that the next Hillgang meeting (Norther Virginia Linux and z/VM
UG) will be held on 13 April at the CA Offices in Herndon. The agenda may
be found at: http://www.vm.ibm.com/events/HILL0416.PDF. Please following
the instructions to register so we can organize catering for breakfast.

I am still looking to add a 4th session on crypto.

Neale

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

Re: Advice needed - GRS across 2 sysplexes with shared dasd

[Jesse 1 Robinson]

None of those functions requires a coupling facility. We have both XCF and GRS 
(ring). And our basic sysplex has full PDSE support:

PDSESHARING(EXTENDED) 
PDSE_RESTARTABLE_AS(YES)  
PDSE1_MONITOR(YES,120,30)  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, April 05, 2016 6:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Advice needed - GRS across 2 sysplexes with shared dasd

On Mon, 4 Apr 2016 23:33:48 +, Jesse 1 Robinson wrote:

>We've had a three-member basic sysplex for 15 years. Supported only 
>by CTCs. I can't speak to scaling, although I would expect GRS ring to 
>be the main inhibitor to serious upsizing. Give it a try. It should 
>give you the PDSE protection you need.

Maybe, but only for PDSESHARING(NORMAL).
PDSESHARING(EXTENDED) requires XCF as well as GRS connectivity.

--
Tom Marchant


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

Re: How to find where a module has been dynamically loaded from?

[David Crayford]

On 5/04/2016 10:14 PM, David Griffiths1 wrote:

Hi, in a batch job. The module is loaded with an assembler LOAD macro.

Cheers,


You need to chase CDE control blocks. I'm sure others will chip in with 
pithy comments and code examples.



Dave Griffiths

  




From:   Elardus Engelbrecht 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   05/04/2016 14:45
Subject:Re: How to find where a module has been dynamically loaded
from?
Sent by:IBM Mainframe Discussion List 



David Griffiths wrote:


Hi, I've got a module which has been dynamically loaded but I'm not sure

where from.

What do you mean by 'dynamically loaded'? Is it a module name which you
perhaps know by the module name in one of the libraries?

Also in what address space was that loaded? (See below)



I can override in the STEPLIB but because it gets loaded even when the

STEPLIB entry isn't there I'd like to discover where this other copy is
coming from.

In batch job or in a session? If in TSO, you already got the answer from
Ren Brenton about ISRDDN.

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


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

Re: How to find where a module has been dynamically loaded from?

[David Griffiths1]

Hi, in a batch job. The module is loaded with an assembler LOAD macro.

Cheers,

Dave Griffiths

 



From:   Elardus Engelbrecht 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   05/04/2016 14:45
Subject:Re: How to find where a module has been dynamically loaded 
from?
Sent by:IBM Mainframe Discussion List 



David Griffiths wrote:

>Hi, I've got a module which has been dynamically loaded but I'm not sure 
where from. 

What do you mean by 'dynamically loaded'? Is it a module name which you 
perhaps know by the module name in one of the libraries?

Also in what address space was that loaded? (See below)


>I can override in the STEPLIB but because it gets loaded even when the 
STEPLIB entry isn't there I'd like to discover where this other copy is 
coming from.

In batch job or in a session? If in TSO, you already got the answer from 
Ren Brenton about ISRDDN.

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: Advice needed - GRS across 2 sysplexes with shared dasd

[Tom Marchant]

On Mon, 4 Apr 2016 23:33:48 +, Jesse 1 Robinson wrote:

>We've had a three-member basic sysplex for 15 years. Supported only 
>by CTCs. I can't speak to scaling, although I would expect GRS ring to be 
>the main inhibitor to serious upsizing. Give it a try. It should give you the 
>PDSE protection you need.  

Maybe, but only for PDSESHARING(NORMAL).
PDSESHARING(EXTENDED) requires XCF as well as GRS connectivity.

-- 
Tom Marchant

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

Re: COBOL 5.2 Programs too large to compile?

[Cameron Conacher]

I am not sure just yet, but I suspect that I will find out that first the
INDEX went one past the number of items in the array, and something was
stored in the item which would step on top of the INDEX itself, and then
when they tried to increment the INDEX again, it died on a S0C7.

Still hunting..

On Tue, Apr 5, 2016 at 9:29 AM, Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)
 wrote:

> It's been a while for me on COBOL - but I would not think that setting the
> index higher than the occurs value should cause a S0C7.  Now if you are
> accessing data in a table with the INDEX and the values in the table are
> numeric - AND when you hit the ninth value as stated below and the data is
> not numeric - then that would be a valid S0C7 premise.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: Tuesday, April 05, 2016 9:25 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL 5.2 Programs too large to compile?
>
> Thank you Mike,
> However, we seem to see a problem with INDEX.
> Specifically when SETting the INDEX value greater than the number of
> OCCURs.
> We did not yet get to the point of accessing the n+1th array item.
> So, if there are eight items in the array, then SET INDEX UP BY +1 when
> INDEX is already eight, appears to have caused a S0C7.
> I say appears, because I did not do the test myself.
> I can see there would be aa problem with trying to access a ninth item in
> an array of eight items, but setting the INDEX to 9 causing an error?
> Hm seems odd to me.
>
> On Mon, Apr 4, 2016 at 8:08 PM, Mike Schwab 
> wrote:
>
> >
> > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v
> > 2r1.ceea100/ceea1mst83.htm
> >
> >
> > On Mon, Apr 4, 2016 at 7:01 PM, Cameron Conacher 
> > wrote:
> > > We need up turning off optimization and the program compiled.
> > > We are now seeing some coding issues. We have programs that SET
> > INDEX-ITEM UP BY +1 where the value would would be larger than the
> > OCCURS clause defined. Resulting in 0C7.
> > > We do not see this with previous versions if COBOL.
> > >
> > > Sent from my iPhone
> > >
> > >> On Apr 1, 2016, at 11:06 AM, Tom Marchant <
> > 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> > >>
> > >>> On Fri, 1 Apr 2016 08:47:14 -0400, Scott Ford wrote:
> > >>>
> > >>> Tom,
> > >>>
> > >>> It would be nice to run/use 64 bit addressing...second comment
> > >>> about
> > time
> > >>> geez IBM...
> > >>
> > >> Maybe yes, maybe no. IBM's stated direction for 64-bit applications
> > generated by Cobol is that they will be XPLINK-64. AFAIK, if you want
> > a non-XPLINK LE-enabled program to call an XPLINK program, you have to
> > create a new enclave. Same with XPLINK-64 calling XPLINK or XPLINK
> > calling XPLINK-64.
> > >>
> > >> XPLINK programs can call non-XPLINK programs that are not LE
> > >> enabled,
> > but the overhead of the call is rather high. And if you have a Cobol
> > program you probably make quite a few non-XPLINK calls. For example,
> > GET and PUT routines.
> > >>
> > >>>
> > >>> Scott
> > >>>
> > >>> On Thursday, March 31, 2016, Tom Marchant <
> > >>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> > >>>
> >  On Thu, 31 Mar 2016 22:17:40 -0400, Don Poitras  >  > wrote:
> > 
> > > In article <
> > 2614843154288992.wa.bill.woodgergmail@listserv.ua.edu
> >  > you wrote:
> > >
> > >> Yes, it uses 64-bit addressing, so has much more available
> > >> space,
> >  specifically for large programs, including generated ones.
> > >
> > > If so, they didn't make it obvious in the announcement. I don't
> > > see anything about 64-bit.
> > 
> >  I think Bill means that the compiler runs AMODE(64), not that it
> >  can generate AMODE(64) programs.
> > 
> >  --
> >  Tom Marchant
> > 
> >  -
> >  - 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
> > > 

Re: How to find where a module has been dynamically loaded from?

[Elardus Engelbrecht]

David Griffiths wrote:

>Hi, I've got a module which has been dynamically loaded but I'm not sure where 
>from. 

What do you mean by 'dynamically loaded'? Is it a module name which you perhaps 
know by the module name in one of the libraries?

Also in what address space was that loaded? (See below)


>I can override in the STEPLIB but because it gets loaded even when the STEPLIB 
>entry isn't there I'd like to discover where this other copy is coming from.

In batch job or in a session? If in TSO, you already got the answer from Ren 
Brenton about ISRDDN.

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: How to find where a module has been dynamically loaded from?

[Brenton, Ren]

Did you try:
TSO ISRDDN LINKLIST
Then member xxx

Ren
Ext 1448


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Griffiths1
Sent: Tuesday, April 05, 2016 9:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to find where a module has been dynamically loaded from?

Hi, I've got a module which has been dynamically loaded but I'm not sure where 
from. I can override in the STEPLIB but because it gets loaded even when the 
STEPLIB entry isn't there I'd like to discover where this other copy is coming 
from. Our LNKLST is rather large and I'd rather not manually search every one 
of them.

So I just wondered if there is an easy way to search the default search order 
for a module? Or is there some trace that I can turn on that will appear in the 
job output, similar to "-verbose:class" in Java?

Cheers,

Dave Griffiths

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.

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

How to find where a module has been dynamically loaded from?

[David Griffiths1]

Hi, I've got a module which has been dynamically loaded but I'm not sure 
where from. I can override in the STEPLIB but because it gets loaded even 
when the STEPLIB entry isn't there I'd like to discover where this other 
copy is coming from. Our LNKLST is rather large and I'd rather not 
manually search every one of them.

So I just wondered if there is an easy way to search the default search 
order for a module? Or is there some trace that I can turn on that will 
appear in the job output, similar to "-verbose:class" in Java?

Cheers,

Dave Griffiths

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

Re: Markdown Processor For z/OS

[David Griffiths1]

Hi Martin, you could just use one of the free Java implementations. Or one 
of the python ones might work with Jython.

Cheers,

Dave Griffiths
IBM Operational Decision Manager
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
Tel: +44 1962 816478 Mobile: 07590 195531
dgr...@uk.ibm.com
 



From:   Martin Packer/UK/IBM@IBMGB
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   27/03/2016 16:12
Subject:Markdown Processor For z/OS
Sent by:IBM Mainframe Discussion List 



Does anyone know of a processor for any flavour of Markdown available on 
z/OS?

(I've an awful feeling I've asked this before - but haven't found the 
question or the answer, so maybe not.)

It's tempting to write some REXX... :-)

Thanks, 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
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: COBOL 5.2 Programs too large to compile?

[Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)]

It's been a while for me on COBOL - but I would not think that setting the 
index higher than the occurs value should cause a S0C7.  Now if you are 
accessing data in a table with the INDEX and the values in the table are 
numeric - AND when you hit the ninth value as stated below and the data is not 
numeric - then that would be a valid S0C7 premise.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cameron Conacher
Sent: Tuesday, April 05, 2016 9:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 5.2 Programs too large to compile?

Thank you Mike,
However, we seem to see a problem with INDEX.
Specifically when SETting the INDEX value greater than the number of OCCURs.
We did not yet get to the point of accessing the n+1th array item.
So, if there are eight items in the array, then SET INDEX UP BY +1 when INDEX 
is already eight, appears to have caused a S0C7.
I say appears, because I did not do the test myself.
I can see there would be aa problem with trying to access a ninth item in an 
array of eight items, but setting the INDEX to 9 causing an error?
Hm seems odd to me.

On Mon, Apr 4, 2016 at 8:08 PM, Mike Schwab  wrote:

>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v
> 2r1.ceea100/ceea1mst83.htm
>
>
> On Mon, Apr 4, 2016 at 7:01 PM, Cameron Conacher 
> wrote:
> > We need up turning off optimization and the program compiled.
> > We are now seeing some coding issues. We have programs that SET
> INDEX-ITEM UP BY +1 where the value would would be larger than the 
> OCCURS clause defined. Resulting in 0C7.
> > We do not see this with previous versions if COBOL.
> >
> > Sent from my iPhone
> >
> >> On Apr 1, 2016, at 11:06 AM, Tom Marchant <
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> >>
> >>> On Fri, 1 Apr 2016 08:47:14 -0400, Scott Ford wrote:
> >>>
> >>> Tom,
> >>>
> >>> It would be nice to run/use 64 bit addressing...second comment 
> >>> about
> time
> >>> geez IBM...
> >>
> >> Maybe yes, maybe no. IBM's stated direction for 64-bit applications
> generated by Cobol is that they will be XPLINK-64. AFAIK, if you want 
> a non-XPLINK LE-enabled program to call an XPLINK program, you have to 
> create a new enclave. Same with XPLINK-64 calling XPLINK or XPLINK 
> calling XPLINK-64.
> >>
> >> XPLINK programs can call non-XPLINK programs that are not LE 
> >> enabled,
> but the overhead of the call is rather high. And if you have a Cobol 
> program you probably make quite a few non-XPLINK calls. For example, 
> GET and PUT routines.
> >>
> >>>
> >>> Scott
> >>>
> >>> On Thursday, March 31, 2016, Tom Marchant < 
> >>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> >>>
>  On Thu, 31 Mar 2016 22:17:40 -0400, Don Poitras   > wrote:
> 
> > In article <
> 2614843154288992.wa.bill.woodgergmail@listserv.ua.edu
>  > you wrote:
> >
> >> Yes, it uses 64-bit addressing, so has much more available 
> >> space,
>  specifically for large programs, including generated ones.
> >
> > If so, they didn't make it obvious in the announcement. I don't 
> > see anything about 64-bit.
> 
>  I think Bill means that the compiler runs AMODE(64), not that it 
>  can generate AMODE(64) programs.
> 
>  --
>  Tom Marchant
> 
>  -
>  - 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
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: COBOL 5.2 Programs too large to compile?

[Cameron Conacher]

Thank you Mike,
However, we seem to see a problem with INDEX.
Specifically when SETting the INDEX value greater than the number of OCCURs.
We did not yet get to the point of accessing the n+1th array item.
So, if there are eight items in the array, then SET INDEX UP BY +1 when
INDEX is already eight, appears to have caused a S0C7.
I say appears, because I did not do the test myself.
I can see there would be aa problem with trying to access a ninth item in
an array of eight items, but setting the INDEX to 9 causing an error?
Hm seems odd to me.

On Mon, Apr 4, 2016 at 8:08 PM, Mike Schwab  wrote:

>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea100/ceea1mst83.htm
>
>
> On Mon, Apr 4, 2016 at 7:01 PM, Cameron Conacher 
> wrote:
> > We need up turning off optimization and the program compiled.
> > We are now seeing some coding issues. We have programs that SET
> INDEX-ITEM UP BY +1 where the value would would be larger than the OCCURS
> clause defined. Resulting in 0C7.
> > We do not see this with previous versions if COBOL.
> >
> > Sent from my iPhone
> >
> >> On Apr 1, 2016, at 11:06 AM, Tom Marchant <
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> >>
> >>> On Fri, 1 Apr 2016 08:47:14 -0400, Scott Ford wrote:
> >>>
> >>> Tom,
> >>>
> >>> It would be nice to run/use 64 bit addressing...second comment about
> time
> >>> geez IBM...
> >>
> >> Maybe yes, maybe no. IBM's stated direction for 64-bit applications
> generated by Cobol is that they will be XPLINK-64. AFAIK, if you want a
> non-XPLINK LE-enabled program to call an XPLINK program, you have to create
> a new enclave. Same with XPLINK-64 calling XPLINK or XPLINK calling
> XPLINK-64.
> >>
> >> XPLINK programs can call non-XPLINK programs that are not LE enabled,
> but the overhead of the call is rather high. And if you have a Cobol
> program you probably make quite a few non-XPLINK calls. For example, GET
> and PUT routines.
> >>
> >>>
> >>> Scott
> >>>
> >>> On Thursday, March 31, 2016, Tom Marchant <
> >>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> >>>
>  On Thu, 31 Mar 2016 22:17:40 -0400, Don Poitras   > wrote:
> 
> > In article <
> 2614843154288992.wa.bill.woodgergmail@listserv.ua.edu
>  > you wrote:
> >
> >> Yes, it uses 64-bit addressing, so has much more available space,
>  specifically for large programs, including generated ones.
> >
> > If so, they didn't make it obvious in the announcement. I don't see
> > anything about 64-bit.
> 
>  I think Bill means that the compiler runs AMODE(64), not that it can
>  generate AMODE(64) programs.
> 
>  --
>  Tom Marchant
> 
>  --
>  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
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: New to Z/OSMF - SOLVED

[Donald J.]

Great.  Now the difficult part begins - figuring out how to use it.

I think the recommended procedure for the old method was to create a base config
with no plugins, then add the plugins by running izusetup again with the -add 
parameter,
and A values in your override file.

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

On Mon, Apr 4, 2016, at 11:31 AM, Tracy Adams wrote:
> So what I found is that the UI90034 ptf was applied back in January during 
> the monthly compliance maintenance round and the ptf actions must have been 
> bypassed as the steps to complete the migration from V2r1 to V2r1 with the 
> ptf  were not completed.  The bottom line is this ptf requires you to create 
> a parmlib member if you want to use the plugins.   Once I did that the 
> plugins are visible on the webpage.
> 
> Thanks for you help!   
 

-- 
http://www.fastmail.com - Does exactly what it says on the tin

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

Re: 5.2

[Elardus Engelbrecht]

Bill Woodger wrote:

>And sorry, Cameron, that should have been Cameron. Spent at least five seconds 
>over each word this thyme.

Hahaha. Perhaps you should turn of that 'chelling specker' and those lame 
'predictive typing' thingamajig...

Those toys can't even get my Afrikaans (and South African English) correct... 
gr...

I'm tired of these toys trying to 'fix' RACF into race, for example.

;-D

Groete / Greetings
Elardus Engelbrecht

'chelling specker' - spelling checker misspelt on purpose...

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

5.2

[Bill Woodger]

And sorry, Cameron, that should have been Cameron. Spent at least five seconds 
over each word this thyme.

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

Re: [EXTERNAL] Re: Advice needed - GRS across 2 sysplexes with shared dasd

[Elardus Engelbrecht]

Dyck, Lionel B. (TRA) wrote:

>Thank you - I've come to the conclusion that we should be in a single sysplex 
>so we have grs protecting every device.  

Ok. Abadon grey hairs! ;-)

Just have your Prod ready and then add one LPAR at a stage from the test Plex.

You could perhaps prepare your HSM, SMS, JES2, RACF etc. *before* you move 
these LPARS over to your single SysPlex.


>Now the discussion begins :-)

Now, I'm asking, thinking outside the box - Question - Do you NEED those PDSE 
residing in their place in their own SysPlex? Could other type of datasets 
work? Or move the contents into a single database system or something?

Granted, I don't know (or missed the reason) for WHAT do you want the PDSE, 
perhaps it is something about COBOL?

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

5.2

[Bill Woodger]

Hah. And not even sent from my iPhone. (not that I have an iPhone, but it 
looked like some predictive text hit Conner's most recent).

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

COBOL 5.2 Programs too large to compile?

[Bill Woodger]

There is a change with V5, and currently the same in V6, whereby the location 
of the storage allocated by the compiler for indexes/indices is different. 
Instead of being nicely separate somewhere, they are now located immediately 
after (subject to slack-bytes) the table which defines them (except, obviously, 
for LINKAGE SECTION tables, I've not used V5, so don't know where those are 
allocated).

This means if you let an index "run off" the end of the table, and then use it, 
you will likely trash the index itself, such that the next time the index is 
used to refer to something it is referring to... who knows what, certainly not 
what you may hope.

See this discussion: 
https://www.ibm.com/developerworks/community/forums/html/topic?id=c476d2c9-0d4e-4073-97c5-6384d8f381c0=25

That behaviour is due to change, under a policy to make V5/V6 behave more like 
V3/V4 in situations where code worked, but relied on the way the V3/V4 compiler 
implemented something (my paraphrase, don't take it literally). See here, 
towards the end of the topic: 
https://www.ibm.com/developerworks/community/forums/html/topic?id=0f54483b-6f83-441d-a5fc-22a3d333dddf=25

For migration to V5/V6 I would recommend the use of SSRANGE for initial 
program-testing for this reason.

On Tuesday, 5 April 2016 01:02:23 UTC+1, Cameron Conacher  wrote:
> We need up turning off optimization and the program compiled.
> We are now seeing some coding issues. We have programs that SET INDEX-ITEM UP 
> BY +1 where the value would would be larger than the OCCURS clause defined. 
> Resulting in 0C7.
> We do not see this with previous versions if COBOL.
> 
> Sent from my iPhone

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

COBOL 5.2 Programs too large to compile?

[Bill Woodger]

Yes, I always ensure that anything used for subscripting is within bounds 
(including lower-bound), either logically or explicitly. This is, 
unsurprisingly, recommended by IBM.

However, doing this turns out to be far from universal. I guess that's why 
SSRANGE was introduced originally (I think with COBOL II).


On Tuesday, 5 April 2016 02:51:24 UTC+1, Steve Beaver  wrote:
> Personally I have NEVER used subscript range.  I have always checked the 
> upper ranges
> Before I do anything having to do with indexing through arrays
> 
> Steve
> 

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

COBOL 5.2 Programs too large to compile?

[Bill Woodger]

No. I have fallen for that before as well. It is perhaps not documented as 
clearly as it could be.

Previously, SSRANGE could be used, and then controlled by a run-time Language 
Environment option, CHECK. CHECK(ON) does the SSRANGE, CHECK(OFF) does not.

The LE run-time option CHECK for V5 (and V6) does nothing.

The range-checking is still controlled by compiler option NOSSRANGE (no 
range-checking) or SSRANGE (range-checking). 

On Tuesday, 5 April 2016 01:40:08 UTC+1, Mike Schwab  wrote:
> Apparently, Cobol 5.1 no longer allows turning off the subscript range
> checking.  And the original post stated the failure occurs when the
> exceed the defined maximum number of occurrences.
> 

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

5.2

[Bill Woodger]

Neither. It is bad code which now causes something else to happen.

On Tuesday, 5 April 2016 01:35:37 UTC+1, Paul Gilmartin  wrote:
> On Mon, 4 Apr 2016 19:08:08 -0500, Mike Schwab wrote:
> 
> >https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea100/ceea1mst83.htm
> >
> >
> >On Mon, Apr 4, 2016 at 7:01 PM, Cameron Conacher wrote:
> >> We need up turning off optimization and the program compiled.
> >> We are now seeing some coding issues. We have programs that SET INDEX-ITEM 
> >> UP BY +1 where the value would would be larger than the OCCURS clause 
> >> defined. Resulting in 0C7.
> >> We do not see this with previous versions if COBOL.
> >>
> The question then becomes, is this a new bug in the compiler, or improved
> error checking discovering a long-standing error in the user's program?
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: [EXTERNAL] Re: Advice needed - GRS across 2 sysplexes with shared dasd

[Vernooij, CP (ITOPT1) - KLM]

I am not sure you know you also have a serious alternative: do not share the 
DASD between the sysplexes, but keep the needed datasets (also PDSE's) in sync 
by synchronizing them periodically. 
We to this. Once a day, a number of PDSs, PDSE's and other datasets are 
unloaded at sysplex1, FTPed to Sysplex2 and loaded there. You can do this at 
your desired frequency.

If this solves your problem, it will be much less work than to merge the 2 
sysplexes into 1.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: 04 April, 2016 19:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Advice needed - GRS across 2 sysplexes with shared 
dasd

Thank you - I've come to the conclusion that we should be in a single sysplex 
so we have grs protecting every device.  Now the discussion begins :-)


--
Lionel B. Dyck (Contractor)
Mainframe Systems Programmer 
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph W Gentile
Sent: Monday, April 04, 2016 12:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Advice needed - GRS across 2 sysplexes with shared dasd

Hello Lionel, 

Regarding your OP, GRS ENQs are generally obtained at the GRS complex level, by 
various operating system programs and other applications that do I/O. GRS only 
knows about its own complex, not another GRS complex. In your description it 
sounds like you have two GRS complexes one for prod and one for test. The GRS 
complex usually matches the Sysplex unless you are using GRS Ring with GRS 
managed CTCs. The two complexes do not communicate ENQs between one another. If 
the two complexes collide on the same resource, data corruption can occur. Some 
resources can be safely shared outside the complex by using RESERVE. You can 
code the RNLs to exclude a resource from global processing and thus propagate 
the HW RESERVE. But not all applications doing I/O use RESERVE so this method 
is not sufficient protection, unless you know the resource is protected by 
RESERVE from product documentation. A CATALOG is one of those resources you can 
serialize with RESERVE and here is an info APAR that explains how to code your 
RNLs for that: 
http://www-01.ibm.com/support/docview.wss?uid=isg1II14297. Note that only 
protects the catalog from corruption and not the datasets themselves. 
RESERVE has its own risks, particularly a higher chance for contention, because 
only one system can own the RESERVE (which locks the whole volume) at a time. 

-Joe

Joe Gentile
z/OS GRS Lead
jwgen...@us.ibm.com


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

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: Linux and C++

[Mark Post]

>>> On 4/4/2016 at 10:16 PM, "Jack J. Woehr"  wrote: 
> Linux comes with GCC, the best compiler in the world.

Dear ${DEITY}, hardly.  Intel's are much better.  Now if you had said "best no 
cost compiler" I wouldn't have nearly so bad a reaction.


Mark Post

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