Regards,
James van Eck | Vc4u | Centre of Excellence for Managed Services | Technology 
Enablement | Africa Technology 
Tel: +27 (0)11 444 3935 | Email: jame...@absa.co.za

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, June 27, 2016 2:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for confirmation of an RCF

     IARV64 REQUEST=DETACH,                                        +        
           MEMOBJSTART=AV_RArea64,                                 +        
           V64COMMON=YES,                                          +        
           COND=YES,                                               +        
           MF=(E,IARV64L,COMPLETE)                                          
 8, "AFFINITY=" DOES NOT ALLOW THE USE OF THE FOLLOWING KEY(S) "V64X01-IARV6
           COMMON".

I now of course know that omitting AFFINITY=SYSTEM was an error on my part,
but the quoted documentation "64-Bit Common memory objects are not affected
by AFFINITY=LOCAL" led me to believe that AFFINITY=LOCAL, the default, was
irrelevant. (That's the point of my proposed RFC.)

(I might also add that the phrasing of the MNOTE is less than a model of
clarity.)

It's a common memory object -- does that answer the question?

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Sunday, June 26, 2016 5:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Request for confirmation of an RCF

>I just got an MNOTE on a nIARV64 macro assembly. I

It would have been helpful to have seen the actual invocation and the actual
MNOTE, as well as information about what kind of memory object you were
actually trying to detach.

None of the following invocations gets an MNOTE:
         iarv64 request=DETACH,memobjstart=(2) 
         iarv64 request=DETACH,memobjstart=(2),affinity=LOCAL 
         iarv64 request=DETACH,memobjstart=(2),affinity=LOCAL,owner=NO 
         iarv64 request=DETACH,memobjstart=(2),affinity=LOCAL,owner=YES 
         iarv64 request=DETACH,memobjstart=(2),affinity=LOCAL,owner=YES*
               ,ttoken=(4) 
         iarv64 request=DETACH,memobjstart=(2),affinity=SYSTEM,        *
               v64common=NO 
         iarv64 request=DETACH,memobjstart=(2),affinity=SYSTEM,        *
               v64common=YES 

Nor did anything else that I tried with syntactically correct use of the
other operands of request=DETACH.

In general, I'm quite sure that your suggested update is wrong. You do not
syntactically always need to specify AFFINITY=SYSTEM on REQUEST=DETACH.
I would not be surprised if semantically there are such cases (but those
would be represented by return/reason codes or abend/abendreason codes from
the service, not by MNOTEs from the macro).

So perhaps you could start over with what went wrong?

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

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

Reply via email to