Re: S_MODE settings to get 755
"umask" maybe ? On 01.05.2014 14:39, Ward Able, Grant wrote: Hi Listers, I use BPX1OPN to create a file and I want to set it to 755, but no matter which S_MODE2 or S_MODE3 options I choose, I only get 4 for the owner. In desperation I have been trying all sorts of things, including the 2 shown below, all to no avail, as when I try to execute the file in a following step, I get: INSUFFICIENT AUTHORITY TO OPEN ACCESS INTENT(--X) ACCESS ALLOWED(OWNER R--) I have tried these: MVI S_MODE2,S_IRUSR+S_ISVTX MVI S_MODE3,S_IWUSR+S_IXUSR+S_IRWXG+S_IRWXO MVI S_MODE2,S_IRUSR+S_ISVTX MVI S_MODE3,S_IWUSR+S_IXUSR+S_IRWXG+S_IRWXO Any/all help will be greatly appreciated. Regards - Grant. Telephone Internal: 201496 (London) Telephone External: +44 (0)207 650 1496 DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research& Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. ---
Re: PDSE and HLASM together in z/OS 2.1
Thank you very much On 28.02.2014 12:26, Sharuff Morsa3 wrote: After a bit of (archaeological) digging, it appears our manuals are incorrect and that we've visited this issue before. When HLASM 1.4 development was in full flight, the CODEPAGE option was added. This appears to have fallen victim to the short-on-os-storage issue - and the coded 128k value was changed to a whopping 132K! - the books never caught up with this modification. I agree with Miklos, and we will look to change this value - Richard will be on the case when he returns from SHARE. Sharuff smo...@uk.ibm.com btw - anyone going to SHARE ? If so, go say hello to Richard Cebula - its his first SHARE conference! From:Miklos Szigetvari Subject: Re: PDSE and HLASM together in z/OS 2.1 Hi Thank you Sharuff. We have closed the PMR76555.010.618, as with REGION=1000M it worked, I think it would be not bad if the SIZE default would be a little less. On 27.02.2014 13:38, Sharuff Morsa3 wrote: Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research& Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. ---
Re: PDSE and HLASM together in z/OS 2.1
Hi Thank you Sharuff. We have closed the PMR76555.010.618, as with REGION=1000M it worked, I think it would be not bad if the SIZE default would be a little less. On 27.02.2014 13:38, Sharuff Morsa3 wrote: Miklos Szigetvari wrote: Subject: PDSE and HLASM together in z/OS 2.1 ... After a PMR it turned out that the PDSE has not enough storage. We are using the default assembler OPTION SIZE(MAX) . In this case , according the book , the assembler gives back 128 K byte storage, but it is not big enough for PDSE. I will change the default SIZE, but maybe the assembler would gives back something more as 128K ? SIZE=MAX is the default. Reading the HLASM Install guide SC26-3494-05 http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/download/asmi1021.pdf page 170, note 4 says: '4. When you specify the MAX suboption, the assembler releases 128 K back to the user region (z/OS), virtual machine (CMS), or the partition GETVIS (z/VSE), for system usage. When you specify the MAX suboption, there might not be enough storage remaining in the user region (z/OS), virtual machine (CMS), or the partition GETVIS (z/VSE), to load any exits you specify, or any external functions you use in your assembly. I also found the HLASM V1.4 pdf (dated Sept 2000) - and it has the same words - and I'd put good money on the older versions saying the same. Richard (the HLASM developer) has asked whether this is the time to change the 128k value & increase it a little rather than have everyone change their procedures. If an RFE or request appears - I'm sure an APAR will soon turn up. (An RFE would be a good place for all to suggest what value should be used in place of 128k) Sharuff smo...@uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research& Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. ---
PDSE and HLASM together in z/OS 2.1
Hi Not so serious problem, in z/OS 1.13 we wrote our SYSADATA to PDSE and using 0M region size. In z/OS 2.1 all this jobs ended with an S0F4 reason x'24' and i/O error with SYSADATA After a PMR it turned out that the PDSE has not enough storage. We are using the default assembler OPTION SIZE(MAX) . In this case , according the book , the assembler gives back 128 K byte storage, but it is not big enough for PDSE. I will change the default SIZE, but maybe the assembler would gives back something more as 128K ? -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research& Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. ---
[no subject]
Hi Very very said . Just yesterday noticed his comments on the TCP/IP newsgroup, kindly joking about my bad English. You have my sympathy. On 11.01.2013 01:09, Chris Mason wrote: Hello to you all, I'm Milena, Chris Mason's daughter. I'm writing to you, to inform you that, unfortunately, dad passed away on Sunday January 6th. The funeral service will be held next Thursday January 17th in Court-Saint-Etienne, Belgium. If you wish to attend, please send me an e-mail to this address: mil_ma...@hotmail.com, I'll give you all the details. Thank you for your attention, Milena MASON
Re: FCNTL.H
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: DFSMS exit
Hi Maybe the Sys1.sacbcntl (NAVIQuest) can do this There is a TOTALS option to report the total space usage On 23.05.2012 05:14, Jake anderson wrote: Dear All, Are there any EXITS which would calculate the Dasd space allocated to a HLQ.** ? Has anyone implemented such Routine just to automate the process for various HLQ's ? Any Pointers or suggestions are appreciated. Jake
Re: Assembler info needed
If you can get Cannatello: Advanced Assembler Language and MVS Interfaces and write/compile/debug as many as you can On 3/16/2012 4:18 PM, Sudheen P M wrote: Hi All, I am new to assembler on z/OS.I have tried to google for a starting point to learn assembler,but unfortunately I am not able to get one.Only thing that I keep hitting are some user/reference guides and some presentations. Could I request you to provide me some pointers to docs which are good starting point for me. Thanks in advance Sudheen
DIAGNOSE(0204) questions
Hi Some questions about the DIAGNOSE (0204) instruction and reply: - try to compute the CPU busy percent in a very busy machine , and never get 100%, the SDSF show 100% in this case , but from the DIAGNOSE output I got only 98-99% CPU busy - another question about the CPU utilization. We have 2 processors and seems a LOOP application is scheduled 50-50% on both processors. It is good for me, but what is the reason behind this ?
Re: CPU timeused
> Hello All, > > I am looking for a assembler source code which would help in measurng the > CPU time taken for each statement in COBOL. Could anyone advise me if you > have sample Code using which I can modify according to my requirement. > > Jake > > Hi The LE FLOW and PROFILE woud not help ? Never worked with COBOL but for C/C++ we used the PROFILE I would check the CBT tape
Re: Where is the CPU time (in the processor )
Hi I'm looking now the Hercules DIAGNOSE code Thank you. On 3/5/2012 2:58 PM, Dave Kreiss wrote: Try a little research on the Diagnose 204-7 interface (I believe the Hercules project documents the parameters and return values). Also for example the SMF manual infers that the diagnose 204 is the source of their CPU usage values - search SMF manual for the term diagnose. Dave -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Miklos Szigetvari Sent: Monday, March 05, 2012 4:36 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Where is the CPU time (in the processor ) Hi Try to find out the processor used times (till now without success), but maybe the question: Where are this values stored, and it is possible to access them , how the RMF gets this values ?
Re: Where is the CPU time (in the processor )
Hi Sounds good, but I found only in VSE On 3/5/2012 12:19 PM, Martin Truebner wrote: processor used times You could use TDSERV here is a sampleTDSERV FUNC=TDINFO,AREA=TDAREA It will return the CPU-time used on each processor since last reset (or IPL) -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Where is the CPU time (in the processor )
Hi Try to find out the processor used times (till now without success), but maybe the question: Where are this values stored, and it is possible to access them , how the RMF gets this values ?
Re: CPU: ASSM vs ENTERPRISE COBOL
Hi On 4/6/2011 1:50 PM, Angel Luis Domínguez wrote: Thanks every body for your ussefull apointments. I have opened this topic because it was a surprise for me. No other problems and considerations are involved. Each language is different from others and each person or company will choose one depending on their needs. Mi client ask me to developp program in two languages concerned because their primary use will be massive in a highly loaded teleprocessing environment. Some notes to clarify terms - Magnitude (Miklos asked): DOUBLE CPU used by ASSM program. If it is in millisecond or in minutes. Still I feel, it is an "invisible" target, but if you have APA(Appl.Perf.Anal) or any other (?) tool maybe you will see the difference. - ASSM and COBOL have the same mainline execution in a batch scenario: it receives a parameter from a calling program, it does a lot ot of mathemathic operations and call many times to CSF for crytographic purposes. After that, it returns control to calling program with a result. There a lot of cross-memory services involved, but are the same for ASSM or for COBOL. - RENT in assembler is coded based in a workarea receveid from calling program. No STORAGE OBTAIN, GETMAIN or FREEMAIN a re used. - Assembler program is LE conforming. As a personal challenge, apart from professional needings, i will try to improve performance of assembler program as a means to improve my skills. I wrote mi first assembler program in 1972 but "world is changing every minute" and it is neccesary to learn new things every day. Thank you all for your knowledge and your time. angel luis dominguez z/os system programmer - spain
Re: SV: CPU: ASSM vs ENTERPRISE COBOL
On 4/5/2011 4:53 PM, Thomas Berg wrote: I have no knowledge about this but as Angel wrote: "I have made a revision of assembler generated by cobol but there are a lot of LE modules involved." Could it be that these LE modules put a zIIP engine at work using SRB enclaves ? That CPU is presumably not showed in the statistics in z/SO ? Unfortunately NO Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK
Re: CPU: ASSM vs ENTERPRISE COBOL
On 4/5/2011 7:08 AM, Angel Luis Domínguez wrote: Thanks every body for clues. Some answers 1) Both assembler and cobol are sub-programs. They were called directly from a main program builded in cobol to test. This main programa does measure of CPU before and after calling. 2) I have made a revision of assembler generated by cobol but there are a lot of LE modules involved. Difficult to translate into my assembler. 3) I will make a revisión about "G" instrucciones, but I have yet used them because I have needed 128 real bits operations. At the end, it is not a so important question. Only I was surprised for that. Sincerely angel luis dominguez z/os system programmer - spain Hi You are saying the COBOL is the winner, but in which magnitude ? (i.e. minutes or millisec )
Re: IEEE floating points
Hi Thank you Dave. I also have the feeling maybe if we change the Windows setting, we could get closer, but unfortunately I have never seen a statement like : "in you set in Windows options and in ZOS options you will get always the same result" As a change would be over a very very large number of modules, nobody want to start this experiment till now On 3/25/2011 9:05 AM, Dave wrote: -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Thomas David Rivers Sent: 23 March 2011 17:28 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEEE floating points Miklos Szigetvari wrote: Hi Thank you. Our problem is: which option and where to change to get the same result. Till now we have ignored this differences( in AFP documents, position difference sometimes in 1 pel), but some of our customers are saying, they would like to get the same result , in all platforms . Hi Miklos, Yes... :-) The basic problem is that the floating point value for the type 'double' is 64-bits wide when stored in memory; but by default, when the x86 floating pt. hardware loads it into the register; the register is 80-bits wide. So, if you have any expressions involving the value, and the compiler rather smartly keeps the values solely in registers; the full 80-bit value participates in the computation. When the result of the expression is stored back into memory (eventually) it's converted to a 64-bit value. The intermediate steps would have potentially different rounding behaviors because of the 'extra bits' while the values "lived" in registers. Thus, you need to look for options that prevent the values from living in registers.. or otherwise cause the compilers to properly use only 64-bit intermediate results during computations. This results in slower running code on the x86. You can imagine, in our C, C++ and Assembler tools, we are *required* to produce exactly the same result on many different platforms as what we would find on the mainframe. A very reliable way we found to do this was to not depend on the native floating-pt at all, and use our own libraries. Many times, a rather straight-forward emulation will suffice, but if you want to get things exactly right with this approach takes quite a bit of testing. But - if you want to try something quick-and-dirty, this article tells you how to set the floating-pt rounding mode on the x87 processor: http://www.network-theory.co.uk/docs/gccintro/gccintro_70.html That article is in relation to GCC, I'm not sure of the syntax for Microsoft Visual Studio... basically, you want to use the x87 fldcw instruction (floating load control word) to set things up the way you need. Microsoft seem to have fudges. This is from the Visual Studio 2010 Express Compiler /fp: choose floating-point model: except[-] - consider floating-point exceptions when generating code fast - "fast" floating-point model; results are less predictable precise - "precise" floating-point model; results are predictable strict - "strict" floating-point model (implies /fp:except) /Qfast_transcendentals generate inline FP intrinsics even with /fp:except So what the heck it does I don't know. I think I would try with "/strict" and see if that makes a difference. As others have said you may also need to adjust optimization levels. By default Visual C has them disabled. This article: http://www.math.ucdavis.edu/~hass/doubbub.cpp has some examples (and references a paper that may discuss this very issue.) It appears to have been published some time ago, so I'm not sure how pertinent it is to more current Visual Studio environments. - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: IEEE floating points
Hi We have always ignored this small rounding differences, but here the "end effect" was that the generated document was different, as "hyphenation" , word splitting worked differently. My little surprise was, that we have changed the C++ compiler option, to use the "standard" IEEE, but the result was still not the same in Windows as in zOS On 3/24/2011 7:51 AM, Bernd Oppolzer wrote: Hi Martin, anyway: it's a problem of proper (that is: identical) rounding, because the OP said that the computed pixels are one position off on the different platforms. Kind regards Bernd Am 23.03.2011 20:23, schrieb Martin Trübner: Bernd, No financial - just pel positioning (printing) even cheques being printed with a few pixels off would be accepted. Dare do I guess what nationality the customer is that wants identical results ;-) -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: IEEE floating points
Hi Thank you. Our problem is: which option and where to change to get the same result. Till now we have ignored this differences( in AFP documents, position difference sometimes in 1 pel), but some of our customers are saying, they would like to get the same result , in all platforms . On 3/23/2011 11:59 AM, Thomas David Rivers wrote: Miklos Szigetvari wrote: Hi Can I expect with IEEE floating points, to get the same results in Windows as in z/OS ? (Seems to us till now, it is not the case, we are using LE C++ in zOS and Windows Visual C++, but got differences) Hi Miklos, Unfortunately, no... the x86 processors support several alternative sizes of IEEE floating pt values which alters the available precision. Thus can affect floating point operations to yield different results. Several x86 compilers offer options that restrict the use of these alternate precisions.. so, in some circumstances you can alter your x86 environment to match z/OS. - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: IEEE floating points
On 3/23/2011 8:42 AM, Miklos Szigetvari wrote: Hi Can I expect with IEEE floating points, to get the same results in Windows as in z/OS ? (Seems to us till now, it is not the case, we are using LE C++ in zOS and Windows Visual C++, but got differences) Found http://www.appinf.com/download/FPIssues.pdf
IEEE floating points
Hi Can I expect with IEEE floating points, to get the same results in Windows as in z/OS ? (Seems to us till now, it is not the case, we are using LE C++ in zOS and Windows Visual C++, but got differences)
Re: Writing a Systems Programmer Resume
On 3/8/2011 11:10 PM, Joe Gallaher wrote: RE: http://share.confex.com/share/116/webprogram/Session8903.html I sent sent out my Anaheim SHARE powerpoint slides today to everyone who requested them. Since there were quite a few, I could have missed somebody. If you did not get them, or would like them, please let me know. Joe j...@spci.net 323-822-1569 On Tue, 22 Feb 2011 10:19:39 -0500, Joe Gallaher wrote: I would like to invite anyone attending next week's SHARE conference in Anaheim to come to my session on "How to Write a Resume for a Mainframe Systems Programmer" (session 8903). It is the third time I have given this presentation at SHARE and it contains a lot of useful information and samples for the aspiring resume writer. Here is a link to my session: http://share.confex.com/share/116/webprogram/Session8903.html If you cannot attend, feel free to send me an email (or LinkedIn message) and I will send you a link to my PowerPoint slides (which will be available after Feb. 28). I look forward to seeing you Monday! Joe Gallaher j...@spci.net www.SPCI.net www.linkedin.com/in/joegallaher 323-822-1569 Hi If you can send me a copy
Re: Best (or any) practices to rewrite "spaghetti" or METAL/C
Original Message Subject:Re: Best (or any) practices to rewrite "spaghetti" or METAL/C Date: Thu, 10 Feb 2011 08:58:28 +0100 From: Miklos Szigetvari To: IBM Mainframe Discussion List Hi If we can consider METAL/C as alternative to rewrite assembler code ?
Re: Best (or any) practices to rewrite "spaghetti"
Hi Thank you. Try to consider this, i.e if I can make some common error routine set. Currently every error label does something special . On 2/4/2011 3:31 PM, Don Higgins wrote: Miklos, all Good question. I'm not sure the following is a best practice, but I've found it useful in developing z390 in Java and zcobol in z390 assembler. I have used several callable routines to handle all error messages and aborts. One routine called log_error(error_number,error_msg) logs error message and returns to caller which allows caller to continue on or handle error. The other routine named abort_error(error_number,error_message) logs error and then issues abort. This approach minimizes insertion of GOTO's (one abort call), and allows user to maintain the shared routines which handle error logs, console logs, maximum return codes, etc. Don Higgins d...@higgins.net On Thu, 3 Feb 2011 18:16:57 +0100, Miklos Szigetvari wrote: Hi Asking here for the best practices to rewrite "spaghetti" assembler code to use structured programming macros I think I red a number of SHARE presentations My concern is currently the error handling Till now, if an error occurred, there was a JUMP/BRANCH to an error block, with all the possible error messages , and after a JUMP/BRANCH to the module RETURN. Seems to me , instead of this, some DOEXIT or ASMLEAVE would be more complicated Mikos, all
Re: Best (or any) practices to rewrite "spaghetti"
Hi Thank you very much for everybody. The answers has confirmed my view , to overuse a good technique can lead to obscure results. On 2/3/2011 9:15 PM, Roger Bolan wrote: I'm sure others will tell you about coding techniques and structured macros etc. My advice when "improving" old spaghetti assembler code is this: Make sure you have a regression test library ready to insure that the behavior of the new code matches the old code. Spaghetti code can hide a lot of little subtleties and you need to make sure that the more structured, more readable code doesn't change or miss anything. You also need to compare performance. On more than one occasion we found the performance of the old spaghetti code module hard to beat or match. --Roger On Thu, Feb 3, 2011 at 10:16 AM, Miklos Szigetvari< miklos.szigetv...@isis-papyrus.com> wrote: Hi Asking here for the best practices to rewrite "spaghetti" assembler code to use structured programming macros I think I red a number of SHARE presentations My concern is currently the error handling Till now, if an error occurred, there was a JUMP/BRANCH to an error block, with all the possible error messages , and after a JUMP/BRANCH to the module RETURN. Seems to me , instead of this, some DOEXIT or ASMLEAVE would be more complicated
Re: z Linux assembler relative or friend or foe?
On 7/7/2010 10:11 PM, Tony Harminc wrote: On 7 July 2010 15:47, Paul Raulerson wrote: Well, yes - there are ways it can know, same as on z/OS. No there are *not*, for either system. Unless Linux is interpreting the entire zArch instruction stream for all user programs, which it manifestly isn't. However in this case, it was the compiler that figured it out, wasn't it? The compiler evidently was back-level, but there is nothing to prevent anyone from coding their desired instruction in hex, or constructing it on the fly and executing it, the compiler's opinion no matter. And it will execute directly on the bare metal, as specified in the Principles of Operation. There is nothing Linux or any other OS can do to prevent an unprivileged instruction from so executing. This is fundamental to the 370 architecture and its successors. Tony H. -Original Message- From: Tony Harminc [mailto:t...@harminc.com] Sent: Wednesday, July 7, 2010 12:39 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z Linux assembler relative or friend or foe? On 7 July 2010 13:15, Paul Raulerson wrote: Linux restricts a bunch of instructions and does not allow user programs to ever run in a priv. mode. That may be so, but EPSW is not a privileged instruction, and cannot even cause a program check of any kind no matter how badly you screw up. There is no way Linux could know that a user program was issuing an EPSW. Tony H. Hi Thank you very much for everybody. I will update if we had the result .
Re: z Linux assembler relative or friend or foe?
On 7/7/2010 9:32 AM, Rob van der Heij wrote: On Wed, Jul 7, 2010 at 8:10 AM, Miklos Szigetvari wrote: Hi My colleague is porting some assembler code to z Linux (gnc glx compiler ? ) and got some "invalid op code" assembler error for "EPSW" (extract psw) There's probably -march=z9-109 and similar options that would tell it for which machine you generate code. But the two abbreviations don't ring a bell with me in this context. I believe 'glx' is the GNU framework to talk to your PC video card... The Linux toolchain has 'gcc' create intermediate assembler source, and 'gas' to take that and produce the object code. If you're brave, you could write source for 'gas' by hand, but it lacks all the features that you need for serious assembler projects. David Bond's presentation explains the issues: http://www.tachyonsoft.com/s8131db.pdf Rob Sorry it is "gcc" , and thank you for the link.
z Linux assembler relative or friend or foe?
Hi My colleague is porting some assembler code to z Linux (gnc glx compiler ? ) and got some "invalid op code" assembler error for "EPSW" (extract psw)
Re: Data exception in SRB routine
Hi Thank you very much for you precious advices. We are thinking about this. On 6/28/2010 7:05 PM, Chris Craddock wrote: Here would be the reason of this exercise, to run C++ code in zIIP, as far as I understand in "Enclave SRB" mode. The routine switches to SRB mode and let the C++ code run , for example a compress C++ routine. I can switch to key 0, but I don't think it would be a good idea. I can save you the trouble of running that experiment. There isn't a snowball's chance in hell that it would work out when called from an SRB in any key. To run C++ code you would need to have an LE main() function that calls LE initialization to set up all of the usual LE gorp. That gets put there automagically by the compiler and binder btw. LE resolutely assumes a key 8 problem state task mode environment and naively calls system services via SVC so the first abend code you would probably get would be a S0F8. But supposing you did call it in key 8 and it did somehow manage to get you a working runtime environment you would then have a supervisor state SRB-mode program running in key 8 and using key 8 storage for stack and heap... in other words, a classic integrity hole. Now if you abandon the idea of actually running in key 8, there IS a way you can get around this using pre-initialized CEEPIPI runtimes, but (1) there's a lot of fiddling about (2) lots of things you would normally expect to "just work" (most system services) don't work at all in SRB mode, or require specific coding to indicate you know what you're doing (3) you're totally on your own for recovery, resource management, I/O etc. In other words, unless the thing you want to run is a simple CPU-bound function that doesn't really need any of the "normal" services a typical HLL program needs, there isn't any chance you can get it to work reliably or safely. Full disclosure: I don't work in z/OS internals development any more, but I did for a very long time. When I do occasionally speak up on one of these topics, I am only trying to save folks from heartache. You may all think I am just grousing about this stuff, or maybe you think I just don't know what I am talking about. If so, feel free to ignore me. CC
Re: Data exception in SRB routine
Hi Here would be the reason of this exercise, to run C++ code in zIIP, as far as I understand in "Enclave SRB" mode. The routine switches to SRB mode and let the C++ code run , for example a compress C++ routine. I can switch to key 0, but I don't think it would be a good idea. On 6/26/2010 7:34 AM, Chris Craddock wrote: I can't believe how often the old chestnut about running in key zero versus user ket comes up. There is nothing inherently risky running in key zero - presuming of course that you're not a cowboy coder who fails to validate input and output areas. Store instructions only go where you point them. The overlay bogey is shorthand for sloppy coding. As for running in key 8 in an SRB, it is certainly NOT necessary (there are mixed key instructions for safely moving data to/from caller storage) and furthermore it is actually a bad idea for a number of reasons. First, it is a fairly unusual condition for an SRB to run in - potentially causing serious astonishment (I.e. Generally a bad idea) in called code, but here's my personal favorite dingbat reason... Running an SRB in a user key is a probable integrity violation if the SRB uses user key storage for work areas, save areas etc. So the ostensible "ooh it is safer in user key" is just a crock. For the record, I have never once run an SRB in anything but a system PSW key, and wouldn't. There's just no reason to Date: Thu, 24 Jun 2010 20:37:29 +0300 From: bdis...@dissensoftware.com Subject: Re: Data exception in SRB routine To: ASSEMBLER-LIST@LISTSERV.UGA.EDU On Thu, 24 Jun 2010 11:53:40 -0500 Chris Craddock wrote: :>> :>> Got a data exception with reason code 7 for an STD instruction in an :>> SRB routine : :>> *PGM007 078C2000 D43615B6 00040007 :>> The instruction STD FR10,... :>> As far as I see , the control reg 0 , bit 45 (AFP control) is on . :>> (It is a z9 S07) :>An SRB routine running in PSW key 8?!? WTF? Nothing at all wrong with that. It knows that the areas that it needs to modify are in key8. It is a quite bad practice to run in key0 when it is not needed. All sorts of bad overlays can happen. -- 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.
Re: Data exception in SRB routine
On 6/24/2010 7:37 PM, Binyamin Dissen wrote: On Thu, 24 Jun 2010 11:53:40 -0500 Chris Craddock wrote: :>> :>> Got a data exception with reason code 7 for an STD instruction in an :>> SRB routine : :>> *PGM007 078C2000 D43615B6 00040007 :>> The instruction STD FR10,... :>> As far as I see , the control reg 0 , bit 45 (AFP control) is on . :>> (It is a z9 S07) :>An SRB routine running in PSW key 8?!? WTF? Nothing at all wrong with that. It knows that the areas that it needs to modify are in key8. It is a quite bad practice to run in key0 when it is not needed. All sorts of bad overlays can happen. -- 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. Hi It is running in user key, I don't see the reason for data exception in this case
Data exception in SRB routine
Hi Got a data exception with reason code 7 for an STD instruction in an SRB routine : *PGM007 078C2000 D43615B6 00040007 The instruction STD FR10,... As far as I see , the control reg 0 , bit 45 (AFP control) is on . (It is a z9 S07)
