Re: FCNTL.H
I did receive a copy of fcntl.h, but it is missing one value that I need, F_DUPFD2. Could someone tell me the value for F_DUPFD2? Tony Thigpen -Original Message - From: Tony Thigpen Sent: 11/26/2012 04:29 PM Could someone send me a copy of FCNTL.H? (offlist!) I need to compare some of the values to those used by our VSE IP product. Thanks. -- Tony Thigpen
Re: FCNTL.H
Yes. Thanks Tony Thigpen -Original Message - From: Miklos Szigetvari Sent: 11/27/2012 06:59 AM Hi If you mean this: #define F_SETFL 4 #define F_GETLK 5 #define F_SETLK 6 #define F_SETLKW 7 #define F_DUPFD2 8 #define F_CLOSFD 9 #define _F_GETFL 3 On 27.11.2012 12:31, Tony Thigpen wrote: I did receive a copy of fcntl.h, but it is missing one value that I need, F_DUPFD2. Could someone tell me the value for F_DUPFD2? Tony Thigpen -Original Message - From: Tony Thigpen Sent: 11/26/2012 04:29 PM Could someone send me a copy of FCNTL.H? (offlist!) I need to compare some of the values to those used by our VSE IP product. Thanks. -- Tony Thigpen
Re: Stupid? though on a new execute instruction.
I was trying to avoid the branch instruction. I guess in today's world where the CPU can actually follow both paths until the actual branch is taken, this is more of my silliness. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER- l...@listserv.uga.edu] On Behalf Of Binyamin Dissen Sent: Monday, November 26, 2012 4:21 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Stupid? though on a new execute instruction. On Mon, 26 Nov 2012 15:38:32 -0600 McKown, John john.mck...@healthmarkets.com wrote: :OK, since I have you here anyway. What about a real weirdie? An instruction which says whether or not to execute the next instruction, based on the condition code? That would enable every instruction to be a conditional instruction. Perhaps EXNC (Execute Next Conditional). What comes to mind? Perhaps: What about simply Jc *+2/4/6 does exactly what you want Can be done by a macro as well. -- Binyamin Dissen bdis...@dissensoftware.com 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.
Usefullness (or not) of STOC/LOC instructions?
We've been using the STOC/LOC (STORE/LOAD ON CONDITION) instructions for some time... But, we just noticed a few words in the Principles of Operations (I'm quoting from the STOC discussion): When the condition specified by the M3 field is not met (that is, store operation is not performed), it is model dependent whether any or all of the following occur for the second operand: (a) an access exception is recognized, (b) a PER storage-alteration event is recognized, (c) a PER zero-address-detection event is recognized, or (d) the change bit is set. Now - a rather common programming idiom is to store a result if a pointer is not NULL. So, it would seem that a comparision of a pointer to x'0' followed by a STOC would be a nice programming idiom. However, one of our recent tests (on a zPDT platform) blows up with this paradigm... getting an 0C4. Even though the condition in the STOC is not met and the store will not occur... The Principles of Operation also appear to be inconsistent, it makes this claim: For example, the following two instruction sequences are equivalent. STOCG 15,256(7),8 BC 7,SKIP STG 15,256(0,7) SKIP DS 0H But, according to the paragraph quoted above, the two sequences are not equivalent. The sequence on the right might not have the possibility of generating an access-exception, while the STOCG does have that possibility even though the store would not occur. I find these semantics a little baffling and wonder if that doesn't essentially make STOC/LOC pretty much unusable in all but the most restrictive situations? Thoughts/Opinions??? - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
