Re: Dancing around RMM [EXTERNAL]

[Feller, Paul]

Here is what I have used to "get around" things.  The DSN start with a "valid" 
HLQ that RACF would not get in the way.  We are a CA-1 shop.

//STEP010  EXEC PGM=FATAR,REGION=4096K
//TAPEIN   DD UNIT=CART90O,DISP=OLD,  
//VOL=SER=MUZM11,LABEL=(,BLP,EXPDT=98000),
//DSN=UDT014.DONT.KNOW.WHAT.IT.IS 
//SYSUDUMP DD SYSOUT=*
//SYSPRINT DD SYSOUT=*,DEST=CRCAMPUS  
//TAPESUMM DD SYSOUT=*,DEST=CRCAMPUS  
//SYSINDD *   
 ANALYZE LBLPRT=FORMAT
/*

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, December 19, 2018 3:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Dancing around RMM [EXTERNAL]

We want to discard some very old tapes after making sure there's nothing of 
value on them. When we run Innovation FATAR to analyze them, the jobs fail with 
messages like those below using JCL like this:

//TAPEIN   DD  UNIT=TAPECR,LABEL=(,BLP),
// DISP=OLD,VOL=SER=(nn)

There's a whole slew of STGADMIN profiles in FACILITY class that allow the user 
to get around 'irregularities', but we can't seem to find one that would allow 
this usage. The tapes are not defined to RMM. We just want to know what's on 
the tapes before the trash truck pulls out of the loading dock.

EDG4025I VOLUME nn REJECTED. READING OF SCRATCH VOLUMES OR VOLUMES OBTAINED 
WITH GETVOLUME IS NOT PERMITTED EDG4006E VOLUME nn ON  REJECTED FOR USE 
BY FATARAN1, FATAR, TAPEIN, OPEN REQUEST FAILED BY DFSMSrmm
IEC502E R ,, ,,FATARAN1,FATAR
IEC145I 413-08,IFG0194K,FATARAN1,FATAR,TAPEIN,,,
SYS18352.T164910.RA000.FATARAN1.R0140502

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


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

--
Please note:  This message originated outside your organization. Please use 
caution when opening links or attachments.

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

Re: Dancing around RMM

[Knutson, Samuel]

Mike Wood previously advised in a post a long time ago but still seems 
applicable

Mike Wood <***@UK.IBM.COM> wrote:
The 413-08 is issued because rmm rejected the volume and the request was
specific; no other volume is acceptable, so OPEN fails the request in this
way. This is what happens when the Volume Mount processing installation
exit rejects a volume.

The ways round this are;
1. Issue RMM CV volser STATUS(MASTER) . then rerun the job
2. Get rmm to ignore the volume using EXPDT=98000. There is no need for BLP

Finally, figure out why a volume you need to use for input is scratch.

Mike Wood RMM Development

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jesse 1 Robinson
Sent: Wednesday, December 19, 2018 4:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Dancing around RMM

We want to discard some very old tapes after making sure there's nothing of 
value on them. When we run Innovation FATAR to analyze them, the jobs fail with 
messages like those below using JCL like this:

//TAPEIN   DD  UNIT=TAPECR,LABEL=(,BLP),
// DISP=OLD,VOL=SER=(nn)

There's a whole slew of STGADMIN profiles in FACILITY class that allow the user 
to get around 'irregularities', but we can't seem to find one that would allow 
this usage. The tapes are not defined to RMM. We just want to know what's on 
the tapes before the trash truck pulls out of the loading dock.

EDG4025I VOLUME nn REJECTED. READING OF SCRATCH VOLUMES OR VOLUMES OBTAINED 
WITH GETVOLUME IS NOT PERMITTED EDG4006E VOLUME nn ON  REJECTED FOR USE 
BY FATARAN1, FATAR, TAPEIN, OPEN REQUEST FAILED BY DFSMSrmm
IEC502E R ,, ,,FATARAN1,FATAR
IEC145I 413-08,IFG0194K,FATARAN1,FATAR,TAPEIN,,,
SYS18352.T164910.RA000.FATARAN1.R0140502

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


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it

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

Re: Dancing around RMM

[Gibney, Dave]

This is CA-1, but I thought RMM was compatible.  And, I there are SAF profiles 
controlling access. CA-1 defines it's own class for them

EXPDT=98000
Nonresident EXPDT keyword. Specifies that the tape volume being processed is 
not under CA 1(r)
Tape Management System control

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
> Sent: Wednesday, December 19, 2018 1:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Dancing around RMM
> 
> We want to discard some very old tapes after making sure there's nothing of
> value on them. When we run Innovation FATAR to analyze them, the jobs fail
> with messages like those below using JCL like this:
> 
> //TAPEIN   DD  UNIT=TAPECR,LABEL=(,BLP),
> // DISP=OLD,VOL=SER=(nn)
> 
> There's a whole slew of STGADMIN profiles in FACILITY class that allow the
> user to get around 'irregularities', but we can't seem to find one that would
> allow this usage. The tapes are not defined to RMM. We just want to know
> what's on the tapes before the trash truck pulls out of the loading dock.
> 
> EDG4025I VOLUME nn REJECTED. READING OF SCRATCH VOLUMES OR
> VOLUMES OBTAINED WITH GETVOLUME IS NOT PERMITTED EDG4006E
> VOLUME nn ON  REJECTED FOR USE BY FATARAN1, FATAR, TAPEIN,
> OPEN REQUEST FAILED BY DFSMSrmm
> IEC502E R ,, ,,FATARAN1,FATAR
> IEC145I 413-08,IFG0194K,FATARAN1,FATAR,TAPEIN,,,
> SYS18352.T164910.RA000.FATARAN1.R0140502
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office <= NEW
> robin...@sce.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

Dancing around RMM

[Jesse 1 Robinson]

We want to discard some very old tapes after making sure there's nothing of 
value on them. When we run Innovation FATAR to analyze them, the jobs fail with 
messages like those below using JCL like this:

//TAPEIN   DD  UNIT=TAPECR,LABEL=(,BLP),
// DISP=OLD,VOL=SER=(nn)

There's a whole slew of STGADMIN profiles in FACILITY class that allow the user 
to get around 'irregularities', but we can't seem to find one that would allow 
this usage. The tapes are not defined to RMM. We just want to know what's on 
the tapes before the trash truck pulls out of the loading dock.

EDG4025I VOLUME nn REJECTED. READING OF SCRATCH VOLUMES OR VOLUMES OBTAINED 
WITH GETVOLUME IS NOT PERMITTED
EDG4006E VOLUME nn ON  REJECTED FOR USE BY FATARAN1, FATAR, TAPEIN, 
OPEN REQUEST FAILED BY DFSMSrmm
IEC502E R ,, ,,FATARAN1,FATAR
IEC145I 413-08,IFG0194K,FATARAN1,FATAR,TAPEIN,,,
SYS18352.T164910.RA000.FATARAN1.R0140502

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


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

Re: CFCC Performance

[Kieron D Hinds]

I agree the original question was a bit confusing, but to answer it 
directly:

-> System-managed duplexing is definitely not deprecated, but yes there is 
an "overhead" to run system-managed duplexing for structures, which is why 
a new enhancement was recently released
on z14 (CFLevel 22 and up) called Asynchronous coupling facility duplexing 
for lock structures, which for now only DB2 IRLM can exploit when at the 
right level. 
This async version of the protocol makes the service time for a CF request 
to a duplexed DB2 lock structure much closer to that of the same structure 
running simplex. This makes it much more feasible to run duplexed, 
especially at distance.
-> Db2 is still the only exploiter of and still supports user-managed 
duplexing as of Db2 V12, so again not deprecated.


If it helps, with regards to Coupling Thin Interrupts, I agree the 
recommendation should be to use them for your shared engine CF 
configurations.
You can find more information to this effect in
–> the PR/SM Planning Guide (for EC12 or later). z14 version is PDF 
SB10-7169-02.pdf available as of October 18 2018 
–> the excellent White Paper 102400 – ‘Coupling Thin Interrupts and 
Coupling Facility Performance in Shared Processor Environments’ by Barbara 
Weiler at 
https://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102400

Hope this helps.



Kieron Hinds
IBM Z Platform Evaluation Test, IBM Systems













From:   Jesse 1 Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/19/2018 11:29 AM
Subject:Re: CFCC Performance
Sent by:IBM Mainframe Discussion List 



Thin interrupts were introduced as a performance booster for shared CF 
engines. However when we recently upgraded both CECs to z14 and z13, we 
discovered that we can no longer live with 'fat' interrupts. In a new CEC, 
thin interrupts must be enabled by CF command; there is no profile to 
carry over the old value to a new CEC. 

Thin interrupts come into play only when a CF engine is shared among 
multiple sysplexes, which we have done for years with Development and 
Sandbox. Without (re)enabling thin interrupts, we found our Sandbox plex 
to be unusable. By simply turning thin interrupts (back) on, Sandbox 
performance returned to very respectable. For dedicated engines, thin 
interrupts are not even an option. The enabling command will be rejected.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Vernooij, Kees (ITOP NM) - KLM
Sent: Wednesday, December 19, 2018 12:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: CFCC Performance

So do we, 2 CFs per Sysplex (you "cannot" run a production site with only 
1).

I am a little confused about your questions:

System managed rebuild is standard and always active. This will rebuild 
structures in another CF in case of problems. It is transparent to the 
application, be it with some delays in structure availability during the 
rebuild.

Structure duplexing comes in 2 flavors: user-managed and system-managed. 
User-managed is done by the application, if it supports it, e.g. DB2. If 
not, you can use system-managed structure duplexing. This comes with some 
cost of inter-CF communication. We do not use it, because we don't have 
structures that require 101% availability.

Thin interrupts are an enhancement that only provides improvement and 
exists for several CPU generations, so it should be beyond doubt.

Kees.



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Mike Schwab
> Sent: 18 December, 2018 19:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CFCC Performance
> 
> We had 4 CFs.  Two for the TestPlex and two for the Production Plex.
> 
> On Tue, Dec 18, 2018 at 10:37 AM Allan Staller 
> wrote:
> >
> > I am in the process or reconfiguring from a Single CF to multiple 
> > CFs
> (per partition) to eliminate the single point of failure.
> > The subject of CFCC Thin Interrupts has been evaluated and will most
> likely be implemented.
> >
> > As part of this process the discussion of DUPLEX CF structure vs. 
> > use
> of SYSTEM MANAGED Rebuild has also come up.
> >
> > I have heard the use of duplexing has been deprecated in favor of
> system managed rebuild for performance reasons.
> > CFCC Thin Interrupts might offset some of the (alleged) performance
> penalty.
> >
> > Can anyone point me to any documentation or contacts on the subject?
> > Searches if IBM Techdocs, Redbooks, ResourceLink, etc. have produced
> very limited information. Most of which seem to be leaning in the 
> SYSTEM MANAGED Rebuild direction.

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

Re: 64-bit C code fetching IGGCSI00

[Tom Marchant]

On Wed, 19 Dec 2018 09:28:53 -0500, Pierre Fichaud wrote:

>I can't believe that an AMODE 31 module can't be fetched by 64-bit C
>code. __malloc31() can be used to get 31-bit storage.

Disclaimer: I am not a C guy.

64-bit C is XPLINK.
XPLINK-64 allocates the stack above the bar.
The save area that is passed to a non-XPLINK program is allocated from the 
stack.

Unless there is a way to alter this behavior, 64-bit C cannot call an AMODE(31) 
program.

-- 
Tom Marchant

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

Re: CBT File 483-contact the author

[ITschak Mugzach]

Sam,

Jan Jaeger is with lzlabs. His mail should be jan.jae...@lzlabs.com.

ITschak

בתאריך יום ד׳, 19 בדצמ׳ 2018, 19:48, מאת Sam Golob :

> Dear Folks,
>
>  Sorry to bother you about this kind of thing.  I have had to modify
> several items on CBT File 483 from Thomas Ramseier, and since it is "his
> file", I would like to contact him.  Last I heard from him was in 2001,
> when he worked for the Swiss Federal Office of Information Technology
> (FOITT).  If you know his whereabouts, please let me know (maybe do it
> offline, to preserve his privacy) at sbgo...@cbttape.org.  Thanks much.
>
>  BTW File 483 contains some really useful items, and it's worth
> looking into.  I "fixed" QSMS to stop it from going into an infinite
> loop, and I created a program DTOD from Thomas' program QTOD, so it
> takes a 16-bit parameter which is an STCK output in "display" format,
> and tells you what time it denotes.
>
> Example:   TSO DTOD D565353F6689C002
>
> Output:   Date: Tuesday, 18th of December 2018 (12/18/18 2018.352) Time:
> 02:56:28.1
>
>  These things can be useful, and I want to discuss the file with the
> author, as I usually try to do.
>
>  Thanks much for your cooperation.   All the best of everything to
> all of you.
>
> Sincerely,Sam
>
> P.S.  If any of you is in contact with Jan Jaeger, I'd like to speak
> with him too.  Thanks again.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

CBT File 483-contact the author

[Sam Golob]

Dear Folks,

    Sorry to bother you about this kind of thing.  I have had to modify 
several items on CBT File 483 from Thomas Ramseier, and since it is "his 
file", I would like to contact him.  Last I heard from him was in 2001, 
when he worked for the Swiss Federal Office of Information Technology 
(FOITT).  If you know his whereabouts, please let me know (maybe do it 
offline, to preserve his privacy) at sbgo...@cbttape.org.  Thanks much.


    BTW File 483 contains some really useful items, and it's worth 
looking into.  I "fixed" QSMS to stop it from going into an infinite 
loop, and I created a program DTOD from Thomas' program QTOD, so it 
takes a 16-bit parameter which is an STCK output in "display" format, 
and tells you what time it denotes.


Example:   TSO DTOD D565353F6689C002

Output:   Date: Tuesday, 18th of December 2018 (12/18/18 2018.352) Time: 
02:56:28.1


    These things can be useful, and I want to discuss the file with the 
author, as I usually try to do.


    Thanks much for your cooperation.   All the best of everything to 
all of you.


Sincerely,    Sam

P.S.  If any of you is in contact with Jan Jaeger, I'd like to speak 
with him too.  Thanks again.


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

Re: 64-bit C code fetching IGGCSI00

[Seymour J Metz]

I would expect the pragma to affect the call, not the fetch.


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


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Wednesday, December 19, 2018 12:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64-bit C code fetching IGGCSI00

Hmm-m-m.  Maybe #pragma linkage (IGGCSI00, OS_NOSTACK) would work?  Also, 
investigate your C compile listing, what is the compiler option XPLINK set to?  
I get the impression from RTFM about the XPLINK option that 
XPLINK(OSCALL(NOSTACK)) is the default when LP64 is in effect, is that true for 
your compile?  If so, maybe #pragma linkage(IGGCSI00,OS) would satisfy the 
runtime system?

Just guessing here, haven't had time to cobble together a real example.  As you 
said, hopefully someone from C/LE development can chime in and enlighten us all.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pierre Fichaud
Sent: Wednesday, December 19, 2018 9:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64-bit C code fetching IGGCSI00

Peter,
Using FETCHABLE gives me the same error.
With OS_DOWNSTACK I get the followig when I build:

CCN6404 (W) The parameter "OS_UPSTACK" specified for "pragma linkage"
is not valid. The pragma is ignored.
I ran it anyway and got the same thing.

I can't believe that an AMODE 31 module can't be fetched by 64-bit C
code. __malloc31() can be used to get 31-bit storage.
Maybe someone from the C/LE IBM lab can add to this.

Regards and thanks, Pierre.
--


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

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

Re: 64-bit C code fetching IGGCSI00

[Farley, Peter x23353]

Hmm-m-m.  Maybe #pragma linkage (IGGCSI00, OS_NOSTACK) would work?  Also, 
investigate your C compile listing, what is the compiler option XPLINK set to?  
I get the impression from RTFM about the XPLINK option that 
XPLINK(OSCALL(NOSTACK)) is the default when LP64 is in effect, is that true for 
your compile?  If so, maybe #pragma linkage(IGGCSI00,OS) would satisfy the 
runtime system?

Just guessing here, haven't had time to cobble together a real example.  As you 
said, hopefully someone from C/LE development can chime in and enlighten us all.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pierre Fichaud
Sent: Wednesday, December 19, 2018 9:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64-bit C code fetching IGGCSI00

Peter,
Using FETCHABLE gives me the same error.
With OS_DOWNSTACK I get the followig when I build:

CCN6404 (W) The parameter "OS_UPSTACK" specified for "pragma linkage" 
is not valid. The pragma is ignored.
I ran it anyway and got the same thing.

I can't believe that an AMODE 31 module can't be fetched by 64-bit C 
code. __malloc31() can be used to get 31-bit storage.
Maybe someone from the C/LE IBM lab can add to this.

Regards and thanks, Pierre.
--


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: CFCC Performance

[Jesse 1 Robinson]

Thin interrupts were introduced as a performance booster for shared CF engines. 
However when we recently upgraded both CECs to z14 and z13, we discovered that 
we can no longer live with 'fat' interrupts. In a new CEC, thin interrupts must 
be enabled by CF command; there is no profile to carry over the old value to a 
new CEC. 

Thin interrupts come into play only when a CF engine is shared among multiple 
sysplexes, which we have done for years with Development and Sandbox. Without 
(re)enabling thin interrupts, we found our Sandbox plex to be unusable. By 
simply turning thin interrupts (back) on, Sandbox performance returned to very 
respectable. For dedicated engines, thin interrupts are not even an option. The 
enabling command will be rejected.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOP NM) - KLM
Sent: Wednesday, December 19, 2018 12:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: CFCC Performance

So do we, 2 CFs per Sysplex (you "cannot" run a production site with only 1).

I am a little confused about your questions:

System managed rebuild is standard and always active. This will rebuild 
structures in another CF in case of problems. It is transparent to the 
application, be it with some delays in structure availability during the 
rebuild.

Structure duplexing comes in 2 flavors: user-managed and system-managed. 
User-managed is done by the application, if it supports it, e.g. DB2. If not, 
you can use system-managed structure duplexing. This comes with some cost of 
inter-CF communication. We do not use it, because we don't have structures that 
require 101% availability.

Thin interrupts are an enhancement that only provides improvement and exists 
for several CPU generations, so it should be beyond doubt.

Kees.



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Mike Schwab
> Sent: 18 December, 2018 19:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CFCC Performance
> 
> We had 4 CFs.  Two for the TestPlex and two for the Production Plex.
> 
> On Tue, Dec 18, 2018 at 10:37 AM Allan Staller 
> wrote:
> >
> > I am in the process or reconfiguring from a Single CF to multiple 
> > CFs
> (per partition) to eliminate the single point of failure.
> > The subject of CFCC Thin Interrupts has been evaluated and will most
> likely be implemented.
> >
> > As part of this process the discussion of DUPLEX CF structure vs. 
> > use
> of SYSTEM MANAGED Rebuild has also come up.
> >
> > I have heard the use of duplexing has been deprecated in favor of
> system managed rebuild for performance reasons.
> > CFCC Thin Interrupts might offset some of the (alleged) performance
> penalty.
> >
> > Can anyone point me to any documentation or contacts on the subject?
> > Searches if IBM Techdocs, Redbooks, ResourceLink, etc. have produced
> very limited information. Most of which seem to be leaning in the 
> SYSTEM MANAGED Rebuild direction.

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

Re: 64-bit C code fetching IGGCSI00

[Pierre Fichaud]

Peter,
Using FETCHABLE gives me the same error.
With OS_DOWNSTACK I get the followig when I build:

	CCN6404 (W) The parameter "OS_UPSTACK" specified for "pragma linkage" 
is not valid. The pragma is ignored.

I ran it anyway and got the same thing.

	I can't believe that an AMODE 31 module can't be fetched by 64-bit C 
code. __malloc31() can be used to get 31-bit storage.

Maybe someone from the C/LE IBM lab can add to this.

Regards and thanks, Pierre.

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

Re: CFCC Performance

[Vernooij, Kees (ITOP NM) - KLM]

So do we, 2 CFs per Sysplex (you "cannot" run a production site with only 1).

I am a little confused about your questions:

System managed rebuild is standard and always active. This will rebuild 
structures in another CF in case of problems. It is transparent to the 
application, be it with some delays in structure availability during the 
rebuild.

Structure duplexing comes in 2 flavors: user-managed and system-managed. 
User-managed is done by the application, if it supports it, e.g. DB2. If not, 
you can use system-managed structure duplexing. This comes with some cost of 
inter-CF communication. We do not use it, because we don't have structures that 
require 101% availability.

Thin interrupts are an enhancement that only provides improvement and exists 
for several CPU generations, so it should be beyond doubt.

Kees.



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Schwab
> Sent: 18 December, 2018 19:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CFCC Performance
> 
> We had 4 CFs.  Two for the TestPlex and two for the Production Plex.
> 
> On Tue, Dec 18, 2018 at 10:37 AM Allan Staller 
> wrote:
> >
> > I am in the process or reconfiguring from a Single CF to multiple CFs
> (per partition) to eliminate the single point of failure.
> > The subject of CFCC Thin Interrupts has been evaluated and will most
> likely be implemented.
> >
> > As part of this process the discussion of DUPLEX CF structure vs. use
> of SYSTEM MANAGED Rebuild has also come up.
> >
> > I have heard the use of duplexing has been deprecated in favor of
> system managed rebuild for performance reasons.
> > CFCC Thin Interrupts might offset some of the (alleged) performance
> penalty.
> >
> > Can anyone point me to any documentation or contacts on the subject?
> > Searches if IBM Techdocs, Redbooks, ResourceLink, etc. have produced
> very limited information. Most of which seem to be leaning in the SYSTEM
> MANAGED Rebuild direction.
> >
> > Thanks in advance,
> > ::DISCLAIMER::
> > --
> 
> 
> 
> > The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
> may contain viruses in transmission. The e mail and its contents (with
> or without referred errors) shall therefore not attach any liability on
> the originator or HCL or its affiliates. Views or opinions, if any,
> presented in this email are solely those of the author and may not
> necessarily reflect the views or opinions of HCL or its affiliates. Any
> form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior
> written consent of authorized representative of HCL is strictly
> prohibited. If you have received this email in error please delete it
> and notify the sender immediately. Before opening any email and/or
> attachments, please check them for viruses and other defects.
> > --
> 
> 
> 
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> --
> 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 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