Re: Does a DD-Statement waste memory after dealloc?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Michael Knigge Sent: Friday, October 09, 2009 3:34 AM To: IBM-MAIN@bama.ua.edu Subject: Does a DD-Statement waste memory after dealloc? All, I currently try to find a obscure memory leak in one of our applications. After some days our appl occupies ~17.000 pages of real memory (needs just ~1.500 after startup). As we track all malloc(), calloc(), realloc() and free() function calls, I can say that there is no obvious memory leak Now... after I've looked at the JESYSMSG I've noticed that we've done approx 17.000 DYNALLOCs, everyone with a different DD-Name (we let the z/OS generate a unique one, like SYS1, SYS2, SYS3 and so on). to be clear: *NOT* ~17.000 at the same time. mostly only one at the same time... Of couse, we deallocate them after we've finished using the DD-Name, but I wonder that even after a DEALLOC (with SVC99) there is some space still occupied Why? Because of performance? Because of some kind of control block that can only grow but not shrink? SNIPPAGE We have found two things in this area. Both are involved in LSQA. One has to do with ACEE (and associated storage) and the other is the dynamic allocation. We also used DYNAMNBR on EXEC statements (see JCL REF). You may find that this alleviates some of the storage creep. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Calulators or Computers? (Was: Outsourcing your Computer Center to IBM ?)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Eric Chevalier Sent: Tuesday, October 13, 2009 3:47 PM To: IBM-MAIN@bama.ua.edu Subject: Calulators or Computers? (Was: Outsourcing your Computer Center to IBM ?) On 13 Oct 2009 07:30:14 -0700, efinnel...@aol.com (Ed Finnell) wrote: Anyway in this day and age TI or HP calculators can do most of the preflight calculations... It's not quite that simple. Sure, your TI or HP probably could perform the calculations, but they don't integrate very well with the rest of the system. Once you've figured out your basic payload and center of gravity, now you need to order fuel. How much fuel? You don't want too much, since excess fuel travels at air freight rates. Obviously the outputs from weight balance become input to your fuel calculations. But fuel requirements are also also a function of weather along the route. So you'd also like to tap into the weather forecasting system as inputs to the fuel system. SNIP Enter the spreadsheet on a laptop. Seems us GA pilots do this. And then the AOPA online flight planner w/ weather. Now, take it's idea of how long you will be in the air given the weather, add the required reserve and put that into the weight and balance. H, over weight. Tell the family that they have to ship their knapsacks and lunch can't come with us. Clear prop and start engines Regards, Steve Thompson -- Opinions expressed by poster probably do not reflect those of the rest of aviation or poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Ownership of PC routines---what I will do
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dave Day Sent: Tuesday, September 29, 2009 11:26 AM To: IBM-MAIN@bama.ua.edu Subject: Ownership of PC routines---what I will do Has been an interesting discussion. What I originally wanted to do was = to establish a PC routine once, the 1st time my started task came up = after an IPL. The same routine could be used by multiple copies of the = started task, if the user decided they wanted to or needed to operate = with more than one copy. Examination of the control blocks that = establish and document the PC function in a running z/OS system seems to = imply some mechanism to establish ownership of a PC by another address = space. For instance, PCAUTH owns LX value 00. The MVS diagnosis = manual contains a table that describes all the PC's that can be entered = using that LX. To me, they do not all logically fit there. I would = have thought MASTER for some of them. So, I will have each started task establish at initialization and tear = down at termination the same routine. Will wind up with two or more = copies of the same code, but will satisfy the requirements of the = operating system, and keep things 'according to hoyle'. SNIP Did you think about a subsystem? It can have an INIT routine (used when the system comes up), and then it can end. IIRC, these will then be owned by the master subsystem (ASCB 1), and available to all address spaces. Your PC routines would then be in the system for the life of the IPL... Just a thought from other days (back in the MVS/SP4/5 days). Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Long parms ... again (was: Reading DD card information)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: Wednesday, September 23, 2009 10:07 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Long parms ... again (was: Reading DD card information) SNIP You are missing the point. The APF program was written to the spec that the parameter will never be more than 100 characters, and it was enforced by JCL. SNIP What about the principle that you do not use KEY0 or SUPSTATE when it is not needed? The PARM info that is passed is not in FETCH protected storage. Therefore, you should not have to be in KEY0 to use that storage. Granted, if you have set things via the PPT, you probably set up this particular APF program wrong all the way around. So is the program written incorrectly -- should it start out in KEYUSER (8) and then as needed switch to KEY0? Should it start in SUPSTATE and do SPKA to KEY0 when needed, otherwise be in some other key? So, when doing a storage move, it is upon the program to ensure that it does not overflow the receiving area (especially true for APF programs). Regards, Steve Thompson -- Opinions expressed by this poster may not reflect poster's employer's opinions -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Long parms ... again (was: Reading DD card information)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: Wednesday, September 23, 2009 10:36 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Long parms ... again (was: Reading DD card information) On Wed, 23 Sep 2009 11:28:05 -0400 Thompson, Steve steve_thomp...@stercomm.com wrote: :-Original Message- :From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On :Behalf Of Binyamin Dissen :Sent: Wednesday, September 23, 2009 10:07 AM :To: IBM-MAIN@bama.ua.edu :Subject: Re: Long parms ... again (was: Reading DD card information) :You are missing the point. :The APF program was written to the spec that the parameter will never be :more :than 100 characters, and it was enforced by JCL. :SNIP :What about the principle that you do not use KEY0 or SUPSTATE when it is :not needed? :The PARM info that is passed is not in FETCH protected storage. :Therefore, you should not have to be in KEY0 to use that storage. Irrelevant. :Granted, if you have set things via the PPT, you probably set up this :particular APF program wrong all the way around. So is the program :written incorrectly -- should it start out in KEYUSER (8) and then as :needed switch to KEY0? Ditto. :Should it start in SUPSTATE and do SPKA to KEY0 when needed, otherwise :be in some other key? Ditto. :So, when doing a storage move, it is upon the program to ensure that it :does not overflow the receiving area (especially true for APF programs). All this is irrelevant, as the program was written according to documented API. You want to change the API without ensuring that the program will be changed to support the new API. SNIP Binyamin: Might I suggest that you are being a bit myopic? Or perhaps suffering from tunnel vision? APF programs are to be written to a higher standard. From what you have written, you believe that if someone passes an APF program you have written, an invalid parm, that program should accept that as gospel and go clobber some part of the address space (say the JSCB, or change the ASCBSENV, etc.) and give the caller authorities they should not have, right? Regards, Steve Thompson -- Opinions expressed by this poster do not necessarily reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Long parms ... again (was: Reading DD card information)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Craddock Sent: Wednesday, September 23, 2009 11:30 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Long parms ... again (was: Reading DD card information) On Wed, Sep 23, 2009 at 10:59 AM, Thompson, Steve steve_thomp...@stercomm.com wrote: Might I suggest that you are being a bit myopic? Or perhaps suffering from tunnel vision? APF programs are to be written to a higher standard. From what you have written, you believe that if someone passes an APF program you have written, an invalid parm, that program should accept that as gospel and go clobber some part of the address space (say the JSCB, or change the ASCBSENV, etc.) and give the caller authorities they should not have, right? I think you're missing the point entirely Steve. This has nothing to do with APF or non-APF and nothing at all to do with abstract program A calling theoretical program B. The consequences for an APF program are potentially more serious, but the problem is the same. Back before the flood the PARM interface was explicitly limited to 100 bytes. So a valid program written to that specification could legally pick up the length and mindlessly move that many bytes from the parameter data into another pre-allocated (or dynamically allocated) 100 byte area knowing full well there was no chance of overflow because the OS guaranteed (then) that the actual length would never be greater than 100. SNIP Not at all. The thing I was responding to was the APF side of things and inappropriate behavior by an APF program being handed a too long JCL PARM based R1. By definition, the area pointed to by R1 is not fetch protected. So an APF program doesn't have to resort to KEY0 to read the parm area. Now, from that perspective, I think what I originally said relative to PARM and APF programs should make more sense. As for the typical non-APF program and handling the JCL PARM based R1 upon entry, I don't even want to go there because of all the different ways that can be coded between, RPG, FORTRAN, COBOL, PL/1, etc. ad naseum. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Long parms ... again (was: Reading DD card information)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick O'Keefe Sent: Tuesday, September 22, 2009 2:36 PM To: IBM-MAIN@bama.ua.edu Subject: Long parms ... again (was: Reading DD card information) SNIPPAGE Whatever technique used to pass a long parm is not going to be safely handled byt the old, standard parm passing scheme because a long parm passed that way will break old, standard programs. Some new technique that can be verified by new programs is needed or a lot of stable production jobs are going to die. I know some people see that as hobbling z/OS with severe limitations of the S/360 past, but I see maintaining compatability as a source of the great stability of z/OS and its ancestors. Thee is an obvious need for lifting the 100-byte limit on parms, but it needs to be done in a way that allows old programs to continue to work. SNIP VBG Now how did they implement that // OPTION again in DOS? /VBG Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 33 Years In IT/Security/Audit
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Umamaheshwar Iyer Sent: Wednesday, September 16, 2009 7:48 AM To: IBM-MAIN@bama.ua.edu Subject: Re: 33 Years In IT/Security/Audit I started mine on a WANG-VS which was user friendly. After the demise of this wonderful machine, I got a chance working on the Mainframe, which was quite tough when working from a user friendly system to a non-user friendly system. Almost 25 Years now! Any idea if WANG is still lurking within the computing world? SNIPPAGE Dr. Wang is no longer with us. And the company, WANG, was taken over by another company and they basically dropped the hardware. Some years ago I was bidding on migrating WANG/VS based entities to z/OS. I understand that there are still a few holdouts in the Government arena. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is there any concern when added real memory from 5G to 7G
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hal Merritt Sent: Wednesday, September 16, 2009 12:12 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Is there any concern when added real memory from 5G to 7G Apples and oranges. The only meaningful relationship between real memory and virtual memory is the paging rates. Of course, if your system paging rates are zero, you might consider allowing various applications to allocate more virtual storage which might have an impact on your auxiliary storage allocations. CSA and SQA are not relevant to this context. ECSA and ESQA should have been sized using other criteria. SNIP I'd been thinking about this. Wouldn't the ESQA increase in size to track the increased number of page frames (needed by RSM)? This would push ECSA a bit higher (address floor is what I refer to here, not size). HSA will get moved. And it might increase in size (I don't know how IBM handles tracking of storage for LPARs -- I knew how this worked on Amdahl 5990-A machines once upon a time). But other than those things, I can't think of any thing else that gets changed. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [turnkey-mvs] turnkey mvs and cobol/jcl environment
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Andreas F. Geissbuehler Sent: Saturday, September 12, 2009 9:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [turnkey-mvs] turnkey mvs and cobol/jcl environment SNIP I second Jo on this and URGE YOU to continue with herc and MVS 3.8j, even Assembler 370, but forget COBOL. You need to master current, modern COBOL which you can accomplish short-term by visiting Prof. Don Higgin's website at www.z390.org. Don's Java-based zASM and zCOBOL at www.zcobol.org are modern, state-of-the-art implementation which I recomend you should evaluate and consider to use, instead of, in addition to and/or in combination with TK3. SNIP Assuming he is running a M/S product, he can probably get one of the COBOL books with a COBOL CD in it. Fujitsu's COBOL runs nicely on NT, and W2K (with a few tweeks). I haven't tried it under XP. The use of the FCOBOL under MVS3.8 or the equivalent under DOS (R34?), will teach COBOL basics. The PC based compilers will take that source (at least the Fujitsu one will) and produce working code under Winders. So the question is, where did OS/2 and a M/F compatible COBOL go? Why do people use Realia (do they still exist?) to do COBOL development on a PC and then upload the source to a M/F? [Same for the Fujitsu system.] It is because of IBM Marketing's view of the world. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: NEON zPrime Business, Legal and Technical Facts Webinar
Seems that Eloqua is Firefox unfriendly, so this link can only be read from a computer system running Windows and IE. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ken Porowski Sent: Thursday, September 10, 2009 3:26 PM To: IBM-MAIN@bama.ua.edu Subject: NEON zPrime Business, Legal and Technical Facts Webinar I guess IBM's letter generated some FUD http://now.eloqua.com/e/es.aspx?s=3D1331e=3D328elq=3Dafd32854d7c047509 a= 3a5e1 65b96bd5a -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dumb Question - Credit Card Number Scanner
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Doc Farmer Sent: Tuesday, September 01, 2009 8:05 AM To: IBM-MAIN@bama.ua.edu Subject: Dumb Question - Credit Card Number Scanner Okay, this one came to me yesterday. Somebody asked me if there were a way to search all files on a mainframe for credit card number information (you know, the 16-digit jobs) for a PCI audit. I know, I know, it could be 16 Alphanumeric, 16 Numeric, 9 Packed Decimal, or 8 Binary. I also know it would require searching EVERY file, and would probably need to use test card numbers in order to determine if they really exist. However, for some reason they want to know if a scanner is available. I'm figuring this could be done with ISPF's SuperC, or with CA-Easytrieve or CA-PanAudit, but if anybody knows of a PCI scanner for z/OS, I'd appreciate some names/links. Many thanks. snip Check out grep (*nix command). It will probably have to be run under Unix Systems Services (OMVS). It will not be pretty, it will take a long time (wall and CPU). And even then, you will get false positives because not every 16 digit number is a credit card number (could be an account number, or just the result of some calculation). Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ist663i suppression
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Mason Sent: Monday, August 31, 2009 8:21 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ist663i suppression SNIPPAGE You may or may not be familiar with the English expression, using a sledgehammer to crack a nut but here I present you with an apposite application! SNIPPAGE So this is to an ESL (English as a Second Language) poster, and you imply that you are using a walnut to crack a sledgehammer? Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catering for ESLs (was Re: ist663i suppression)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Mason Sent: Monday, August 31, 2009 1:29 PM To: IBM-MAIN@bama.ua.edu Subject: Catering for ESLs (was Re: ist663i suppression) Steve Well, I had hoped it was clear that a simple, surgical MODIFY command (or start option) constituted a nutcracker and that assembly and linkage editing of what must be one humongous set of assembler macros, representing as it does the totality of VTAM commands and messages, could legitimately be considered a wrecking ball in comparison, much less a sledgehammer. But each to his own opinion. SNIPPAGE again You may or may not be familiar with the English expression, using a sledgehammer to crack a nut but here I present you with an apposite application! SNIPPAGE So this is to an ESL (English as a Second Language) poster, and you imply that you are using a walnut to crack a sledgehammer? Regards, Steve Thompson SNIP Well, here we are again with a 50 cent word, apposite, which when looked at by an ESL person, may have been taken as opposite having been misspelled. My wife speaks German. I speak a very small bite of German (not correct but a literal for how I would say I speak a little German in Deutsch). She attempted to say something for me at my level and realized that she had used the wrong form of to hear. I thought she was telling me that what I heard belonged here. In context, it kinda made sense (I can hear a certain poster in Germany having a very good laugh right about now). So, this was a long explanation of how I read what you posted, thinking in as simplistic terms as I could for someone who is both not fluent in English and having a huge vocabulary. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Test Posting, please ignore
Duly ignored. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Anthony Fletcher Sent: Friday, August 28, 2009 5:37 AM To: IBM-MAIN@bama.ua.edu Subject: Test Posting, please ignore Test only -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Counter
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Friday, August 21, 2009 7:37 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ISPF Counter On Fri, 21 Aug 2009 06:56:07 -0400, Dave Salt wrote: The only way you could get the time to keep refreshing is if you keep pressing an interrupt key to manually keep refreshing the panel, or display the panel in LOCK mode (so it automatically keeps refreshing itself). But if the panel is displayed in LOCK mode this means a user can't enter any data; i.e. the entire mainframe session is locked. I doubt this is what you want, so in short, you're stuck with it working the way you already have it. That's *so* twentieth century! Since the advocates often argue that mainframes are more economical than small systems, why is this feature readily available on desktops, but not on mainframes where it should be cheaper? There's one ISPF function (I forget which) that lately shows a progress bar. It's a continual source of irritation that I can't put SCSV in auto-refresh and go edit a file in the other split. It's a continual source of irritation that I can't split between OMVS and Edit, for example. Why does DDLIST show the message, Searching data sets not on screen rather than scrolling so they appear? Why does Find in a large file pause each time after a fixed number of lines and prompt for continuing rather than displaying a progress counter and letting the user interrupt? I believe that nowadays much of the duplex interaction would be possible with modern 3270s. VTAM is much the culprit for prohibiting it. Why is horizontal scrolling so much more difficult than vertical scrolling in ISPF? Did I say it's all *so* twentieth century? SNIP Why is the sky blue? Why is water wet? Why do the birds go on singing [Sorry, it is Friday, on a long hard week] Regards, Steve Thompson -- Opinions expressed by this poster do not reflect those of poster's employer in all probability -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Counter
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Friday, August 21, 2009 8:35 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ISPF Counter On Fri, 21 Aug 2009 09:21:46 -0400, Thompson, Steve wrote: Why is the sky blue? Why is water wet? Why do the birds go on singing Apparently, according to your metaphor, IBM's design decisions, good or bad, modern or obsolete, are tantamount to laws of nature. But in some places we've done too thorough a job of silencing the birds and turning the sky yellowish-brown. SNIPPAGE No, the first two are answers to grandchildren who ask why after every answer. The last is from a song. It is a lament about someone's life now that their love interest has left them. Similar to mainframes. Here we are hammering on why 3270 behaves the way it does. But as I asked a former client of mine, did anyone ever ask if their mainframe COULD do GUI? [Did IBM ever think about 5250 support under VTAM or some such?] Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: The Death of Servers and Software
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Timothy Sipples Sent: Tuesday, August 18, 2009 6:14 PM To: IBM-MAIN@bama.ua.edu Subject: The Death of Servers and Software Hewlett-Packard reported its 3Q earnings earlier today: http://h30261.www3.hp.com/phoenix.zhtml?c=3D71087p=3Dirol-newsArticle= ID=3D1322129 A few highlights: 1. Industry standard server revenues are down 21% (quarter, year to year). And it's not a single quarterly fluke: revenues are also down ov= er 24% (nine months, year to year). These are the Intel/AMD X86 servers. Clearly this means that X86 servers are dead. And because they are industry standard, that obviously means the entire standard server industry is dead. 2. Non-industry standard server ... oh, sorry... Business critical server revenues are down over 30% (quarter, year to year). And it's no= t a single quarterly fluke: revenues are also down over 25% (nine months, y= ear to year). These are almost all Intel Itanium-based servers running HP/U= X (UNIX) plus a few NonStop Kernel (NSK) servers. Clearly this means that= distributed UNIX and NSK servers are even more dead. 3. HP doesn't break out profit (earnings from operations) separately = for these two units, but for the overall Enterprise Storage and Servers division, profits were down 34.5% (quarter, year to year) and a whoppin= g 46% (nine months, year to year). Clearly since the profit is declining = even faster than sales, HP server RD investment is really, really dead. Whi= ch fits, actually: there hasn't been a new Itanium CPU sincewhen was t= hat again? (Anybody remember?) 4. Perhaps services and software will help fill the gap? HP doesn't actually produce too much software, and anyway that business was down t= oo (22% for the quarter, year to year; 15% for the nine months, year to ye= ar). So obviously software is dead. The EDS acquisition makes services comparisons hard for now, so more time is needed before deciding that's= dead. SNIP I guess this means I should throw out my laptop, file server, etc. at home as well. Long live COBOL. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Multi-file tape
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Saturday, August 15, 2009 11:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Multi-file tape SNIPPAGE Thanks. Easy enough. An off-list communication described this: MOUNT [devaddr],vol=(sl,volser) Does sl stand for Standard Label Is BLP likewise supported? SNIP Two different issues are raised by your questions. MOUNT defines the type of labels that the volume has. The following are supported (as of z/OS 1.7): SL is standard label AL is ASCII/ANSI label NL is NON-Labeled When you access the volume, you may then override the label information (such as with BLP). However, if you change the first three records on the tape (if you specified AL or SL) life may become interesting. Also, if you are using AL and you make a mistake with your AL label from within your program, the volume will be dismounted, (OPEN thinks it has the authority to change the UCB bits and effectively cause an UNLOAD!). Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM halves mainframe Linux engine prices
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant Sent: Monday, August 17, 2009 3:54 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM halves mainframe Linux engine prices On Mon, 17 Aug 2009 14:24:56 -0600, Mark Post wrote: SNIP He also said, Linux is not an operating system. SNIP Could he identify malware masquerading as an O/S? Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Multi-file tape
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Friday, August 14, 2009 4:44 PM
To: IBM-MAIN@bama.ua.edu
Subject: Multi-file tape
This worked OK on a virtual tape. Now I must make
it work on a physical tape. My EXEC says:
do File = 0 + 1 to 99
File = right( File, 3, 0 )
say
say ' File' File '='
InDD = 'F'File
DynArg =( 'alloc dd('InDD') dsn(''TAPE.FILE'File''')' ,
'expdt(98000) recfm(U) blksize(32760)' ,
'label(BLP) position('File')' ,
'unit(AB2)' VolArg 'shr reuse' )
address 'TSO' DynArg
if RC0 then leave File
RC = ProcessFile() /* FREEs InDD */
if RC0 then leave File; end File
To my utter dismay, it dismounts the tape after each file
and I must re-mount it.
What's the ALLOCATE analogue of RETAIN?
This takes longer each time.
Do I need to code a DD statement in JCL with RETAIN for
each file?
Should I count my blessings because auto ops is at least
replying to the VSN messages.
Long ago, a colleague caused a tape volume to be mounted,
even across job boundaries. This is outside my operator's
and my current skill set. Is that an alternative?
SNIP
Yes.
MOUNT [devaddr],vol=(sl,volser)
Where devaddr is the device address to hold the tape
volser is the actual Volume Serial of the tape
I believe that this will work on an ATL -- although some others may not
like it much (particularly if you only have two heads and the system is
rather busy).
Regards,
Steve Thompson
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Satisfaction surveys (Was: The Shame Approach)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick O'Keefe Sent: Thursday, August 13, 2009 1:41 PM To: IBM-MAIN@bama.ua.edu Subject: IBM Satisfaction surveys (Was: The Shame Approach) snippage [Patrick O'Keefe Kicks open the door] The one thing that was apparently missing in the survey process was a way to provide feedback on the survey itself. The last question was something like Would you recommend IBM Service to others?. Why yes; I tell all my friends and relatives to use IBM service. What kind of a question is that?!? (Stupid, THAT's what's what kind!)That question has been part of the survey for years, and I'm sure I'm ot the only one to complain. SNIPPAGE The last two surveys that I've gotten, I have made it appoint to ask the survey opinion taker one question: And just where will I go for maint support for mainframe stuff, Microsoft? twenty-something valley girl voice Like, we actually have a choice. \twenty-something valley girl voice Now, back to my testing a new release of some IBM code Regards, Steve Thompson -- Poster's opinion may not reflect poster's employer's opinion(s) -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concatenations and blocksizes
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick O'Keefe Sent: Monday, August 10, 2009 4:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Concatenations and blocksizes On Mon, 10 Aug 2009 15:20:53 -0500, Mark Zelden mark.zel...@zurichna.com wrote: ... CONCATENATION ENHANCEMENT: Like-attribute concatenation will be allowed for eligible data sets with different block sizes in any order; the largest no longer need be first. Eligible data sets are partitioned or sequential data sets that are DASD-resident, accessed by QSAM, and for which the system obtained buffer space. ... Interesting wording. partitioned ... data sets ... accessed by QSAM ... If they really meant that, wouldn't that restrict this enhancement to a concatenation sequential datasets and/or PDS members? Doesn't a PDS or concatenation of PDSs have to be accessed by BPAM? SNIP No. If you take a program that uses a QSAM DCB and point the DD statement to a PDS with member name, it will read that member and treat it as if it were reading a DSORG=PS data set. The QSAM code will detect end of member and treat that as if it were EOD (and I think it even drives your EOV exit if you have one). So if you concatenate a series of DSORG=PS data sets together, you can't concatenate a PDS as a PDS in the middle. Well, maybe you can, if you forced RECFM=U and BUFL=32760. But enjoy the dir blocks followed by ALL the data blocks (as gas or still in use). OTOH, if you concatenate PDSs together as PDS and then stick in a DSORG=PS I would imagine you will get a very interesting ABEND when the FIND or BLDL that you do doesn't find any directory blocks in the DSORG=PS file (you might even get an early ABEND out of OPEN - I haven't tried this trick in a while). Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DASD: to share or not to share
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of McKown, John Sent: Thursday, August 06, 2009 1:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: DASD: to share or not to share SNIPPAGE It is VSAM Record Level Sharing (not Locking). SNIP Within CICS it is Record Level Locking (or at least it was). It appears that they changed that with CICS/TS v2 (?). Meanwhile, I've not kept up with all the VSAM changes and options as it applies to batch with CICS (I know that you have to do specific things to get the commit and all to work the same). Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USS misuse (was Re: Mainframe hacking)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Friday, August 07, 2009 4:12 PM To: IBM-MAIN@bama.ua.edu Subject: Re: USS misuse (was Re: Mainframe hacking) Ted Even IBM used USS ... Sadly, some IBMers are as careless as some list participants. I DON'T think it's carelessness!n - Too busy driving to stop for gas! SNIPPAGE It either is, or they are at best, not competent (here is where I have to explain this: Not competent does not imply you can't be only that you need some training, Incompetent means you may have been but now definitely aren't). It is also a problem that some time after 1991, the IBM internal standards were apparently discarded (apparently with management blessing). There were specific naming standards, specific requirements for program directories (and their very specific formatting), etc. Even the keywords to be used for ETR/PMR and APAR/PTF are being sluffed, which is making it difficult to find HIPERs at times. A recent example: any one *directly* affected by the recent double writes within TCPIP. If you had searched using INCORROUT you came up empty. Yet that is what was happening - In Correct Output. This is but one formerly STANDARD keyword. The rules are changing w/o equivalent buy in or announcement of the changes. Rather like the non-mainframe platforms, the Whatever boxen (example of the Whatever is given by Shania Twain in That Don't Impress me). Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DASD: to share or not to share
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Rowe Sent: Thursday, August 06, 2009 12:44 PM To: IBM-MAIN@bama.ua.edu Subject: Re: DASD: to share or not to share I think the real question here is: Why don't you have a SYSPLEX? There is = little to no cost involved, and many benefits. Frank Swarbrick frank.swarbr...@efirstbank.com 8/6/2009 12:15 PM SNIPPAGE We're slowly coming to this realization. We don't have a Sysplex, and shar= ing PDSE's, while it works somewhat, doesn't work that great. My personal = libraries are PDSEs and if I am logged on to both PROD and DEV at the same = time I have to make sure I am not trying to edit members in the same PDSE i= n both environments. Blech. I thought PDSEs were the future? SNIPPAGE If you set this up correctly, you will get Record Level Locking for VSAM which will give you some benefits that you lost in moving from VSE. It is something to think about, if you are heavily using VSAM with onlines and batch. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DASD: to share or not to share
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Thursday, August 06, 2009 1:01 PM To: IBM-MAIN@bama.ua.edu Subject: Re: DASD: to share or not to share On 8/6/2009 at 11:47 AM, in message 45d79eacefba9b428e3d400e924d36b902557...@iwdubcormsg007.sci.local, Thompson, Steve steve_thomp...@stercomm.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Rowe Sent: Thursday, August 06, 2009 12:44 PM To: IBM-MAIN@bama.ua.edu Subject: Re: DASD: to share or not to share I think the real question here is: Why don't you have a SYSPLEX? There is = little to no cost involved, and many benefits. SNIPPAGE to a prior post by Steve Thompson If you set this up correctly, you will get Record Level Locking for VSAM which will give you some benefits that you lost in moving from VSE. It is something to think about, if you are heavily using VSAM with onlines and batch. Can you explain this a bit more? I will admit to not even knowing how this works on VSE. SNIPPAGE Within DOS/VS-VSE the buffers are handled by DOS for an image. So you get to better share VSAM between Partitions (as in a VSE partition) than you can between z/OS Address Spaces. This allows, as I recall (it has been several years since I've done any VSE-VSAM work on a VSE system), more than one partition to have an ACB open to output to a file (share options that are NOT available on MVS if you compare your VSE IDCAMS against z/OS IDCAMS doc). With RLL (Record Level Locking), you can now have batch and onlines updating VSAM files at the same time. This goes a step beyond what VSE allowed, giving you certain performance boosts that were lost in going to z/OS where buffers are controlled within an address space as opposed to within an instance of VSE (image). Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DASD: to share or not to share
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Wednesday, August 05, 2009 12:40 PM To: IBM-MAIN@bama.ua.edu Subject: DASD: to share or not to share As part of our migration to z/OS from z/VSE we have started a discussion on what DASD, if any, should be shared between our production z/OS LPAR and our development z/OS LPAR. For what it's worth, on VSE here is what we have right now... SNIPPAGE Theoretically I can see this possibility, but is it really a concern? What do others do for: 1) System executables 2) System parameter libraries 3) Applications executables 4) Application data I should note that this is not the case of an uneducated manager trying to make technical decisions. But he is from the distributed systems world, and even though he's worked here for 15+ years, much of that as CIO over both distributed and mainframe systems, he still has a bit of a distributed systems mindset. In that world they don't share system or application data at all (or very little). But to me that doesn't mean that it's wrong in the mainframe world. Thoughts? SNIPPAGE First: Stop thinking VSE and its catalog system. Second: You have a security system (well, I would think you are running one, and probably RACF). Allow the system to put data sets where the system wants/needs based on esoterics and SMS. Let the security system control who can access which data set and if that is read, write, destroy, update, control, twist, fold, spindle or mutilate. Put into LNKLST what needs to be in LNKLST. Define to VLF what needs to be defined there. Now, system executables will be determined by IPL and the PARMS used for that IPL (so if you change o/s levels, and the like...). Application executables and application data should be more or less under the control of the applications people. Production should be under control of production control (or whatever you call that function), and systems stuff should be under the control of the systems programmers. BECAUSE mainframes are not BUS CENTRIC (those open platforms seem to have this characteristic), there should not be problems with executables being shared between systems. After all, once LPA is loaded, you aren't going to read the base libraries until you IPL again. It is in Central Memory or it is on a non-shared PAGE data set. Think of LNKLST elements in roughly the same way thanks to LLA and VLF. Again, stop thinking VSE and tell your CIO to stop thinking 10,000 chickens trying to deliver the mail. Regards, Steve Thompson -- Opinions expressed by this poster do not necessarily reflect those held by the poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ziip api for vendors
However, I was unable to find this on the US PTO site. That makes me think that this is filed in the area that is not available for publication for some months (I forgot the legally mandated number). So, it appears to not be viewable by the public at this point. Regards, Steve Thompson -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Monday, August 03, 2009 8:36 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ziip api for vendors Agreed on both points. The purpose of the web site it is establish a stake-in-the-ground about what you know and when you know it ... specifically for IP rights. SNIPPAGE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Utility for EBCDIC to ASCII conversion
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of esst...@juno.com Sent: Thursday, July 30, 2009 8:23 AM To: IBM-MAIN@bama.ua.edu Subject: Mainframe Utility for EBCDIC to ASCII conversion This may have been discussed before, Is anyone aware of an IBM utility that converst an EBCDIC file to ASCII ? Any IEB*** utilities ? snippage Yes, you can use IEBGENER. I've done similar things in years gone by to prepare for processing tapes from a WANG System (WANG systems use Pack Decimal, but are otherwise ASCII): //COPY EXEC PGM=IEBGENER //SYSINDD DUMMY //SYSUT1 DD DSN=ebcdic.based.dsn.here,DISP=SHR //SYSUT2 DD DSN=ascii.based.dsn.here, // DISP=(NEW,CATLG), // DCB=OPTCD=Q, // UNIT=CART //SYSPRINT DD SYSOUT=* Note that the tape label will be changed to AL. However, if you have BLP authority, you can build the label as SL, and then with this as a subsequent step, do LABEL=(2,BLP). Expect the reading program to have a problem with not having trailer labels. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: USS misuse (was Re: Mainframe hacking)
Deep breath you need. Archive search you might. The picture and last laugh came from one who had been rebuffed for pointing out the confusion caused by using USS instead of OE or OMVS, or some such. Regards, Steve Thompson -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Mason Sent: Monday, July 27, 2009 4:51 AM To: IBM-MAIN@bama.ua.edu Subject: USS misuse (was Re: Mainframe hacking) How ridiculous to propose that this is some sort of competition! And if it was so to be presented, the VTAM component would win by about two decades. Given that Howard Rifkind, supported by Jim Horne and Bruno Sugliani, jumped immediately to the incorrect interpretation of USS, that Ivan Warren denied the correct interpretation of USS and that Mary Anne Matyaz felt she had to apologise for the correct interpretation of USS, correct use of USS is a matter of *respect* for fellow list users. This unnecessary misunderstanding, compounded by denial and apology, has demonstrated that insistence on the correct use of USS is far from pedantry. What further nonsense is meant by last laugh and interesting picture I have no idea - perhaps the writer didn't checking the wind direction ... Perhaps considering listiquette before posting is to be recommended. As long as I am attacked on this point, I will repel with equal vigour. Chris Mason On Tue, 21 Jul 2009 14:33:15 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, July 21, 2009 11:19 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking SNIPPAGE The interpretation Howard, Jim and Bruno arrived at is, of course, total nonsense, caused solely because this persistent misuse of an abbreviation for UNIX System Services. So much so that USS can even be denied its proper interpretation!!! Chris Mason SNIPPAGE Unix System Services vs. VTAM and USS. Pedantic. Last laugh. Interesting picture here. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Operator Validation before Executing Command
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bott, Steven Sent: Monday, July 27, 2009 4:38 PM To: IBM-MAIN@bama.ua.edu Subject: Operator Validation before Executing Command We recently experienced an outage due to an operator command being=0D=0Aexe= cuted on the wrong LPAR because the operator neglected to include the=0D=0A= RO portion of the command=2E The command being executed was F=0D=0ABPXOINI= T,SHUTDOWN=3DFORKINIT=2E Now Management would like all destructive=0D=0Aco= mmands to have a WTOR which the operator would be asked Do you really=0D= =0Awant to execute this command and provide the opportunity to reply NO= =0D=0Ato abort the command=2E IBM recommends using the MVS Commands=0D=0AI= nstallation Exit and the =2ECMD in MPFLST=2E Has anyone tried using that= =0D=0Aexit in this fashion? Would you care to share your pain or pleasure?= =0D=0AHas anyone found a better solution to this problem? Thanks for shari= ng=0D=0Ayour experience=2E=0D=0A=0D=0A =0D=0A=0D=0ARegards,=0D=0A=0D=0AStev= en Bott=0D=0A=0D=0ASr=2E Systems Administrator=0D=0A=0D=0ACSX=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A SNIPPAGE For destructive commands, you can intercept them with automation. If they are formatted correctly (such as a *required* RO or ** -- you pick the characters), then automation does not cancel them. If they are not formatted the way you require, you cancel the command and put out a message to that console about the command not being _ as is required (formatted, issued with all the parameters, etc.). As has been pointed out, (Robert Heinlein) It is impossible to make anything foolproof, because fools are so ingenious. So, make the command issuer do things the right way. It takes a bit of programming in the AO product, but it will handle what needs to be done better. A suggestion in this area: Use Site specific commands to do certain things. Then have the AO product issue the real command. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Offload work to zIIP with zPRIME
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Anthony Giorgio Sent: Thursday, July 23, 2009 3:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Offload work to zIIP with zPRIME Hal Merritt wrote: Old days? Still very much so today here in the US. It is called 'off road' diesel, and, except for the color and tax, it's exactly the same fuel. Or so I'm told. Don't know the price difference but I'd suspect it's substantial. As the penalties for using it for inappropriately. I've heard stories of inspectors going to county fairs and checking the color of the diesel in the fuel tanks of pickup trucks. If you're caught using the off-road diesel, the penalties are rather severe. SNIPPAGE Wanna have some fun? Pour a quart of Dextron II (ATF) in your 50 Gal Diesel tank. In Ohio that's the same color as off-road diesel. The reason I was given for doing such a thing is that ATF will actually clean your injectors. Beats me if that is true, but it seems to burn OK (I didn't do it, I saw someone doing it). Oh, and in the places that I've seen that sell off-road diesel, it costs more than the highway diesel. Still scratching my head on that one (at the time I was operating both types of equipment). Later, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, July 21, 2009 11:19 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking SNIPPAGE The interpretation Howard, Jim and Bruno arrived at is, of course, total nonsense, caused solely because this persistent misuse of an abbreviation for UNIX System Services. So much so that USS can even be denied its proper interpretation!!! Chris Mason SNIPPAGE Unix System Services vs. VTAM and USS. Pedantic. Last laugh. Interesting picture here. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Article Mainframe Stolen
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Arthur Gutowski Sent: Friday, July 17, 2009 7:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Article Mainframe Stolen On Thu, 16 Jul 2009 15:19:08 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Schwarz, Barry A There is no more worse than worst. SNIP So does that mean that wurst is chopped liver? So, then, is the knock better, or is the wurst best? (Sorry, it's Friday, and I couldn't resist.) SNIP Or is Liver worst? (and on it goes for a Friday) Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LE options
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Friday, July 17, 2009 4:25 PM To: IBM-MAIN@bama.ua.edu Subject: LE options There appears to be (at least) two ways to change LE runtime options system wide. There's the assember macro table way (CEEDOPT for batch and CEECOPT for CICS) and there's the PARMLIB(CEEPRM00) way. Is one preferred over the other? Does one offer something the other does not? I am thinking that the PARMLIB way allows for multiple systems to share the same LE libraries and still have different LE options, if desired. Is this the reason for is its existence? If we use the PARMLIB way is there anything that has to be done with the macros and can't be done with the PARMLIB? SNIP Be aware of the differences in the defaults from release to release. You may find that behaviors change for not so obvious reasons, all because of depending on a default setting that changes. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Gould Sent: Thursday, July 16, 2009 12:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM error messages getting worse? --- On Thu, 7/9/09, Patrick O'Keefe patrick.oke...@wamu.net wrote: From: Patrick O'Keefe patrick.oke...@wamu.net Subject: Re: IBM error messages getting worse? To: IBM-MAIN@bama.ua.edu Date: Thursday, July 9, 2009, 2:29 PM On Thu, 9 Jul 2009 08:21:22 -0400, David Andrews=20 d...@lists.duda.com wrote: I think you make a very good point.=A0 There have always been absolutely inscrutable MVS messages and there will probably be new ones.=A0 But there are many prefectly clear ones, too, and there is that message id you can look up, run searches on, submit RCFs on (if those still exist ... and are read), or even open PMRs on=20 if they are so bad as to be considered a defect.=A0 I don't think it is=20 getting worse. Pat O'Keefe=A0=20 - Pat:I am not sure I agree , but I think that most USS messages are at best = inscrutable. Take TCP as an example most of the messages I had to look up a= t the time did not follow the IBM convention as to importance (W,I,E,C) and= then they didn't set the condition code to match the message. The conditio= n code IMO was the worse and it looked to me like they threw the dice when = it came to setting codes. Frankly I gave up and after reading the message i= n the manual 2 or 3 times and it still did not make sense I opened a PMR. I= very rarely got anyplace with the PMR as the USS people live in the own = universe separate from IBM. To me they decided to thumb their nose at the r= est of IBM and said we are going to operate as we like to hell with IBM and= their rules. I think the LE people weren't quite as bad, but they are up there. Do *NOT*= get me going on COBOL messages. Their so called self describing messages m= ust have been made up on a bad acid trip. In the past, say 1970 or so we can all agree that some messages like call = your systems programmer were nightmares especially at 3AM and there was no= IBM support to call back then.=A0 Since then (thanks to GUIDE anyway) we made the messages a MAJOR issue and = I can still remember 1 GUIDE where the pubs people came into GUIDE and prom= ised to do a better job. It actually did work, thank goodness. Messages act= ually started to mean something and they were reasonable english straightfo= rward and it might take you a bit to understand the famous VSAM messages th= at gave you a bunch of possibilities at an answer if you could discern if i= t was a FC or other type of RC or whatever. If you read it carefully enough= it did make sense (most of the time). That was about the time that (sorry = I do not remember the name of the IBM product) but IBM shipped you a search= able database every month or so and you could play with search args to find= something you couldn't make heads or tales out of. Of course now its IBMLI= NK (when it is up) and it functions the same and with reasonably more up to= date issues than the once a month tape shipment. The pubs people might have lost their way as it seems in the late 80's (esp= ecially with USS) components (I DO NOT MEAN UNFORMATTED SYSTEM SERVICES so = if anyone wants to get anal about the meaning I do not care. Ed=A0=A0=0A=0A=0A -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
Sorry, that reply was the result of a comedy of errors. Suffice to say that having multiple displays and M/S deciding that it will take focus... Well it resulted in the focus changing to Outlook with the mouse over the wrong SEND button (I had more than one reply screen up)... And my thoughts, relative to this thread, and in particular to what Mr. David Andrews brought out, I decided weren't necessary. Working for an ISV, being in PWD, having worked at IBM and thinking about how absolutely wonderful the BPX/OE world is and the associated highly descriptive and meaningful messages -- well, I decided to keep those comments and opinions to myself. Regards, Steve Thompson -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Mason Sent: Thursday, July 16, 2009 8:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM error messages getting worse? Steve I could say that IBM-MAIN posts were getting worse what with commenting before the quoted post(s) - much preferred by yours truly - or commenting after the quoted posts and maybe not having quoted lines preceded by greater than signs, it can be quite difficult to find the fresh text! Chris Mason SNIPPAGE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Article Mainframe Stolen
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Schwarz, Barry A Sent: Thursday, July 16, 2009 2:17 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Article Mainframe Stolen There is no more worse than worst. SNIP So does that mean that wurst is chopped liver? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Find the computer error
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Thursday, July 16, 2009 2:42 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Find the computer error Ted MacNEIL pisze: Well, my understanding is that American English uses terms a little differently than the-rest-of-the-world English. My understanding is opposite: Both Canada and the US uses a billion to mean a thousand million (giga -- 10^9), whereas Britain uses a billion to mean a million million (peta -- 10^12). And, I believe they (UK) are the only ones that use 10^12 as a billion. BTW, SI (the Metric System) also uses a billion as 10^9. I believe this is difference between U.S. and German meaning of terms. In German camp we use milion-miliard, bilion-biliard etc. pairs. In U.S. camp you don't know miliard, biliard, etc. Of course our system is definitely better than yours vbg snip Doch! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Submit a JCL from within another JCL
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Thursday, July 16, 2009 4:46 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Submit a JCL from within another JCL On Thu, 16 Jul 2009 14:17:38 +0200, CUNY Yann wrote: You can use IKJ : //REXX1EXEC PGM=IKJEFT1B //SYSTSIN DD * SUBMIT 'YOUR.PDS.JCL(JCL)' //SYSTSPRT DD SYSOUT=* Subject to the restriction that the source data set must have RECFM=F[B],LRECL=80. IEBGENER is more flexible. -- gil snip Except that the OP did say KSDS... IDCAMS can REPRO to the INTRDR. Later, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Article Mainframe Stolen
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, July 15, 2009 11:42 AM To: IBM-MAIN@bama.ua.edu Subject: Article Mainframe Stolen From the Palistine Herold in Palestine TX. This was repeated in the Enterprise e-Mag. Apparently when you steal the MAINFRAME the data is on it. Lizette SNIPPAGE From the college's website: No information stolen during weekend theft Monday, July 13, 2009 / We here at Trinity Valley Community College are saddened and angered by the events of this weekend's break-in at TVCC-Palestine. Information reported by area media outlets regarding this incident is in error. We want to assure our students that absolutely no student, personnel or other confidential information was contained on the computer stolen during the weekend theft. The terminal which was taken was wired only to the security surveillance system and was used specifically for surveillance video. TVCC takes all possible precautions to maintain the security and confidentiality of personal data. In the aftermath of this event, we are dedicated to recovering the stolen property. The college is working diligently with the Anderson County Sheriff's Office to apprehend those who are responsible for this incident. We are asking anyone who may have information on the theft to please contact the sheriff's department. Students should watch our website at www.tvcc.edu for more information as it develops. -- Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Find the computer error
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bob Woodside Sent: Wednesday, July 15, 2009 3:39 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Find the computer error On Wednesday 15 July 2009, Roach, Dennis (N-GHG) wrote: One too many digits for VISA. Account number + check digit? SNIPPAGE Seems like VISA has a problem. http://www.nbcdfw.com/around_town/shopping/Wow-Quadrillion-Dollar-Credit -Card-Bill.html?yhp=1 (watch the wrap). Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM-MAIN Digest - 10 Jul 2009 to 11 Jul 2009 (#2009-192)
Sent from my Dick Tracy Two-Way Wrist Radio. Nanny Nanny Boo Boo! -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Johnson, Larry W. Sent: Sunday, July 12, 2009 12:11 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM-MAIN Digest - 10 Jul 2009 to 11 Jul 2009 (#2009-192) Sent from my ATT Windows Mobile phone. SNIPPAGE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: AMBLIST Funny
-Original Message- snippage I had something to do with that. My concern is that system programs are usually reading that book at a time when they are dealing with the gravity of some problem, and may not be in a mood to appreciate its opposite, levity. snippage And we all know how humorless those systems programs are and how exacting to syntax they are;-) Now, Systems Programmers, on the other hand Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Planned IBMLink Outage July 10-11
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Clark Morris Sent: Wednesday, July 08, 2009 3:00 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Planned IBMLink Outage July 10-11 On 8 Jul 2009 10:01:22 -0700, in bit.listserv.ibm-main you wrote: Planned IBMLink Outage July 10-11 SNIPPAGE Haven't they heard about 24/7/365.25. If I wasn't semi-retired, I would be submitting a SHARE requirement and if rejected, I would seriously consider embarrassing publicity, say at an annual meeting of IBM. SNIPPAGE You do realize you are talking about ~7 years? Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question about REUS=NONE
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Michael Knigge Sent: Tuesday, July 07, 2009 5:13 AM To: IBM-MAIN@bama.ua.edu Subject: Question about REUS=NONE SNIPPAGE But I wonder how to migrate the ASM-Subs nearly painless I could rewrite all this ASM-Subs and use dynamic Saveareas but I wonder if just using REUS=NONE would do the same job... So bring it to a question: What is the scope of the REUS-Option? (Sub)Task-Level? Then using REUS=NONE would bring up a new copy of the ASM-Stubs for every Subtask - just what I need I don't care for the wasted memory because the ASM-Subs are mostly rather small (and well, today they are all statically linked together with some really big COBOL-Subs) SNIPPAGE FIRST: what I am about to say applies to the address space, not just to a specific subtask. The LOAD of a module affects the whole address space, not just a subtask. REUSE=NONE means that every time you issue LOAD you will get a new copy. So if you do multiple LOADs, you will get as many copies as you have issued LOAD for. This will result in BTL (Below The Line) storage creep because of the system control blocks that are built in LSQA, which means that you might take a short on storage ABEND if you are not also issuing DELETE for the module. IF you use REUSE, or RENT, AND the ASM stubs are actually ReENTrant, you MAY care if you are not also issuing DELETE, because only one copy will get loaded, but each subsequent LOAD will result in the use count being incremented by 1 (DELETE decrements by 1). When the count rolls over, you will ABEND. If you do LINK with REUSE or RENT and those stubs are not actually Reentrant (or effect serial reusability), results will probably be unpredictable -- the assumption being that the DSA within the program is YOUR DSA (your return registers), but meanwhile, your task has not been dispatched while another has, so that when you start dispatching again, where you return to... I hope this answers your questions. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Language Environment runtime options and system dumps
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Klein Sent: Wednesday, June 24, 2009 10:31 PM To: IBM-MAIN@bama.ua.edu Subject: Fw: Language Environment runtime options and system dumps I would check with any vendor as to whether this is still true (that they can't handle LE dumps). Current software should work with LE and should not need non-normal dumps. If your vendor requires something else, then ask THEM what LE options they expect to be in effect when the dump in THEIR product occurs. If they can't tell you, then I would refer them to one of the IBM 'vendor support teams. SNIP And I would refer you to another thread, And you ask why I hate OMVS. Maybe it is just me, but LE and BPX incantations seem to somehow be related. I see this as further breakage of the MVS subroutine call protocols. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another one bites the dust
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bob Shannon Sent: Wednesday, June 24, 2009 4:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Another one bites the dust snippage IBM used to give huge discounts to universities. About 15-20 or so years ago they did away with the discounts and universities started migrating off the mainframe. The few that are left mostly use mainframes for some type of administrative processing. The processing done by students is done on PCs or on eunuchs systems, where years ago the processing was done on mainframes. I don't think IBM failed to convince the university in question to stay on the mainframe; I think IBM abandoned the educational mainframe market a long time ago. snip I'm not sure, but I think there was some kind of consent decree or other as a result of an Anti-Trust action that put the skids to this. Now that all those have expired (I think), one might wonder when IBM will go for this market driver again. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
TCP Settings for KeepAlive
I've run into a problem where I have TN3270 sessions attached to a VTAM session manager. The problem is this: When the system, where the VTAM session manager is running, is at 100% for extended periods (5 minutes or more), AND, you have a TSO session on the system where the session manager is, AND that TSO session attempts to run a long running task (Endevor update to promote source is an example), the TSO session will continue to run, BUT the TN3270 session will be timed-out and dropped. In this case the TN3270 is QWS3270 Plus. In tracing this, we see that QWS is posted with a lost connection. However, QWS is running the TCP keep alive at about a 5 minute interval. And the last thing that QWS shows is it sent a buffer to the host and is now waiting for a response when it gets this lost connection posting. I have been looking at the z/OS Comm Server manuals (even searching them) and I don't see anything that needs to be changed in the configuration. I have looked at various APARs (particularly the ones about IMS and additional keepalive support from 1.7 and later). But I don't see anything that seems to apply. The other thing about this that is interesting, those running Hummingbird don't seem to have this drop problem. And this is something that I can recreate at will. Note: TSO is not timing out. This is specifically a TCP connection termination issue that is timing related. It takes the z/OS system (1.8) going to 100% busy for 5 minutes or longer. And, while this is happening, I can be directly connected to other MVS or VM systems and they are not affected. So anyone have any idea where I need to look in the config parms for TCP (or VTAM?). Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCP Settings for KeepAlive
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hal Merritt Sent: Thursday, June 18, 2009 10:20 AM To: IBM-MAIN@bama.ua.edu Subject: Re: TCP Settings for KeepAlive Hmmm.. almost sounds like QWS3270 may be getting impatient when waiting for a reply. That is, the 'keep alive' time may apply only to an idle session as opposed to a wait for reply situation. I'd look into QWS3270 parameters. SNIP QWS3270 is the one getting notified that the connection has dropped. In discussions with Jolly Giant, they will wait forever for the host to respond. Meanwhile, they will continue, at the prescribed intervals, to send the keepalive. Something, somehow is deciding on the host side to terminate the connection. And I just can't seem to find it. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCP Settings for KeepAlive
Yes, the common item to this problem is the Session manager. We were just discussing this among ourselves just a few minutes ago. If QWS is connected directly to the TSO APPLIDs (as opposed to going through the session manager first), then these timeouts do not happen. However, because of a few other things that were discussed, I am starting to think there is a problem with QWS. The problem is, proving what is the problem and how to solve it. Regards, Steve Thompson -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hal Merritt Sent: Thursday, June 18, 2009 11:25 AM To: IBM-MAIN@bama.ua.edu Subject: Re: TCP Settings for KeepAlive True: we are searching for what drive the lost session disconnect. But I would not limit my search to the host. Network appliances/firewalls can be configured to do things like this. What does not fit in this scenario is that other TN3270 clients are not having the problem. That would point back to QWS as being the unique factor in the equation. That said, we cannot assume that all are following the same network path (and thus chain of network appliances/firewalls). Another thought: Have you tried connecting directly to the host and bypassing the session manager? SNIPPAGE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REXX HI vs HE
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick O'Keefe Sent: Monday, June 15, 2009 12:37 PM To: IBM-MAIN@bama.ua.edu Subject: REXX HI vs HE SNIPPAGE This is a hare-brained idea, but I wonder if there could be something in my shop (my last 2 shops) that would prevent HI from working. SNIPPAGE I have the same problem, and I'm not using compiled REXX. However, we do have TRX installed. I have no idea if this is related to this particular problem, but I do know that when I am doing a lot of REXX and/or Panel work, I change my TSO logon to not use a proc that contains TRX (because it seems to cache the REXX and Panels that I'm changing). Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Language Environment runtime options and system dumps
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jim McAlpine Sent: Friday, June 12, 2009 10:05 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Language Environment runtime options and system dumps SNIPPAGE Interesting, but it doesn't really help except to confirm what the manual says which is the following. =F4=80=81=B9*(UAIMM)(UAIMM)System dump via original error (only for debug p= urposes), also TRAP(ON,NOSPIE)* But when I specify that option I get a system dump and a U4039 abend when what I want is the original S0C4 abend. Jim McAlpine SNIP You may be forced to use a SLIP. LE C/C++ causes me more heartburn than I'm allowed to express here. Regards, Steve Thompson -- Opinions expressed by this poster may not be in compliance with those of employee's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: First ipl of z/OS 1.9
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jim McAlpine Sent: Wednesday, June 10, 2009 11:12 AM To: IBM-MAIN@bama.ua.edu Subject: Re: First ipl of z/OS 1.9 On Wed, Jun 10, 2009 at 5:04 PM, Binyamin Dissen bdis...@dissensoftware.com wrote: No work wait. SNIPPAGE I can't. If I hit enter on the console, I get X CLOCK and the console input is inhibited. SNIP And if you hit the restart button or Extern Interrupt button, what happens? Not having used one of those systems, do you have a logical NIP console? And what does it show, if anything? Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Broken link on web ibmlink
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Monday, June 08, 2009 12:50 PM To: IBM-MAIN@bama.ua.edu Subject: Broken link on web ibmlink I wanted to make my futile objection to the end of the tn3270 access, but feedback in not 3270 anymore and: https://www-304.ibm.com/ibmlink/feedback/feedbackPage.jsp?lc=encc=US SNIP Just for fun, remove the -304 and see what happens. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXEC Above the Bar (Was Large Page Support)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of McKown, John Sent: Friday, June 05, 2009 5:36 PM To: IBM-MAIN@bama.ua.edu Subject: Re: EXEC Above the Bar (Was Large Page Support) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Friday, June 05, 2009 4:18 PM To: IBM-MAIN@bama.ua.edu Subject: Re: EXEC Above the Bar (Was Large Page Support) snip That one reply about the theological place of eternal damnation: isn't that rather like climbing the inside of a working blast furnace without getting your eyebrows singed? :-) -- Rick Know of ancient document which said that three guys did that! SNIP And they had a visitor while they were doing it that was brighter than the flames... -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why are z/OS people reluctant to use z/OS UNIX?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kelly Arrey Sent: Thursday, June 04, 2009 3:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Why are z/OS people reluctant to use z/OS UNIX? Also those of us who compile using the C/C++ compiler in USS need a lot of memory because the compiler is a memory hog when optimizing. It's no different when compiling using batch. Not to mention a cpu hog. It's true, our compiler can take up a lot of memory and cpu. We provide several choices of optimization levels, and a highly optimized application can use significantly less cpu than an unoptimized app. The IPA level of optimization, for example, does whole program optimization, which exposes many more optimization opportunities than optimizing one source file at a time. However, optimizing an entire program requires significantly more memory, and cpu. One of the ways we have tried to mitigate this is to move memory used by the IPA compile phase above the bar, i.e., into 64-bit virtual storage. Considering the number of times the application code will be executed in production, the cpu time invested in optimizing it can be time well spent. SNIP How much memory does the PL/1 (optimizing) compiler take? Are there any lessons that can be learned and applied? Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSE RPG question
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert A. Rosenberg Sent: Monday, June 01, 2009 7:54 PM To: IBM-MAIN@bama.ua.edu Subject: Re: VSE RPG question At 09:35 -0400 on 06/01/2009, Thompson, Steve wrote about Re: VSE RPG question: SNIPPAGE [snip of my comment about using auto-tabbing And you are going to change your edit macro (or have it smart enough to handle...) as you need to enter/update F/E/L/I/C/O/** specs? (If you don't know RPG, you won't recognize **). BTDT, and it sucks. I may be misunderstanding you but I fail to see how the need for DISPLAY Highlighting has anything to do with getting the text contents into the correct columns (which was the original complaint that I was responding to). SNIP Yes, you are misunderstanding. I worked with SPF long before ISPF and with RPG on VS1 and MVS. Trying to set tabs to handle the different fields for a CALC spec (or pick your favorite) is one thing. But trying to get the edit macro(s) to automatically recognize that you have moved from File spec (F) to Input spec (I) all the way to array/table definitions without having hit enter just ain't gonna happen -- Because you would have to hit enter after putting in the spec byte (H/F/E/L/I etc.) so the editor would understand the rest of the statement. And then the attribute bytes needed for tabbing will get in the way. I've also used terminals that allowed for the setting of tab points that were not 3270 attributes. RPG is too complicated for them as well. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSE RPG question
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert A. Rosenberg Sent: Saturday, May 30, 2009 8:47 PM To: IBM-MAIN@bama.ua.edu Subject: Re: VSE RPG question AT 16:23 +0200 ON 05/30/2009, GILBERT SAINT-FLOUR WROTE ABOUT RE: VSE RPG QUESTION: RPG was designed for punch-cards, and like DYL260, requires programmers to write code in specific columns. Not really convenient when programmers use 3270-type terminals instead of card-punch machines. If you are using SPF, you just need to set up a Tabs bar and either tab between columns or just type a tab glyph character (which you set). Thus you can type: Field1\Field2\Field3 etc. (where the \ is the tab glyph you defined) and as soon as you hit Enter, the characters will move to the correct locations on the line. This is no different from entering ASM or COBOL code. SNIP And you are going to change your edit macro (or have it smart enough to handle...) as you need to enter/update F/E/L/I/C/O/** specs? (If you don't know RPG, you won't recognize **). BTDT, and it sucks. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: service link down ?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lionel B Dyck Sent: Monday, June 01, 2009 9:16 AM To: IBM-MAIN@bama.ua.edu Subject: service link down ? I am getting an error code 500 when I try to connect to service link this=20 morning :( snip I got logged in and then it failed with a privacy issue. It was caused by a malformed URL that had HTTP:// rather than HTTPS://. Seems this system is still not quite ready to replace the VM system. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS STORAGE service
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Wednesday, May 27, 2009 2:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS STORAGE service Passing just to itself via a STCM R1,B'',MQCXP_EXITDATA at exit init time. Then I plan to release it at exit termination time. I haven't figured out how I can continue to reuse it over and over between different invocations. SNIP Mike: It sounds like you are trying to get storage that you will pickup later. The problem is, you need to anchor it somewhere where you will be able to find it again. If the caller of your exit will be the same from one call to the next, and that caller will know to pass you a workarea, then as long as they pass that same workarea over and over, you will be able to save the address of your storage (an anchor). If not, and you are APF authorized, there are some possible tricks for you so you can solve this problem. But first, more information is needed to determine how you are being called and why. I'd guess that there is some communications area that is passed to you (by some other name, possibly?) by MQ since you are writing a user exit. And knowing what state you are entered in will tell us a lot about how to go about this. Regards, Steve Thompson Too busy to land for gas -- doing air-to-air refueling -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCB time question
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Phil Smith III Sent: Friday, May 22, 2009 12:36 PM To: IBM-MAIN@bama.ua.edu Subject: TCB time question The following is typical output found in the SYSMSG produced by a batch job on our z/OS 1.9 system: -STEPNAME PROCSTEPRC EXCP CONNTCBSRB CLOCK SERV -NNN1SW 00 2326 1195 200.44.00 .9 3094K -NNN1HW 00 2316 1069.64.00 .0 9753 The following are the step termination message produced for those steps: /START 2009139.1224 /STOP 2009139.1225 CPU0MIN 46.98SEC SRB0MIN 00.03SEC /START 2009139.1225 /STOP 2009139.1225 CPU0MIN 00.15SEC SRB0MIN 00.01SEC We are not able to reconcile the step TCB time, particularly in the first step, with the actual run/clock time of that step. In fact, the TCB time attributed to the first step is considerably greater than the job's entire wall-clock run time. SNIP The Friday Dumb Question: Since I don't know your environment, and since other questions have been asked here at work which ignored the obvious (everyone wants the weekend to get started...), here is the dumb question: How many CPUs available and how many TCBs in the address space? If the number of CPUs is greater than 1... Regards, Steve.T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCB time question
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Phil Smith III Sent: Friday, May 22, 2009 1:36 PM To: IBM-MAIN@bama.ua.edu Subject: Re: TCB time question Thompson, Steve wrote: The Friday Dumb Question: Since I don't know your environment, and since other questions have been asked here at work which ignored the obvious (everyone wants the weekend to get started...), here is the dumb question: How many CPUs available and how many TCBs in the address space? If the number of CPUs is greater than 1... I see your dumb question and raise you a few more :-) 1 CPU. I can answer that one. I don't know how to answer the TCB question; My z/OS colleague says six usually. It's a single-threaded application that reads a file, does some stuff to it (encrypts some of it), then writes it back out. Nothing fancy. If it did have multiple CPUs, then I could see wall-clock being less than total CPU. But the total at the bottom shouldn't be less than one of the steps anyway, should it? ...phsiii snip CALL. Double check the SMF exits (I think those are the ones that put out this info). There could be a logic error in it (arithmetic or failed to clear some getmained storage -- a bit of that going around I hear). Otherwise, I'm at a lost as well. (Oh, and someone already suggested which exit). Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Untouchable architectures( Was: checking for the existence of a file in batch REXX)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, May 21, 2009 3:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Untouchable architectures( Was: checking for the existence of a file in batch REXX) SNIP Architecture is not a strict set of dictates; it's a consensus! SNIP Is this how a bridge got built in China, down the bay from the new passenger ship terminal -- you know the one, that is so low, few cruise ships can pass under it at low tide? Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Where Is a Functional Characteristics for 3592 Tape Subsystem
I have spent quite some time searching for the equivalent of a 3592 Functional Characteristics manual. Or a 3592 Tape Subsystem Hardware Reference. I need to get my hands on what the precise command codes (doing EXCP w/ CCWs) are for certain types of I/O, what the response is to, say a BLOCKID operation, and so forth. I have this for 3480, 3490 drives. But I sure can't find it for the 3592 (yes, I know, it is now obsolete and replaced by some LTO drive, 1120?). Can someone point me to where I can get this manual or its equivalent? Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: vse to z/os migration
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, May 18, 2009 9:28 AM To: IBM-MAIN@bama.ua.edu Subject: Re: vse to z/os migration -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Howard Rifkind Sent: Monday, May 18, 2009 9:13 AM To: IBM-MAIN@bama.ua.edu Subject: Re: vse to z/os migration I believe the 'Stop Run' statement just ends the program in VSE. In a z/OS environment you want the program to return control back to the O/S...a different world then VSE. IIRC, The COBOL STOP RUN terminates the current COBOL run unit. This may or may not return control to the OS. For example, if you have a non-LE assember program (in a non-LE environment) which does a LINK to a COBOL program, then LE will get control and initialize itself. The COBOL run unit will then be initialized and then, finally, the COBOL program started. If that COBOL program then dynamically CALLs another COBOL program which executes a STOP RUN, then your assembler program will get control back, bypassing the calling COBOL program entirely. I also think this terminates the COBOL run unit, which means that the files opened in the run unit are closed (may be wrong on this one). SNIPPAGE Anyone besides me see a very broken MVS SUBROUTINE protocol by this behavior? After all, how is your program supposed to know that a subroutine it calls is later modified to invoke a LE based program Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where Is a Functional Characteristics for 3592 Tape Subsystem
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Monday, May 18, 2009 9:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Where Is a Functional Characteristics for 3592 Tape Subsystem Thompson, Steve pisze: I have spent quite some time searching for the equivalent of a 3592 Functional Characteristics manual. Or a 3592 Tape Subsystem Hardware Reference. I need to get my hands on what the precise command codes (doing EXCP w/ CCWs) are for certain types of I/O, what the response is to, say a BLOCKID operation, and so forth. I have this for 3480, 3490 drives. But I sure can't find it for the 3592 (yes, I know, it is now obsolete and replaced by some LTO drive, 1120?). Can someone point me to where I can get this manual or its equivalent? 1. It is not obsolete, but replaced by third generation of Jaguar family. I assumed you mean 3592-J1A which is the first generation. The second one is also 3592: 3592-E05. 2. I'd suggest SCSI command reference. However you'll get reference of the drive commands which is good idea if you talk directly to the drive. Not a mainframe case. For mainframes you should read controller specs. SNIP [SCSI Command reference] Which seems to be lacking on the IBM web pages for this unit. However, everywhere I turn I find the following: Effective September 29, 2006, IBM will withdraw from marketing the 3592 Enterprise Tape Drive. : : The IBM TotalStorage 3592 Enterprise Tape Drive has been replaced by the IBM System Storage TS1120 Tape Drive But the controller info is not quite so readily available. The Redbook, IBM System Storage Solutions Handbook states also, Note: IBM has announced it will withdraw all models of the IBM TotalStorage 3590 Tape Drive on September 29, 2006. It is replaced by the IBM TotalStorage 3592 Tape Drive Model J1A and IBM System Storage TS1120 Tape Drive. Yet, no where can I find the information on the controller. Even the links given go to dead ends. Our problem is, certain options with NOTE/POINT are causing heartburn with this device. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BLOCK CONTAINS
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Thursday, May 14, 2009 7:03 PM To: IBM-MAIN@bama.ua.edu Subject: BLOCK CONTAINS I have been a bit of experimenting with z/OS QSAM files from a Cobol program and I find that the manuals don't exactly agree with my results. The manuals seem to imply that if you use the BLOCK CONTAINS clause (whether 0 or something else) then the file has a RECFM of either VB or FB. And if you don't include it then it's either V or B. SNIPPAGE Welcome to the MVS world. In the MVS world, we are not device dependant, nor are we data definition locked/blocked. We generally don't have to recompile our programs, change the DTF contents (DCB in MVS), etc. just because the file attributes change (xSAM to VSAM is the exception). We do not have to link PIOCS or LIOCS routines to our programs to handle I/O. The access method itself handles these things (particularly at the QSAM level). If you are using a vendor to help you migrate, you should spend a bit of time with them discussing all the changes to the environment and different concepts between VSE and MVS. As you have seen with your experiments, the information on the DD statement will override what you have in your program. And the label from the file in MVS actually contains the LRECL, BLKSIZE and RECFM, which as I recall, is not the case with VSE (for disk or tape). However, what happens if the DD statement only contains the UNIT, SPACE, DISP, and DSN? Does what you specify in the COBOL program then behave the way the manual says? Your ESDS files being taken to SAM: Just make sure that you don't actually depend on VSAM functions. And as far as your ASSIGN clause on the SELECT: you can probably leave them as they are -- but I haven't used the latest COBOL for a migration. In fact it has been a few years since I've done a migration. So unless it is going to enforce something, as I recall, only what is after the last - is paid attention to. And if you end with -SYS112 (or some such), then the DD being looked for is SYS112. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BLOCK CONTAINS
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Friday, May 15, 2009 8:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS What if a new device came out and there was a better optimum blocksize for it? Wouldn't you have to recompile everthing that used that file to get the optimum blocksize? I don't know I'm just asking. SNIPPAGE Under VSE that would be true for other than VSAM access. Under MVS you would have to go out of your way to get into this problem of being blocksize dependent. Granted, this was done in days when there were different device geometries (2314, 3330, 3340, 3375, 3380, 3390). But as has been and will be pointed out, as long as you specify BLKSIZE=0, you will get System Determined Blocksize which will handle this situation. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BLOCK CONTAINS
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Friday, May 15, 2009 9:07 AM To: IBM-MAIN@bama.ua.edu Subject: Re: BLOCK CONTAINS On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve wrote: Welcome to the MVS world. In the MVS world, we are not device dependant, nor are we data definition locked/blocked. We generally don't have to recompile our programs, change the DTF contents (DCB in MVS), etc. just because the file attributes change (xSAM to VSAM is the exception). Huh??? If we are not device dependant, why is there such intense trepidation and resistance to the mere suggestion of a device with a novel geometry such as more bytes per track or more tracks per cylinder? It doesn't appear that you and I have been living in the same MVS world. SNIP In the VSE world, if you set up to read tape, you can not change your JCL to instead read Disk. A DTFSD (Define The File - Sequential Disk) can not be used to read a tape (DTFMT - Define The File - Magnetic Tape). If you did use the DTFDI (Define The File - Device Independent) it is only good for limited situations. In the MVS world, DCB is DCB -- We don't have DCBSD for Data Control Block - Sequential Disk. The Access Method connects you to the device and handles it (unless you went out of your way to make the DCB specific to a device, such as a card reader). As you can see, there is device dependence and then there is device dependence. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
VSE I/O Performance VS MVS [was BLOCK CONTAINS]
Because of past conversions, I think this needs to be said: 1) VSE/ESA got to use XA I/O just like MVS. This means, to the VSE shop, that some slick stuff that got offloaded to the I/O Subsystem (shall we say parts of VM's and MVS' I/O Supervisor code) became available w/o any JCL or application coding changes. Things like dual (or multi) pathing with dynamic pathing. What does this have to do with anything? Well, the typical throughput performance gains seen in the past when going from VSE to MVS don't happen because what was giving those (for the most part) has already been realized. 2) VSAM is implemented in VSE differently than in MVS. So, the way sharing and buffer management is done changes and WILL cause performance issues when you get to MVS. 3) CICS is impacted by these changes, and you may see less throughput. Although, with the ability to have more storage than z/VSE allows, you may over come it. But be sure to have sufficient page volumes. Bottom line: To get the same or better performance from a well tuned VSE shop that goes to MVS, you will need people who are well versed in all the tricks. And they will need to understand what was happening on the VSE system to effect similar results on the MVS system. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Journal Does it Again
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Eric Bielefeld Sent: Wednesday, May 13, 2009 1:02 PM To: IBM-MAIN@bama.ua.edu Subject: z/Journal Does it Again I just received another z/Journal email sponsored by Microsoft urging us to get off the mainframe and going to .NET. They refer you to the following web site: http://www.microsoft.com/windowsserver/mainframe/whoknew/default.aspx I would think that would be counter productive. I'm sure that Microsoft pays z/Journal big bucks to advertise, but if every mainframe user followed MS advertising, there wouldn't be a need for the z/Journal. SNIP I went and found the article being advertised. I read it. I would LOVE to see the size of the mainframe they were using. I would also love to see a true apples to apples comparison of the two systems. I find it very interesting that they didn't even try to convert the COBOL code to something else. They used Realia (I think I have that spelled right) who has a .net capable COBOL compiler. And they migrated to the M/S SQL server. So what kind of I/O problems did the old system have that going to two of these new M/S Servers allowed them to cut their nightly processing window in half (from 4 hours to 2, was it?). There's a lot of missing stuff. This is the kind of article written by marketing people for airline magazines to use as articles (my personal opinion). Perhaps someone should contact Amy Novotny and ask her a few questions. Regards, Steve Thompson -- Opinions expressed by this poster do not necessarily reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Fw: Re: 308x Processors - was Mainframe articles
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Anne Lynn Wheeler Sent: Tuesday, May 12, 2009 12:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Fw: Re: 308x Processors - was Mainframe articles SNIP 3033 and 3081 in 370 mode were 24bit (16mbyte) addressing (real virtual). SNIPPAGE Didn't the 30xx machines have 26 bit addressing (the 3033 mode) when operating in S/370 mode? Starting with the 3033MP? Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Accessing a big sequential file
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of K Zafirop Sent: Friday, May 08, 2009 8:30 AM To: IBM-MAIN@bama.ua.edu Subject: Accessing a big sequential file Hi listers! Do you have any idea on how to get only the last record of a very big file using either REXX or some other method? I will want to prevent reading all file records in any any case. snip I would allocate the file with DISP=MOD and write one record and then do a NOTE. Then I would close the file, and reopen INPUT. Then I would issue POINT and do a read backward. Fastest way I know of to get there w/o having to read the whole file, or do a catalog lookup, get the last volume (or only), read the VTOC, get the EOD info... Regards, Steve Thompson -- Opinions expressed by this poster do not necessarily reflect those of poster's employer, wife, or those of IBM-Main's subscribers -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Validating Addrees
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joe Reichman Sent: Friday, May 08, 2009 5:01 PM To: IBM-MAIN@bama.ua.edu Subject: Validating Addrees Hi would anyone know if you have a stroage address to determine its nature e.g. CSA SQA etc. would I have to check all of the entries in the LDA ..GDA or is the best way to invoke VSM. macros LSIT RGN etc or is a combination of all these methods SNIP I am not entirely sure what you are asking for. If you need to know where CSA is, look at the GDA. I think it also has the LPA, and SQA entries as well (I'm not looking into the DATA Areas right now). The LDA has what is LOCAL to the address space (which authorized programs can change as they need -- to a point). Regards, Steve Thompson -- Opinions expressed by this poster may offend certain users, and do not necessarily represent poster's employer's opinions or stated positions. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Test
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lionel B Dyck Sent: Wednesday, May 06, 2009 5:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Test SNIPPAGE NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, = you are prohibited from sharing, copying, or otherwise using or disclosing = its contents. If you have received this e-mail in error, please notify the = sender immediately by reply e-mail and permanently delete this e-mail and=20 any attachments without reading, forwarding or saving them. Thank you.=20 SNIPPAGE The old BURN BEFORE READING ploy? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Test
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rich Smrcina Sent: Thursday, May 07, 2009 9:13 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Test Ron wrote: Funny part is that these type of notices are always at the bottom of the email. Just the place I always scroll to immediately when receiving and reading an email... No, he was referring to the Netzero advertisement that was appearing in his sent email, in addition to the customary IBM-Main verbage. snip Actually, I was referring to the legalese at the bottom of a posting that boils down to, if this email isn't meant for you you have to unread it, forget that you saw it and then reply to the sender to let them know you didn't read it. To that, I took something from Get Smart (the old fogies version), to Burn Before Reading. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]
Having done a few VSE to MVS migrations, let me speak to this at a conceptual level. What kind of security risk is it for someone to duplicate a volume with sensitive data on it? This can be done with FLASHCOPY or physical volume backup (DSS). Granted, in a VSE shop, programmers get much more freedom than they do under MVS. And just like in the VSE shop, you can access NON-VSAM files as long as you know the VOLSER where the data is. So a CLIP and a VARY ONLINE and the data is available. However, if the senior level programmers have access to flashcopy, how would you know that a volume had not just been clobbered before you got it backed up? Two people using the same phantom volume, and the last one to write wins. How would you ensure that the production backups and the programmers are using different volumes for the flashcopy? UNLIKE VSE, MVS does not have the catalogs owning the volumes where their VSAM files are. So catalog backup doesn't work for MVS as it does for VSE. And DSS logical backups come close, but there are some gaps that can cause serious heartburn during DR testing. Again, not even using the MVS SMS capabilities, MVS manages files for you, while under VSE, without some third-party product, you (the data manager) must assign EXTENTS on volumes. Very different mind-set and function between MVS and VSE (and granted, my VSE knowledge is rather dated, I really haven't touch VSE for a while, and not even looked at z/VSE). DSS also allows you to take that logical backup and then rename for restore. How do you secure this, so that production data (perhaps subject to HIPPA) doesn't get out in the wild (as it were)? You will want to make sure that the security keys in your security system are set appropriately. Which brings up a new set of concepts. What Security system did you have for VSE? If you didn't have one, MVS does things at the data set name level. So it might not matter what the volser is, DSN=A.B.C obtained via the CATALOG system, or via VOLSER will be checked. Many concepts to understand that are very different in their implementations between the two environments. Regards, Steve Thompson SNIPPAGE That is the question I am trying to have answered. What harm might be done in giving programmers access to DSS COPY flashcopy? Going by the name of the resource and the comments on http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.i bm.zos.r9.e0zh300/dssracf.htm it would appear that this resource pertains only to DSS COPY and not to Flashcopy in general. Therefore I would think that giving programmers rights to it would not unexpectedly give us rights to something else. Does anyone disagree with this? To answer someone else's question about something having changed if we could do this before but can no longer, this is not the case. We are a new z/OS shop (in process converting from VSE), and I had just never tried this function before. Thanks! Frank SNIPPAGE -- Opinions expressed by this poster may not reflect poster's employer's views or policies. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Using FTP to send loadlib
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kurt Eastwood Sent: Monday, April 27, 2009 10:32 AM To: IBM-MAIN@bama.ua.edu Subject: Using FTP to send loadlib Hello, =A0 I have been digging through the OS/390 TCP/IP OE: User's Guide and have not= been able to get this to work. =A0 Is it possible to send a loadlib from 1 mainframe to another mainframe usin= g FTP, either batch or interactive? =A0 If so, would anyone be willing to share some batch jcl with me? =A0 Thanks, Kurt=0A=0A=0A SNIP I think you will have to unload it using IEBCOPY to a flat file, then send that as BIN. After receiving it, use IEBCOPY to load the PDS. OR, you can use TSO XMIT to a file, FTP as BIN, then point TSO RECEIVE to the file... Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What (More) Open Source Software for z/OS?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John McKown Sent: Tuesday, April 21, 2009 1:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: What (More) Open Source Software for z/OS? On Tue, 21 Apr 2009 12:55:15 -0500, Ron Wells rwe...@agfinance.com wrote: MVS use to be open. It would not have gotten very far without the aid of others back in the 60's/70's early 80's--- Before Microsoft started it's lock down.. and yes would be a big benefit having it open again ... Possibly. But, from what little I know, most of the new stuff is written in PL/S or whatever. It doesn't do much good to have source when you don't have a compiler! Part of the lock down occurred when IBM transitioned from a pure hardware company (where software was only used to help sell hardware) to a hardware + software company where software in itself became a source of income. And the OEM CPU people may have been a part of it too since they used IBM software (like OS/MVT) without the need for a license (due to IBM overlooking copyrighting the OS). Another part of OCO is to keep information away from users so that they don't use non-GUPI interfaces in such a way as to force IBM to freeze that interface due to its popularity. SNIP You don't think that OCO was a reaction to some company located on/in an Island country that took MVS, made modifications (and kept the same errors and misspelling in error messages and the like), and then put it out as their own SCP, would you? Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mass Updates to JOB Cards for Account Code Changes
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Brown, Larry - St. Louis, MO Sent: Friday, April 17, 2009 7:56 AM To: IBM-MAIN@bama.ua.edu Subject: Mass Updates to JOB Cards for Account Code Changes We have been tasked to update the account codes for all our production and development jobs. Endevor is used for configuration management. Have not talked to our configuration (Endevor) person yet, but she is fairly new to Endevor, so may not be able to help a lot. Also, I don't have access to Endevor manuals - yet. So, I am assuming (hoping) we can check out jobs en mass from Endevor some how with a batch job. And then come up with with something (REXX EXEC maybe) to change the job cards to reflect the correct account code. Then run another batch job to return the jobs to Endevor. I'm not an Endevor user, so sorry for not knowing the proper terms for 'checking out', and 'returning'. Anyway, does this sound doable? I know folks have done mass updates to JCL, but not sure about having to work with Endevor. I've done mass updates on VM/CMS files in the past, not MVS though. Checked the archives for Mass Updates, Endevor and Account Code, but didn't see anything helpful right away. SNIP We use Endevor here. We run it in the penalty box (low powered CEC), we use batch processing rather than online (thru TSO). So, yes, you can check out all the members you want (JCL, MACRO, etc.) in a batch run. You can then update them however you like, and then via batch check them all back in and depending on how things are done, promote them from the initial stage to the production stage. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Downloading IBM manuals
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Alcock Sent: Wednesday, April 15, 2009 12:03 AM To: IBM-MAIN@bama.ua.edu Subject: Downloading IBM manuals Every time a new z/OS operating system level comes along I go to the IBM library page and download each manual I'm interested in (i.e. most in the MVS bookshelf) one at a time and give them somewhat meaningful names like zos 110 init and tuning ref.pdf instead of iea2e291.pdf for example. What do you do? SNIPPAGE I do the same thing, but I leave the IBM name as the first characters. I have asked, and was roundly shot down by someone at IBM, that perhaps there should be some way to make this friendly. The thinking is, there are links in the manuals to other of IBM's manuals, and renaming breaks those. If Acrobat and IBM could get things to come together, the link would search for the first 8 characters... [Since I was out of the office yesterday, you watch that someone else has already posted something similar...] Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Is it me, or is IBMLINK having problems?
Title says it all. Message I'm getting (this is after I had been logged in for a while): - Error There has been a problem processing your request. Please try again. If you continue to have difficulties, please contact IBMLink customer support. - Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is it me, or is IBMLINK having problems? -- SEEMS Functional Now
Title says it all. Message I'm getting (this is after I had been logged in for a while): - Error -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is it me, or is IBMLINK having problems?
Yeah, and my 3270 access is also toast this time. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Tuesday, April 07, 2009 2:17 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Is it me, or is IBMLINK having problems? I keep getting errors trying to access IBMLINK. So I do not think it is you - it is THEM. Lizette Title says it all. Message I'm getting (this is after I had been logged in for a while): - Error -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Withdraws Patent Application on offshoring jobs
I didn't get it from Gary (although he reminded me of it). I got it from an old friend who said something to that effect in the mid-70s. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Monday, April 06, 2009 3:03 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM Withdraws Patent Application on offshoring jobs Trusted Scout. I don't think Gary Larson got the etymology right... And you should have seen the look on the Lone Ranger's face when he finally found out what Keomsabe really meant. [A bit of levity appeared to be needed for this post.] Regards, Steve Thompson -- Normal disclaimer applies about my opinions and those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Withdraws Patent Application on offshoring jobs
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Adams, Tracy Sent: Friday, April 03, 2009 9:25 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM Withdraws Patent Application on offshoring jobs SNIPPAGE Kemosobe SNIPPAGE And you should have seen the look on the Lone Ranger's face when he finally found out what Keomsabe really meant. [A bit of levity appeared to be needed for this post.] Regards, Steve Thompson -- Normal disclaimer applies about my opinions and those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 exit?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John McKown Sent: Wednesday, April 01, 2009 12:35 PM To: IBM-MAIN@bama.ua.edu Subject: JES2 exit? SNIPPAGE I don't like doing the above, but management basically wants a rule of any job which will execute more than ... minutes must be scheduled by Production Control via CA-7. Of course, a rule without enforcement is not a rule. It is a request. SNIPPAGE So any and all jobs that execute 1 second beyond get cancelled, right? I can think of two system issues that can cause heartburn. Should the system have an enque hang, or allocation (as in it being single threaded for ALL address spaces) get stuck for some reason, all batch jobs subject to this rule could get executed. Now for the busy situation that causes this problem: What happens when the tape system you have has all its tape heads tied up when a large data set is needed has been migrated off to tape? Do all the jobs that are waiting for restores get charged with the wall time it takes to get their files restored? Just a few items that management, who may know nothing about how real processing takes place, may need a small bit of education about. Regards, Steve Thompson -- Opinions expressed by this poster may not be those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: A foolish consistancy or 3390 cyl/track architecture
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant Sent: Tuesday, March 31, 2009 5:23 PM To: IBM-MAIN@bama.ua.edu Subject: Re: A foolish consistancy or 3390 cyl/track architecture On Tue, 31 Mar 2009 15:54:09 -0500, Eric Bielefeld wrote: Snip When I worked at Wayne State University in Detroit, we bought an RVA. That was IBM's re-branded Iceberg. AFAIK, Sun also sells it as the SVA. On that box, all data stored on disk was compressed. Because any new data written to a track may not fit in the same location, every time data on a track was written, the track was written to a new location, and only the disk space required for the compressed data was used. There was a special utility used to report on how much of the back-end disk storage was used. IIRC, it was called Net Capacity Load. Allocating another volume or creating a snapshot did not increase the NCL. The micorcode has garbage collection routines that accumulate track areas that are no longer used and background tasks that move data around in order to maintain a contiguous area where new tracks can be written. It is a marvelous feat of engineering. And it is no wonder that the Iceberg was so much later getting to markket than originally planned. In order for any DASD subsystem to be insensitive to blocksize, it would have to do something similar, compressing out the gaps and storing the track in discontiguous locations. AFAIK, the rest of modern DASD subsystems allocate specific locations for each logical volume, and therefore for each logical track. There has to be sufficient disk space to store the maximum amount of data in each track location. If short blocks are written, less data will fit in that logical track. SNIP Wouldn't this effectively defrag DASD units? But then we would still have to run some kind of defrag just to fix the VTOC (so it wouldn't have so many extent entries for data sets), right? Regards, Steve Thompson -- Postings by this poster may not reflect the views or opinions of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC 50 (0A32)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Schuster Sent: Wednesday, March 25, 2009 4:05 PM To: IBM-MAIN@bama.ua.edu Subject: SVC 50 (0A32) Does anyone know what this SVC does? The diag ref manual only says 'reserved'. snip I believe its unintended use is for putting entries into the system trace. So, depending on what you want to note, you stick values into R15-R1 and then invoke SVC 50. Regards, Steve Thompson -- Opinions expressed by this poster may not be those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM in talks to acquire Sun Microsystems
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Eric Chevalier Sent: Wednesday, March 18, 2009 7:21 AM To: IBM-MAIN@bama.ua.edu Subject: IBM in talks to acquire Sun Microsystems This morning's Wall Street Journal is reporting that IBM is in talks to buy Sun Microsystems for as much as $6.5 billion. A deal could take place as early as this week. The deal furthers a recent pattern of consolidation in the tech industry around the services, hardware and software used to run data centers, the big computing rooms that store and process information. In recent years, the market for servers has shifted from the huge, custom-built 'mainframes' that IBM dominates to vast numbers of standardized computers. By pushing standardized servers, H-P has made inroads on IBM. In the meantime, Sun has suffered, as its strategy of using its own operating system on standardized software has failed to propel new growth. SNIP Custom built (as he spits coffee all over his LCD)!?!? A few coughs and gasps with the ...own operating system on standardized software... has me thinking they don't have a good editing staff any more. Shouldn't that have been HARDWARE? Seems to me that the mainframes are more standard than not with more standard devices to attach. Seems that journalists should get out more and KNOW more before writing this junk. Ah, but what do I know? I'm just a balding middle-aged white guy who has been working on/with computers since about 1968. Regards, Steve Thompson -- Opinions expressed by poster are not necessarily those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: protecting ISPF dataset allocations
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jousma, David Sent: Wednesday, March 18, 2009 9:00 AM To: IBM-MAIN@bama.ua.edu Subject: protecting ISPF dataset allocations All, Is there any mechanism or approach to protect a TSO/ISPF user from accidentally/intentionally FREEing SYSPROC or SYSEXEC? Until now, our shop has been mostly Roscoe users outside of tech support. We are trying to migrate developer's to use TSO/ISPF, and want to protect the environment where needed. I don't mind them using ALTLIB, and LIBDEF to create their own stuff, but I don't want them FREEing and reallocating SYSPROC/SYSEXEC to concatenate their own stuff ahead of what we want them to use. We already do not allow them to get to the READY prompt, but testing shows that even when in ISPF I can still FREE SYSPROC/SYSEXEC. I want to allow some ingenuity, just not too much is all. =20 SNIP Once they screw this up and can't go anywhere, their only out is LOGOFF. When they log back on, it will all be fixed up again. After doing this a few times, they will be tired of the pain and stop doing dumb things. OR, they will get real smart and learn how to do it the right way, which is the ingenuity you are trying to encourage, right? And by preventing getting to the READY prompt, are you getting in the way of using TSO TEST to be able to diagnose certain problems? After all, you did say these are programmers, and unless you are using some other debugger (such as my favorite, XDC), how do you expect them to interactively diagnose and fix problems? Just my .2 cents worth (highly devalued due to inflation...) Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: protecting ISPF dataset allocations
The problem here is the OP is coming from a ROSCOE environment which has a control mentality. The TSO world can have that level of control, but to what end? Having worked in and with ROSCOE, WYLBUR, TSO, etc. and having done migrations between different environments (Univac, Honeywell, S/x, etc.) I have learned to deal with the thinking of the groups. Eventually, the corporate climate changes to match the new environment and a equilibrium is reached. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FW: SYSOUT dynamic allocation in COBOL
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, March 16, 2009 4:01 PM To: IBM-MAIN@bama.ua.edu Subject: Re: FW: SYSOUT dynamic allocation in COBOL SNIP (DDName SYSOUT? Not SYSPRINT? Not SYSTERM? COBOL seems to want to be the misfit. Will it accept an alternate DDNAME list as a second PARM?) SNIP COBOL's original implementation has been carried forward from all the way back to OS/MFT as far as I know. This is why some others pointed out COMPILE time options that can be set. You can only change the SYSOUT DD (well, this was back when I was dealing with VS/COBOL) via some slick tricks (like an ASM Subroutine that finds all open DCBs to a particular DD...). Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cost of CPU Time
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Carson, Brad Sent: Tuesday, March 10, 2009 6:36 AM To: IBM-MAIN@bama.ua.edu Subject: Cost of CPU Time Hello IBM-Main'ers, I'm looking for some information on how to calculate the cost for using CPU= . Our new performance management team is trying to come up with a calculat= ion that can be used for multiple platforms. Those include zSeries, Unisys= , pSeries, HP9000, and intel. Since I'm not allowed to access the Gartner = site (due to $$), we're trying this the old fashioned way on our own. Any insight, tips, hints would be appreciated. SNIP This is probably hashed greatly in the archives. It hasn't been too long since a large argument was running over how to do things in this area and why. The basics are: 1) How long do you take to amortize the machine to $0? 2) How much do you use the machine per processing day (if the machine is idle for 16 hours vs run 24x365 -- pet peeve, 24x7x365 is roughly 7 years)? 3) Are you going to put in all your costs for software that runs on the machine, and how do you plan to amortize those? 4) Are you going to figure your costs for environmentals for the machine? 5) Will you put in the manpower costs to operate (as in any operators, administrators, etc.)? 6) Will over-all manpower costs be applied (manager costs for the IT department)? 7) Are storage costs to be apportioned to the machine, and if so, how? Once you have all of this, you can then assign the cost per CPU unit (hour, minute, etc.) Next, will you set this for a CPU, or divide by the number of CPUs (this is what started the argument last time as I recall)? Once you get this done, and you are comparing apples to apples, I would love to see which system is the most cost effective for general processing (I know that there are specific things that different systems are especially good at, such as math, or data base handling). Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Tape Stealing in z/OS with CBR4000I
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Friday, February 27, 2009 7:32 AM To: IBM-MAIN@bama.ua.edu Subject: Tape Stealing in z/OS with CBR4000I Running z/OS V1.9 with JES2, GRS, and CA1 I have a production batch job that has been running fine for months passing a tape from one step to the next. Now it is receiving CBR4000I messages indicating that the tape is already mounted on a different drive. The previous step is (,CATLG) and VOL=(,RETAIN,REF=*.prevstep.ddname) for all of the datasets that are to be stacked on the same tape. And the next step uses the same coding technique for stacking its datasets on the previous step's output tape dataset. The job will get the CBR message to Cancel Retry or Wait. When Cancel is replied the job fails with S613-1C Okay, I can see that. The tape is still mounted on the drive from the previous step and now the next step wants it to be mounted on a different drive. No Dismount has been issued between the steps. IBM is telling me that this is normal. That something called tape stealing can occur in a busy system and they looked at my dump and see that the UCB has been cleared. Yet there does not seem to be a solution other than perhaps changing the job to only do one step for stacking datasets on a tape or having an operator issue a manual dismount when this message occurs. Has anyone run into this situation? When you will get the CBR4000I message in a multiple step job trying to pass a tape which is having datasets stacked on it, from one step to another? SNIP I have a similar situation with allocation using cartridge drives. I have 4 drives, with my tapes MOUNTed (MVS MOUNT). When a restart happens (long story, but the job restarts a process and goes back through allocation), ALLOCATION asks for a new drive. It should know that the volume it wants is mounted, yet it still asks for a new drive (which doesn't exist in this case) to put the *MOUNTed* volume on. I have a second situation where an MVS MOUNT has been done, but the job step has a label problem (one of its own making). OPEN causes the MOUNT to be terminated! Me thinks that something in allocation (and possibly a conflict from inside of DFP O/C/E) is not working quite right. Regards, Steve Thompson -- Opinions expressed by poster may not be those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Pedantic Tape Analyzer?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, February 23, 2009 7:01 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Pedantic Tape Analyzer? On Mon, 23 Feb 2009 19:31:09 -0500, Thompson, Steve wrote: SNIPPAGE I don't know if you want to go this far, but if your tape utility is also going to have some part(s) that are not fully attached (that is, must be linked to your main routines), you could put them into the system Label Exit (DFP/DFSMS part of the system?). I know it exists, but I don't know the name. I know you can use it to handle things for AL tapes (that's how I stumbled upon its existence about 8 months ago). Can this be done in a way that's nondisruptive; transparent to users other than me? SNIP To my knowledge, you can put out WTOs in the JOBLOG. If they pay attention to them, then it won't be so transparent. But after reading more and having a better understanding of what you want to do, forget I even mentioned the exit points. snip During the pass to the exit of the label(s), you could verify that they match the VOL1 contents. I don't know when or how that exit point is invoked for trailer labels. Can this be written in Rexx? IANASP. IANAHLASMP. SNIP AFAIR, no, this must be assembled and linked and AC=1 type stuff. SNIP Otherwise, you will probably have to satisfy yourself with the DCB label exit point -- unless you want to do EXCP and BLP :-) . Currently, I'm using BLP, RECFM=U, and LMGET. That's how I noticed the discrepancy between the VOL1 and HDR1 volsers. Further thought: How about validating SDWs? Continuation bits valid, and continuation allowed only when RECFM=VBS? Etc. (Relentlessly pedantic.) SNIP I think you can do all you are trying to do with REXX as long as you are specifying RECFM=U. You will have some fun handling all of this. It almost sounds like you are trying to write part of DITTO. Regards, Steve Thompson -- Opinions expressed by this poster may not be those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3270 emulator cost
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Schwarz, Barry A Sent: Tuesday, February 24, 2009 12:31 PM To: IBM-MAIN@bama.ua.edu Subject: 3270 emulator cost As part of a replacement for a 12 year old system at a customer site in Japan, we will be replacing PCs running Windows 95 and IBM's PCOMM 3270 emulator with new PCs running Vista (don't bother) and a PCOMM replacement from IBM called Host Access Client Package. This new package comes with two pretty hefty price tags: approximately $1,000 purchase price per PC and approximately $250 per PC per year license fees. We will have 40 PCs. I can live with the $40K one time purchase cost even though I think it is pretty high but it seems absurd that the $10K license fees are 1/4 of the purchase price. In my experience, this is not the type of package that gets updated very often (actually I've never seen a 3270 emulator update). Does anyone have any experience with this Host Access Client Package? Are the fees comparable in other countries? Do other packages (Extra, Rumba, etc) charge annual fees? I would love to use one of the 3270 emulation products frequently mentioned here but I'm going to need ammunition to overcome the political inertia. SNIP QWS3270 (Jolly Giant) does have annual maint fees. And they do put out some maint yearly. I'm *guessing* that for 40 seats, Jolly Giant would be in the neighborhood of US$600 (initial) if not less for a site license and annual maint after that less than $100. So if the parties concerned aren't math challenged... Regards, Steve Thompson -- Opinions expressed by this poster may not be those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Pedantic Tape Analyzer?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, February 23, 2009 5:05 PM To: IBM-MAIN@bama.ua.edu Subject: Pedantic Tape Analyzer? Lately, examining a dump of a tape output from SAS TAPECOPY, I noticed that the volser in the HDR1 records did not match the volser in the VOL1 record. OK. IBM doc says this field is defined but not verified by OPEN/CLOSE processing, etc. But I'm working on a utility of my own, for complex reasons. I'd like to do better than SAS. How can I verify the result? Is there a utility to which I could pass a (putatively) standard labeled tape, such as that output from SAS TAPECOPY which would report loud and clear on irregularities such as the volser mismatch, possible block count errors in trailer labels, all such? Bruce Black probably would have known; we all miss him; I for some volunteer research he did when I asked another stupid question years ago. snip I don't know if you want to go this far, but if your tape utility is also going to have some part(s) that are not fully attached (that is, must be linked to your main routines), you could put them into the system Label Exit (DFP/DFSMS part of the system?). I know it exists, but I don't know the name. I know you can use it to handle things for AL tapes (that's how I stumbled upon its existence about 8 months ago). During the pass to the exit of the label(s), you could verify that they match the VOL1 contents. I don't know when or how that exit point is invoked for trailer labels. Otherwise, you will probably have to satisfy yourself with the DCB label exit point -- unless you want to do EXCP and BLP :-) . Regards, Steve Thompson -- Opinions expressed by poster may not reflect those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
