Re: GRS ring vs star mode

[Gil Peleg]

Radoslaw,
 For small XCF signalling message sizes, CTC will give performance very
close and sometimes even better than a CF structure. This behavior is sort
of documented in a WSC Flash.
 Gil.

 On 11/4/05, R.S. <[EMAIL PROTECTED]> wrote:
>
> I created sandbox sysplex within one CPC (shared CPs for both MVS and CF
> LPARs, IC channels).
> I observed significant performance improvement when changed GRS from
> ring to star mode. I didn't notice such improvement, when changed XCF
> transport from CTC (ESCON) to CF structures.
> From the other hand I was told that there is not noticeable difference
> between ring mode and star mode for two-member sysplex.
>
> Is the difference because of star mode advantage or just I have
> something something to tune when using ring mode ?
> BTW: I don't want to use ring, it's just curiosity.
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: GRS ring vs star mode

[Edward E. Jaffe]

Gil Peleg wrote:


Radoslaw,
For small XCF signalling message sizes, CTC will give performance very
close and sometimes even better than a CF structure. This behavior is sort
of documented in a WSC Flash.
Gil.
 



For XCF signaling, CTCs can provide better performance because, unlike a 
signaling structure in a CF, CTCs are a dedicated resource. However, 
this fact is hardly relevant in a discussion of GRS STAR vs RING.


The algorithms are completely different for STAR (hash table, etc.) than 
for RING. And, you're comparing an XES implementation (STAR) to an 
XCF-only implementation (RING). These intrinsic differences are present 
regardless of how your XCF signaling is configured.


For our parallel sysplex running in real LPARs, we use CTCs for XCF 
signaling (for performance). For our emulated parallel sysplexes under 
z/VM, we use CF structures for XCF signaling (easier to configure). In 
all cases, we use GRS STAR.


--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SSID for devices

[Schiradin,Roland HG-Dir itb-db/dc]

Tnx Ed and Jim for taking the time and info.

I got an offline email pointing to IDCSS01 as an interface
to obtain those info. Working on this.

For the archive
This interface is documented in the 
z/OS V1R6.0 DFSMSdfp Advanced Services 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2S321/CCONTENTS?SHELF=DGT2BK41&DN=SC26-7400-04&DT=20050124151137


Roland

-Original Message-
From: IBM Mainframe Discussion List 
[mailto:[EMAIL PROTECTED] On Behalf Of Edward E. Jaffe
Sent: Sunday, November 06, 2005 5:10 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: SSID for devices


Jim Mulder wrote:

>  I think DS obtains the SSID via a
>Sense Subsystem Status   channel command.  I don't know whether
>this is documented in a manual which you can obtain.  I 
searched around 
>in the online manuals looking for something current which would be 
>analgous to the old 3990 Reference, but couldn't find anything.
>
>

Here is a description for the 2105 (Shark):

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f2acr00/3.11.3

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Rexx compiler runtime question

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 11/04/2005
   at 02:20 PM, Charles Mills <[EMAIL PROTECTED]> said:

>The problem appears to be that the customer's job is finding the
>original IRXCMPTM in SYS1.LINKLIB rather than the alias for the one
>in SEAGALT because it's in the wrong library or list (see previous
>paragraph).

What happens if the customer loads the correct IRXCMPTM into MLPA?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Sharing z/OS DASD under VM

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 11/04/2005
   at 08:06 AM, "Knutson, Sam" <[EMAIL PROTECTED]> said:

>This is perfectly safe since z/VM will enforce read only access if
>that is the way a disk is attached you are not violating any sharing
>rules.

FSVO safe. It will certainly protect the R/O volumes, but, as you
mention, you might get incorrect results on some reads if you skip the
serialization. If you are depending on out from the system being
correct then you are at risk.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ZIP SOFTWARE for Mainframe

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 11/04/2005
   at 12:00 AM, Ted MacNEIL <[EMAIL PROTECTED]> said:

>But, supported means they will fix problems, bugs, and usability
>issues.

Then some free software is supported and some chargeable software is
not, including software for which you pay a support fee.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Rexx compiler runtime question

[Charles Mills]

The customer is apparently going to try that but is/was resistant to MLPA
for some reason. "Maintenance headache" or some such. I'm not a sysprog, and
I'm not the customer, so my ability to argue this position is limited.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Shmuel Metz (Seymour J.)
Sent: Sunday, November 06, 2005 12:27 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Rexx compiler runtime question


In <[EMAIL PROTECTED]>, on 11/04/2005
   at 02:20 PM, Charles Mills <[EMAIL PROTECTED]> said:

>The problem appears to be that the customer's job is finding the
>original IRXCMPTM in SYS1.LINKLIB rather than the alias for the one
>in SEAGALT because it's in the wrong library or list (see previous
>paragraph).

What happens if the customer loads the correct IRXCMPTM into MLPA?
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Heads-up: OA08692

[Barbara Nitz]

> don't you have a preventive maintenance philosophy there? We've had that
> fix on since April this year. 

Well, I am not responsible for the maintenance policy (which is mainly
'never touch a running system' unless it has a problem). We had ordered zOS
1.6 back in February and wanted to be much further with the rollout by now.
So back then it was decided that the 1.4 system would not get a refresh, it
would only get toleration maintenance and HIPERs.

So had the apar been marked either, we would have had it on. We hit the
(starting) abend0c4 7 times, and lost the system 'only' once, and so far IBM
isn't saying *why* we lost the system (I suspect an overlay caused by the
first 0C4, and depending where that hits...). Instead, we are being told
that this is not a toleration issue.

Go figure.

Best regards, Barbara

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFACTRT modifications

[Barbara Nitz]

Sine I am right now in just this area:

Here ACTRT spits out a WTO with the step completion code that everyone wants
to see in the JESMSGLG (not JESYSMSG). Using IEFYS would move the location
of the message in the output to JESYSMSG, I think.

Using a WTO with ROUTCDE 11 (only) is not a good idea (as I just found out)
as that gets converted to a WTP, and for every STC on my system that results
in duplication of the message, the duplicate being preceded by IEF170I.

In the past, we had used ROUTCDE 6, and I have written an MPF exit to
suppress the message for OMVS steps (it's annoying when there is nothing but
this message for pages in the hardcopy log). I got objections when I
suppressed the message completely (via MPF) from hardcopy.

Regards, Barbara Nitz

-- 
Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat,
DSL-Flatrate für nur 4,99 Euro/Monat*  http://www.gmx.net/de/go/dsl

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html