AW: Re: Interested in BASH becoming part of z/OS UNIX? Vote for requirement 60048
In my opinion the problem with the OP's post is more that he apparently thinks that BASH in and of itself will compromise z/OS security. No, that's not at all what I'm thinking! Shell shock has just been the trigger to open the long due requirement. If we offer some piece of software to our customers, we're responsible for it. People will use the software in production jobs, sooner or later. When a job that used to work fails due to some bug in the software, those responsible for the software are in charge of fixing the problem. If the software is a supportes piece of software, you can (hopefully) rely on someone to fix the problem. If the software is not supported, you may be out of luck. I'd rather have supported software being used for production jobs. That's it. In my opinion the problem with the OP's post is more that he apparentlythinks that BASH in and of itself will compromise z/OS security. [snip] ... I don't know why the OP has this association in his mind. It puzzles me what made you think so. Having BASH as part of a supported package doesn't make it neither safer nor weaker. It just makes it a piece of supported software. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSM Recall process
At 19:51 + on 10/17/2014, Chase, John wrote about Re: HSM Recall process: An exception to the order of processing is when doing recalls from tape, where DFSMShsm reduces the number of mounts by doing several recalls from a given tape while the tape is continuously mounted. If a recall task has just completed a recall from a tape, it processes the highest-priority request that is currently on the queue for that same tape, no matter where the request is positioned on the queue. Assuming that it has multiple recalls with the same priority on the tape is it smart enough to do them in the order that they are on the tape (ie: File Number Order) thus reading the tape sequentially or does it go with their order on the queue (ie: In essence random) thus seeking back and forth on the tape? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
As I read thru the MVS Extended Addressability Guide I am trying to understand restrictions, In general, you should assume that a z/OS service does not support AMODE 64 unless it says it does. In general, you should assume that a z/OS service that supports AMODE 64 does not support data above 2G unless it says it does. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XM POST ERRET=
The ERRET routine applies to cases where the invoker has no opportunity to cover things: - use of SPOST - blowing up within the target address space attempting to post the XM ECB. It is up to the invoker's recovery to deal with a problem in the invoker's thread (such as an invalid address space rejected by schedule). Hold on a second - you are not coding the ASCB parameter. POST (R1),ERRET=error_routine, X MF=(E,EXITPLST),LINKAGE=SYSTEM,ECBKEY=0 This shows a classic error in using execute form where you fail to provide all the parameters, but the expansion assumes that you have initialized things properly with an initialized list form. For these macros (indeed all traditional macros) the execute form does not (is not allowed to) do the sort of checking that would say you have ERRET without ASCB. The standard form would do so but of course is not reentrant. Some of these traditional macros do support COMPLETE on the execute form to indicate that you are expecting to provide everything so completely initialize the parameter list -- MF=(E,listname,COMPLETE). POST is not one of these, though. In this case, you get what you get. I don't know what's in EXITPLST. I don't know if the POST module ignores ERRET or assumes, because of the presence of ERRET, that you provided an ASCB and this is an XM POST. I suspect the former. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On Sat, 18 Oct 2014 10:11:15 -0400, Peter Relson wrote: In general, you should assume that a z/OS service that supports AMODE 64 does not support data above 2G unless it says it does. If it does not, there's not a whole lot of rationale for (claiming to) support AMODE 64. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSM Recall process
For the requests on the queue, in order. You may still be submitting requests when the first one gets processed. On Sat, Oct 18, 2014 at 8:34 AM, Robert A. Rosenberg hal9...@panix.com wrote: At 19:51 + on 10/17/2014, Chase, John wrote about Re: HSM Recall process: An exception to the order of processing is when doing recalls from tape, where DFSMShsm reduces the number of mounts by doing several recalls from a given tape while the tape is continuously mounted. If a recall task has just completed a recall from a tape, it processes the highest-priority request that is currently on the queue for that same tape, no matter where the request is positioned on the queue. Assuming that it has multiple recalls with the same priority on the tape is it smart enough to do them in the order that they are on the tape (ie: File Number Order) thus reading the tape sequentially or does it go with their order on the queue (ie: In essence random) thus seeking back and forth on the tape? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
It means junk that happens to be in the high 32 bits of a register won't mess us up. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, October 18, 2014 7:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit On Sat, 18 Oct 2014 10:11:15 -0400, Peter Relson wrote: In general, you should assume that a z/OS service that supports AMODE 64 does not support data above 2G unless it says it does. If it does not, there's not a whole lot of rationale for (claiming to) support AMODE 64. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Never mind. Should not post before coffee. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Saturday, October 18, 2014 8:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit It means junk that happens to be in the high 32 bits of a register won't mess us up. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, October 18, 2014 7:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64bit On Sat, 18 Oct 2014 10:11:15 -0400, Peter Relson wrote: In general, you should assume that a z/OS service that supports AMODE 64 does not support data above 2G unless it says it does. If it does not, there's not a whole lot of rationale for (claiming to) support AMODE 64. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
Paul, There would certainly be no rationale for having AMODE(64) if there were no above-the-bar virtual storage. Since, however, we do have this storage there is sometimes a rationale for using AMODE(64) below the bar, and the ability to invoke a facility from AMODE(64) code is then also valuable. It reduces the need for mode switching and its associated prologues and epilogues, if nothing else. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
It's as much as I can do just to spell CoBOL but, as far as I can tell, it's not ready for prime time. Even its most avid proponent signs off thus: TomR COBOL is the Language of the Future! We are trapped in the present. We cannot get to the future. The nearest we can get to the future is the latest, most recent, current instance of the present. Ergo, CoBOL is not for us. 'Nuff said! ;-) === Date: Thu, 16 Oct 2014 10:17:56 -0400 From: 0006f84450fa-dmarc-requ...@listserv.ua.edu Subject: 64bit To: IBM-MAIN@LISTSERV.UA.EDU All, I have a generalized design question. First background will help. Our products run as Enterprise Cobol STC, no multi-tasking, yet. We call hlasm subroutines. I would like to use 64bit storage for some functions from Cobol. Is this feasible. I think it is, where I am unclear is the call and binder parameters. Do I have to do anything special parameter wise ? Thanks as always, Regards, Scott ford www.identityforge.com - www.idmworks.com from my IPAD -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
Well, I have no experience with forking an address space, but how would the two communicate? Usually, there is some sort of common shared storage which does require APF authorization to establish and cleanup. Thanks! This would be a totally different ball game as it brings an extra layer of communication between the address spaces. This would also require extra authorization which wouldn't fly well with the management Yes, it requires extra communication. But it solves your problem in a clean way :) I'm not sure in what sense you mean extra authorization. It does not require any form of system authorization (APF, supervisor state, system key), though it might require that the user ID that the main address space is running under has an OMVS identity (UNIX UID and GID) defined. But the ID may already be set up that way. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64bit
On Sat, 18 Oct 2014 11:16:13 -0400, John Gilmore wrote: There would certainly be no rationale for having AMODE(64) if there were no above-the-bar virtual storage. Since, however, we do have this storage there is sometimes a rationale for using AMODE(64) below the bar, and the ability to invoke a facility from AMODE(64) code is then also valuable. It reduces the need for mode switching and its associated prologues and epilogues, if nothing else. Having been through this (but not to successful completion) in the 370-XA transition when I had to obtain contol blocks below the line and add interface code below the line, and cursing IBM not for shirking the former (which is harder), but for shirking the latter (which is easier; they've done it at last), it was perhaps easy for me to intend more irony than you perceived. It's still far from the level of compatibility of being able to code EXEC PGM=ASMA90,PARM='64-bit,...' and being able to supply a 370 source program unmodified and letting conditional assembly handle the compatibility. The GET macro might test the AMODE and generate code to interface to either a DCB or a DCBE (or in the future a DCBG) as suitable. C comes rather close to this with its #ifdefs, but not entirely, as previous plies in this thread suggest. On Fri, 17 Oct 2014 20:12:58 -0500, John McKown wrote: Most likely not of any use to you, but have you looked at GnuCOBOL? It was OpenCOBOL, but has been taken over by GNU / FSF as one of their languages. It works by translating COBOL to C and then compiling the C code. If nothing else, it might give you some ideas. http://sourceforge.net/projects/open-cobol/ . Of course, it does not run on z/OS, ... I thought that was only because you haven't finished porting it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
On Sat, 18 Oct 2014 23:39:12 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: Is there some kind of USS communication path available? The standard MVS XMEM post requires APF. You wouldn't be posting; you'd be sending messages back and forth through one of a variety of UNIX communication mechanisms. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSM Recall process
At 09:38 -0500 on 10/18/2014, Mike Schwab wrote about Re: HSM Recall process: For the requests on the queue, in order. You may still be submitting requests when the first one gets processed. I suppose you can live with the Race Condition (which means one out of tape order recall requiring a rewind) since the first tape mount and recall would take long enough to allow the rest of the requests to be made. To attempt to avoid/reduce this exposure doing the sort by vol-ser and file-seq would seem to help. It is too bad that there is no way to send the requests followed by a commit (ie: Tell HSM I am going to send a number of requests but do not do them until I tell you to process the full batch). On Sat, Oct 18, 2014 at 8:34 AM, Robert A. Rosenberg hal9...@panix.com wrote: At 19:51 + on 10/17/2014, Chase, John wrote about Re: HSM Recall process: An exception to the order of processing is when doing recalls from tape, where DFSMShsm reduces the number of mounts by doing several recalls from a given tape while the tape is continuously mounted. If a recall task has just completed a recall from a tape, it processes the highest-priority request that is currently on the queue for that same tape, no matter where the request is positioned on the queue. Assuming that it has multiple recalls with the same priority on the tape is it smart enough to do them in the order that they are on the tape (ie: File Number Order) thus reading the tape sequentially or does it go with their order on the queue (ie: In essence random) thus seeking back and forth on the tape? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Calculation involving SMF CPU Time
In 45fcfbbb8bc8eb4a9dfedc6fa2cc7fdf99a82...@sdkmbx02.emea.sas.com, on 10/15/2014 at 06:03 AM, Lindy Mayfield lindy.mayfi...@sas.com said: I honestly cannot remember why I did that, to divide by 38400, Google for timer units, or check a 370-mode PoOps. I would hope that IBM has stopped using them for new fields, but SMFCPU is fairly old. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
