Re: multiple TSO Sessions (try this)
On Wed, 29 Jan 2014 08:31:07 -0600, John McKown wrote: Oh, my. Given the fact that many of our users cannot remember a single RACF logon id, assigning them multiple would cause chaos. And is against company Yup. We can't even get a group ID for some tech support purposes. If the employee having the ID terminates, the function vanishes. policy. We really need to implement EIM and an SSO solution (zero cost with no overhead, of course) so that Windows people can access z/OS (TSO, ftp, and CICS) without needing to do another logon. Of course, this won't solve But would they want to? IBM needs to wake up and recognize it's no longer the biggest kid in every block, and accept enterprise-wide identity management, not necessarily mainframe based, notwithstanding the advertised security advantages of the mainframe. all the id problems because we have literally had people forget their name (Oh? I said kathy.mulligan? It should be cathy.mulligan! But everybody calls me cat.) At 1/28/2014 09:15 PM, Govind Chettiar wrote: A contractor who joined our team said that in his previous place of employment he could have multiple TSO sessions each of which used the same userid and password, so he used to have multiple instances of his TN3270 emulator running and a different TSO session in each. IBM is the only vendor I know of that enforces such an archaic restriction, at least with CMS and TSO. But it's getting better with Unix System Services. (I suspect not with VM/CMS Open Extensions.) It's time IBM woke up. In the bad old days when carbon was cheaper tnan siilcon, we couldn't even afford one terminal per programmer; we had to share. Things should be different now. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multiple TSO Sessions (try this)
On Wed, 29 Jan 2014 13:44:41 -0800, Frank Swarbrick wrote: Is there some actual technical reason why TSO cannot be made to allow one user ID to log in multiple times to TSO within a single LPAR? Yes. Bad design. The assumption that the user ID could be used as a handle for an interactive TSO session. There's no practical limit to the number of concurrent instances of the TSO TMP I can run under batch (plus one foreground). I even run ISPF that way (but I allocate ISPPROF to DUMMY). Is fear of sharing ISPPROF old bad habit? It was mentioned earlier in this thread that ISPPROF can now be shared. How does that work? Doesn't ISPF cache ISPPROF and write it back on exit, thereby obliterating changes that may have been made in sessions that exited earlier? We've disabled MIM's propagation of certain ENQs -- our testers in particular prefer not to logoff one system in order to be able to logon to another. Last session to exit wins. We're used to it. I have never heard of member corruption, and it's not Shmuel's dog. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multiple TSO Sessions
On Wed, 29 Jan 2014 15:56:41 -0600, John McKown wrote: LPARs are exactly like separate machines. Or maybe closer to virtual machines under z/VM or VMWare or Hyper-V or ... . Extremely close indeed. There are legends that in the earliest days of PR/SM one could recognize VM CP message prefixes flashing by on the HMC during startup. On Wed, 29 Jan 2014 15:54:46 -0600, John McKown wrote: As I recall, this dates back to the beginnings of TSO under MVT. As I recall the story, the original (perhaps unreleased) version of TSO did allow multiple signons to a single id. But there was some sort of problem having to do with how to CANCEL a given session, or how to SEND a message to a particular session. Back in the MVT days, the CANCEL command did not have a way to direct the CANCEL to a given region (as the A= does to a given address space today). So if you had an id signed on 3 times with only 1 of them having a problem, then a CANCEL U=thisid would cancel all 3 sessions. The same happened with started tasks and batch jobs. Oh, and I So rather than repair the problem they withdrew the facility!? That might be a necessary stopgap; it should never have been accepted as a long-term solution. think there was also a problem with the TIOC sending command output to the wrong terminal. I.e. enter the LISTALC command on terminal#1 and the results might go to terminal#2 instead. But I'm real vague on that last one. I can do that right now. From a Unix System services, I issue Rexx address TSO hmigrate DATA.SET.NAME and watch messages appearing on my 3270 TSO session. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multiple TSO Sessions
On Wed, 29 Jan 2014 18:40:11 -0500, Tony Harminc wrote: On 29 January 2014 17:19, Paul Gilmartin wrote: think there was also a problem with the TIOC sending command output to the wrong terminal. I.e. enter the LISTALC command on terminal#1 and the results might go to terminal#2 instead. But I'm real vague on that last one. I can do that right now. From a Unix System services, I issue Rexx address TSO hmigrate DATA.SET.NAME and watch messages appearing on my 3270 TSO session. Sure, but that's a rather different and far less unreasonable problem. What does UNIX do in general when you send a message to a user by userid? Send it to all sessions, or the first, or a random one, or...? Who said it had to be done wrong? It is not reasonable. HSM should send the response, not to a userid, but to the ASID, session, ..., whatever originated the request. I'll be quite surprised to find the TIOC using only the userid as a key to keep track of where to send non cross-memory TPUTs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multiple TSO Sessions (try this)
On Thu, 30 Jan 2014 01:21:19 -0600, Elardus Engelbrecht wrote: Barbara Nitz wrote: We only have one lpar (one system), and I am now logged in 11 times with the same TSO userid. We have made sure that each of those TSO sessions has their own ISPF profile data set. And each session can have up to 8 split screens. Having own ISPF profile makes sense. That depends. If the user wants to operate in 11 different personae or roles, having distinct profiles makes sense. If the user wants profile changes made in one session to propagate to all subsequent logins, it's undesirable. Perhaps ISPF should be enhanced with a pair of commands, one to sync the DASD copy with the in-storage copy, the other to refresh the in-storage copy from the DASD copy just synched. Or keep the profile in a VSAM data set with shared access. This doesn't bother me much in UNIX systems. If I want to change my ~/.profile, I edit and save it; otherwise it remains unchanged. If you go into SDSF and name all of those SDSF consoles the default (the TSO userid), then command responses won't necessarily come back to the console that issued the command. Indeed, my TSO users sometimes come crying back to me 'where are my responses/messages', just because they're too lazy to have unique console names. Oh well... ;-) That's a bug. It should be fixed. It might be as simple as making SDSF enforce or generate unique console names. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: System Symbols Question
On Thu, 30 Jan 2014 09:04:14 -0500, Peter Relson wrote: I don't know what aboriginal refers to in this context, but the answer to the first question is yes. And the behavior has existed since the introduction of system symbols. That's what I meant by aboriginal. It is not OK to truncate silently. Would you even dare to suggest that if in a JCL EXEC PARM='...FOO' the resulting PARM should be silently truncated to 100 bytes if substitution were to cause it to be longer? Yes I certainly do dare. This is practical reality. If a group of customers think it is OK, then it can be OK, even if you choose to disagree, especially when it has no impact to you in the absence of exploitation. You are free not to use a function if you do not like its behavior. There is a cost vs benefit tradeoff in everything all of us do. What's good for General Bullmoose is good for America. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accountability (was: multiple TSO Sessions (try this))
On Thu, 30 Jan 2014 14:35:19 -0400, Clark Morris wrote: On 30 Jan 2014 09:55:32 -0800, in bit.listserv.ibm-main you wrote: Every single TSO user in my shop is assigned two ID's. No one has ever asked for a third, but many people only use one of their assigned ID's. We have never had an auditor ask us why we do this. I don't know what productivity is gained by our applications programmers who use both, but I know we systems guys sometimes need to reply to a console message from one session to free up another session. Unix System Services can meet much of this need. I'm usually able to cancel my (hung) TSO session from a USS session with kill -9. I had a systems programmer-id plus an applications id so that I could test to make sure that an applications programmer had all the appropriate access and only that access. I can see two or more ids for applications programmers to they can properly test their applications from a user point of view. When my systems programmer is trying to reproduce a problem I report from JCL I supply, he (prudently) runs on his non-privileged ID. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
On Thu, 30 Jan 2014 15:01:48 -0500, Micheal Butz wrote: Would anyone know if there is a way For example scanning the TIOT If a dataset has been dummied out I get the following, without resorting to a TIOT scan: user@HOST: rexx say BPXWDYN( 'alloc dd(FOO) dummy' ); say BPXWDYN( 'info dd(FOO) inrtdsn(X)' ); say x 0 0 NULLFILE -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote: We have an exit for DFSORT that scans TIOT to see if someone concatenated a DUMMY dataset as input. Here is what I believe to be the relevant snippet of code: Comments inline. *-* * THIS ROUTINE WAS ADDED TO CIRCUMVENT A PROBLEM CREATED BY DUMMY * * FILES SPECIFIED FOR SORTIN. * *-* This PROBLEM sounds like a bug, which ought to be subject to APAR. DDSCAN DS0H EXTRACT FW,'S',FIELDS=(TIOT),MF=(E,EXTRACTL) L R5,FW USING IEFTIOT1,R5 MVC DDNAME,=CL8'SORTIN' SET DEFAULT DDNAME TMILEXF2A,ILEXFCPYQ. COPY APPLICATION ? BZDDSRCH A. NO, SEARCH FOR SORTIN MVC DDNAME,=CL8'SYSUT1' A. YES, SEARCH FOR SYSUT1 DDSRCH CLC TIOEDDNM,DDNAMEQ. DDNAME MATCH BEDDCON A. YES, CHECK IT OUT SRR0,R0 CLEAR REGISTER ICR0,TIOELNGHGET LENGTH OF THIS ENTRY ARR5,R0 BUMP TO NEXT ENTRY CLI TIOELNGH,X'00' Q. END OF TIOT ? BERETURN A. YES, GET OUT B DDSRCH A. NO, KEEP LOOKING DDCONDS0H CHECK FOR CONCATENATION * IF NOT CONCATENATION, THEN SKIP SRR0,R0 CLEAR REGISTER ICR0,TIOELNGHGET LENGTH OF THIS ENTRY ARR5,R0 BUMP TO NEXT ENTRY CLI TIOELNGH,X'00' Q. END OF TIOT ? BERETURN A. YES, GET OUT CLC TIOEDDNM,=CL8' ' Q. SORTIN CONCATENATED? BNE RETURN A. NO, FORGET IT SRR5,R0 A. YES, RESTORE DSECT POINTER * CHECK FOR DUMMY DD STATEMENT * NOTE: COULD ALSO BE DD * Does this mean that DD * (also DD DATA?) is problematic, even as DUMMY? What about DD PATH='...'? DDCHKCLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ? BEDDBAD A. NO, BAD DD Where's label DDBAD? SRR0,R0 CLEAR REGISTER ICR0,TIOELNGHGET LENGTH OF THIS ENTRY ARR5,R0 BUMP TO NEXT ENTRY CLI TIOELNGH,X'00' Q. END OF TIOT ? BERETURN A. YES, GET OUT CLC TIOEDDNM,=CL8' ' Q. SORTIN CONCATENATED? BEDDCHK A. YES, CHECK AGAIN B RETURN -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multiple TSO Sessions (try this)
On Thu, 30 Jan 2014 13:07:45 -0800, Ed Jaffe wrote: Of course, CEA is the great equalizer (subsequent to the enhancements for Web ISPF). Thanks for posting this Barbara! :-) I thought I was curious, so I searched the doc for CEA (publibz; 1.13; I have no idea how I'd do this with Infocenter, or even if it's possible.) After skimming the first few hits for Common Event Adapter, I decided I wasn't so curious, after all. Multiple logons shouldn't be so hard; merely routine! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
On 2014-01-30 14:04, Jousma, David wrote: We had some enterprising programmers that coded jobs something like: //SORTIN DD DSN=a.data.set.name,disp=shr // dd dd1,disp=shr // dd DD2,disp=shr // dd dsn=another.data.set.name,disp=shr And in the proc defaulted DD1, and DD2 to DUMMY so that they could dynamically change the input datasets. Problem was when they didn’t use them or only one of them, DFSORT stops reading input and the real datasets beyond the dummy ones never got read, and the JOB finished with RC(0), so it was obvious there was missing data. With the exit we abend the job. Much as I detest that behavior (I'd much prefer that DUMMY behaved as DD SPACE=0), it's documented in JCL Ref. or Using Data Sets or somewhere, so WAD. Implementing DWIM, as you appear to be trying to do is an endless and mostly thankless task. And a sophisticated programmer who knowingly codes DUMMY (perhaps to disable some catenands for a test) has much reason to complain when experiencing behavior not only unexpected but also contrary to OS documentation. Have you tried (or suggested) using DD SPACE=0 in place of DUMMY? Even worse (also documented) Allocation substitutes DUMMY for PATH='/dev/null' or PATH='//dev/null', which I deem a colossal misapplication of DWIM by the OS designers. There was *no* reason to do that. They might as well, and with similar rationale substitute DUMMY for SPACE=0. Fortunately, Allocation is sufficiently dumb that it fails to recognize and override the otherwise equivalent PATH='/dev//null'. Do you ABEND only if DUMMY is followed by a non-dummy data set? There should be no problem if DUMMY (or several) is/are the last catenand(s). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multiple TSO Sessions (try this)
On Fri, 31 Jan 2014 06:39:47 -0600, Govind Chettiar wrote: I would respectfully disagree with this somewhat blanket statement. ... this? Please cite. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Compiled rexx fails on readfile
On Fri, 31 Jan 2014 07:19:37 -0700, Lizette Koehler wrote: So I did a little searching and discovered a whole new REXX manual I did not know about REXX/UNIX It's precious! And, dismayingly, it's the only place that BPXWDYN is documented. Proving that Conway's Law applies to documentation as well as to code. Do a display on RETVAL and see what it shows after your READFILE And the documentation is sketchy. It may not be clear that if RC0, no system call is issued and RETVAL is meaningless, perhaps undefined. On Fri, 31 Jan 2014 15:41:11 +0100, jan de decker wrote: Hi list, John, thanks for the suggestions but the first one gives me a n rc of -1, the second one gives an rc of 127 Anybody any idea? Is RC=127 what shell returns for an unrecognized command? Are you perhaps using address SH (by default) rather than address SYSCALL? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I am getting message IKJ56866I DATA SET NOT ALLOCATED, CONCURRENT ALLOCATIONS
On Fri, 31 Jan 2014 09:16:41 -0600, John McKown wrote: Look at the DYNAMNBR parameter on the EXEC JCL statement ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2B6A0/16.6 Should this matter if he's doing FREE? The allocations should then not be concurrent. Perhaps the FREE is failing. On Fri, Jan 31, 2014 at 9:13 AM, Mil Hashoul wrote: ... IKJ56866I DATA SET x NOT ALLOCATED, CONCURRENT ALLOCATIONS ... for the allocation I use SVC99, and I am doing free, all the datasets are temporary datasets, I just use the DCB parametter, and it is dynamical -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Work Station Agent using Windows 7
On Fri, 31 Jan 2014 13:21:41 -0500, Dave Salt wrote: Are you saying you can edit PC files on the mainframe without the WSA being active? If so, how? I customarily edit Solaris files on the mainframe without WSA. Does Win 7 have an NFS server? Customarily? Well, infrequently. I more regularly edit z/OS data sets on Solaris. SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Work Station Agent using Windows 7
On Fri, 31 Jan 2014 10:34:50 -0800, John Norgauer wrote: No, I'm sorry to mis-lead you. I am not editing PC files on the mainframe. What I meant was that I edit mainframe files on my PC using ISPF. What benefit does this provide over tn3270? Well, CPU cycles, of course. ISPF hosted on mainframe, or one of the many clones available for desktop, such as THE? (GINYF!) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Compiled rexx fails on readfile
On Fri, 31 Jan 2014 13:59:47 -0500, Shmuel Metz (Seymour J.) wrote: on 01/31/2014 at 07:02 AM, Lizette Koehler said: There is a TSO REXX newsgroup that might also be helpful. Not as much as the listserve. And for this, MVS-OE might be more relevant than TSO-REXX. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Compiled rexx fails on readfile
On Fri, 31 Jan 2014 18:26:02 +0100, jan de decker wrote: Thanks to a sugesstion from the list (Thanks John) I got a bit further. The stem is empty apart from the number of lines which is correct. o How does interpreted Rexx behave? o Is the behavior the same with other input files? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Infocenter, dammit!
Today, when I click on my bookmarked: http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp ... it appears that Infocenter has tossed its cookies on me, and I get taken, deeper, to the last individual page I visited. I can get to the index by deleting all cookies pertaining to pic.dhe.ibm.com and trying again. Grrr..., gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Work Station Agent using Windows 7
On Mon, 3 Feb 2014 10:58:16 +1100, Hank Oerlemans wrote: Does NOTEPAD work from the command prompt (CMD.EXE) ? How about Notepad++? I suspect Cygwin might show me how. I have my WSA set up to invoke WORDPAD on the PC but I had to mess around with the environment PATH variable to find it. Could it be fully qualified, instead? Or I could have changed it to invoke WRITE instead. Ouch! Several years ago, some of my cow-orkers had configured MS Exchange to use MS Write as a viewer, with the result that embedded JCL samples such as BLKSIZE=6000 displayed as BLKSIZE`00. Did they ever fix that? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Work Station Agent using Windows 7
On Tue, 4 Feb 2014 10:09:59 +1100, Hank Oerlemans wrote: Anything that takes a file as an argument should work I would think. WS cmd field is 50 bytes wide so whatever fits I suppose. Ouch! I have filenames (not to mention pathnames) longer than that. For comparison, in the Classic world, that won't even hold 44+8+2. Is that a concession to the limitations of 3278 Mod 2? Ouch! MS write in this instance invokes wordpad. Go figure ! Maybe they'll fix the help text and title lines in WIN7+? When I saw WRITE earlier, I thought Word and nattered about that. In fact wikipedia, which is always right, says: http://en.wikipedia.org/wiki/Microsoft_Write Microsoft Write is a basic word processor included with Windows 1.0 and later, until Windows NT 3.5. Throughout its lifespan it was minimally updated, and is comparable to early versions of MacWrite. Early versions of Write only work with Write (.wri) files, but after Windows 3.0, Write became capable of reading and composing early Word (.doc) documents. With Windows 3.1, Write became OLE capable. In Windows 95, Write was replaced with WordPad. So, I'm not surprised. Is this, perhaps, sensitive to filename associations? Someone here a few days ago suggested freeware Notepad++. I tried it and immediately made it my default editor for text files. I'm glad I'm rarely compelled to use Windows. My cow-orkers who prefer to use TSO have their Solaris files exported via NFS; I, who prefer not to, have my legacy data sets likewise exported. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote: We have an exit for DFSORT that scans TIOT to see if someone concatenated a DUMMY dataset as input. Here is what I believe to be the relevant snippet of code: ... * CHECK FOR DUMMY DD STATEMENT * NOTE: COULD ALSO BE DD * DDCHKCLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ? BEDDBAD A. NO, BAD DD ... How does this behave for DD PATH=...? Is the UCB address nonzero for zFS files? Are you unwittingly prohibiting use of zFS in the SORTIN concatenation? That would be imprisoning your users in the twentieth century. Prohibiting DD * is also unduly harsh. A similar question applies to Shmuel's suggestion of DEVTYPE. The definitive test should be for DSNAME='NULLFILE'. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
On Tue, 4 Feb 2014 10:25:32 -0600, Mike Schwab wrote: Suggestion: Add DD keyword SKIP. Similar to DUMMY, but will continue with the next concatenated DD statement. No good: user@HOST: rexx say bpxwdyn( 'alloc skip msg(wtp)' ) -22 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
On Tue, 4 Feb 2014 12:20:21 -0600, John McKown wrote: On Tue, Feb 4, 2014 at 11:45 AM, Jousma, David wrote: Sorry for being dense...Never heard of it? What is SKIP? I just looked in JCL reference, don't see anything? There is no SKIP parameter in JCL. Gil was wanting IBM to create such a beasty just for this type of problem. How to null out a DD in the midst of a concatenation, short of creating an empty data set with the correct DCB information. Gil who? It was Mike's idea. Perhaps he has a user exit. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Number of entries in the TIOT
On Wed, 5 Feb 2014 16:39:14 +, Blaicher, Christopher Y. wrote: The end of the list is shown by having a TIOELNGH of zero. Also, TIOSLTYP bit will be on if the entry has been freed. You can skip the entry if this is on. You only have to worry about that bit if you do dynamic allocation and free data sets as your program runs. Are TIOT entries ever freed? Is there a hazard of rotted links? Are they reused (difficult if the length is variable)? Are they in private storage, so freed when the job step ends? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DCB for load library
On 2014-02-05 17:25, Micheal Butz wrote: Is there any way of knowing a data set contains load modules I know that it has a RECFM=U LRECL =0 If it's a PDS, no. A PDS may even contain a mixture of load modules and other things. If it's a PDSE, it may be empty, or contain load modules, or contain other things, but not both. I don't know how to tell which. If it's neither a PDS nor a PDSE, it contains no load modules. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DCB for load library
On Thu, 6 Feb 2014 17:34:56 +1100, Greg Price wrote: On 6/02/2014 11:25 AM, Micheal Butz wrote: Is there any way of knowing a data set contains load modules If PDSE verify it is a program (and not a DATA) PDSE using ISITMGD macro. I have received a correction off-list that a PDSE must not contain load modules. I'll echo the sentiment that the OP needs to clarify his objective. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error overriding concatenated DD in PROC where one is instream data
On Thu, 6 Feb 2014 14:43:07 -0800, Ray Mullins wrote: In z/OS 1.13, I'm playing with instream data in a PROC for the first time to try to simplify some bind JCL and I've run into an error. It's an atypical situation, I realize. Of course, instream data in a PROC are (sic!?) a relatively new facility. They may not have attained a robust maturity. From a logic standpoint, this makes sense, but I'm wondering if this is WAD (thou shalt not override instream data) or maybe DD concatenation needs some extra checks if the underlying DD is instream (or does not have a DSN). I am curious as how this would be handled if the DD was a SUBSYS. The question this brings to mind is, When I override an instream data set with something else, what does the reader/converter/interpreter do with the data? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error overriding concatenated DD in PROC where one is instream data
On Fri, 7 Feb 2014 14:58:53 +, Nims,Alva John (Al) wrote: I have been doing a little research and looking at the z/OS 1.13's z/OS MVS JCL User's Guide it turns out you can code in-stream data in a JES2 procedure and I am going to assume you can't with JES3, but to do so, DO NOT use the // DD * use instead // DD DATA. So I am going to amend my original message by saying, instead of coding // DD * for your second DD in the procedure, try coding // DD DATA instead, so you would have this: I would be astonished if for the matter here // DD DATA were not the functional equivalent of // DD *. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error overriding concatenated DD in PROC where one is instream data
On Fri, 7 Feb 2014 10:09:34 -0600, Mike Schwab wrote: On Fri, Feb 7, 2014 at 9:39 AM, Paul Gilmartin wrote: I would be astonished if for the matter here // DD DATA were not the functional equivalent of // DD *. -- gil // DD DATA,DLM='##' (is the default /*?) //* jcl statements of your choice. ## Just the same except it allows JCL statements. Of course; well known. I would hope that if I override DD DATA with DD * (or vice versa): o The instream data used is that appearing with the overriding statement, not that appearing with the overridden statement o Overriding DD * with DD DATA does not spookily expose and activate JCL statement images appearing in the overriden DD * (Regardless that some might consider such behavior useful. Likewise, IIRC it's documented that: // SET HOW=DATA //... //SYSIN DD HOW ... does not have the effect the programmer might have intended.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumb SMPE question
On Fri, 7 Feb 2014 13:55:27 +, Pommier, Rex wrote: That depends on if the fix PTF contains all the elements in the PE-PTF or only some of them. If it contains all then it can SUP. If it does not it must PRE to pick up the elements that it does not contain - Note this can only occur if PE-PTF has more than one element. When it contains only one, the fix can SUP(PE-PTF) and should contain all of PE-PTF's PREs and SUPs. It's possible that the PE PTF exposed a functional defect in another, older element not in the PE PTF. If the fix PTF replaces only that element, it is not required to PRE and must not SUP the PE PTF (provided that the fix is downward-compatible). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF scrolling in z/OS 2.1
On Mon, 10 Feb 2014 13:28:41 -0600, Peter X. DeFabritus wrote: Do you have OA42696 installed? Wherein I read: Problem conclusion The member list processor and the data set list processor are enhanced to process scroll amounts greater than . New ISPF system variable ZSCROLNL is provided to support scroll amounts greater than . If a scroll amount greater than is processed variable ZSCROLLN is set to a value of and variable ZSCROLNL contains the valid scroll amount. Awww gee. Why not simply extend ZSCROLLN? Is there a new limit? Is ZSCROLNL set even when the requested scroll amount is ? (The APAR doesn't say it is.) So the programmer who wants to find the real scroll amount must check for ZSCROLLN= to determine whether to use ZSCROLNL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: file types
On 2014-02-10 16:16, Scott Ford wrote: I have a Cobol program that can input either RECFM=FB or RECFM=VB and I am trying to make it easier for our customers to use. The input file can be either and whats the simplest way to tell the program that the input is FB OR VB. I was thinking PARM= … What do you guys/gals think ? When I did this sort of thing, long ago, not in COBOL, I inspected DCBRECFM in my DCB exit. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: file types
On Mon, 10 Feb 2014 15:41:53 -0500, John Gilmore wrote: If you write the assembly-language subroutine, make it [a] generic, reentrant RECFM-get routine that will be reusable and put the logic for distinguishing FB and VB (and rejecting other possible values) in its caller. My notion of generic would be to return RECFM whatever it is (and LRECL) and let the caller make the decision of suitability. (Or, accept a list of permissible values.) In COBOL, must the necessary choices be made earlier than entry to the DCB OPEN exit? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMP/E SYSMOD SOURCEID(s)?
In: http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.gim2000/entgsm.htm SYSMOD entry (global zone) SMP/E for z/OS Reference SA23-2276-00 I read: SOURCEID lists the character strings assigned to this SYSMOD during RECEIVE. These values ... The plurals strings and values seem to imply that this SYSMOD may have multiple SOURCEIDs. But (loc. cit.): Example 1: Changing the SOURCEID of a SYSMOD ... etc. The definite article seems to imply that SMP/E supports only one SOURCEID. Which? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E SYSMOD SOURCEID(s)?
On Mon, 10 Feb 2014 16:03:40 -0800, Skip Robinson wrote: A sysmod can have multiple SOURCEIDs. If you receive a sysmod and specify your own SOURCEID, yours is added to any that are already supplied in the PTF being delivered. I do this all the time. Thanks. That seems reasonable. But now I see: http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.gim2000/smbex1.htm Example 1: Changing the SOURCEID of a SYSMOD [definite article, again] SMP/E for z/OS Reference SA23-2276-00 Assume that you received a SYSMOD and assigned it a SOURCEID value of DATALINK, and that you now want to change the SOURCEID value to PUT0701 so that the SYSMOD will be installed with that service level. The following UCL can be used to change the SOURCEID value: SET BDY(GLOBAL)/* Set to global zone. */. UCLIN /* */. REP SYSMOD(UZ1)/* Specify SYSMOD. */ SOURCEID(PUT01) /* Change SOURCEID value. */ /* */. ENDUCL (to agree with the text, it should say SOURCEID(PUT0701).) ... the example is, at best oversimplified. Suppose UZ1 has three SOURCEIDs. How do I code the UCL to: o Change the first from DATALINK to WOMBAT o Leave the second unmodified, whatever it is o Remove the third entirely? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E SYSMOD SOURCEID(s)?
On Mon, 10 Feb 2014 16:24:19 -0800, Skip Robinson wrote: When you run UCL, the syntax may vary according to the type of element you're modifying. Never had occasion to 'change' SOURCEID, but I would guess that you REP the entire existing set of SOURCEIDs with a new set that has all and only the names you want. Or even DEL the subentry on one pass and ADD it back again with your choice of ids. Perhaps SOURCEID( SID1, SID2, SID3, ... ) Or, even delete it/them and add the others back with RECEIVE? The addition I was referring to was simply specifying SOURCEID(s) on a RECEIVE command. Understood. I suspect we'll get an authoritative answer within a couple days. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumb SMPE question
On Fri, 7 Feb 2014 19:32:30 +, Gibney, Dave wrote: -Original Message- On Behalf Of Kurt Quackenbush Sent: Friday, February 07, 2014 5:40 AM ... Or do what I do and build the exclude list required to get RC=0. Why even spend the time to do that? The result is the same, the PTFs don't get applied. RC=0 anality is the only reason. Old habits die hard :) Rarely is it more than 12 to 15, rarely more than 3 or 4 deep. Does REJECT or EXCLUDE or any such make any difference whatever? Don't you get the same RC if no PTFs are selected to APPLY regardless whether there were any candidates in the GLOBAL zone or no candidates in the GLOBAL zone? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumb SMPE question
On Mon, 10 Feb 2014 19:51:39 -0800, Skip Robinson wrote: If no PTFs will APPLY in a particular effort, you're treated to a special message and return code: GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY COMMAND. GIM20501IAPPLY PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. My question is, is there any way one can get a different message or a less serious return code if one unreceive[s] PTFs before the APPLY? I don't believe so; thus, I see no point in attempting to unreceive PTFs to get a cleaner-looking APPLY. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Default OMVS segment
On Tue, 11 Feb 2014 11:25:54 +0530, venkat kulkarni wrote: Hello, On newly installed z/OS 2.1 system we experiencing OMVS segment not defined issue $HASP373 EZAZSSI STARTED ICH408I JOB(OSNMPD ) STEP(OSNMPD ) CL(PROCESS ) 807 OMVS SEGMENT NOT DEFINED etc... We already defined Steps for setting up default OMVS segments. http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.icha700%2Fdefomvs.htm Hmmm... You appear to be reading the 1.12 documentation attempting to configure a 2.1 system. I have heard mumblings that the default OMVS system is deprecated; near end-of-life. In the corresponding 2.1 document: http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.icha700/russ.htm ... I see no mention of a default OMVS segment. Perhaps IBM finally got rid of the wretched thing. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E SYSMOD SOURCEID(s)?
On Tue, 11 Feb 2014 06:38:33 -0600, Kathryn A. Pinto wrote: Skip has given most of the answers already. But to summarize the processing of UCLIN on the SOURCEID subentry: Thanks. Should I have been able to infer all this clearly from the SMP/E Commands manual? If not, I'll submit an RCF. Examples should serve only to clarify information presented in the processing description, not to supply essential information. Is this behavior characteristic of repeatable subentries of DB entries (such as the CSECT subentry of the MOD entry in the Target zone)? Is there an overall rule that I missed? Is there a limit to the number of SOURCEIDs that can be defined for SYSMOD? A SYSMOD can have multiple SOURCEIDs. The ADD and DEL UCLIN operations can be used to act on one or more SOURCEID values and leave the existing values as is. For example, if a SYSMOD has 2 SOURCEIDs (DATALINK1 and DATALINK2), I can ADD one or more SOURCEIDs like so: UCLIN. ADD SYSMOD(sysmodid) SOURCEID(DATALINK3, DATALINK4). ENDUCL. This will leave the SYSMOD with 4 SOURCEIDs - DATALINK1, DATALINK2, DATALINK3 and DATALINK4. I can delete one or more SOURCEIDs like so: UCLIN. DEL SYSMOD(sysmodid) SOURCEID(DATALINK2, DATALINK4). ENDUCL. This will leave the SYSMOD with 2 SOURCEIDs - DATALINK1 and DATALINK3. I can also DELete all of the SOURCEIDs like so: UCLIN. DEL SYSMOD(sysmodid) SOURCEID(). ENDUCL. The REP UCLIN command will completely replace any existing SOURCEID values with the values specified in the UCLIN command. For example, if a SYSMOD has 3 SOURCEID values - DATALINK, DATALINK2, DATALINK3 and I want to o Change the first from DATALINK to WOMBAT o Leave the second unmodified, whatever it is o Remove the third entirely? I could REPlace them as follows: UCLIN. REP SYSMOD(sysmodid) SOURCEID(WOMBAT, DATALINK2). ENDUCL. This will leave the SYSMOD with 2 SOURCEID values - WOMBAT and DATALINK2. I could also do as Skip suggested and delete them all, then add the require ones: UCLIN. DEL SYSMOD(sysmodid) SOURCEID(). ADD SYSMOD(sysmodid) SOURCEID(WOMBAT, DATALINK2). ENDUCL. Thanks again, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E SYSMOD SOURCEID(s)?
On Tue, 11 Feb 2014 08:56:03 -0600, Paul Gilmartin wrote: On Tue, 11 Feb 2014 06:38:33 -0600, Kathryn A. Pinto wrote: Skip has given most of the answers already. But to summarize the processing of UCLIN on the SOURCEID subentry: Thanks. Should I have been able to infer all this clearly from the SMP/E Commands manual? If not, I'll submit an RCF. Examples should serve only to clarify information presented in the processing description, not to supply essential information. I can also DELete all of the SOURCEIDs like so: UCLIN. DEL SYSMOD(sysmodid) SOURCEID(). ENDUCL. The syntax diagram in: http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.gim1000/gim1217.htm SYSMOD entry other than deleted SYSMOD SMP/E for z/OS Commands SA23-2275-00 ... appears not to allow an empty SOURCEID() list. This, at least, deserves an RCF. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Users of CSP and its successor migrating to COBOL 5.1
On Tue, 11 Feb 2014 22:47:42 -0400, Clark F Morris wrote: ... CSP and possibly its successor forced an F zone on all signed fields with positive values leaving the D zone for negative fields. The elimination of NUMPROC(MIG) means this behavior if still existing can cause problems. ... Demonstrating that in the long term a hardware design that allows multiple representations of any mathematical value is a colossal blunder. +0 and -0 are a case in point. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage Obtain .....
On Wed, 12 Feb 2014 18:06:56 -0500, Tony Harminc wrote: ..., but some instructions are allowed by the architecture to recognize access exceptions in the case where no data is stored, e.g. STCM with a zero mask. Ouch! How does this work when the 4 bytes that might be accessed span a page boundary so that some might be accessible and others not? If no bytes selected by the mask are inaccessible, there should be no access exception *except* that for recognizing access exceptions the behavior is may be as if one (only?) byte were selected, even if the mask is zero? Ouch! Or may recognizing access exceptions be performed as if the mask were B''? Ouch! Is recognizing an access exception performed according to rules different from recognizing a protection exception when a page might be accessible but not writable? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage Obtain .....
On Wed, 12 Feb 2014 18:39:14 -0500, Tony Harminc wrote: ..., freeing zero length is an instant disaster. That ought to be a no-op. You can't free 0 bytes at address 0? Now that is an inconsistency. Ah - the subpool thing on FREEMAIN. Is that also true for STORAGE RELEASE? The subpool thing oughtn't be checked unless one or more bytes are to be freed. So to be consistent, a non-zero address with appropriate access setup (primarily key) should probably be returned. Consistent with what? It can't return an address because one wasn't assigned. Sure - it could assign one. It wouldn't have to be unique; just access-exception correct. This is somewhat reminiscent of allocating a data set with VOL=SER=xx, SPACE=(CYL,0), when no space exists on volume xx, which I am told succeeds. I hope, likewise, that such a data set can be freed without a check of the validity of the primary extent. -- gil Tony H. -- 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: Storage Obtain .....
On Thu, 13 Feb 2014 12:10:54 +, DASDBILL2 wrote: If you are allocating such a data set with disposition=new, the request will fail if there is not at least one available (Format 0) DSCB in the VTOC which z/OS can change into a Format 1 DSCB in which to save all the information about your new data set that occupies no real space. At least the data set name of this unreal data set will need to be saved. I raised this question here several years ago. A reader who had the needed privileges (I haven't) got curious and tried the test. He reported that the allocation succeeded even when there were no cylinder extents available. If you really wanted to, you could initialize a new volume with a gazillion cylinders of space and a VTOC of some reasonable size, say 1 cylinder, and then completely fill the VTOC with Format 1 DSCBs for new data sets, all of which have 0 space. And then the VTOC would be full and no new data set of any size could be allocated on this volume which would have a gazillion minus one cylinders of free space on it. This sounds like something that should be tested to make sure it would work this way. I don't know that he tested with no available DSCBs; I'd expect that to fail. I can't think of suitable keywords to search the archives. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage Obtain .....
On Thu, 13 Feb 2014 09:42:32 -0500, Thomas H Puddicombe wrote: If your application didn't want any storage, why did it waste the system service's time by asking for none? It might be that the size is variable, as John G. suggested, and 0 is so unlikely that it is on average a greater waste of time for the application to test for it than to call a system service. To that, add the possibility of coding error in even the very few lines of code needed to test and branch around the call to the system service. I prefer uniform handling of boundary conditions. I was irritated once to discover that SMP/E indicates a syntax error on ++ FUNCTION(name) FILES(0)... so I need to test for 0 and branch around the code that generates the FILES() operand. On Thu, 13 Feb 2014 08:35:19 -0500, John Gilmore wrote: ... I prefer designs that behave appropriately ands coherently at boundary values. It should be possible to allocate zero bytes of storage, concatenate a string of length zero bytes to another one, etc., etc. (I hope I'm not diminishing JWG's evaluation of me by infrequently agreeing with him.) And to FREE the storage not obtained when finished not using it? (Imagine clearing 0 bytes of storage with BCTR; EX ... XC.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Users of CSP and its successor migrating to COBOL 5.1
On Thu, 13 Feb 2014 10:24:44 -0500, John Gilmore wrote: Clarke Morris wrote: begin extract The problem is not the compiler options used for the COBOL generation of CSP programs, the problem is the compiler options of the programs that use the output from CSP programs. /end extract and I disagree. The problem here is one of incoherence. All of the COBOL programs that access the same data need to be compiled with the same value of option in NUMPROC(option). Moreover, it is now clear that NUMPROC(NOPFD) is what is required globally. More generally, the traditional COBOL-shop aversion to recompiling is one that urgently needs to be discarded. It was never sensible, and it is no longer even tenable. What, then, of archival data generated with NUMPROC(YESPFD)? Is there even a conversion utility available? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a C macro for is z/OS
On Fri, 14 Feb 2014 15:14:44 -0800, Charles Mills wrote: Is there a standard IBM z/OS XLC macro for is compiling on z/OS? I looked for __ZOS and __MVS and so forth but did not find anything. I have code that runs Windows or z/OS and I have just been using #ifdef WIN32 to differentiate the two cases, but now I need code that will run Windows, z/OS or Linux so a Boolean check is no longer adequate. All you need to do is to leave out Windows and a binary choice will work OK for you again. You'll be the better for it. I don't need tremendous granularity - this release versus that release or USS command versus batch - just is z/OS rather than Windows or Linux. And obviously I could kludge something, but I thought most systems had a standard this is who I am macro. See: http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.cbclx01/xlmacros.htm Macros indicating the z/OS XL C/C++ compiler product z/OS XL C/C++ Language Reference SC14-7308-00 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance question - adding
On Sun, 16 Feb 2014 07:40:39 -0800, Charles Mills wrote: I am by no means an expert but based on my mental model, the branch approach is going to be slower. It depends on the likelihood of an expensive cache fault performing an operation which has no effect. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Sunday, February 16, 2014 1:11 AM CURRENT and SUM are not adjacent (different data lines) I long chuckled at what I considered a pointless test in: If CURRENT is not zero, then add CURRENT to SUM, thinking it a relic of instructions given to an apprentice bookkeeper working with quill pen on parchment. But modern hardware makes Binyamin's concern realistic. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Branch (was: Performance question - adding)
On Mon, 17 Feb 2014 07:49:18 -0500, Peter Relson wrote: If the branch technique is faster, and depending on how high a percentage most of the time (as in most of the time CURRENT will be zero) is, then the branch technique given as the alternative to no-branch is likely not optimal. Even with branch prediction technology, it is still better to have the expected path not take a branch. So, for example (when LT is available), (It's possible that CURRENT has just been calculated and CC is already set.) LTRx,CURRENT JNZ Need_To_Add Return_From_Need_To_Add DS 0H ... Need_To_Add DS 0H A Rx,SUM STRx,SUM J Return_From_Need_To_Add Is there a maxim here? When the programmer expects that a branch will usually be taken, is it better to avoid: BCC,USUALLY and code instad: BC15-C,*+8 B USUALLY ??? Then you get to factor in how much readability is worth to you. Macros are your friend. But does providing readability at the programming interface level make such a macro unpleasantly verbose internally? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On Mon, 17 Feb 2014 08:02:40 -0800, Charles Mills wrote: I got to thinking it would be nice to have a store different instruction (or make store behave this way automatically under the covers) which would invalidate the cache only if what it were storing were different from what was in memory already. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, February 17, 2014 6:37 AM Combining the thoughts engendered from about three replies, I wonder if avoiding a branch as follows (on a processor which supports the instructions) would perform better than branching. LT R0,CURRENT #LOAD CURRENT AND SET CC SPM R1 #SAVE CC FROM LT A R0,SUM #ADD SUM TO IT IPM R1 #RESTORE CC FROM LT STOC R0,SUM,NZ #STORE SUM ONLY IF CC OF LT WAS NZ Doesn't one also want to avoid fetching the line into cache if it's not already there? I once examined the circuit diagram of some 3rd-party add-on DRAM for a PDP-12 we had. The hardware compared the data to be stored with that already in memory and bypassed the write-back if identical. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On 2014-02-17, at 10:36, Ted MacNEIL wrote: I have to ask: Why they big concern over a few instructions? Optimisation of a few is not worth the effort these days. Hmmm... No single instruction is worth optimizing. No single instruction among a million is worth optimizing. It's not worth optimising a million instructions because that would imply optimizing each, which is not worth it. E.E. asked whether the code is in a loop. -- 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 issue TSO prompts in batch
On Mon, 17 Feb 2014 14:11:32 -0600, Greg Kreth wrote: How to issue TSO prompts in batch Why bother? Whom would you expect to reply to such a prompt? If I have a program that insists on issuing a prompt, such as RECEIVE, I can (sometimes) stage a reply with a Rexx queue instruction. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
On Mon, 17 Feb 2014 20:05:12 -0500, Gerhard Postpischil wrote: On 2/17/2014 7:34 PM, Bernd Oppolzer wrote: My question is: if we had such an instruction, how would this fit into the overall machine concept? And: are there some performance benefits, or are there some problems with this approach, which I do not see? I'm sure, that some historical machines had such concepts ... The IBM 704/709/709x machines had several SKIP instruction types (Compare[one or two skips], Compare Logical[1 or 2 skips], Test Sense Switch); using the latter I could create a print string (0/1 for 6 switches) with fourteen instructions. However, all instructions were the same length, which avoided problems. On zOS machines you'd need to specify the skip amount to make them usable in general, or use macros? The Data General Nova had no condition code register; rather every RR instruction had a condition mask selecting the condition on which the next instruction would be skipped or not. Also, a bit which suppressed loading the target register: Don't load; just test. One might code a fairly long sequence of interleaved RR instructions beginning with a conditional skip and followed by any number of unconditional skips until the paths finally merged at the bottom. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
XL2 capacity (was: assembler)
On Tue, 18 Feb 2014 11:26:41 -0500, John Gilmore wrote: X L2 defines a two-byte field. Its value can range from x'' to x''. Viewed as unsigned this is a numeric range of 0 = u = 65535. Viewed as signed it is a numeric range of -32768 = s = +32767. In either case the answer to your question is yes. As I read it, the OP intends to count bits, not bytes, in which case the answer is no. In passing, let me note that the subject Assembler is not very informative. +1 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Xmitting file between disconnected systems
On Tue, 18 Feb 2014 17:27:50 -0500, Mike Myers wrote: I am trying to xmit a couple of files from a z/OS system and then receive them on a different system. There is no connection between these systems except an intervening notebook. The process I have used is: 1. xmit the file to myself on the source system 2. use SDSF's output queue to see the xmitted file I would first suggest using TRANSMIT's OUTDATASET option to bypass the spool. With Unix System Services, you can get a checksum to verify with (from memory, untested): cp -b //'data.set.name' /dev/fd/1 | cksum 3. use the XDC command to create a dataset from the output file (I see that the xmit files created on the CBT tape are RECFM=F and LRECL-80, so the dataset I create fron XDC is given these properties) 4. transfer the data set to my PC from the source system as binary using my 3270 emulator's transfer file screen 5. transfer the file from my PC to the target system as binary using my 3270 emulator's transfer file screen Again, generate and compare a cksum. 6. receive the created data set on the target system and get the message:* INMR921I* *Received* *file* *appears* *not* *to* *be* *an* *Interactive* *Data* *Transmission* *Facility* *file.* *The* *first* *record* *is: Using the INDATASET() option of RECEIVE? *If the CBT tape can transfer files in this manner, it must be manageable, but I must have missed something. What am I missing? I'm more familiar with, and prefer FTP to 3270 emulator transfer. But that may not be available to you. I believe that Cygwin can verify the checksum on the PC waystation. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Xmitting file between disconnected systems
On Tue, 18 Feb 2014 22:42:56 +, Mike Walter wrote: On z/OS the XMIT/TRANSMIT command creates files in NETDATA format (on z/VM the commands is SENDFILE). The first record is easily identifiable as NETDATA format as it always begins with: \INMR01 For more detailed info, Google: IBM netdata format To read the file on a non-IBM system you'll need to be able to deblock the NETDATA records. Hmmm. Mike M. didn't make this perfectly clear. Does different mean non-z/OS? I assumed otherwise. Does disconnected mean FTP is unavailable? There must be some connection. But not TCP/IP? -Original Message- From:f Mike Myers Sent: Tuesday, February 18, 2014 16:28 Subject: Xmitting file between disconnected systems I am trying to xmit a couple of files from a z/OS system and then receive them on a different system. There is no connection between these systems except an intervening notebook. The process I have used is: ... 4. transfer the data set to my PC from the source system as binary using my 3270 emulator's transfer file screen I did verify the syntax of the cksum command with: User@MVS:131$ _UNIX03= cp -B //'SYS1.MACLIB(SPLEVEL)' /dev/fd/1 | cksum 3684370417 29440 (I did not try the TRANSMIT command. Users slightly less weird than I may omit the UNIX03=.) I used x3270 file transfer (ugh!) to transmit the file in binary to a PC, and replicated the checksum with Cygwin cksum. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Xmitting file between disconnected systems
On Tue, 18 Feb 2014 16:58:01 -0600, Mike Schwab wrote: I would TRS PACK the XMIT file, FTP it to target, then TRS UNPACK the file, and receive. Why? If you really want to have fun, TRS PACK the XMIT file; compress the PACKed file; use jar to create a .zip archive; FTP that to the target system; use jar to unzip it; uncompress it, then use TRS UNPACK, then receive. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Xmitting file between disconnected systems
On 2014-02-19, at 01:22, Hunkeler, Peter wrote: I would TRS PACK the XMIT file, FTP it to target, then TRS UNPACK the file, and receive. Why? Because of the size of the XMTI file? Apart from that it doesn't help much since also the tersed file needs to be copied to the target system where it must be received into an FB1024 dataset. A valid concern, but no help and perhaps a distraction when the OP was struggling with data corruption during the transfer process. I did however use TERSE instead of XMIT ... instead of as opposed to in addition to is proper. Adding TRANSMIT adds overhead fields and increases the size of the TERSEd file and CPU time used. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: assembler
On Wed, 19 Feb 2014 12:51:33 +, DASDBILL2 wrote: Since virtual storage is now so much less expensive and so much more available than storage [1] was 50 years ago, why not be really extravagant and use one whole byte per store? If the byte contains 0, then the store number is not valid, or something like that, and if the byte contains anything other than 0, then the store number is valid. This should result in much simpler code to access this table. Locality of reference. [1] In those days, there was no virtual or real storage available on IBM's mainframes. There was only storage. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
On Tue, 18 Feb 2014 18:39:42 -0500, Shmuel Metz (Seymour J.) wrote: at 01:47 PM, Tony Harminc t...@harminc.net said: Indeed this is the way conditional execution and branching works (and has always worked) in channel programs. No. Every generation believes that it invented sex, ... ObQoheleth? Further, every religion believes that it invented sex, holds the patent, and prohibits its use without expressed consent and according to firm rules. Reminds me of IBM's management of specialty engines on the zSeries. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: assembler
On Wed, 19 Feb 2014 17:29:17 -0500, John Gilmore wrote: Curtis G Pew wrote: begin extract I think one of the folks involved in Solaris zfs (not to be confused with OMVS zFS) calculated that the entropy generated by a full 128-bit address space would result in enough heat to boil all the oceans on earth. So I believe 128 bits is enough for a long time. /end extract and I am puzzled. Is this entropy the entropy of thermodynamics or information theory? The quantity having the dimensions J/K, Joules per Kelvin? I'd be tempted to start here: http://en.wikipedia.org/wiki/Holographic_principle#Limit_on_information_density Which I don't understand at all. But Wikipedia Is Always Right. And follow the link to Bekenstein Bound: ... It implies that the information of a physical system, or the information necessary to perfectly describe that system, must be finite if the region of space and the energy is finite. ... So you need either a bigger storage warehouse or a hotter storage warehouse. And if you try to make your storage system too small, the necessary mass-energy will suck it into a black hole. 128 is much bits. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check whether job still running
On Tue, 30 Apr 2013 23:25:40 -0400, Robert A. Rosenberg wrote: This solution does not fly. JOB2 will sit there and waste an initiator until JOB1 (which is long running) ends. How much does an initiator cost? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Linear search vs. Binary search
On Wed, 1 May 2013 07:51:50 -0400, John Gilmore wrote: The UPT (UPdate Tree) instruction inserts a new node in a tree conditionally. If it does not find an existing node having a nominated key in a [sub]tree, it inserts a new node into that [sub]tree at a location that, while not inappropriate, can be suboptimal. It is thus useful for maintaining a dynamic tree, e.g., a compiler's 'symbol table', but not for many of the validating uses---Is this search argument a supported keyword? and the like---of search operations. It also has the severe limitation that even in AMODE(64) a node---both key AND chaining information---is only a quadword in size. Ah! We need UPTG. And the corresponding search function. And we need it to be serialized against concurrent updates (is it?) Would token services be a better choice? I believe it is serialized. Is it 64-bit exploitive? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check whether job still running
On 2013-05-01, at 10:32, Ed Jaffe wrote: On 5/1/2013 8:43 AM, Ed Jaffe wrote: On 5/1/2013 8:24 AM, Ed Gould wrote: I am somewhat surprised that you indicate that duplicate jobnames are to be allowed. I have worked in a few shops that job naming stand is frozen and it would wreek havoc if a duplicate jobname were to be allowed running at the same time. Not sure what to say. This long-standing customer requirement was implemented in JES2 over six years ago. Wow! Time flies when you're getting old. ;) Research suggests this feature was introduced to JES2 in OS/390 V2R6 ca. 1998! And Ed G. didn't read the announcements, SHARE proceedings or DOC holds. A scheduler can be seen as a sort of outboard hypervisor. If it's programmable, I don't see why it shouldn't be able to support, even as a one-off a program such as: Run JOB A wait for completion Run JOB B ... Again, as John M. notes, this much more natural in UNIX where there's no artificial distinction between jobs and other kinds of processes. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mixing C and assembler - under OpenMVS
On 2013-05-01, at 10:42, Steve Comstock wrote: 2. The z/OS UNIX Command Reference doc points out that 'cc' command is fully supported for compatibility with older UNIX systems. However, it is recommended that the c89 command be used instead Or, perhaps c99. About which that document says: C99 c99 -- Compile C source code, link-edit and create an executable file See xlc. There's also a c11 Standard out there somewhere. So many choices. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT Implications of changing the 'HOSTNAME' statement in TCPIP.DATA
On 2013-05-01, at 10:11, Staller, Allan wrote: Your Doman Name Service (DNS) should be able to overcome this difficulty. A DNS translates an name (e.g. HOSTNAME) to an IP address (e.g. 192.168.81.99) or vice versa. This problem most often arises because of acquisitions, reorganizations, recombinations, in which case preserving the old domain name may not be an option. If you are not changing the IP address, as long as the original name is known to the DNS, the connection should be successful. Which feels backward. Domain names are supposed to be stable; IP addresses relatively volatile. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check whether job still running
On Wed, 1 May 2013 19:20:36 +, DASDBILL2 wrote: Duplicate jobnames are allowed or not allowed at the discretion of the customer. There is now a parameter to allow duplicate jobnames' running simultaneously. Those shops that do not want havoc can opt not to use the new parameter. All shops are not identical. FSVO customer. Better this should be JOB statement option at the discretion of the individual programmer, with only the default selected by the installation. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check whether job still running
On Thu, 2 May 2013 10:14:04 -0500, Ed Gould wrote: R.S. That would mean that the scheduler had its own security and letting applications near production. No, not its own security. RACF. Then the finger pointing would start and never end. No Thanks. Look. If you let people submit jobs outside the scheduler, then there's enough security and the scheduler needs no more. You don't let people submit jobs outside the scheduler, then everyone submits jobs through the scheduler, and the needed mechanisms must exist. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate job names (Was: Check whether job still running)
On Thu, 2 May 2013 17:22:51 -0400, John Gilmore wrote: Some shops have even institutionalized practices that produce duplicate jobname values. I know of one that long required development programmers who used the submit command to use their TSOIDs as the name of every job they All because they haven't yet grasped the concept of OWNER. submitted. I suggested that it would be helpful to these programmers if they could suffix a single character to that jobname to help them to distinguish such jobs from each other; and they were then grudgingly permitted to do so; not all of them, however, make use of this freedom. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OE Historical article re: Mainframes
On Fri, 3 May 2013 21:13:56 -0500, J. Leslie Turriff wrote: On 2013-05-03 18:24:07 Phil Smith wrote: http://www.tomshardware.com/picturestory/508-mainframe-computer-history.html I didn't realize that Eniac was that big... 49-ft high cabinets! Wow! And: Also, in a backward step from the ABC computer, the ENIAC worked with decimal and not binary numbers. We're still stepping backwards. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SAS Deserting the MF?
On Sat, 4 May 2013 21:53:08 -0400, Anne Lynn Wheeler wrote: ... http://www.garlic.com/~lynn/2013f.html#57 The cloud is killing traditional hardware and software ... ... is killing traditional ... is a paraphrase of progress. In the 1950s you might have heard The electronic computer is killing traditional punched card tabulators. Or in the 1960s The transistor is killing traditional vacuum tube computers. This is unpleasant only to those overly invested in the obsolescent technologies. And not all such technological prognostications become reality. Magnetic bubbles. Cryogenic computers. Quantum computers. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
On Tue, 7 May 2013 13:34:07 -0400, Gerhard Postpischil wrote: On 5/7/2013 5:02 AM, Lizette Koehler wrote: The only way I can think of restricting is an exit in JES2. Or if this is a TSO User you may wish to look at IKJEFT10 exit. You'd be surprised how many secure installations permit a TSO user to allocate an internal reader and write a job to it. Why is that a problem? Control resources, not tools. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
On Tue, 7 May 2013 17:50:32 -0400, Ed Finnell wrote: Yeah, we had a bright VMer said he could run circles around ISPF with XEDIT macros. Well maybe after six thousand job submissions. Had to retool him pretty good How was he submitting the jobs? NJE? FTP? Other (specify)? But are you arguing that bad response/throughput of ISPF/TSO SUBMIT is a merit? One reason to employ alternatives to ISPF/TSO SUBMIT is the restrictions is imposes on RECFM and LRECL. (It's documented that NJE has similar restrictions.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
On Wed, 8 May 2013 10:33:46 -0400, Gerhard Postpischil wrote: On 5/8/2013 8:37 AM, Walt Farrell wrote: I'm not sure why Gerhard thinks that is a security problem, gil. But certainy if users push jobs through the INTRDR directly (as opposed to via TSO/E SUBMIT or ISPF SUB) then you can't depend on any restrictions imposed by IKJEFF10; you would have to use JES or SMF exits. I never said that I consider it a security problem, only that I installed software at sites that did. No idea what their auditors or management are concerned about. Ah! Job security! Walt suggests that it's pretty hard to stop them. How did you (or they) do it? I suppose if TSO SUBMIT operates in authorized state one could hack allocation to restrict INTRDR to authorized programs. Does ISPF SUBMIT invoke TSO SUBMIT in authorized state? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
On Wed, 8 May 2013 08:37:12 -0700, Ed Jaffe wrote: They might have simply put their 'control's in the wrong exits (TSO) and were too lazy to refit them into the (JES and SMF) exits where they belonged. A plausible motivation is that they want all jobs submitted via their scheduler. On Tue, 7 May 2013 13:34:07 -0400, Gerhard Postpischil wrote: I once installed a package at a hush-hush installation (program needed configuration data, then submitted assembly/link jobs) and was told it wouldn't work because they prohibited TSO job submission. They were surprised when my jobs started running. Next time I talked to them, they had modified JES2 so that internal reader allocation went to class B (punch) instead! Does the class matter? If I allocate: //SYSUT2 DD SYSOUT=(B,INTRDR) ... will the job not run? Will the punch writer contend with INTRDR? (You mean they had a punch?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
On Wed, 8 May 2013 11:08:36 -0500, Mark Zelden wrote: On Wed, 8 May 2013 10:55:37 -0500, Paul Gilmartin wrote: Does the class matter? If I allocate: //SYSUT2 DD SYSOUT=(B,INTRDR) ... will the job not run? Will the punch writer contend with INTRDR? (You mean they had a punch?) It will run. The B is the MSGCLASS if one is not specified on the JOBCARD. And the SYSPRINT piles up in the punch queue. If the submitters didn't specify a SYSOUT class. I think I'm seeing som whimsy in Gerhard's anecdote. Does the SYSOUT class on INTRDR override the class(es) in: // OUTPUT JESDS=ALL,... if MSGCLASS is not specified? (I suspect not.) I know that for some early JCL errors OUTPUT is not processed, but MSGCLASS is respected. I need to try to see how the class on INTRDR plays in this game. What class (if any) does TSO SUBMIT supply when it allocates INTRDR? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
On Wed, 8 May 2013 12:10:36 -0500, Mark Zelden wrote: What is this, MVS 101? :-) There's an aphorism I haven't used here in a while. I'll let readers guess. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Return codes
On Wed, 8 May 2013 14:41:28 -0400, Gerhard Postpischil wrote: While I prefer the branch table conjecture, I have a number of programs that use a three-way branch (e.g., CH R15,=H'8') to save, what in the good old days was expensive storage. As for range checking, my all-time favorite is CL (e.g., CL R15,=F'16' / BH) that catches both negative and excessive values. But does not catch values that are not multiples of 4. I suppose it's slightly more plausible that a future extension introduce RC=20 than that it introduce RC=3. IBM has complicated matters, starting with BPAM macros, by adding more return codes. I would have preferred the old 0,4,8,12 paradigm, with R0 set to a reason code. And ISRSUPC SRCHFOR returns RC=0 if the target is not found; RC=1 if the target is found. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Duplicate Batch Job
On Wed, 8 May 2013 22:40:13 -0400, John Gilmore wrote: ... 2) interdict, or anyway attempt to interdict, any practice that is judged to be anomalous. In some cases when someone has espoused a practice or point of view that you judge to be anomalous, you characterize him as an intelligent Martian. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examing Setting Return Codes in a CLIST/MACRO
On Sat, 11 May 2013 17:09:19 -0400, Dave Salt wrote: The edit session ends with CANCEL, which means no changes were saved, which means ISPF sets the return code of the macro to 4. If you want to end with a different return code, you can hard code it like this: EXIT CODE(0) Or set it using this as an example: ISREDIT CHANGE 'XXX' 'V0' ALL SET EXITCODE = LASTCC do more stuff EXIT CODE(EXITCODE) It appears to be the OP's intent to make changes; submit a job, and exit the edit session without saving those changes. Apparently he considers this normal operation, and prefers a zero return code. Does your suggestion leave the file unchanged, end the edit session with RC=0, and not leave the user in a terminal edit session? (When I wish to be reminded not to save changes, I use View rather than Edit. But I don't put the SUBMIT and CANCEL in my macro because I want to inspect the job before SUBMITting.) Date: Sat, 11 May 2013 19:44:12 + From: essteam ... ISREDIT CHANGE 'XXX' 'V0' ALL ISREDIT SUB ISREDIT CAN EXIT -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: Business politics and software development
On Sun, 12 May 2013 18:55:05 -0500, J. Leslie Turriff wrote: Sorry; I should have marked that Off-Topic. This is an interesting exposition on the subject. I suppose that this is unavoidable in any business that produces large software systems. http://blog.zorinaq.com/?e=74 I have a question on a technique. How does publishing a SHA-1 checksum of a system file authenticate the author as having access to the source code? But he probably knows what he's doing, and I'm relatively naive: http://xkcd.com/1181/ ... looks fine to me. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Business politics and software development
On Mon, 13 May 2013 10:46:45 -0400, John Gilmore wrote: The work of Rufus Isaacs on aircraft-collision avoidance, which I have mentioned here before, is highly instructive. He found that the only safe collision-avoidance strategies for aircraft A in an air space also occupied by aircrafts B, C, D, . . . were based upon the assumption they were hellbent on colliding suicidally with it. The John Madden / Isaac Asimov corollary: If any of B, C, D, has a higher maximum airspeed and higher operational ceiling than A, there is no safe strategy for A. This weekend, for the first time in a very long time, I looked at a stream of problem reports for a compiler. (It was a C compiler, but that is not important.) What struck me about them was that most of those that involved syntactically constructs reflected 'bizarre' uses of the language that would not occur to anyone who was proficient in it. Plus those that would occur only to someone who was proficient in it. (Or is that what you meant to say?) The only way to cope with such deficiencies is to generate syntactically correct constructs, however absurd, mechanically/programmatically for testing. Here, as elsewhere, malice and ignorance are often very difficult to disentangle. Fuzz testing. Black Team. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Co:z SFTP and Public/Private Key Authentication
On Mon, 13 May 2013 15:15:06 -0500, Kirk Wolf wrote: Agreed - it would be nice if TSO OMVS had a solution for masking passwords, but it doesn't. Long ago, before SSL was available, I went to PMR with this. I even used the magic word, security. I reported it as a problem with stty -echo, and said that I thought the root cause was in tcsetattr(). Guess what? IBM patched stty -echo and left tcsetattr() broken. They may have made a collateral comment that I should be using getpass() instead. In the mean time, it is silly to completely disable the ssh client under TSO OMVS - it would suffice to simply disable password-interactive mode under the Ported Tools ssh client if a tty that doesn't support masking is detected. agreed. BTW - I always use an ssh telnet shell under z/OS rather than TSO OMVS, which is brain-dead by comparison ( IMO :-) What!? Have you no respect for the many decades of rich tradition behind the 3270? And scant appreciation for ISPF and OEDIT and OBROWSE? What do your peers think? Can you not at least use an editor that emulates the behavior of ISPF? You seem to be as much a masochist as John M. VM VTAM allows a session to wait concurrently for terminal output and for keyboard input. Porting that technology to TSO OMVS would eliminate the need for the infuriating RUNNING/INPUT toggle and elevate TSO OMVS from brain-dead to merely comatose. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HOST feature or understand a sentence
On Wed, 15 May 2013 06:00:44 -0500, John McKown wrote: According to IBM, you cannot get a z/OS license for a Hercules based machine. It has been asked for by many, for a hobbyist environment. Perhaps more like WINE than like Hercules. You don't need z/OS to run applications; only interface compatibility. Another emulator is Boch. It is an x86 emulator. As I recall, one person used this to run Windows, slowly, on an old pre-z machine. It would be interesting, to me, to have somebody do this on a zEC12 running full speed. I don't know if Windows can be licensed on this configuration, or not. I believe there was a short thread on IBMVM LISTSERV about a week ago, started by a vendor who's about to release such a product commercially, offering a demo with a Linux x86 guest OS installed. We'll see. Business case? If you have spare cycles on the z (And who hasnt? as Letterman says) you might as well use them. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On Wed, 15 May 2013 06:54:01 -0400, John Gilmore wrote: Earlier this week, on another list, I encountered someone who was proposing to use STCK TOD values in a new system. Circa 1987, in a design meeting I advocated reserving a 4-digit field for a date. I was sneered at because the TIME macro wouldn't support it. He should of course have chosen STCKE values instead. At 23:58:43 on 17 September 2042 the IBM mainframe TOD clock, 64-bit STCK value will +/- leap seconds. IAT? UTC? UT1? ... overflow. STCKE values do not have this defect; the portions of them that are incremented are unsigned 14-byte, 8 x 14 = 112-bit values; and 2^112 - 1 is an adequately large number. They should have made it signed. Year 1899 seems to me to have more practical use than 19,000. The slogan Do not reinvent the wheel sounds virtuous, at worst innocuous. In fact its use is an all but infallible indicator of sanctimony mixed with sloth. I once heard, Don't reinvent the flat tire. (The topic was the VM/CMS Shared File System.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On Thu, 16 May 2013 09:36:55 +0300, Binyamin Dissen wrote: While questionably STCKE will be better than STCK (depending on the use), the correct solution is to use some kind of unbiased value with an optional displacement. True, STCK(E) is easier, but it not a good value to be hardened for long term use. One MUST plan for the future. Any fixed-length representation can theoretically encounter limits of range or precison or both. Among fixed-length representations, STCKE is 49% good: it bears an affine relationship to TAI and has sufficient precision for practical uses, and sufficient range for practical uses in the present and future, but not in the past. If I were to consider a representation of unlimited range and precision, I'd first think of an XML representation of TAI in decimal display, but beware of buffer overflows. What would you consider unbiased? On Wed, 15 May 2013 11:06:02 -0400, John Gilmore wrote: TOD clocks, incremented counters in general, are by definition unsigned. Moreover, with the exception of some few astronomical ones, we do not know the times of past events, even quite recent ones with precision. Few indeed. In Classical times the offset can be hours, with considerable uncertainty. the elephant in the room: http://en.wikipedia.org/wiki/%CE%94T On Wed, 15 May 2013 11:27:47 -0500, John McKown wrote: Rather than being signed, IBM _could_ move the epoch back. ... What is the etiology of this irrational dread of negative numbers? Must clock values be deemed cardinal numbers? I had thought that considering the STCKE value as signed would introduce no incompatibilities; it still seems the most likely to be compatible. But an IBM employee (and others?) have said here that this would be incompatible with existing use. What? I can only imagine setting the Clock Comparator Register to all ones for an interval that is unlikely to expire between IPLs. (Are there nowadays both 64-bit and 112-bit Clock Comparator registers? Are there any GUPI interfaces to the 64-bit Comparator that must be preserved?) --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On Thu, 16 May 2013 11:23:08 -0400, John Gilmore wrote: ... of STCK[E] values: It is usable 'against the past' only after midnight 1899 December 31. The question whether it is GMT, UTC, or LOCAL misses the point. It is none of these. It is best thought of as a coarse-grained TIA-like value. No 'leap values' have been or should properly be applied to it. Its conversion into TUC, GD, or JD values does involve applying [different] leap values, but this is straightforward both for leap years and leap seconds. If it's straightforward, why doesn't STCKCONV do it, or at least state in documentation that it doesn't. The table of offsets is readily availabli in P[0r]Op, so IBM knows the information. It is also possible, indeed easy, to devise an STCKE-based signed timestamp. To do so, one needs to sacrifice the high-order bit, which will in any cased be unset for about 18,000 years. Times before midnight 1899 December 31 can then be represented in the usual way as twos-complement values. That's two votes,. But IBM has stated that would introduce incompatibilities, but hasn't been more specific. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Business politics and software development
On Fri, 17 May 2013 07:24:48 -0700, Lloyd Fuller wrote: You have to look at where C was originally designed to run. It was designed for the DEC PDP8. Those were SMALL in resources machines. Later versions of C were built on the PDP11s, but Richie and crew started out on the PDP8. And, yes, C was designed to be a middle-level language. Wikipedia tends to confirm my recollection of PDP-7: http://en.wikipedia.org/wiki/C_%28programming_language%29#History ... not quite as restrictive as PDP-8. Hmmm... IIRC, PDP-7 was ones-complement word-addressed machine (18-bit words). I wonder when C acquired its dependency on 2's complement and addressing storage by characters? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XMIT Manager
On Fri, 17 May 2013 10:43:43 -0400, Farley, Peter x23353 wrote: There was a person who offered to re-package the XMIT software in a more current installer a few years back, but IIRC when he contacted the author he could not get permission to do so. I do not believe that the original author is interested in any update of the software, but I am willing to be proven wrong. No source is available, as far as I know. There is/was an analogue called unXMIT, written in Java, perhaps available from SourceForge. I tried it a few years ago and deemed it Not Ready for Prime Time. I don't know what has happened since. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Hold Output in SDSF
On Sat, 18 May 2013 03:39:05 -0500, Elardus Engelbrecht wrote: I like to use ST screen so I can see all elements of a job/stc/tso. One line per address space. You want to see more lines per Address Space, use ? against it. ST is also handy where I absolutely want to see ALL elements of a job even when something has been purged on H/O screen. Alas, I believe ST does not show SYSOUT from UNIX processes. (I understand the (E)JES analogue overcomes this defect.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rather interesting article on hacking the mainframe using ftp
On Sat, 18 May 2013 15:17:22 -0500, John McKown wrote: http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two basically the person must be able to ftp into a UNIX subdirectory and to submit a job. They upload a program called netcat into a data set starting with their RACF id. They then submit a job which copies the data set into the /tmp subdirectory with a random name, chmod the name to be executable, then executes does starts the netcat in the background (asynchronous to the batch job) and piping to/from the z/OS UNIX shell. The hacker simply connects to the port that netcat is listening on, and presto, they have a shell on their desktop. And the batch job may be submitted via FTP; the hacker needn't have a TSO session. And it's pretty obvious that FTP submit doesn't use TSO SUBMIT internally, so it's fairly likely that the TSO exits won't be entered. I was surprised when the z/OS FTP server gained the ability to deal with named pipes -- that feels risky. I wonder who required it. Named pipes on client -- not so bad. Years ago in one of these fora I suggested that xterm might be used as this article suggests netcat. That would put the server (X11) on the desktop and the client on the z -- no need to listen on a port. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XMIT Manager
On Sat, 18 May 2013 11:57:35 -0700, William Smith wrote: If you are having issues with the CBT implementation of XMIT manager on a 64-bit machine, I suggest you look into UnXmit on SourceForge.� It's open source and runs just fine on Windows 7 x64.� Truly, well done and documented nicely by the author. Here's a link to the application's home page:� http://unxmit.sourceforge.net/p1.htm I believe it's Java. How portable is it? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Hex Long Floating Point REXX
On Sun, 19 May 2013 13:24:49 +, Robert AH Prins wrote: On 2013-05-19 09:40, Uwe Oswald wrote: Hi @ll, has someone ever tried to extract fields SMF30DDS and SMF30DDR (long floating point hex) or any field in REXX? There are a couple of F2something routines out there but it seems that none of them produce the right value. Has somebody a REXX example for me? Anything would be very appreciated since it might bring me further. This code coming from Michel Castelein Jim Connelly might be of some use ... Eek! Clearly the author's brain was rotted by excessive exposure to Assembler programming. Why not simply: /* This REXX exec computes a S/370 floating-point's value ... e.g. X'C128' represents -2.5 */ castelein: parse arg Float numeric digits ( length( Float ) % 0.4 ) /* 1 / log( 256 ) */ parse var Float Hexponent 2 Mantissa sign = 1 - c2d( Hexponent ) % 128 * 2 Hexponent = c2d( bitand( Hexponent, '7F'x ) ) - 64 Hexponent = Hexponent - 2 * length( Mantissa ) Dec = sign * 16 ** Hexponent * c2d( Mantissa ) say c2x( Float ) Dec return( Dec ) The problem of decimal to HFP is a nightmare, relatively. I'd be tempted to use iteration to find a root of the HFP to decimal function. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rather interesting article on hacking the mainframe using ftp
On Sun, 19 May 2013 18:21:38 -0400, Scott Ford wrote: I agree you need a RACF ID and password an of course a list of permits. Which as was pointed that batch submission can be prevented by the permits no being there. Secondly, I find an article of this type irresponsible. irresponsible because it contains misinformation or incomplete information, or because it contains information you feel only you are entitled to know? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On Mon, 20 May 2013 17:25:38 +0200, Thomas Berg wrote: As I described at the ISPF-L list, this didn't work. And that's because ISPF uses an userid.ISPn.SPFTEMPn.WORK file just for file tailoring into a preallocated ISPFILE ddname. But it worked with preallocating the ISPWRKn and/or ISPCTLn files. (The created JCL was 173000 lines, most of them control cards to utilities.) There's a real need for an enhancement to SUBMIT to accept a DDNAME as input as an alternative to a DSN. This might even be an allocated POSIX pipe, eliminating the need for a preallocated work file. And its RECFM=FB, LRECL=80 restriction should be eliminated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On 2013-05-20, at 09:59, Thomas Berg wrote: Windows make work until the disk is full. And that is what we want! Someone is apt to point out that behavior is better suited to a single-user desktop system than to a multi-user enterprise system. And on Windows the constraint is your local disk. Unless you use a Samba-mounted filesystem. I'll restate my wish for an input DDNAME option to SUBMIT. Even if not a pipe, it might be an allocated UNIX file. z/OS UNIX with its private HOME filesystems approximates the Windows desktop behavior: you use what you want until it's all gone and you don't bother other users. Historians tell me that part of the motivation for JES was to shed the constraints of allocation parameters. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
On Mon, 20 May 2013 13:45:46 -0500, Mike Schwab wrote: Our section uses and IEBGENER proc to SYSOUT=(A,,INTRDR) and works just fine. I have an EDIT macro that does very similar. _And_ it allocates the INTRDR with attributes of the data set being submitted; it doesn't quietly truncate my data to 80 columns. --On Mon, 20 May 2013 21:39:01 +0200, Thomas Berg wrote: 3. We have always done like this, therefore it must be good. http://www.thealders.net/humour/work/wk49.html Yes, there is the presumed overallocation with release solution. But many (if not most) allocations don't work with release at allocation. In most cases this causes waste of space and still x37's. And z/OS UNIX cp command allocates its output data set with RLSE, then opens it several times. The first time it writes no data, guaranteeing an x37 shortly thereafter. IBM took an APAR. First they suggested secondary extents, then they agreed to provide a NORLSE option, with RLSE remaining the default, just to be inconsistent with almost all MVS allocation. cp() generates the RLSE TU only if the programmer specifies SPACE. Go figger. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rather interesting article on hacking the mainframe using ftp
On Tue, 21 May 2013 00:03:00 -0400, Thomas Kern wrote: On 05/20/2013 11:21 AM, Shmuel Metz (Seymour J.) wrote: at 03:17 PM, John McKown said: http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two Control the resources, not the tools. There are easier ways to get a shell on your desktop if you're allowed to submit jobs. Where is the security breach? The security breach is in HR for hiring someone who would do this to their own system, their own company, their own country. What breach!? A poorly informed hack writer in a posting to a blog (the paradigm of responsibly peer-reviewed media) carelessly referred to a routine (but fairly uncommon) procedure as a hack. Through the magic of rumor, mostly in these lists, this has escalated to a threat to national security. Give us a freaking break! (I truly hope I'm overlooking some intended sarcasm.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
