Re: DR site implementation steps

[Rob Schramm]

Isn't GDPS still a custom offering?  Or am I behind the times?

Rob

On Mon, Jun 13, 2016, 2:44 PM Mohamed Gomaa <
00cefc9a9b79-dmarc-requ...@listserv.ua.edu> wrote:

> Hi
>
> We are now in the process for DR site implementation, our shop has two
> production zEC12 with one ICF and one external  CF in one sysplex, also we
> have one z114 test cpu  two LPARs with one ICF. One DS8870 disk.
> In the DR we have one z13 with two ICF, and DS8870 disk.
> Our goal to have the prod in sysplex Active/active between the two sites.
> And Test will be active/passive
> Up to now we already did the PPRC replication between the two disks.
>
> I want recommended steps  and plan, from who went to such project before
> First to implement the Active/passive between the two sites for test then
> prod systems. Then the full implementation active/active GDPS for prod.
>
> And what is the best practice to do that also if there is PDF which can
> guide us
>
> Any help will be appreciated,
>
> Thanks
>
> Mohamed juma
>
> 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
>
-- 

Rob Schramm
The Art of Mainframe, Inc

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

Re: LINK and high order word of R1

[Tom Marchant]

On Mon, 13 Jun 2016 14:05:40 -0700, Charles Mills  wrote:

>Okay, got it. The rules for a called program and the rules for the IBM macros 
>are the same (except as otherwise explicitly specified):
>
>- The high halves of R2 through R13 must go back as they arrived.
>- The high halves of R14 through R1 are fair game. You can use a grande 
>instruction or an IBM macro in your subprogram and not worry about restoring 
>R14 through R1.

Not quite:


o The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged  
o The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged  


It seems to me that the low half of 14 should be unchanged as well, but that's 
not what the book says.

-- 
Tom Marchant

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

Re: Sysplex Timer issue

[Kieron D Hinds]

Hi, 
It sounds like you have a situation where the CF you're attempting to IPL 
is running on a CPC with a different CTNID than the CTNID of the CPC[s] 
where other images are already active (z/OS and CFs). 
I'd have to compare the CTNID in the output of the IXL160E as well as the 
IEA386I from the D ETR of active system[s] in the sysplex to know for 
sure, but if it the case then you'll need to get the CTNIDs to match.

Is this the first attempt to activate the CF - if so was STP configured on 
the CF CPC? Versus if it was after a configuration change made to an 
existing CF, do you expect the STP configuration or the CTNID to change? 

Changing CTNIDs *can* be disruptive so please check with your local or IBM 
hardware support if you don't understand this already.


Kieron Hinds
z/OS Integration Test / System z Platform Evaluation Test















From:   Nathan Astle 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   06/13/2016 01:54 PM
Subject:Sysplex Timer issue
Sent by:IBM Mainframe Discussion List 



Hi,

We are receiving the error message on CF, while IPling .

IXL160E CF REQUEST TIME ORDERING: REQUIRED AND NOT-ENABLED 194

REASON: CTNID MISMATCH


The ETR I displayed in the Console is different from the error message.


Does it mean i have to correct that in the IOGEN ?


Jake

--
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: LINK and high order word of R1

[Charles Mills]

Okay, got it. The rules for a called program and the rules for the IBM macros 
are the same (except as otherwise explicitly specified):

- The high halves of R2 through R13 must go back as they arrived.
- The high halves of R14 through R1 are fair game. You can use a grande 
instruction or an IBM macro in your subprogram and not worry about restoring 
R14 through R1.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Monday, June 13, 2016 1:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LINK and high order word of R1

On Mon, 13 Jun 2016 11:19:06 -0700, Charles Mills wrote:

>In the description of LINK in Assembler Services I read
>
>...
>
>Does that mean that for standard "old-fashioned" AMODE 31 72-byte savearea
>linkage I am obligated to save the high word of R1 before issuing LINK in a
>called program? If so, this would seem to be a compatibility issue for older
>code that uses LINK. Or is R1 fair game as a work register in a called
>program?

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

Re: LINK and high order word of R1

[Tom Marchant]

On Mon, 13 Jun 2016 11:19:06 -0700, Charles Mills wrote:

>In the description of LINK in Assembler Services I read
>
>...
>
>Does that mean that for standard "old-fashioned" AMODE 31 72-byte savearea
>linkage I am obligated to save the high word of R1 before issuing LINK in a
>called program? If so, this would seem to be a compatibility issue for older
>code that uses LINK. Or is R1 fair game as a work register in a called
>program?

The Linkage conventions do not require that R1 be preserved. From the Assembler 
Services Guide:


Unless otherwise defined by the individual interface, the calling program 
should expect, upon return, that  
o The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged  
o The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged  
o ARs 2 through 13 are unchanged  
o FPRs 8 through 15 are unchanged; The Floating Point Control (FPC) Register is 
unchanged with the exception of two fields: the IEEE exception flags and the 
data exception code (DXC).  
o When return information is provided in GPR 0, 1, and/or 15 (for example 
return and reason codes), only bits 32-63 of the register contain the returned 
value.


-- 
Tom Marchant

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

Re: IEAMSCHD and SRB entry questions

[Binyamin Dissen]

I was kind of disappointed when IBM initially gave the list of services that
could be called from AMODE 64.(as long as the parameters were below the bar).
I mentioned that the hardware does all the work for a PC from a 64 bit caller,
so stating "support" really didn't require any code changes. All my PC
routines equally supported 64bit callers.

On Mon, 13 Jun 2016 10:48:54 -0700 Ed Jaffe 
wrote:

:>On 6/13/2016 10:12 AM, Andre Schoeman wrote:
:>>> Since the documentation for IEAMSCHD says that AMODE 64 is not supported,
:>>> you are taking a risk that your code might at any point stop behaving
:>>> properly. That is your choice, but it is your (and your users') risk. Is
:>>> there any plan to do so in the immediate future? Not that I know of. Would
:>>> any such plan be announced? Probably not.
:>> I accept what the current state of the documentation says. However, when
:>> z/OS is touted as 64-bit capable, shouldn't a continous effort be driven 
whereby
:>> all invoked system system services eventually are AMODE(64) capable ??
:>> (disregard the restricted location of certain control blocks for now   
I'm
:>> merely referring to invoking a service whilst running in AMODE(64))
:>
:>I have stated before (possibly in other forums -- certainly at TDMs) 
:>that our approach is to try to help IBM and the z/OS community identify 
:>existing system services that don't work for AMODE(64) callers. IBM has 
:>only limited manpower to test z/OS services, so we test them for them by 
:>invoking them in real-world AMODE(64) code.
:>
:>That means we completely disregard documentation that states a service 
:>requires 31-bit mode and rely solely on the results our own empirical 
:>testing. (Of course, we limit AMODE(64) invocations to SVC and PC-based 
:>services and never even try to invoke LINKAGE=BRANCH services in 
:>AMODE(64) because we know that won't work.)
:>
:>What we've discovered is that _nearly all_ SVC and PC-based services 
:>work just fine so long as you pass the parameters below the bar. The 
:>main "gotchas" are macro expansions that have not yet been updated to 
:>use grande instructions when SYSSTATE AMODE64=YES is in effect. Usually, 
:>all you must do is clear XGR 14,14 (or another register) before invoking.
:>
:>Is it a risk? Of course! IBM is free to change these interfaces at any 
:>time without warning and we're happily prepared to adapt our code as 
:>necessary in the event the macro expansion changes or they choose to 
:>support AMODE(64) callers in an incompatible way (hopefully on a release 
:>boundary).
:>
:>For us, improved performance, better code readability, and (hopefully) 
:>fewer changes down the road when those services finally do "officially" 
:>support AMODE(64) callers,  are worth that risk. YM-AS-MV (Your Mileage 
:>-- And Sensibilities -- May Vary).

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: LINK and high order word of R1

[Farley, Peter x23353]

PMFJI here.

No, he specifically said ". . . if your code . . . guarantees to callers to 
preserve R1 . . .".  IOW, if you do guarantee to your callers that you will 
preserve the value in system work registers (14 through 1) then be sure to save 
and restore what you claim to guarantee.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, June 13, 2016 3:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LINK and high order word of R1

So you are saying "if you write a standard (legacy) linkage AMODE<=31 
subprogram and use *any* system service then you are obligated to do an 
STMG/LMG R14,R1,x"?

(Not criticizing or sarcastically contradicting you, just re-stating what you 
said to be certain.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, June 13, 2016 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LINK and high order word of R1

On Mon, 13 Jun 2016 11:19:06 -0700, Charles Mills wrote:
>
>Does that mean that for standard "old-fashioned" AMODE 31 72-byte 
>savearea linkage I am obligated to save the high word of R1 before 
>issuing LINK in a called program? If so, this would seem to be a 
>compatibility issue for older code that uses LINK. Or is R1 fair game 
>as a work register in a called program?
> 
I asked a similar question a while back, concerning STORAGE.  An IBM expert 
explained that certain registers (0, 1, 14, 15?) are fair game for system 
services.  So, if your code, even in AMODE<=31 with a 72-byte save area 
guarantees to callers to preserve R1 and uses STORAGE, you must do something 
more to preserve the high word.

--


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: LINK and high order word of R1

[Charles Mills]

So you are saying "if you write a standard (legacy) linkage AMODE<=31 
subprogram and use *any* system service then you are obligated to do an 
STMG/LMG R14,R1,x"?

(Not criticizing or sarcastically contradicting you, just re-stating what you 
said to be certain.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, June 13, 2016 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LINK and high order word of R1

On Mon, 13 Jun 2016 11:19:06 -0700, Charles Mills wrote:
>
>Does that mean that for standard "old-fashioned" AMODE 31 72-byte 
>savearea linkage I am obligated to save the high word of R1 before 
>issuing LINK in a called program? If so, this would seem to be a 
>compatibility issue for older code that uses LINK. Or is R1 fair game 
>as a work register in a called program?
> 
I asked a similar question a while back, concerning STORAGE.  An IBM expert 
explained that certain registers (0, 1, 14, 15?) are fair game for system 
services.  So, if your code, even in AMODE<=31 with a 72-byte save area 
guarantees to callers to preserve R1 and uses STORAGE, you must do something 
more to preserve the high word.

-- 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: LINK and high order word of R1

[Charles Mills]

I wrote the LINKed program so I guess the interface is defined any way I
want it to be.  Seriously, it is assembler called from C++. I would have
to plow through a bunch of manuals and do a fine parsing on the language I
am sure. There is also a C option as to whether C can count on the high
words of the registers, which I set to "use the high words" as a theoretical
performance booster.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Greg Dyck
Sent: Monday, June 13, 2016 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LINK and high order word of R1

On 6/13/2016 11:18 AM, Charles Mills wrote:
> Does that mean that for standard "old-fashioned" AMODE 31 72-byte 
> savearea linkage I am obligated to save the high word of R1 before 
> issuing LINK in a called program? If so, this would seem to be a 
> compatibility issue for older code that uses LINK. Or is R1 fair game 
> as a work register in a called

The fine manual states-

Upon return to the caller, the GPRs contain whatever values the
called program placed there.

So it all depends on how the 'interface' to the LINK'd to program is
defined.  If R1 is unpredictable on return then use the high half as you
wish.  If R1 defined as unchanged or returns a 32 bit value you need to save
and restore the high half.
Greg

--
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: LINK and high order word of R1

[Paul Gilmartin]

On Mon, 13 Jun 2016 11:19:06 -0700, Charles Mills wrote:
>
>Does that mean that for standard "old-fashioned" AMODE 31 72-byte savearea
>linkage I am obligated to save the high word of R1 before issuing LINK in a
>called program? If so, this would seem to be a compatibility issue for older
>code that uses LINK. Or is R1 fair game as a work register in a called
>program?
> 
I asked a similar question a while back, concerning STORAGE.  An IBM
expert explained that certain registers (0, 1, 14, 15?) are fair game for
system services.  So, if your code, even in AMODE<=31 with a 72-byte
save area guarantees to callers to preserve R1 and uses STORAGE, you
must do something more to preserve the high word.

-- gil

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

Re: LINK and high order word of R1

[Greg Dyck]

On 6/13/2016 11:18 AM, Charles Mills wrote:

Does that mean that for standard "old-fashioned" AMODE 31 72-byte savearea
linkage I am obligated to save the high word of R1 before issuing LINK in a
called program? If so, this would seem to be a compatibility issue for older
code that uses LINK. Or is R1 fair game as a work register in a called


The fine manual states-

   Upon return to the caller, the GPRs contain whatever values the
   called program placed there.

So it all depends on how the 'interface' to the LINK'd to program is 
defined.  If R1 is unpredictable on return then use the high half as you 
wish.  If R1 defined as unchanged or returns a 32 bit value you need to 
save and restore the high half.

Greg

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

LINK and high order word of R1

[Charles Mills]

In the description of LINK in Assembler Services I read

If the LINK is not successful and the caller provided an ERRET exit to
receive
control, the GPRs contain the following:
Register Contents
...
1
Bits 0-31 of the 64 bit register contain the abend reason code for the abend
code for the ABEND that would have been issued if the caller had not
provided an ERRET exit.
Bits 32-63 of the 64 bit register contain the abend code for the ABEND that
would have been issued if the caller had not provided an ERRET exit.

Does that mean that for standard "old-fashioned" AMODE 31 72-byte savearea
linkage I am obligated to save the high word of R1 before issuing LINK in a
called program? If so, this would seem to be a compatibility issue for older
code that uses LINK. Or is R1 fair game as a work register in a called
program?

Charles 

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

Re: IEAMSCHD and SRB entry questions

[Ed Jaffe]

On 6/13/2016 10:12 AM, Andre Schoeman wrote:

Since the documentation for IEAMSCHD says that AMODE 64 is not supported,
you are taking a risk that your code might at any point stop behaving
properly. That is your choice, but it is your (and your users') risk. Is
there any plan to do so in the immediate future? Not that I know of. Would
any such plan be announced? Probably not.

I accept what the current state of the documentation says. However, when
z/OS is touted as 64-bit capable, shouldn't a continous effort be driven whereby
all invoked system system services eventually are AMODE(64) capable ??
(disregard the restricted location of certain control blocks for now   I'm
merely referring to invoking a service whilst running in AMODE(64))


I have stated before (possibly in other forums -- certainly at TDMs) 
that our approach is to try to help IBM and the z/OS community identify 
existing system services that don't work for AMODE(64) callers. IBM has 
only limited manpower to test z/OS services, so we test them for them by 
invoking them in real-world AMODE(64) code.


That means we completely disregard documentation that states a service 
requires 31-bit mode and rely solely on the results our own empirical 
testing. (Of course, we limit AMODE(64) invocations to SVC and PC-based 
services and never even try to invoke LINKAGE=BRANCH services in 
AMODE(64) because we know that won't work.)


What we've discovered is that _nearly all_ SVC and PC-based services 
work just fine so long as you pass the parameters below the bar. The 
main "gotchas" are macro expansions that have not yet been updated to 
use grande instructions when SYSSTATE AMODE64=YES is in effect. Usually, 
all you must do is clear XGR 14,14 (or another register) before invoking.


Is it a risk? Of course! IBM is free to change these interfaces at any 
time without warning and we're happily prepared to adapt our code as 
necessary in the event the macro expansion changes or they choose to 
support AMODE(64) callers in an incompatible way (hopefully on a release 
boundary).


For us, improved performance, better code readability, and (hopefully) 
fewer changes down the road when those services finally do "officially" 
support AMODE(64) callers,  are worth that risk. YM-AS-MV (Your Mileage 
-- And Sensibilities -- May Vary).


--
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: IEAMSCHD and SRB entry questions

[Andre Schoeman]

>>Note that all the GPR's in the issuing code are purified to contain "clean" 
>>31-bit addresses
>>before the IEAMSCHD is issued.

>That's not good enough. Your SRB routine, which received control in 31-bit 
>mode cannot make 
>any assumptions about the high halves of the registers.

I mentioned that in relation to the fact that an AMODE(64) module issued the 
IEAMSCHD whilst
the doc states AMODE(31) is required ... didn't have any assumptions about 
the SRB routine
itself.

>>As of late (I suspect since z/OS V2R1), the high halves (bits 0-31) of all 
>>GPRs, and the ARs,
>>contain x'' when the SRB routine is entered (the routine is scheduled 
>>in KEY=0
>>with PASN=SASN=HASN), even if (in the case of the GPRs) bits 32-63 is zero.

>As Ed pointed out, this is a DIAG trap that is intended to help you to find 
>errors in your code 
>where you assume that the high halves are zero when they may not be.

Indeed! I found that out the hard way ...

Thanks to everyone who responded to this  learnt a few lessons here.

Best regards, Andre

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

Re: IEAMSCHD and SRB entry questions

[Andre Schoeman]

>Since the documentation for IEAMSCHD says that AMODE 64 is not supported, 
>you are taking a risk that your code might at any point stop behaving 
>properly. That is your choice, but it is your (and your users') risk. Is 
>there any plan to do so in the immediate future? Not that I know of. Would 
>any such plan be announced? Probably not.

I accept what the current state of the documentation says. However, when
z/OS is touted as 64-bit capable, shouldn't a continous effort be driven whereby
all invoked system system services eventually are AMODE(64) capable ??
(disregard the restricted location of certain control blocks for now   I'm
merely referring to invoking a service whilst running in AMODE(64))

>Regardless, the AMODE of the target SRB is not AMODE 64, and the high 
>halves are not part of the interface. You must make no assumption about 
>those values other than what has been documented.
>So aside from observing that they are FF's, why do you care?

The SRB routine was created as a 64-bit routine and immediately switches
to AMODE(64) upon getting control. Since SRB routines receive control in
AMODE(31), I did not expect or depend on any specific values in the high
halves of the GPR's or the AR's. I was merely interested why that condition
existed and Ed's comment about the DIAGxx member explained that.

Best regards, Andre

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

Re: rant on IBM support offerings

[Ed Jaffe]

On 6/13/2016 8:06 AM, Pommier, Rex wrote:

So I need to pay IBM extra money on top of the monthly/annual support charges 
for the privilege of being able to save IBM time and money by updating PMRs 
myself rather than having IBM update them for me?  This doesn't compute!!


We pay something ($250/mo?) for a single user license of Software Excel 
Basic.


--
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: rant on IBM support offerings

[Lizette Koehler]

You might need to talk to IBM admin for your site.

This has happened to me in the past when my company was having a challenged with
IBM accounting practices,

You should be able to talk to your IBM account manager to find out what is going
on

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Pommier, Rex
> Sent: Monday, June 13, 2016 8:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: rant on IBM support offerings
> 
> So maybe somebody can explain the logic behind this.  I opened a PMR last week
> on an IBM product that I have support on.  I was able to electronically open
> the ticket and as part of my opening documentation, I mentioned that I have an
> SVC dump of the offending product that I can send them if they need it.  (20-
> 20 hindsight, I should have just attached the dump when I opened the PMR).
> Anyway, I got an e-mail back from IBM support asking me to send in the dump,
> along with a link to my PMR.  However when I go back to the PMR, the web page
> says that if I want to update my PMR electronically I need either Software
> Xcel or Resolve to attach, otherwise I need to call IBM-SERV to update the
> ticket.
> 
> So I need to pay IBM extra money on top of the monthly/annual support charges
> for the privilege of being able to save IBM time and money by updating PMRs
> myself rather than having IBM update them for me?  This doesn't compute!!
> 
> 
> 
> Rex

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

Re: rant on IBM support offerings

[Charles Mills]

Yeah, I remember the same sort of issue. Made no sense to me at the time
either.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Pommier, Rex
Sent: Monday, June 13, 2016 8:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: rant on IBM support offerings

So maybe somebody can explain the logic behind this.  I opened a PMR last
week on an IBM product that I have support on.  I was able to electronically
open the ticket and as part of my opening documentation, I mentioned that I
have an SVC dump of the offending product that I can send them if they need
it.  (20-20 hindsight, I should have just attached the dump when I opened
the PMR).  Anyway, I got an e-mail back from IBM support asking me to send
in the dump, along with a link to my PMR.  However when I go back to the
PMR, the web page says that if I want to update my PMR electronically I need
either Software Xcel or Resolve to attach, otherwise I need to call IBM-SERV
to update the ticket.  

So I need to pay IBM extra money on top of the monthly/annual support
charges for the privilege of being able to save IBM time and money by
updating PMRs myself rather than having IBM update them for me?  This
doesn't compute!!

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

Re: rant on IBM support offerings

[Paul Gilmartin]

On Mon, 13 Jun 2016 15:06:27 +, Pommier, Rex wrote:

>So maybe somebody can explain the logic behind this.  I opened a PMR last week 
>on an IBM product that I have support on.  I was able to electronically open 
>the ticket and as part of my opening documentation, I mentioned that I have an 
>SVC dump of the offending product that I can send them if they need it.  
>(20-20 hindsight, I should have just attached the dump when I opened the PMR). 
> Anyway, I got an e-mail back from IBM support asking me to send in the dump, 
>along with a link to my PMR.  However when I go back to the PMR, the web page 
>says that if I want to update my PMR electronically I need either Software 
>Xcel or Resolve to attach, otherwise I need to call IBM-SERV to update the 
>ticket.  
>
>So I need to pay IBM extra money on top of the monthly/annual support charges 
>for the privilege of being able to save IBM time and money by updating PMRs 
>myself rather than having IBM update them for me?  This doesn't compute!!
> 
I have never found this to be the case.  But it's possible that my employer has 
paid the fee.

-- gil

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

rant on IBM support offerings

[Pommier, Rex]

So maybe somebody can explain the logic behind this.  I opened a PMR last week 
on an IBM product that I have support on.  I was able to electronically open 
the ticket and as part of my opening documentation, I mentioned that I have an 
SVC dump of the offending product that I can send them if they need it.  (20-20 
hindsight, I should have just attached the dump when I opened the PMR).  
Anyway, I got an e-mail back from IBM support asking me to send in the dump, 
along with a link to my PMR.  However when I go back to the PMR, the web page 
says that if I want to update my PMR electronically I need either Software Xcel 
or Resolve to attach, otherwise I need to call IBM-SERV to update the ticket.  

So I need to pay IBM extra money on top of the monthly/annual support charges 
for the privilege of being able to save IBM time and money by updating PMRs 
myself rather than having IBM update them for me?  This doesn't compute!!



Rex

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

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

Re: CCSID

[Charles Mills]

Okay ...

01200 UTF-16 UTF-16 as defined in the Unicode Standard. Data is big endian 
order. PF
01202 UTF-16 LE UTF-16 as defined in the Unicode Standard. Data is little 
endian order. T7
01208 UTF-8 UTF-8 as defined in the Unicode Standard. PK
01210 UTF-EBCDIC UTF-EBCDIC as defined in the Unicode Standard. UH
01232 UTF-32 UTF-32 as defined in the Unicode Standard. Data is big endian 
order. J1
21680 UCS-2, DBCS UTF-16 (Unicode version 4.0) TH
61953 UCS-2, DBCS UNICODE 1.0 RG
61956 UTF-16, DBCS With mapping of PUA characters as prescribed by Microsoft T0

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, June 12, 2016 10:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CCSID

On Sun, 12 Jun 2016 17:08:34 -0700, Charles Mills wrote:

>z/OS Unicode Services, on which I think all of these CCSID translation 
>implementations are based, fully supports UTF-8 (assuming that's what you mean 
>by Unicode). I use it all the time. Specify CCSID 1028 as the "ASCII" code 
>page.
> 
A fair assumption except for those bred in the zSeries tradition, to whom 
Unicode is likely to mean UCS-2; big-endian; no futher questions.  I believe 
there's even hardware support for this.  Don't know about little-endian, 
pervasive in the outside world.  Doubtful about UTF-8 which would require far 
more complex microcode.  So while the WorldWide Web has largely migrated to 
UTF-8, zSeries remains at UCS-2.

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

Re: IEAMSCHD and SRB entry questions

[Ed Jaffe]

On 6/13/2016 6:52 AM, Tom Marchant wrote:

On Fri, 10 Jun 2016 14:39:35 -0700, Andr é Schoeman wrote:


As of late (I suspect since z/OS V2R1), the high halves (bits 0-31) of all 
GPRs, and the ARs,
contain x'' when the SRB routine is entered (the routine is scheduled 
in KEY=0
with PASN=SASN=HASN), even if (in the case of the GPRs) bits 32-63 is zero.

As Ed pointed out, this is a DIAG trap that is intended to help you to find 
errors in your code
where you assume that the high halves are zero when they may not be.


These traps also "dirty" the access registers. We have found many bugs 
in our code with these traps, and quite a few in IBM's code as well...


--
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: IEAMSCHD and SRB entry questions

[Tom Marchant]

On Fri, 10 Jun 2016 14:39:35 -0700, Andr é Schoeman wrote:

>Note that all the GPR's in the issuing code are purified to contain "clean" 
>31-bit addresses
>before the IEAMSCHD is issued.

That's not good enough. Your SRB routine, which received control in 31-bit mode 
cannot make 
any assumptions about the high halves of the registers.

>As of late (I suspect since z/OS V2R1), the high halves (bits 0-31) of all 
>GPRs, and the ARs,
>contain x'' when the SRB routine is entered (the routine is scheduled 
>in KEY=0
>with PASN=SASN=HASN), even if (in the case of the GPRs) bits 32-63 is zero.

As Ed pointed out, this is a DIAG trap that is intended to help you to find 
errors in your code 
where you assume that the high halves are zero when they may not be.

-- 
Tom Marchant.

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

Re: Displaying Users and Processes for UNIX z/OS Functions

[Kirk Wolf]

On z/OS 2.1 or later, you can use this command:

zlsof -d /tmp

Other commands and suggestions for managing /tmp can be found here:
http://dovetail.com/docs/pt-quick-inst/pto-inst-tmp.html

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Mon, Jun 13, 2016 at 2:03 AM, Peter Hunkeler  wrote:

>
> >I'd try the UNIX command, "ls -alrt /tmp", which would show timestamps,
> >user IDs, and file sizes.  It's at least a good start.  Automate with
> BPXBATCH
> >or BPXWUNIX.
>
>
>
>
> That would not show files that have been unlinked but are still in use
> (open). I understand it is quite common for temporary files: OPEN (create
> mode), UNLINK, WRITE & READ to and from file, CLOSE.
>
>
> The temporary file will be deleted a CLOSE time. In the case of unnormal
> end, the kernel will CLOSE the file, thus the file will be deleted also in
> that case. No zombie file left behind.
>
>
> "ls" will not show this file.
>
>
> "fsinuse" will show processes that use files in a specific directoy, but
> /tmp might be used by many. So, how do you indentify the one eating up all
> space?
>
>
> --
> Peter Hunkeler
>
>
>
> --
> 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

Microsoft to buy LinkedIN

[Lizette Koehler]

Microsoft Corp said in a blog post it agreed to buy LinkedIn Corp for $26.2
billion in cash. The offer of $196 per share represents a premium of 49.5
percent to LinkedIn's Friday closing price

FoxBusiness.com
 

 

 

 

Lizette Koehler

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

 


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

AW: Re: Displaying Users and Processes for UNIX z/OS Functions

[Peter Hunkeler]

>I'd try the UNIX command, "ls -alrt /tmp", which would show timestamps,
>user IDs, and file sizes.  It's at least a good start.  Automate with BPXBATCH
>or BPXWUNIX.




That would not show files that have been unlinked but are still in use (open). 
I understand it is quite common for temporary files: OPEN (create mode), 
UNLINK, WRITE & READ to and from file, CLOSE.


The temporary file will be deleted a CLOSE time. In the case of unnormal end, 
the kernel will CLOSE the file, thus the file will be deleted also in that 
case. No zombie file left behind.


"ls" will not show this file.


"fsinuse" will show processes that use files in a specific directoy, but /tmp 
might be used by many. So, how do you indentify the one eating up all space?


--
Peter Hunkeler



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

Re: CCSID

[Paul Gilmartin]

On Sun, 12 Jun 2016 13:32:27 -0400, Scott Ford  wrote:

>All,
>
>I need some assistance in troubleshooting a codepage issue .
>I have a server sending ascii data using codepage 850 to another server
>running codepage 437. Then the message is sent to z/OS ..The character in
>question is a '~' which is x'7E'..I looked at both character maps and since
>x'7E' is a ascii 126 will this character not be translated from server to
>server ? If so we use codepage 037 to convert ascii to ebcdic ...We are
>actually seeing the tilde on z/OS..
>
And these are the code pages mentioned by the OP.  (Largely a test to
see how well LISTSERV deals with UTF-8.)

@MVS3:506$ cat `ls -Art | tail -3` | iconv -f ISO8859-1 -t IBM-1047 
   
Host: IBM-1047  output: from_IBM-850
  0  16  32  48  64  80  96 112 128 144 160 176 192 208 224 240
  0  10  20  30  40  50  60  70  80  90  a0  b0  c0  d0  e0  f0

   0  0   0   @   P   `   p   á   ░   └   ð   Ó   ­
   1  1   !   1   A   Q   a   q   í   ▒   ┴   Ð   ß   ±
   2  2   "   2   B   R   b   r   ó   ▓   ┬   Ê   Ô   ‗
   3  3   #   3   C   S   c   s   ú   │   ├   Ë   Ò   ¾
   4  4   $   4   D   T   d   t   ñ   ┤   ─   È   õ   ¶
   5  5   %   5   E   U   e   u   Ñ   Á   ┼   ı   Õ   §
   6  6   &   6   F   V   f   v   ª   Â   ã   Í   µ   ÷
   7  7   '   7   G   W   g   w   º   À   Ã   Î   þ   ¸
   8  8   (   8   H   X   h   x   ¿   ©   ╚   Ï   Þ   °
   9  9   )   9   I   Y   i   y   ®   ╣   ╔   ┘   Ú   ¨
  10  a   *   :   J   Z   j   z   ¬   ║   ╩   ┌   Û   ·
  11  b   +   ;   K   [   k   {   ½   ╗   ╦   █   Ù   ¹
  12  c   ,   <   L   \   l   |   ¼   ╝   ╠   ▄   ý   ³
  13  d   -   =   M   ]   m   }   ¡   ¢   ═   ¦   Ý   ²
  14  e   .   >   N   ^   n   ~   «   ¥   ╬   Ì   ¯   ■
  15  f   /   ?   O   _   o   »   ┐   ¤   ▀   ´    

Host: IBM-1047  output: from_IBM-437
  0  16  32  48  64  80  96 112 128 144 160 176 192 208 224 240
  0  10  20  30  40  50  60  70  80  90  a0  b0  c0  d0  e0  f0

   0  0   0   @   P   `   p   á   ░   └   ╨   α   ≡
   1  1   !   1   A   Q   a   q   í   ▒   ┴   ╤   ß   ±
   2  2   "   2   B   R   b   r   ó   ▓   ┬   ╥   Γ   ≥
   3  3   #   3   C   S   c   s   ú   │   ├   ╙   π   ≤
   4  4   $   4   D   T   d   t   ñ   ┤   ─   ╘   Σ   ⌠
   5  5   %   5   E   U   e   u   Ñ   ╡   ┼   ╒   σ   ⌡
   6  6   &   6   F   V   f   v   ª   ╢   ╞   ╓   μ   ÷
   7  7   '   7   G   W   g   w   º   ╖   ╟   ╫   τ   ≈
   8  8   (   8   H   X   h   x   ¿   ╕   ╚   ╪   Φ   °
   9  9   )   9   I   Y   i   y   ⌐   ╣   ╔   ┘   Θ   ∙
  10  a   *   :   J   Z   j   z   ¬   ║   ╩   ┌   Ω   ·
  11  b   +   ;   K   [   k   {   ½   ╗   ╦   █   δ   √
  12  c   ,   <   L   \   l   |   ¼   ╝   ╠   ▄   ∞   ⁿ
  13  d   -   =   M   ]   m   }   ¡   ╜   ═   ▌   φ   ²
  14  e   .   >   N   ^   n   ~   «   ╛   ╬   ▐   ε   ■
  15  f   /   ?   O   _   o   »   ┐   ╧   ▀   ∩    

Host: IBM-1047  output: from_IBM-037
  0  16  32  48  64  80  96 112 128 144 160 176 192 208 224 240
  0  10  20  30  40  50  60  70  80  90  a0  b0  c0  d0  e0  f0

   0  0   &   -   ø   Ø   °   µ   ^   {   }   \   0
   1  1       é   /   É   a   j   ~   £   A   J   ÷   1
   2  2   â   ê   Â   Ê   b   k   s   ¥   B   K   S   2
   3  3   ä   ë   Ä   Ë   c   l   t   ·   C   L   T   3
   4  4   à   è   À   È   d   m   u   ©   D   M   U   4
   5  5   á   í   Á   Í   e   n   v   §   E   N   V   5
   6  6   ã   î   Ã   Î   f   o   w   ¶   F   O   W   6
   7  7   å   ï   Å   Ï   g   p   x   ¼   G   P   X   7
   8  8   ç   ì   Ç   Ì   h   q   y   ½   H   Q   Y   8
   9  9   ñ   ß   Ñ   `   i   r   z   ¾   I   R   Z   9
  10  a   ¢   !   ¦   :   «   ª   ¡   [   ­   ¹   ²   ³
  11  b   .   $   ,   #   »   º   ¿   ]   ô   û   Ô   Û
  12  c   <   *   %   @   ð   æ   Ð   ¯   ö   ü   Ö   Ü
  13  d   (   )   _   '   ý   ¸   Ý   ¨   ò   ù   Ò   Ù
  14  e   +   ;   >   =   þ   Æ   Þ   ´   ó   ú   Ó   Ú
  15  f   |   ¬   ?   "   ±   ¤   ®   ×   õ   ÿ   Õ

-- gil

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