SR
Anyone else as disgusted with the SR replacement as I am? Half time, it doesn't updae the record correctly and you have to sign-on twice just to get into the thing. On a positive note, you can download files which is nice but does not make up for the generally poor design. Makes me wonder if anyone at IBM bothered to look at the ETR function and how easy that was to use before designing SR. I can't help but feel IBM is shooting itself in the foot by deploying stuff like SR while making it worse that the prior product. Sorry for rant but I see SR just one component of The Rise and Fall of IBM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A z/OS Redbook Corrected - just about!
Oh, so USSTAB means Unix Systems Services table. Wonder what that's used for, mate? On Fri, Apr 6, 2012 at 10:20 PM, Ron Hawkins ronjhawk...@sbcglobal.netwrote: Chris, I took your advice and read this post, but then I took it to a higher authority for validation. Yes, I googled acronym USS.' Mate, I'm sure I don't have to tell you that the internet holds the keys that unlock all mysteries, and for this one I was horrified to find that for all your hard work, the first hit in Google just simply did not support your position. There was the site with all the answers staring me in the face, waiting for the USS conundrum to be unraveled at a hit labeled USS - Definition by AcronymFinder. I mean, this has to be place to find the correct meaning of an acronym - forget all these red books and stuff. And so I curtailed my googling activities, sallied forth, clicked my mouse button, and infiltrated this place of purveyance to negotiate the reading of some contracted comestibles. And there it was, on the fifth line of the list: Unix System Services (IBM). I'm afraid there was no mention of that other meaning you are always talking about. I mean, based on this unassailable reference it is hard to believe that Unformatted System Services was ever abbreviated to USS, and probably should not have been because all the math's majors working in mainframes back then would have immediately been misled into thinking one was talking about the Uncorrected Sum of Squares (did you know that SAS has a USS function - you should write to them and get them to change it). So I'm afraid we have Internet 1, Chris nil, and we should all start using USS the way God and Google intended us to. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Wednesday, March 21, 2012 5:35 AM To: IBM-MAIN@bama.ua.edu Subject: [IBM-MAIN] A z/OS Redbook Corrected - just about! Back in early February, I sent off this comment to the redbooks site: comment To whom it may concern, - This feedback concerns redbook z/OS Version 1 Release 13 Implementation, SG24-7946-00, which is described still to be in Draft status. - Recently I wanted to check on what z/OSMF was all about. Expecting to be more quickly enlightened by finding a suitable redbook, I tried z/OSMF as a search word on the redbooks site. There were 3 hits, the first, gratifyingly, was entitled z/OS Management Facility. The other two were z/OS Version 1 Release xx Implementation, where xx was 12 and 13. I happened to notice the following at the beginning of the z/OS UNIX System Services chapter in the release 13 redbook: quote z/OS UNIX System Services, is an element of z/OS, is a UNIX operating environment, and is implemented within the z/OS operating system. It is also known as z/OS UNIX. In addition, there is a short abbreviation called USS. /quote How very curious, I thought. How did this mistake creep in? I then checked the beginning of the z/OS UNIX System Services chapter in the release 12 redbook and found that the curious addition had been slipped in only in the later V1R13 edition: quote The UNIX System Services element of z/OS is a UNIX operating environment, implemented within the z/OS operating system. It is also known as z/OS UNIX. /quote Since the V1R13 redbook is still in draft status, the inappropriate text can be removed. - First, in order to confirm that the abbreviation sanctioned by the authors of the manuals when UNIX System Services was introduced, we can pick any of the front-line manuals, the OS/390 MVS Initialization and Tuning Reference being one: quote CHANGES Summary of Changes ... As part of the name change of OS/390 OpenEdition to OS/390 UNIX System Services, occurrences of OS/390 OpenEdition have been changed to OS/390 UNIX System Services or its abbreviated name, OS/390 UNIX. ... /quote http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/IEA1E211/CHANGES Thus we have it confirmed that OS/390 UNIX is the supported abbreviation, clearly to be transformed to z/OS UNIX when z/OS was introduced and that there is nary a mention of any other abbreviation. After all, one abbreviation should be sufficient, shouldn't it? In case there is any doubt over the ancestry of this other abbreviation, we have the following web page in order to remind us what, within IBM, is the correct attribution: http://www- 01.ibm.com/software/globalization/terminology/u.html#x2042481 quote IBM Terminology ... This site contains terms and definitions from many IBM software and hardware products as well as general computing terms. ... unformatted system service (USS) A communications function that translates a character-coded command, such as a LOGON or LOGOFF
Re: A z/OS Redbook Corrected - just about!
This could go another route and ask why every IBM product that is old, new or purchased via OEM, seems to be given the Tivoli brand name? ;-) On Tue, Mar 27, 2012 at 6:09 AM, Scott Ford scott_j_f...@yahoo.com wrote: After seeing this thread it's very apparent to me, IMHO, that someone at IBM missed the boat on the acronyms. Maybe an accident ? zUSS would have been better IMHO than calling Unix System Services , USS ...fwiw Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 27, 2012, at 8:21 AM, McKown, John john.mck...@healthmarkets.com wrote: Many, especially around here, would go with a different expansion of the first three characters. And it's not Point Of Sale. They don't like the POSIX / UNIX (since it is X/Open branded) portion of z/OS at all. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of J R Sent: Monday, March 26, 2012 9:34 PM To: IBM-MAIN@bama.ua.edu Subject: Re: A z/OS Redbook Corrected - just about! I agree, why not zUnix? Or z/Unix? However, since Lynn Wheeler has reminded us that z/OS Unix is (to some degree) POSIX compliant/compatible, why not adopt a catchy contraction of POSIX? I'd like to suggest z/POX, which also connotes the blight it has become on z/OS. ;-) ... Date: Mon, 26 Mar 2012 10:16:32 -0700 From: dickbond...@gmail.com Subject: Re: A z/OS Redbook Corrected - just about! To: IBM-MAIN@bama.ua.edu I agree with Chris Mason. IBM should have never started called it USS - how about a simple definitive abbreviation, like zUnix. IBM adores putting a z in front of everything (for some clueless reason) so why should their version of Unix be any different? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A z/OS Redbook Corrected - just about!
I agree with Chris Mason. IBM should have never started called it USS - how about a simple definitive abbreviation, like zUnix. IBM adores putting a z in front of everything (for some clueless reason) so why should their version of Unix be any different? On Wed, Mar 21, 2012 at 11:31 AM, Scott Ford scott_j_f...@yahoo.com wrote: Amen, heaven forbid the improve unix systems services, btw I have worked Vtam and unix, so amen brothers and sisters I ave seen the Chris light, teasing Chris . Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 21, 2012, at 11:57 AM, Kirk Wolf k...@dovetail.com wrote: Thank goodness IBM is spending time correcting USS atrocities rather than improving z/OS Unix. Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBM researchers make 12-atom magnetic memory bit
I have one card - punched with the eternal single finger salute! Fun times ... On Tue, Jan 17, 2012 at 2:02 PM, Rick Fochtman rfocht...@ync.net wrote: Anyone remember the 96-column cards? I'd like to find a box of them. Rick --**-- On 1/16/2012 10:13 PM, Mohd Rizwan wrote: Quite interesting On Sun, Jan 15, 2012 at 8:49 PM, Scott Fordscott_j_f...@yahoo.com wrote: Linda, This development is simply amazingas a dinosaur of the original 80 column card age ...things have really changed, big time Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 15, 2012, at 1:42 AM, Linda MooneyLinda.lstsrv@COMCAST.**NETlinda.lst...@comcast.net wrote: Hi zMan, Ah, well, whatz a couple of typpos among firends? :) Linda - Original Message - From: zManzedgarhoo...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Saturday, January 14, 2012 9:13:24 PM Subject: Re: IBM researchers make 12-atom magnetic memory bit On Sat, Jan 14, 2012 at 11:55 PM, Linda MooneyLinda.lstsrv@comcast.** net linda.lst...@comcast.net wrote: Hi John and Ed, Yowsers! That's really tiny! Just in my career - The first machine I was paid to work with was a 4341 with 8MB and 8 channels. My IPhone has 32MB. The possibilities of 2.5 Petabytes is, well, an awful lot. I can't help but wonder what some of the early computing pioneers would think of this. I suspect your iPhone has 32GB, not MB... And let's not start swapping You had 8MB? We had 5 bytes...and we LOVED it! stories, eh? Related, however: this could make a reality something I read a while ago suggestion that memory would soon be cheap enough that we could have HD video of our surroundings recording constantly. This could/would change things a fair bit, both good and bad. -- zMan -- I've got a mainframe and I'm not afraid to use it --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JES2 SPOOL QUESTION
$DJQ,spl=(v=xx)(see what is allocated to the volume) Note the parenthesis. $SSPL,(xx),p,cancel (purge remaining output on volume) On Tue, Aug 9, 2011 at 6:02 AM, John Dawes jhn_da...@yahoo.com.au wrote: G'Day, I am trying to find out what jobs (output) are occupying a certain spool volume. I issued the following command : $D JQ,SPL=V=(XMSPL4) however I receive other spool volumes. Is there another command which I can enter? Thanks. -- 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: CFSIZER?
Also ran into that here since we also followed the big bang theory while replacing two z9's with one z196. CFSIZER is ok if taken tongue-in-cheek, but some warning about CFLEVEL code size should be available somewhere. Wait state since GRS wouldn't come up due to not enough storage left in the CFs to allocate its structure. Doubled the size of the CF storage and all was well - but that was after trying various other things first since I had no warning of the code size increase. On Tue, Jul 5, 2011 at 5:55 AM, Mark Zelden m...@mzelden.com wrote: On Tue, 5 Jul 2011 11:48:37 +0200, mario@tiscali mbe...@tiscali.it wrote: Also, when moving to CFLEVEL17 don't forget that the size of the CF Control Code itself increases significantly. From some 100 MB to some 500 MB if I remember correctly. The CFCC LPAR memory definition should be updated to accomodate this. This is the one that bothered me - only because it was a surprise. I couldn't find anything written that told me it was normal nor was it mentioned in any of the z196 pre-install meetings that my client had. It took me a while to get confirmation from a large systems specialist within IBM that it was expected. He passed along this information from a colleague: the growth of the image is do to many enhancements in function and recovery in the CFCC 17 code. CFCC 17 on z196 has added some function and added enhanced recovery of the CF code. The number of supported structures was increased from 1023 to 2047 structures, the number of logical connection to a structure was increased, and the recovery was enhanced to improve nondisruptive MCL activation to maintain code levels and the ability to take nondisruptive CF dumps. CFCC recovery code has been added to take nondisruptive dumps of the CF and signal all connected images with a CRW machine check to invoke sysplex wide SVC and nondisruptive CF dumps for some CF recovery events to gather problem data. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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: zPRIME is Dead - Neon Surrenders to IBM
Is this really a surprise to anyone? On Tue, May 31, 2011 at 6:56 PM, Lizette Koehler stars...@mindspring.comwrote: NEON, a Texas-based maker of mainframe utility software, has settled its lawsuit with IBM and has agreed to stop selling its zPrime product. NEON Enterprise Software, a maker of mainframe software, announced it has settled its legal dispute with IBM and will immediately withdraw its zPrime product from the market. In the May 31 announcement, NEON said that pursuant to the terms of a permanent injunction, NEON and its distribution partners and affiliates will no longer market, sell, license--including any renewal or extension of any existing license, install, distribute, export, import, offer to sell, offer to license, offer to install, offer to distribute, offer to export or offer to import zPrime. Moreover, the legal dispute was settled with no payments having been made by either party to the other as part of the settlement. According to the NEON press release on the settlement: “The U.S. District Court has ruled that (1) only workloads expressly authorized by IBM may be processed on Specialty Engines (including zIIPs and zAAPs) and (2) IBM’s contracts, including the IBM Customer Agreement and the License Agreement for Machine Code, prohibit software (a) that enables workloads not expressly authorized by IBM to be processed on Specialty Engines or (b) that circumvents IBM’s technological measures in Machine Code that protect the Built-in Capacity of Specialty Engines and enables workloads not expressly authorized by IBM to be processed on Specialty Engines. Neon has agreed to a permanent injunction under which it will withdraw zPrime from the market and request that licensees and customers remove and destroy their copies of zPrime. Neon will not renew, extend or transfer any existing zPrime license or any warranty, maintenance or service period of any existing zPrime license (or any portion thereof).” NEON filed suit against IBM in the U.S. District Court for the Western District of Texas in December 2009, claiming IBM was using anticompetitive mainframe tactics. IBM came back and countersued NEON in January of 2010 for unfair business practices and anticompetitive behavior of its own, namely copyright violation. NEON then amended its complaint in February 2010 sharing more specific details of IBM’s alleged anticompetitive behavior. In a June 2009 press release announcing zPrime, NEON said: “NEON zPrime can save companies with System z mainframes 20 percent or more of their annual mainframe hardware and software costs under conventional use-pricing structures. Unlike any approach to date that attempts to offload processing from a System z central processor, or CP, to IBM specialty processors such as System z Integrated Information Processor (zIIP) or System z Application Assist Processors (zAAP), zPrime easily enables the shift of huge amounts of routine workloads running on CPs to these equally-fast but lower-cost specialty processors.” Meanwhile, this settlement with IBM does not affect any other NEON products, the company said. http://www.eweek.com/c/a/IT-Infrastructure/NEON-Settles-Mainframe-Software-L awsuit-with-IBM-848628/http://www.eweek.com/c/a/IT-Infrastructure/NEON-Settles-Mainframe-Software-L%0Aawsuit-with-IBM-848628/ Lizette -- 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: SMPPTS run out of Space (another approach)
*Exactly! *This is the correct way of doing RSU maintenance upgrades. It also solves some of the objections to the way RESTORE works as well. There are those who say they never ACCEPT maintenance which will cause a lot of problems which is then attributed to poor SMP/E design. SMP/E is the best thing since bacon-and-eggs if used properly. For the SMPPTS, I generally predefine 4-5 of them which works well for me but each shop is unique. Thanks. On Fri, Apr 29, 2011 at 9:47 PM, Linda Mooney linda.lst...@comcast.netwrote: As can be seen from the replies, there are different approaches for handling the PTS. In my shop, when a z/OS release is installed, the PTS is placed on a volume where it will have plenty of room. For the life of the install, PTFs are not purged from the PTS - ever. If necessary, spill PTS datasets are defined. We are not a large shop, and this works for us. *For ACCEPT, we generally run the ACCEPT of previous service just before beginning the next maintenance cycle. * Regards, Linda - Original Message - From: Mark Zelden m...@mzelden.com To: IBM-MAIN@bama.ua.edu Sent: Friday, April 29, 2011 7:45:39 AM Subject: Re: SMPPTS run out of Space (another approach) On Fri, 29 Apr 2011 15:25:36 +0200, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2011-04-29 15:18, Mark Zelden pisze: On Fri, 29 Apr 2011 12:30:59 +0530, saurabh khandelwal saurabh.khandel...@oracle.com wrote: Hello, Thanks for reply. I will check in my site about old PTF, which can be removed from PTS library and detail about accepted PTFs. Regards Saurabh Caution: SMP/E option PURGE(YES) is needed for the above. PURGE(NO) means the PTF is not deleted after ACCEPT. In simpler words: if you accept old PTFs then you don't need more PTS space for new PTFs. What R.S. didn't tell you was what to do if PURGE(NO) is specified. I have to run that way at one of my clients because while I maintain a single global zone / SMPPTS, I have multiple target zones for different companies within that shop (multiple per company to match the sysres set) and a single DLIB zone for each company. I can't clean up the SMPPTS until ACCEPT is done in all the DLIB zones (otherwise the 2nd and subsequent ACCEPTs get very angry when the sysmod is gone from the global zone / SMPPTS!) . What you have to do is run REJECT in PURGE mode. Simple enough: SETBOUNDARY (GLOBAL). REJECT PURGE (DLIB1,DLIB2,DLIB3,...). After I do that, I run CLEANUP against the maintenance target zones and compress the SMPPTS(es). Mark, I also have multiple DLIB and TARGET zones. My way to clean up PTS is to switch PURGE OFF, then perform ACCPET on every DLIB *except* last one, switch PURGE ON (YES) and then perform ACCEPT on the last one. It's error-prone ;-) Even if not error prone, seems like more work to me than it's worth. Also, for me, the different companies / business units don't always have the same schedules to roll out maintenance. So company A could be at RSU1009 and company B at RSU1012 and since I won't except anything that isn't at least 6 months old, the DLIB zones could be at different accept levels also. I have a question to the command above: REJECT PURGE(DLIB1,DLIB2,...) Is AND or OR between the zones? In other words: PTF accepted on every DLIB will be purged, what about PTF accepted on single DLIB? I should tell you to RTFM, but I like you. :-) It means to consider all the specified zones when doing the REJECT - so it is an AND condition. If only one zone was specified, it would only look at that one zone and could delete a PTF from the global zone that was not yet accepted into the other DLIB zone(s) being maintained. Cheers, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ *** Please note the new URL for Mark's MVS Utilities *** -- 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: The plural of 'virus'
Especially since I have read that Washington, Jefferson and their crew wanted to originally model the republic after the old Greek form of government. On Wed, Apr 13, 2011 at 11:08 AM, Bill Fairchild bi...@mainstar.com wrote: Latin is not dead. Many people converse in Latin around the world, especially within Vatican City. There is also a radio news broadcast in Latin: http://en.wikipedia.org/wiki/Nuntii_Latini At least one American public high school has conversational Latin classes: http://www.youtube.com/watch?v=GVBN0_UOL6I Thomas Jefferson began studying Latin and Greek when he was six years old. This was normal in the 1740s. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas H Puddicombe Sent: Wednesday, April 13, 2011 12:41 PM To: IBM-MAIN@bama.ua.edu Subject: Re: The plural of 'virus' Latin is a dead language It's dead as it can be First it killed the Romans And now it's killing me. Tom Puddicombe Mainframe Performance Capacity Planning CSC 71 Deerfield Rd, Meriden, CT 06450 ITIS | (860) 428-3252 | tpudd...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: Gibney, Dave gib...@wsu.edu To: IBM-MAIN@bama.ua.edu Date: 04/13/2011 11:11 AM Subject: Re: The plural of 'virus' -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shane Sent: Wednesday, April 13, 2011 5:44 AM To: IBM-MAIN@bama.ua.edu Subject: Re: The plural of 'virus' After that last effort I decided I'd better see who had trodden on Johns corns and caused him to fire up again. Dave, Dave, Dave ... That's a plan. I never had the opportunity to drop into Latin, let alone drop out. At the risk of another language lesson, c'est la vie. Next time we bump into each other in a bar this should keep us suitably entertained. Shane ... -- 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 -- 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: Fear the Internet, was Cool Things You Can Do in z/OS
We can connect to IBM and other known Internet websites just fine from our mainframes but some of our Intranet(s) are prohibited, like the one my PC is on. We also are not allowed remote access to our HMC(s). I can't vouch for our network people, I was just stating what they apparently consider to be security risks. These risks prevent connecting to was.exe on my PC from ISPF. On Tue, Apr 12, 2011 at 3:37 PM, Gibney, Dave gib...@wsu.edu wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Dick Bond Sent: Tuesday, April 12, 2011 3:19 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Cool Things You Can Do in z/OS That's a couple of big ifs - that's why we can't use it. Our workstation IP addresses, even if fixed (like mine - most are not), cannot be accessed from z/OS. I would think most real-world shops are that way - if not, well, they may need to hire some networking personnel to setup proper security. I am curious, why do some of the powers that be fear connecting their mainframe to the network. With proper vpn, there should be no reason to block z/OS from reaching out to users work stations. I wouldn't even insist on vpn if WSA would do SSL or SSH tunneling. And presumably much of this traffic would be on an intranet, not the wild and wooly Internet. There is no fear of virii, well maybe an application in java, but certainly not the system. Properly secured, a user can get anywhere they don't belong not matter what port or door they come in on. I'd truly hate the (IMO unneeded) extra steps to do Shopzseries or CA MSM without direct connection to IBM and CA's sites. Is there a real reason, not PHB paranoia that I'm missing? Dave Gibney Information Technology Services Washington State University -- 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: Fear the Internet, was Cool Things You Can Do in z/OS
I meant wsa.exe On Wed, Apr 13, 2011 at 2:43 PM, Dick Bond dickbond...@gmail.com wrote: We can connect to IBM and other known Internet websites just fine from our mainframes but some of our Intranet(s) are prohibited, like the one my PC is on. We also are not allowed remote access to our HMC(s). I can't vouch for our network people, I was just stating what they apparently consider to be security risks. These risks prevent connecting to was.exe on my PC from ISPF. On Tue, Apr 12, 2011 at 3:37 PM, Gibney, Dave gib...@wsu.edu wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Dick Bond Sent: Tuesday, April 12, 2011 3:19 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Cool Things You Can Do in z/OS That's a couple of big ifs - that's why we can't use it. Our workstation IP addresses, even if fixed (like mine - most are not), cannot be accessed from z/OS. I would think most real-world shops are that way - if not, well, they may need to hire some networking personnel to setup proper security. I am curious, why do some of the powers that be fear connecting their mainframe to the network. With proper vpn, there should be no reason to block z/OS from reaching out to users work stations. I wouldn't even insist on vpn if WSA would do SSL or SSH tunneling. And presumably much of this traffic would be on an intranet, not the wild and wooly Internet. There is no fear of virii, well maybe an application in java, but certainly not the system. Properly secured, a user can get anywhere they don't belong not matter what port or door they come in on. I'd truly hate the (IMO unneeded) extra steps to do Shopzseries or CA MSM without direct connection to IBM and CA's sites. Is there a real reason, not PHB paranoia that I'm missing? Dave Gibney Information Technology Services Washington State University -- 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: Cool Things You Can Do in z/OS
That's a couple of big ifs - that's why we can't use it. Our workstation IP addresses, even if fixed (like mine - most are not), cannot be accessed from z/OS. I would think most real-world shops are that way - if not, well, they may need to hire some networking personnel to setup proper security. On Tue, Apr 12, 2011 at 6:39 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In banlktiksfdfnavkz0nhk5tg7df0wry+...@mail.gmail.com, on 04/08/2011 at 03:52 PM, Dick Bond dickbond...@gmail.com said: a couple of glitches - make sure have a fixed IP address for your workstation That's not necessary if you are running a current release unless 1. You are running a session manager that can't pass on the IP address 2. You don't have dynamic DNS to associate a fixed A RR to the floating IP address. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@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: Cool Things You Can Do in z/OS
a couple of glitches - make sure have a fixed IP address for your workstation (could be a big glitch in some shops) and also, if you are lucky to have a fixed IP address, make sure you can ping it from your ISPF session before bothering to set this up - if you can't ping it for one reason or another (eg, firewall rules), it isn't going to work. Thank you, Dick Bond SofW DIS On Fri, Apr 8, 2011 at 2:02 PM, Rick Fochtman rfocht...@ync.net wrote: * Finally, to make the list, the cool thing has to be taught in one or more of our courses + So we name a cool feature and can also show you where to learn how to use it (Of course, one can theoretically learn these things oneself by reading and trial and error; but we write courses to save you the trouble. Some shops refuse to spend the money. And, yes, it's shortsighted, but that's a rant for another day. --unsnip--- Only a day? Room for a full month's rant, at least! :-) Rick -- 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
