Re: REPLY DEVICE NAME OR 'CANCEL' for FTP to mainframe and SMS ACS routines
Hi, have you tried to activate SMS for FTP: ;MGMTCLASS SMSMGMT ; sms mgmtclass name ;DATACLASS SMSDATA ; sms data class name in the TCPIP.FTP.DATA (or whatever name it has in your installation)? Denis. -Original Message- From: Fred Schmidt To: IBM-MAIN@bama.ua.edu Sent: Thu, Apr 29, 2010 7:49 am Subject: REPLY DEVICE NAME OR 'CANCEL' for FTP to mainframe and SMS ACS routines Issued: Error! Unknown document property name. iii We are seeing... IEF244I ZZZ STEP1 - UNABLE TO ALLOCATE 1 UNIT(S) 969 AT LEAST 1 OFFLINE UNIT(S) NEEDED. IEF877E ZZZ NEEDS 1 UNIT(S) 970 FOR STEP1 SYS1 FOR VOLUME PRIVAT- 1 OFFLINE 1004-1007 1011-1012 1027-1028 102E-1033 1035-1039 103B-103D 1042-1049 IEF878I END OF IEF877E FOR ZZZ STEP1 SYS1 05 IEF238D ZZZ - REPLY DEVICE NAME OR 'CANCEL'. ... when FTP'ing from userid=ZZZ a file to the mainframe named ZZZ.TEST.DATA. It fails because the request is for a non-SMS allocation with no VOLSER specified and we do not have any volumes mounted STORAGE. We want the allocation to fail, as we don't want these FTP userids to create datasets under their own HLQ, only transfer other files. But we don't want the WTOR. I've tried setting a DFP segment for userid ZZZ, with STORCLAS= FAILALOC and in the STORCLAS routine coding ... WHEN ((&DSOWNER = '') OR (&DEF_STORCLAS = 'FAILALOC')) DO SET &STORCLAS = '' WRITE 'DATASET ALLOCATION FAILED' WRITE 'HIGH LEVEL QUALIFIER (HLQ) IS NOT DEFINED' WRITE 'PLEASE CONTACT YOUR SECURITY ADMINISTRATOR' EXIT CODE(0) END This works as intended for allocations via TSO/Batch. But it does not prevent the WTOR for FTP's. Is there some way that I can prevent the WTOR for FTP using SMS? Or do I have to use ALLOCxx to cancel all allocation requests? I would rather not, as this has implications for all allocations and it is only FTP that has the problem. Regards, Fred Schmidt NT Government, Australia -- 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
REPLY DEVICE NAME OR 'CANCEL' for FTP to mainframe and SMS ACS routines
Issued: Error! Unknown document property name. iii We are seeing... IEF244I ZZZ STEP1 - UNABLE TO ALLOCATE 1 UNIT(S) 969 AT LEAST 1 OFFLINE UNIT(S) NEEDED. IEF877E ZZZ NEEDS 1 UNIT(S) 970 FOR STEP1 SYS1 FOR VOLUME PRIVAT- 1 OFFLINE 1004-1007 1011-1012 1027-1028 102E-1033 1035-1039 103B-103D 1042-1049 IEF878I END OF IEF877E FOR ZZZ STEP1 SYS1 05 IEF238D ZZZ - REPLY DEVICE NAME OR 'CANCEL'. ... when FTP'ing from userid=ZZZ a file to the mainframe named ZZZ.TEST.DATA. It fails because the request is for a non-SMS allocation with no VOLSER specified and we do not have any volumes mounted STORAGE. We want the allocation to fail, as we don't want these FTP userids to create datasets under their own HLQ, only transfer other files. But we don't want the WTOR. I've tried setting a DFP segment for userid ZZZ, with STORCLAS= FAILALOC and in the STORCLAS routine coding ... WHEN ((&DSOWNER = '') OR (&DEF_STORCLAS = 'FAILALOC')) DO SET &STORCLAS = '' WRITE 'DATASET ALLOCATION FAILED' WRITE 'HIGH LEVEL QUALIFIER (HLQ) IS NOT DEFINED' WRITE 'PLEASE CONTACT YOUR SECURITY ADMINISTRATOR' EXIT CODE(0) END This works as intended for allocations via TSO/Batch. But it does not prevent the WTOR for FTP's. Is there some way that I can prevent the WTOR for FTP using SMS? Or do I have to use ALLOCxx to cancel all allocation requests? I would rather not, as this has implications for all allocations and it is only FTP that has the problem. Regards, Fred Schmidt NT Government, Australia -- 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: ZFS
On 28 April 2010 19:37, Martinez, Frank J wrote: > MVT was not broken. Are you still running it? Well, MVT *was* seriously broken in many ways. I remember the operators struggling to get the nightly jobs through, using all their wits to release the right work to arrange the regions so that the right number of things would fit in the available real storage. MVT had no system integrity or security at all. Password "security" was trivially bypassed, and any informed undergrad could get into supervisor state in a few lines of code. There was no fetch protection for all that real storage, so anyone could troll through storage looking for interesting strings. One day, one of those undergrads who we would today call a script kiddy, ran an IEHPROGM SCRATCH VTOC on all the packs whose names he could figure out. He was caught, but not by the system. Do you remember TCAM...? IEHMOVE...? TSO with swapping and a hard region size (real storage again) and no ability to run in batch...? CRJE...? HASP-II...? It is indeed fun to play with on an emulator in 2010, but to say it wasn't broken... Tony H. -- 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: 25 reasons why hardware is still hot at IBM
take on competition effect on the market and the mainframe pricing Financial Matters: Mainframe Processor Pricing History http://www.zjournal.com/index.cfm?section=article&aid=346 from above (2006) article: is that the price per MIPS today is approximately six times higher than the $165 per MIPS that the traditional technology/price decline link would have produced ... snip ... past posts in this thread: http://www.garlic.com/~lynn/2010h.html#51 25 reasons why hardware is still hot at IBM http://www.garlic.com/~lynn/2010h.html#56 25 reasons why hardware is still hot at IBM http://www.garlic.com/~lynn/2010h.html#62 25 reasons why hardware is still hot at IBM http://www.garlic.com/~lynn/2010h.html#63 25 reasons why hardware is still hot at IBM http://www.garlic.com/~lynn/2010h.html#66 25 reasons why hardware is still hot at IBM http://www.garlic.com/~lynn/2010h.html#70 25 reasons why hardware is still hot at IBM http://www.garlic.com/~lynn/2010h.html#71 25 reasons why hardware is still hot at IBM http://www.garlic.com/~lynn/2010h.html#79 25 reasons why hardware is still hot at IBM -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- 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: 25 rea sons why h ardware is still hot at IBM?
On Wed, Apr 28, 2010 at 9:39 PM, Clark Morris wrote: > Ask the various organizations that are making serious use of them. My > guess is possibly SAP, Oracle and various Websphere based services. > Huh? I was asking what the Linux machines at the grocery chain were being used for. I'm well aware of Linux on System z. -- 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: 25 rea sons why h ardware is still hot at IBM?
On 28 Apr 2010 14:01:43 -0700, in bit.listserv.ibm-main you wrote: >--- >What do the Linux machines provide? Web serving? Free donuts? Inquiring >minds want to know!! Ask the various organizations that are making serious use of them. My guess is possibly SAP, Oracle and various Websphere based services. Take a look at catalogs of Linux based applications. It is probably easier to move a Unix based application to Linux which is ASCII or Unicode than to z/OS Unix using EBCDIC. There is DB2 and Oracle for zLinux if I recall correctly. Also remember once we may have been pimple faced operators, college grads and application programmers. Using Linux under VM for serious work causes people to mature or be forced out. >- >Mostly, jobs for PFCSK's, as LINUX administrators. :-) > >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
Re: ZFS
On 28 Apr 2010 17:55:35 -0700, in bit.listserv.ibm-main you wrote: >Some people are. Other than on Hercules and similar as a hobby, where, on what and why? > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On >> Behalf Of Martinez, Frank J >> Sent: Wednesday, April 28, 2010 7:37 PM >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: ZFS >> >> MVT was not broken. Are you still running it? >> >> >> rest snipped -- 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: ZFS
Some people are. > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Martinez, Frank J > Sent: Wednesday, April 28, 2010 7:37 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: ZFS > > MVT was not broken. Are you still running it? > > > From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of > John Mattson [john_matt...@ea.epson.com] > Sent: Wednesday, April 28, 2010 3:44 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: ZFS > > If HFS ain't broke... why "fix" it? > > > > > Bruce Burgdoff > Sent by: IBM Mainframe Discussion List > 04/27/2010 10:15 AM > Please respond to > IBM Mainframe Discussion List > Expire Date: 04/27/2012 > > > To > IBM-MAIN@bama.ua.edu > cc > > Subject > ZFS > > > > > > > Our upcoming migration from HFS to zFS for the root file systems is > causing a > new problem for us. > > > > The previous maintenance method was to keep the HFS root file system on > the sysres with all other non-VSAM SMPE-target files. All datasets were > implicitly cataloged at IPL time. By replacing the SYSRES volume a > total > replacement or back-off of maintenance was just an IPL away. We > currently > are running from a single mod 27 sysres. The rest of the HFS/ZFS file > systems > will be mounted from other non-SMPE impacted volumes. > > > > The zFS file systems on the other hand is subject to the special volume > ownership and naming requirements of VSAM. We can no-longer use a > simple > full volume copies to transfer the test SYSRES to production. Further > it > looks > like a second dump will need to be done of the test zFS root files and > then a > restore with the RENAMEU option run made under the production master > catalog. We may even have to put the zFS files on separate sysres > volumes > which are "owned" by the production system catalog structure. > > > > Does this make sense or what are some other ideas to maintain the new > zFS > root files? > > > > -- > 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: ZFS
MVT was not broken. Are you still running it? From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of John Mattson [john_matt...@ea.epson.com] Sent: Wednesday, April 28, 2010 3:44 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ZFS If HFS ain't broke... why "fix" it? Bruce Burgdoff Sent by: IBM Mainframe Discussion List 04/27/2010 10:15 AM Please respond to IBM Mainframe Discussion List Expire Date: 04/27/2012 To IBM-MAIN@bama.ua.edu cc Subject ZFS Our upcoming migration from HFS to zFS for the root file systems is causing a new problem for us. The previous maintenance method was to keep the HFS root file system on the sysres with all other non-VSAM SMPE-target files. All datasets were implicitly cataloged at IPL time. By replacing the SYSRES volume a total replacement or back-off of maintenance was just an IPL away. We currently are running from a single mod 27 sysres. The rest of the HFS/ZFS file systems will be mounted from other non-SMPE impacted volumes. The zFS file systems on the other hand is subject to the special volume ownership and naming requirements of VSAM. We can no-longer use a simple full volume copies to transfer the test SYSRES to production. Further it looks like a second dump will need to be done of the test zFS root files and then a restore with the RENAMEU option run made under the production master catalog. We may even have to put the zFS files on separate sysres volumes which are "owned" by the production system catalog structure. Does this make sense or what are some other ideas to maintain the new zFS root files? -- 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: 25 reasons why hardware is still hot at IBM
On Wed, Apr 28, 2010 at 5:02 PM, Clark Morris wrote: > They may be better than nothing but with inadequate help they may mean > the people who are entering data may be making mistakes they > shouldn't. I have run into cases where wrong actions were taken for > years. Business initiatives may be stifled because of inflexibility. > In some cases, it may become impossible to go to a new operating > system release or more current hardware (same thing is true in PC > arena). The people stuck with try to do a job using these > applications (the users) may become increasingly hamstrung and forced > to engage in unnatural workarounds (the Avis car rental application > that didn't know what to do with foreign postal codes forcing rental > agents to fake it). > So those are real requirements that, if recognized, might (might!) justify the fix. But "they're grotty" isn't a reason. -- 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: 25 rea sons why h ardware i s still hot at IBM
On Wed, Apr 28, 2010 at 4:55 PM, Rick Fochtman wrote: > And leave us not forget: it's business needs that drive IT technology, not > the opposite. > Exactly. Like I said, I'd *want* to "fix" them, but if there's no pressing business problem that they'll solve, I should be restrained from doing so. -- 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: 25 reasons why hardware is still hot at IBM
On 28 Apr 2010 10:40:17 -0700, in bit.listserv.ibm-main you wrote: >On Wed, Apr 28, 2010 at 1:05 PM, Clark Morris wrote: > >> Granted this is based on the applications that I worked on personally >> over the past 20 years but most of them were difficult to change, had >> interesting anomalies in them and were poorly documented at best. >> While this represents only 4 shops including one that had moved COBOL >> batch and CICS to HP-UX from the mainframe, I suspect that it is true >> elsewhere. Some of those applications have since been replaced. I >> suspect the help function for users in most CICS systems stinks again >> based on my limited experience. >> > >OK, but if they work, they're "good enough". Sure, you and I would be >itching to 'fix' them, but that's an urge we should resist. They may be better than nothing but with inadequate help they may mean the people who are entering data may be making mistakes they shouldn't. I have run into cases where wrong actions were taken for years. Business initiatives may be stifled because of inflexibility. In some cases, it may become impossible to go to a new operating system release or more current hardware (same thing is true in PC arena). The people stuck with try to do a job using these applications (the users) may become increasingly hamstrung and forced to engage in unnatural workarounds (the Avis car rental application that didn't know what to do with foreign postal codes forcing rental agents to fake it). > >-- >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: 25 rea sons why h ardware is still hot at IBM
--- What do the Linux machines provide? Web serving? Free donuts? Inquiring minds want to know!! - Mostly, jobs for PFCSK's, as LINUX administrators. :-) 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
Re: 25 rea sons why h ardware i s still hot at IBM
-- I disagree. My own experience of these applications has been different. Most do "work", in the sense that they get some useful processing done; but this is the only favorable thing that it occurs to me to say about them: o In most shops more resources are devoted to routine, trivial maintenance, accomplished ad hoc, than to either new-system development or significant system extensions; o They employ obsolete compile-time bound, move-orient[at]ed, synchronous technology that pours concrete over their company's business plans; o They are radically inflexible, full of ad hoc "design' limitations that permit them to take cognizance of at most 4 or 7 widgets, at most 6 gidgets, and the like; o They have not been designed; they are radically incoherent because bits and pieces of them have evolved in many different directions under many disparate impeti; o They reflect no understanding of the distinction between functional requirements and processing strategies, of the notion that requirements do not dictate implementations; o Qua programs, they are disasters: one of the founding fathers observed long ago that COBOL programmers could in his experience be divided into two disjoint subsets, there were those, a moiety, who did not know what binary search was and then there were those few who did and were pround of this arcane knowledge; and this situation is little changed today; o IT management is technically ill-informed, petulant, and risk-aversive. Fatuous defense of what is will not save the platform. Nor will crackpot realism of the if-it-isn't-broken-don't-fix-it sort. What is worse is that moving to another environment will not usually help either. The same people will replicate the same ills in it. That's a lot of generalizations, most of which I must strongly dispute. I've seen a few shops that fit some of your statements, but none that fit all. And leave us not forget: it's business needs that drive IT technology, not the opposite. 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
Re: ZFS
On Wed, 28 Apr 2010 12:44:50 -0700, John Mattson wrote: >If HFS ain't broke... why "fix" it? > They wanted to invent aggregates, but those didn't work, so they've been deprecated. (Oh! _That_ ZFS.) -- gil -- 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: 25 rea sons why h ardware is still hot at IBM?
On 28 Apr 2010 12:18:47 -0700, in bit.listserv.ibm-main you wrote: >About mainframe business applications, Zman writes: > >| OK, but if they work, they're "good enough". Sure, you >| and I would be itching to 'fix' them, but that's an urge we | should resist. > >I disagree. > >My own experience of these applications has been different. Most do "work", >in the sense that they get some useful processing done; but this is the only >favorable thing that it occurs to me to say about them: > >o In most shops more resources are devoted to routine, trivial maintenance, >accomplished ad hoc, than to either new-system development or significant >system extensions; > >o They employ obsolete compile-time bound, move-orient[at]ed, synchronous >technology that pours concrete over their company's business plans; Many of the systems still really date back to the 1960's where the limitations of the time meant far more compile time freezing as opposed to run time. > >o They are radically inflexible, full of ad hoc "design' limitations that >permit them to take cognizance of at most 4 or 7 widgets, at most 6 gidgets, >and the like; > >o They have not been designed; they are radically incoherent because bits and >pieces of them have evolved in many different directions under many disparate >impeti; > >o They reflect no understanding of the distinction between functional >requirements and processing strategies, of the notion that requirements do not >dictate implementations; > >o Qua programs, they are disasters: one of the founding fathers observed long >ago that COBOL programmers could in his experience be divided into two >disjoint subsets, there were those, a moiety, who did not know what binary >search was and then there were those few who did and were pround of this >arcane knowledge; and this situation is little changed today; Getting a sorted table from input if the input isn't already sorted requires one to either know sorting techniques or use the SORT verb. SEARCH ALL (more efficient, usually binary but up to the implementer) came in with the 1974 standard but did require someone to know what they were doing. I was not impressed with the implementation in COBOL 74 and don't recall checking the generated code to see if COBOL II or COBOL for MVS and VM improved it. At one shop, programming was on the rotation for accounting and marketing types. > >o IT management is technically ill-informed, petulant, and risk-aversive. The first and third can be true (especially the third) if the management comes from outside IT. > >Fatuous defense of what is will not save the platform. Nor will crackpot >realism of the if-it-isn't-broken-don't-fix-it sort. > >What is worse is that moving to another environment will not usually help >either. The same people will replicate the same ills in it. If most of the problem is management and management attitude, platform change may cure it by fiasco. More dangerous are those who still believe sales people implicitly. > >John Gilmore Ashland, MA 01721-1817 USA > > > >_ >The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with >Hotmail. >http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 > >-- >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: 25 reasons why hardware is still hot at IBM
- Bay City, MI had several mainframes 25 years ago. To my knowledge they now have none, and it has been that way for almost twenty years. Back in those days most banks and hospitals and many manufacturers and insurance companies had one. (Pre merger mania there were a lot more banks and hospitals back then). I would be surprised if there was much more than a dozen mainframe shops in Michigan today. -- You should be surprised. The auto industry alone operates that many. IIRC, GM runs/owns half a dozen. 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
Re: HFS Copy Problem
We may have found the solution. Looks good so far. RTM I learned that with RENAMEU the REPLACE keyword is ignored which is probably why we were deleting the HFS files in the previous step. We changed REPLACE with REPLACEU. (The book says "When used with the RENAMEU usable preallocated data sets with the new name are replaced. If no preallocated target is found, DFSMSdss attempts to allocate a data set.") Looking further I spotted PROCESS(SYS1) and added that to the mix. I've run the job twice with consecutive cc=0. One would think I'd need the PROCESS even now but there's no time to question this. Thanks for all the replies Alan Schwartz Infrastructure Management Sr. Analyst -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Kelly Sent: Wednesday, April 28, 2010 2:41 PM To: IBM-MAIN@bama.ua.edu Subject: Re: HFS Copy Problem I'm not too sure what you have but I do remember that 1.7 to 1.9 (I think) was a problem with VSAM and UCATs. The jobs would run OK but the data wasn't available in 1.9. The way that would work is to stop using ... CAT(...) and use SSA on the 1.7 system. A pain but it works. There have been several thread about this issue, so the archive might be helpful. HTH Jack Kelly 202-502-2390 (Office) -- 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: 25 rea sons why h ardware is still hot at IBM
On Wed, Apr 28, 2010 at 4:36 PM, Bob goolsby wrote: > My SO works for a Largish Grocery-Store chain. They did a pilot > project last year that took-off beyond all expectations. The Pilot > was set up on a (note: A, Single, Solitary, Lone) Linux server in the > smallest region of the LGS; in case the Pilot failed, the bad PR would > be limited to a couple of states in the US mid-west. It took two > weeks from the time the pilot started until the server fell over with > ETOOMANYCONN. They added a second server and a DNS round-robin; that > lasted another day and a half. > > The Pilot was planned to run for six months. At the end of the fifth > week, the LGS declared the Pilot a success. They were up to fifteen > servers behind a load-balancer and the load was still growing by 5% > week over week. The 'Project' went back to the Architects for > re-thinking. > > It was decided that, based on the results in their smallest market, > this was going to have to be a Main Frame Application, since a z-Box > was the only thing that had a remote change of keeping up. > > This will be the first new application on the Main Frame Systems in at > least fifteen years; it will be the first Customer Facing Application > on the Main Frame at the LGS, ever. And the Architects are scrambling > to see whether they can find anything from Barracuda Networks big > enough to load-balance a z-Machine Cluster. > What do the Linux machines provide? Web serving? Free donuts? Inquiring minds want to know!! -- 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: 25 rea sons why h ardware is still hot at IBM
My SO works for a Largish Grocery-Store chain. They did a pilot project last year that took-off beyond all expectations. The Pilot was set up on a (note: A, Single, Solitary, Lone) Linux server in the smallest region of the LGS; in case the Pilot failed, the bad PR would be limited to a couple of states in the US mid-west. It took two weeks from the time the pilot started until the server fell over with ETOOMANYCONN. They added a second server and a DNS round-robin; that lasted another day and a half. The Pilot was planned to run for six months. At the end of the fifth week, the LGS declared the Pilot a success. They were up to fifteen servers behind a load-balancer and the load was still growing by 5% week over week. The 'Project' went back to the Architects for re-thinking. It was decided that, based on the results in their smallest market, this was going to have to be a Main Frame Application, since a z-Box was the only thing that had a remote change of keeping up. This will be the first new application on the Main Frame Systems in at least fifteen years; it will be the first Customer Facing Application on the Main Frame at the LGS, ever. And the Architects are scrambling to see whether they can find anything from Barracuda Networks big enough to load-balance a z-Machine Cluster. B 2010/4/28 john gilmore : > About mainframe business applications, Zman writes: > > | OK, but if they work, they're "good enough". Sure, you > | and I would be itching to 'fix' them, but that's an urge we | should resist. > > I disagree. > > My own experience of these applications has been different. Most do "work", > in the sense that they get some useful processing done; but this is the only > favorable thing that it occurs to me to say about them: > > o In most shops more resources are devoted to routine, trivial maintenance, > accomplished ad hoc, than to either new-system development or significant > system extensions; > > o They employ obsolete compile-time bound, move-orient[at]ed, synchronous > technology that pours concrete over their company's business plans; > > o They are radically inflexible, full of ad hoc "design' limitations that > permit them to take cognizance of at most 4 or 7 widgets, at most 6 gidgets, > and the like; > > o They have not been designed; they are radically incoherent because bits and > pieces of them have evolved in many different directions under many disparate > impeti; > > o They reflect no understanding of the distinction between functional > requirements and processing strategies, of the notion that requirements do > not dictate implementations; > > o Qua programs, they are disasters: one of the founding fathers observed long > ago that COBOL programmers could in his experience be divided into two > disjoint subsets, there were those, a moiety, who did not know what binary > search was and then there were those few who did and were pround of this > arcane knowledge; and this situation is little changed today; > > o IT management is technically ill-informed, petulant, and risk-aversive. > > Fatuous defense of what is will not save the platform. Nor will crackpot > realism of the if-it-isn't-broken-don't-fix-it sort. > > What is worse is that moving to another environment will not usually help > either. The same people will replicate the same ills in it. > > John Gilmore Ashland, MA 01721-1817 USA > > > > _ > The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with > Hotmail. > http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 > > -- > 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 > -- Bob Goolsby bob.gool...@gmail.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
Re: HFS Copy Problem
I searched the archive (but not older stuff). The frustrating part is I can get a good copy by deleting the HFS off the volume and doing a 'delete noscratch'. Then the DFDSS step seems to work perfectly. Listcat of the HFS specifying the 1.9 mcat shows the entry and it's on the OUTDYNAM volume with the new name. But when I try and rerun with a normal delete I get the IKJ56228I message. I'm looking at everything I can think of but no luck so far. I did define an SSA when I defined the catalog. I'll give it a try. Thanks for the suggestion Alan Schwartz Infrastructure Management Sr. Analyst -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Kelly Sent: Wednesday, April 28, 2010 2:41 PM To: IBM-MAIN@bama.ua.edu Subject: Re: HFS Copy Problem I'm not too sure what you have but I do remember that 1.7 to 1.9 (I think) was a problem with VSAM and UCATs. The jobs would run OK but the data wasn't available in 1.9. The way that would work is to stop using ... CAT(...) and use SSA on the 1.7 system. A pain but it works. There have been several thread about this issue, so the archive might be helpful. HTH Jack Kelly 202-502-2390 (Office) -- 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: server pac install and RACFDRV
Yes, the RACF commands which come with ServerPac have the potential to
reallty muck up things if you are not VERY Careful.
I would very much like to see most every RACF command have an option
something like EXEC(DISPLAY | IFNOTEXIST | EXEC) to allow :
1) Just display the "thing(s)" affected by the command
2) Only create if not already exist or active
3) Do it...
(There might be other good options, but these come to mind). Or Perhaps a
PARM on the executing program to do the same for the commands. This would
allow you to mass change the "EXEC(" parm to get a better idea of how the
RACFDRV commands compare to what you already have in place.
Tim Brown
Sent by: IBM Mainframe Discussion List
04/27/2010 05:32 AM
Please respond to
IBM Mainframe Discussion List
Expire Date: 04/27/2012
To
IBM-MAIN@bama.ua.edu
cc
Subject
server pac install and RACFDRV
As part of the server pack install a job called RACFDRV is run
to modify the driving systems RACF. Back when we upgraded from
1.7 to 1.9 I first ran this on our test Z/OS to determine if
would have any affect when we had to run it on our production
system.
Is this still best practice. Is there a way to run it in a way
that updates are not performed but just checking what would be
updated ?
If it just adds definitions where necessary how would that prevent
a production system fronm failing. Has anyone ever experienced a
situation where it did cause problems.
Tim Brown
Systems Specialist - Project Leader
Central Hudson Gas & Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbr...@cenhud.com
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255
This message contains confidential information and is only for the
intended recipient. If the reader of this message is not the intended
recipient, or an employee or agent responsible for delivering this message
to the intended recipient, please notify the sender immediately by
replying to this note and deleting all copies and attachments. Thank you.
--
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: ZFS
If HFS ain't broke... why "fix" it? Bruce Burgdoff Sent by: IBM Mainframe Discussion List 04/27/2010 10:15 AM Please respond to IBM Mainframe Discussion List Expire Date: 04/27/2012 To IBM-MAIN@bama.ua.edu cc Subject ZFS Our upcoming migration from HFS to zFS for the root file systems is causing a new problem for us. The previous maintenance method was to keep the HFS root file system on the sysres with all other non-VSAM SMPE-target files. All datasets were implicitly cataloged at IPL time. By replacing the SYSRES volume a total replacement or back-off of maintenance was just an IPL away. We currently are running from a single mod 27 sysres. The rest of the HFS/ZFS file systems will be mounted from other non-SMPE impacted volumes. The zFS file systems on the other hand is subject to the special volume ownership and naming requirements of VSAM. We can no-longer use a simple full volume copies to transfer the test SYSRES to production. Further it looks like a second dump will need to be done of the test zFS root files and then a restore with the RENAMEU option run made under the production master catalog. We may even have to put the zFS files on separate sysres volumes which are "owned" by the production system catalog structure. Does this make sense or what are some other ideas to maintain the new zFS root files? -- 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: HFS Copy Problem
I'm not too sure what you have but I do remember that 1.7 to 1.9 (I think) was a problem with VSAM and UCATs. The jobs would run OK but the data wasn't available in 1.9. The way that would work is to stop using ... CAT(...) and use SSA on the 1.7 system. A pain but it works. There have been several thread about this issue, so the archive might be helpful. HTH Jack Kelly 202-502-2390 (Office) -- 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: DFHSM QUESTION - MOVING TO DASD FROM TAPE - ML2
On Wed, 28 Apr 2010 03:20:15 -0700, Ron Hawkins wrote: >Mike, > >Well if you want any sort of decent, scalable performance you wouldn't want >an SVA. You would want a USP-V. > >Ron Thanks for the reco, Ron! Regards, Mike Baldwin Cartagena Software Ltd. Markham, Ontario, Canada http://www.cartagena.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
Re: 25 rea sons why h ardware is still hot at IBM
About mainframe business applications, Zman writes: | OK, but if they work, they're "good enough". Sure, you | and I would be itching to 'fix' them, but that's an urge we | should resist. I disagree. My own experience of these applications has been different. Most do "work", in the sense that they get some useful processing done; but this is the only favorable thing that it occurs to me to say about them: o In most shops more resources are devoted to routine, trivial maintenance, accomplished ad hoc, than to either new-system development or significant system extensions; o They employ obsolete compile-time bound, move-orient[at]ed, synchronous technology that pours concrete over their company's business plans; o They are radically inflexible, full of ad hoc "design' limitations that permit them to take cognizance of at most 4 or 7 widgets, at most 6 gidgets, and the like; o They have not been designed; they are radically incoherent because bits and pieces of them have evolved in many different directions under many disparate impeti; o They reflect no understanding of the distinction between functional requirements and processing strategies, of the notion that requirements do not dictate implementations; o Qua programs, they are disasters: one of the founding fathers observed long ago that COBOL programmers could in his experience be divided into two disjoint subsets, there were those, a moiety, who did not know what binary search was and then there were those few who did and were pround of this arcane knowledge; and this situation is little changed today; o IT management is technically ill-informed, petulant, and risk-aversive. Fatuous defense of what is will not save the platform. Nor will crackpot realism of the if-it-isn't-broken-don't-fix-it sort. What is worse is that moving to another environment will not usually help either. The same people will replicate the same ills in it. John Gilmore Ashland, MA 01721-1817 USA _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 -- 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: HFS Copy Problem
On Wed, 28 Apr 2010 13:52:23 -0500, Schwartz, Alan wrote: >I don't think so. We always make sure the lpar that is the source for >the copies is down. >At the moment I have no 1.9 lpars ipled so the HFS shouldn't be >allocated anywhere. >The catalog, if it's allocated anywhere, should be to CAS. Your >response did make me check >The mcat attributes in case the SHROPTNS got altered but they all show >3,4 > >Alan Schwartz >Infrastructure Management Sr. Analyst >Affiliated Computer Services >A Xerox Company >612-726-4505 > >-Original Message- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On >Behalf Of Patrick Lyon >Sent: Wednesday, April 28, 2010 1:42 PM >To: IBM-MAIN@bama.ua.edu >Subject: Re: HFS Copy Problem > >On Wed, 28 Apr 2010 13:26:21 -0500, Schwartz, Alan INC.COM> wrote: > >> DELETE SYS1.OMVS.AAOPROOT.M2OMA1 CAT >(SYS1.MCATZS19.MVS2) >>IKJ56228I DATA SET SYS1.OMVS.AAOPROOT.M2OMA1 NOT IN CATALOG OR >CATALOG >>IKJ56228I CAN NOT BE ACCESSED > >>IDC0551I ** ENTRY SYS1.OMVS.AAOPROOT.M2OMA1 NOT >DELETED >>IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS >8 > >Alan - is the file allocated on that other LPAR (Or elsewhere?) > >Looking up the message: >IKJ56228I DATA SET dsname NOT IN CATALOG or CATALOG CANNOT BE >ACCESSED > > >Explanation: DISP=OLD was specified. The dynamic allocation error code >is >1708, 5708, or 5710. For a description of the dynamic allocation return, > >informational, and error codes, refer to z/OS MVS Programming: >Authorized >Assembler Services Guide. > Here are the return codes referenced above. Was this file copied on this system? Is the catalog in question import connected to this mastercat? 1708 Meaning: One of the following occurred: ° The data set name specified is in error. (program error) ° A system error occurred when processing the data set name. In the request block, the S99INFO field contains the text unit key instead of an information reason code. See the corresponding message for the specific error. Application Programmer Action: Ensure that the correct data set name was specified. If a generation data group (GDG) level of index was coded for a non-GDG data set, remove the level of index and resubmit the job. Otherwise, this is probably a system error. Resubmit the request. If the problem persists, report the associated messages and DYNALLOC error codes to your system programmer. System Programmer Action: If the problem recurs and no installation action corrects the problem, search problem reporting data bases for a fix for the problem. If no fix exists, contact the appropriate IBM support personnel. Corresponding Messages: IKJ56228I or IKJ56229I 5708 Meaning: Either the existing catalog structure is inconsistent with the operation, or the program was not authorized to perform the operation. Application Programmer Action: Consult the z/OS DFSMSdfp Advanced Services, correct the error, and resubmit the request. - 5710 Meaning: The index structure necessary to catalog the data set does not exist. Application Programmer Action: Consult the z/OS DFSMSdfp Advanced Services, correct the error, and resubmit the request. -- 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: how big is big?
Try this http://www.arcati.com/newyearbook10 Chart 4 on page 44 Mike On Wed, Apr 28, 2010 at 8:58 PM, Kirk Talman wrote: > what is the size (in mips?) are the datacenters or companies that it takes > to make the 1st, 2nd ... quintile? Is that published? > > - > The information contained in this communication (including any > attachments hereto) is confidential and is intended solely for the > personal and confidential use of the individual or entity to whom > it is addressed. If the reader of this message is not the intended > recipient or an agent responsible for delivering it to the intended > recipient, you are hereby notified that you have received this > communication in error and that any review, dissemination, copying, > or unauthorized use of this information, or the taking of any > action in reliance on the contents of this information is strictly > prohibited. If you have received this communication in error, > please notify us immediately by e-mail, and delete the original > message. Thank you > > -- > 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 > -- Mike Shorkend m...@shorkend.com www.shorkend.com Tel: +972524208743 Fax: +97239772196 -- 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: 25 reasons why hardware is still hot at IBM
john.mck...@healthmarkets.com (McKown, John) writes: > Most are 3270 oriented. In today's world, that is difficult for end > users to comprehend. So, "webifying" an application so that it can run > on a browser makes it much easier for the typical end user to use. And > that reduces cost by decreasing training costs and increasing > productivity. > > Unfortunately, we did this by "screen scraping" and "automating" our > existing 3270 applications. So the end user browses to a Windows IIS > server, which somehow drives the 3270 application using a combination > of 3270 "screen scraping" and CICS Web Services. We didn't "bite the > bullet" to convert the 3270 portion to Web services. Of course, our > old systems did not separate presentation from the business logic. some of the webification of 3270 apps have been call-center ... but that required adding some amount of authentication and other security features ... before letting individuals access there own information (and eliminating call-center costs; this isn't webification for moving call-centers to browser-centric ... but web delivery directly to customer/clients). some of the online banking has at times fallen into that category -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- 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: 25 reasons why hardware is still hot at IBM
On Mon, 26 Apr 2010 16:45:27 +, Eric Bielefeld wrote: >So Toronto hasn't lost many of its mainframes? That's good to hear. I suspect that my experiences in Milwaukee are similar to a lot more people's on this list than yours are. Anyone care to comment? > Bay City, MI had several mainframes 25 years ago. To my knowledge they now have none, and it has been that way for almost twenty years. Back in those days most banks and hospitals and many manufacturers and insurance companies had one. (Pre merger mania there were a lot more banks and hospitals back then). I would be surprised if there was much more than a dozen mainframe shops in Michigan today. P -- 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: HFS Copy Problem
I don't think so. We always make sure the lpar that is the source for the copies is down. At the moment I have no 1.9 lpars ipled so the HFS shouldn't be allocated anywhere. The catalog, if it's allocated anywhere, should be to CAS. Your response did make me check The mcat attributes in case the SHROPTNS got altered but they all show 3,4 Alan Schwartz Infrastructure Management Sr. Analyst Affiliated Computer Services A Xerox Company 612-726-4505 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick Lyon Sent: Wednesday, April 28, 2010 1:42 PM To: IBM-MAIN@bama.ua.edu Subject: Re: HFS Copy Problem On Wed, 28 Apr 2010 13:26:21 -0500, Schwartz, Alan wrote: > DELETE SYS1.OMVS.AAOPROOT.M2OMA1 CAT (SYS1.MCATZS19.MVS2) >IKJ56228I DATA SET SYS1.OMVS.AAOPROOT.M2OMA1 NOT IN CATALOG OR CATALOG >IKJ56228I CAN NOT BE ACCESSED >IDC0551I ** ENTRY SYS1.OMVS.AAOPROOT.M2OMA1 NOT DELETED >IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8 Alan - is the file allocated on that other LPAR (Or elsewhere?) Looking up the message: IKJ56228I DATA SET dsname NOT IN CATALOG or CATALOG CANNOT BE ACCESSED Explanation: DISP=OLD was specified. The dynamic allocation error code is 1708, 5708, or 5710. For a description of the dynamic allocation return, informational, and error codes, refer to z/OS MVS Programming: Authorized Assembler Services Guide. Detected by: CALLER Program: DAIRFAIL -- 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: how big is big?
On Wed, Apr 28, 2010 at 12:58 PM, Kirk Talman wrote: > what is the size (in mips?) are the datacenters or companies that it takes > to make the 1st, 2nd ... quintile? Is that published? > well if you figure on a single z10-EC engine being O(1K) old fashioned meaningless thingies and then do the math you come up with a number that is O(bloody big). -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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: HFS Copy Problem
On Wed, 28 Apr 2010 13:26:21 -0500, Schwartz, Alan wrote: > DELETE SYS1.OMVS.AAOPROOT.M2OMA1 CAT (SYS1.MCATZS19.MVS2) >IKJ56228I DATA SET SYS1.OMVS.AAOPROOT.M2OMA1 NOT IN CATALOG OR CATALOG >IKJ56228I CAN NOT BE ACCESSED >IDC0551I ** ENTRY SYS1.OMVS.AAOPROOT.M2OMA1 NOT DELETED >IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8 Alan - is the file allocated on that other LPAR (Or elsewhere?) Looking up the message: IKJ56228I DATA SET dsname NOT IN CATALOG or CATALOG CANNOT BE ACCESSED Explanation: DISP=OLD was specified. The dynamic allocation error code is 1708, 5708, or 5710. For a description of the dynamic allocation return, informational, and error codes, refer to z/OS MVS Programming: Authorized Assembler Services Guide. Detected by: CALLER Program: DAIRFAIL -- 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
HFS Copy Problem
I'm close to implementing z/OS 1.9 from my current 1.7 system with the intent of starting the 1.11 upgrade after this but I'm running into an HFS copy problem that I haven't been able to figure out. I'm following the same procedure we use to copy our HFS volumes. I have a job where one step is to delete the HFS datasets that are in another master catalog ex (DELETE SYS1.OMVS.AFOROOT.M1RSC1 CAT (SYS1.MCAT.MVS1.ZS17M9). The next step is to do a DFDSS copy thus: COPY DATASET( - INCLUDE( - SYS1.OMVS.*.T2RSC1- ))- INDYNAM(T2OMC1) - OUTDYNAM(M1OMC1) - RENAMEU( - (SYS1.OMVS.*.T2RSC1,SYS1.OMVS.*.M1RSC1) - ) - REPLACE - INCAT (SYS1.MCAT.TST2.ZS17M9) ONLYINCAT - RECAT (SYS1.MCAT.MVS1.ZS17M9) This has worked nicely for years. I have 1.9 catalogs for test lpar TST2 and for the production lpars as well (names are SYS1.MCATZS19.TST2, etc.). I run a very similar job using the 1.9 catalogs (using only one HFS for speed until I get this solved: COPY DATASET( - INCLUDE( - SYS1.OMVS.AAOPROOT.T2OMA1 - ))- INDYNAM(T2OMA1) - OUTDYNAM(M2OMA1) - RENAMEU( - (SYS1.OMVS.AAOPROOT.T2OMA1,SYS1.OMVS.AAOPROOT.M2OMA1) - ) - INCAT (SYS1.MCATZS19.TST2) ONLYINCAT - RECAT (SYS1.MCATZS19.MVS2) and it works perfectly. DFDSS reports DATA SET SYS1.OMVS.AAOPROOT.T2OMA1 ALLOCATED WITH NEWNAME SYS1.OMVS.AAOPROOT.M2OMA1, ON VOLUME(S): M2OMA1 DATA SET SYS1.OMVS.AAOPROOT.M2OMA1 HAS BEEN CATALOGED IN CATALOG SYS1.MCATZS19.MVS2 DATA SET FILTERING IS COMPLETE. 1 OF 1 DATA SETS WERE SELECTED: 0 FAILED SERIALIZATION AND 0 FAILED FOR OTHER REASONS. THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED SYS1.OMVS.AAOPROOT.T2OMA1 2010.118 12:40:31 EXECUTION ENDS 2010.118 12:40:31 TASK COMPLETED WITH RETURN CODE 2010.118 12:40:31 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS A listcat shows the new HFS file name and the vtoc shows the dataset. I was able to mount it in a test lpar and see files. The problem is if I rerun the job with the original DELETE step I get DELETE SYS1.OMVS.AAOPROOT.M2OMA1 CAT(SYS1.MCATZS19.MVS2) IKJ56228I DATA SET SYS1.OMVS.AAOPROOT.M2OMA1 NOT IN CATALOG OR CATALOG IKJ56228I CAN NOT BE ACCESSED IDC0551I ** ENTRY SYS1.OMVS.AAOPROOT.M2OMA1 NOT DELETED IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8 which causes the DFDSS step to fail with UNABLE TO SELECT A TARGET VOLUME FOR DATA SET SYS1.OMVS.AAOPROOT.T2OMA1, 08 Somewhere somethings not hooked up right but we haven't spotted it yet so I'm looking for suggestions. Thanks so much Alan Schwartz Infrastructure Management Sr. Analyst -- 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
how big is big?
what is the size (in mips?) are the datacenters or companies that it takes to make the 1st, 2nd ... quintile? Is that published? - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- 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: 25 reasons why hardware is still hot at IBM
>Being technical doesn't make someone a SYSPROG. Hair-splitting. Being a SYSPROG makes you technical, but only a subset of technical. Disaster planning, operations management, capacity planning, and other disciplines are also technical. >They need to get hired before the existing SYSPROGs retire, not after. Rarely done. - Too busy driving to stop for gas! -- 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: 25 reasons why hardware is still hot at IBM
On Wed, Apr 28, 2010 at 1:05 PM, Clark Morris wrote: > Granted this is based on the applications that I worked on personally > over the past 20 years but most of them were difficult to change, had > interesting anomalies in them and were poorly documented at best. > While this represents only 4 shops including one that had moved COBOL > batch and CICS to HP-UX from the mainframe, I suspect that it is true > elsewhere. Some of those applications have since been replaced. I > suspect the help function for users in most CICS systems stinks again > based on my limited experience. > OK, but if they work, they're "good enough". Sure, you and I would be itching to 'fix' them, but that's an urge we should resist. -- 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: 25 reasons why hardware is still hot at IBM
On 27 Apr 2010 19:32:43 -0700, in bit.listserv.ibm-main you wrote: >On Tue, Apr 27, 2010 at 10:14 PM, Clark Morris >wrote: > >> .Many of the applications currently running on z are >> >in need of serious overhaul or replacement... >> > >Based on what? Do they work? If so, why do they need overhaul or >replacement? Granted this is based on the applications that I worked on personally over the past 20 years but most of them were difficult to change, had interesting anomalies in them and were poorly documented at best. While this represents only 4 shops including one that had moved COBOL batch and CICS to HP-UX from the mainframe, I suspect that it is true elsewhere. Some of those applications have since been replaced. I suspect the help function for users in most CICS systems stinks again based on my limited experience. > >That's a straight question. > >-- >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
R: RMM VRSDROP
Mike, I followed you suggestion and I am using the ACTIVITY file and JCL EDGJACTP to understand why the EDGHSKP get the problem with VRSDROP. The problem is that no summary or analytical report (DDNAME VRS and VRSS) are produced at VOLUME level. Indeed, ALL the reports are produced at DATASET level while message " EDG2244I NUMBER OF VRS RETAINED VOLUMES TO BE DROPPED = 16 1%" reports the data at VOLUME level. Furthermore, I suppose there is not way to confirm a number volumes that exceed the VRDDROP value using, for example, the CONFIRM option. Thank you and best regards Marco -Messaggio originale- Da: Mike Wood [mailto:mikew_w...@uk.ibm.com] Inviato: lunedì 26 aprile 2010 17.52 A: IBM-MAIN@bama.ua.edu; TORRETTA MARCO Oggetto: Re: RMM VRSDROP Marco, To analyze the results of VRSEL processing you can use the ACTIVITY file and the sample JCL EDGJACTP. That JCL creates detail and summary reports and those VRS related will show you summary of the reason data sets are dropped, and details of each data set dropped. This information is added to the R12 books. When FAIL action is specified there are no CDS updates made by the run, but the ACTIVITY file is updated to show what changes would have been made - this is just like you had a trial run with EDGHSKP parms VRSEL,VERIFY. In case you also start to look at VRSRETAIN or EXPDTDROP be aware there is an APAR OA30881 which provides some additional reporting for EDGJACTP to help with limit reporting for other than VRSDROP. That is new function in R12 rolled-back to R10 and R11. Mike Wood RMM Development ** Le e-mail provenienti dalla Banca d'Italia sono trasmesse in buona fede e non comportano alcun vincolo ne' creano obblighi per la Banca stessa, salvo che cio' non sia espressamente previsto da un accordo scritto. Questa e-mail e' confidenziale. Qualora l'avesse ricevuta per errore, La preghiamo di comunicarne via e-mail la ricezione al mittente e di distruggerne il contenuto. La informiamo inoltre che l'utilizzo non autorizzato del messaggio o dei suoi allegati potrebbe costituire reato. Grazie per la collaborazione. -- E-mails from the Bank of Italy are sent in good faith but they are neither binding on the Bank nor to be understood as creating any obligation on its part except where provided for in a written agreement. This e-mail is confidential. If you have received it by mistake, please inform the sender by reply e-mail and delete it from your system. Please also note that the unauthorized disclosure or use of the message or any attachments could be an offence. Thank you for your cooperation. ** -- 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: 25 reasons why hardware is still hot at IBM
On 28 Apr 2010 08:23:42 -0700, paulgboul...@aim.com (Paul Gilmartin) wrote: >>The funny thing is that IBM doesn't seem to be pushing Linux and Unix >>on the mainframe either. >> >>Our shop is going Linux/Unix and getting rid of its mainframe, but >>keeping the mainframe was never considered. >> >Other than Linux, I know of two UNIXen on the mainframe. Which one(s) >did you have in mind? All I know is that the choice isn't limited to Linux - and that nobody considered anything.The political choice was "we spend this money, then we can unplug the mainframe saving - then we can put down in our resumes how good we are and go onto the next job". The software vendors understood this and pushed their buttons. Converting our mainframe to run their software just wasn't considered. W -- 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: 25 reasons why hardware is still hot at IBM
On 28 Apr 2010 07:34:11 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote: >>I was told in 1980 that by 1985 all systems would be turnkey and therefore my >>decision to enter into systems programming was a mistake. >Best thirty year >>mistake of my life! :-) > >There are fewer SYSPROGs supporting larger and more systems than back then. >And, there are more unemployed technical people, now. >But, the discipline is going to be around for many more years. >Hopefully, as the older ones vacate the scene, the unemployed will be able to >reverse their plight. Being technical doesn't make someone a SYSPROG.They need to get hired before the existing SYSPROGs retire, not after. -- 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: 25 reasons why hardware is still hot at IBM
On Wed, 28 Apr 2010 08:22:50 -0600, Howard Brazee wrote: > >The funny thing is that IBM doesn't seem to be pushing Linux and Unix >on the mainframe either. > >Our shop is going Linux/Unix and getting rid of its mainframe, but >keeping the mainframe was never considered. > Other than Linux, I know of two UNIXen on the mainframe. Which one(s) did you have in mind? -- gil -- 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: 25 reasons why hardware is still hot at IBM
On Wed, 28 Apr 2010 14:33:42 +, Ted MacNEIL wrote: >>I was told in 1980 that by 1985 ... > >There are fewer SYSPROGs supporting larger and more systems >than back then. Is that based upon anecdotal evidence? Here's another. One of the biggest sites that I dealt with from 1980 to 1985 had ten of the biggest processors you could get in one data center. It was my understanding that the other data center was a little smaller, but I was never there. Today, after acquiring several foreign subsidiaries and consolidating many of them at headquarters, I think they are down to one z10 at each site. The number of system programmers is about the same. -- Tom Marchant -- 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: 25 reasons why hardware is still hot at IBM
>I was told in 1980 that by 1985 all systems would be turnkey and therefore my >decision to enter into systems programming was a mistake. >Best thirty year >mistake of my life! :-) There are fewer SYSPROGs supporting larger and more systems than back then. And, there are more unemployed technical people, now. But, the discipline is going to be around for many more years. Hopefully, as the older ones vacate the scene, the unemployed will be able to reverse their plight. - Too busy driving to stop for gas! -- 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: 25 reasons why hardware is still hot at IBM
On 28 Apr 2010 05:57:54 -0700, m42tom-ibmm...@yahoo.com (Tom Marchant) wrote: >It may reduce training costs, but I'm not persuaded that a "webified" >application increases productivity over a well designed 3270 based >application. 3270 applications tend to perform better than similar >web applications. If the 3270 design is based upon 24x80, it is not, >IMO, a well designed application. IMHO, businesses have are increasingly following the lead of congress critters.Make decisions based upon what can be made to look good on one's resume for the next election/job interview.Productivity over the long run doesn't get you the next job. -- 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: 25 reasons why hardware is still hot at IBM
On 27 Apr 2010 11:19:52 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote: >>Training for z/OS related cours are decreasing. > >Does that mean there are fewer mainframes? >Or, does that mean there are fewer managers willing to spend money on training? When the philosophy is to spend less on training, a strong criterion for the next "upgrade" will be to go to a system that doesn't appear to need in-house training.Whichever system markets that fit has a head start in selling itself. >Don't get me wrong. >I, regardless of the comments I've been making, DO believe that mainframes are >shrinking. >But, I'd like to see more than anecdotal evidence. >Anything that cannot be substantiated is just more smoke. I see another option - more consolidation. Sure Ross Perot's idea is old, but with so much better communication lines and distributed processing, a computer center in Nebraska, backed up in Alabama can run a hundred company's data needs. -- 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: 25 reasons why hardware is still hot at IBM
On 27 Apr 2010 12:37:45 -0700, st...@trainersfriend.com (Steve Comstock) wrote: >IBM's not telling the story of the glories of z/OS? We need >to make it seem more desirable than Windows and Linux and >Unix to the decision makers. Any suggestions? The funny thing is that IBM doesn't seem to be pushing Linux and Unix on the mainframe either. Our shop is going Linux/Unix and getting rid of its mainframe, but keeping the mainframe was never considered. -- 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: Warning: TS7700 spontaneous reboot.
We're running 1.6.1 since a few months without any problems. Werner Kuehnel IMD-Gesellschaft für Informatik und Datenverarbeitung mbH Augustaanlage 66 68165 Mannheim Tel: +49.621.457-4885, Fax: -4046 IMD-Gesellschaft für Informatik und Datenverarbeitung mbH IBM Mainframe Discussion List schrieb am 28.04.2010 15:39:27: > "Vernooij, CP - SPLXM" wrote in message > news:<3310ac9d797ec94db8d89ccabdea47a7021bc...@kl1221tc.cs.ad.klmcorp.ne > t>... > > > > > > > > FYI: > > This week one of our TS7700 clusters had a spontaneous reboot and was > > unavailable for 22 minutes. The other cluster in the grid operated > > normally. Investigations by IBM showed that this was a know bug in the > > V1R5 microcode which is resolved in V1R6. > > > TS7700 users who have intentions to upgrade their 1.5 code to 1.6, > might > > want to review their planning. > > > Regards, > > Kees. > > > We have some issues that are delaying our upgrade to 1.6, but I am > thinking about pushing it a little harder. > Does anyone already have expirience with microcode 1.6, either positive > or negative? > > Thanks, > Kees. > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee > only. If you are not the addressee, you are notified that no part of > the e-mail or any attachment may be disclosed, copied or > distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have > received this e-mail by error, please notify the sender immediately > by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > and/or its employees shall not be liable for the incorrect or > incomplete transmission of this e-mail or any attachments, nor > responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > > > -- > 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: Warning: TS7700 spontaneous reboot.
"Vernooij, CP - SPLXM" wrote in message news:<3310ac9d797ec94db8d89ccabdea47a7021bc...@kl1221tc.cs.ad.klmcorp.ne t>... > > > FYI: > This week one of our TS7700 clusters had a spontaneous reboot and was > unavailable for 22 minutes. The other cluster in the grid operated > normally. Investigations by IBM showed that this was a know bug in the > V1R5 microcode which is resolved in V1R6. > TS7700 users who have intentions to upgrade their 1.5 code to 1.6, might > want to review their planning. > Regards, > Kees. We have some issues that are delaying our upgrade to 1.6, but I am thinking about pushing it a little harder. Does anyone already have expirience with microcode 1.6, either positive or negative? Thanks, Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: 25 reasons why hardware is still hot at IBM
On Wed, 28 Apr 2010 07:31:51 -0500, McKown, John wrote: >> -Original Message- >> From: IBM Mainframe Discussion List >> [mailto:ibm-m...@bama.ua.edu] On Behalf Of zMan >> Sent: Tuesday, April 27, 2010 9:32 PM >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: 25 reasons why hardware is still hot at IBM >> >> On Tue, Apr 27, 2010 at 10:14 PM, Clark Morris >> wrote: >> >> > .Many of the applications currently running on z are >> > >> in need of serious overhaul or replacement... >> > >> >> Based on what? Do they work? If so, why do they need overhaul or >> replacement? >> >> That's a straight question. > >Most are 3270 oriented. In today's world, that is difficult for >end users to comprehend. So, "webifying" an application so that >it can run on a browser makes it much easier for the typical end >user to use. And that reduces cost by decreasing training costs >and increasing productivity. > It may reduce training costs, but I'm not persuaded that a "webified" application increases productivity over a well designed 3270 based application. 3270 applications tend to perform better than similar web applications. If the 3270 design is based upon 24x80, it is not, IMO, a well designed application. > >NOTE TO VENDORS: Don't send me any information on how your >product will make this easier. It is unfortunate that you should need to add this request to reduce the amount of spam that you receive. -- Tom Marchant -- 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: 25 reasons why hardware is still hot at IBM
I was told in 1980 that by 1985 all systems would be turnkey and therefore my decision to enter into systems programming was a mistake. Best thirty year mistake of my life! :-) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Tuesday, April 27, 2010 2:00 PM To: IBM-MAIN@bama.ua.edu Subject: Re: 25 reasons why hardware is still hot at IBM >I recall my supervisor telling me in the early nineties that the trend was >toward fewer systems programmers. I thought the trend started earlier. I had a colleague, around 1984, point out that SYSPROGs were becoming PARMLIB editors. I recall when you had to assemble the PPT. Now it's just a PARMLIB member. -- 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: 25 reasons why hardware is still hot at IBM
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of zMan > Sent: Tuesday, April 27, 2010 9:32 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: 25 reasons why hardware is still hot at IBM > > On Tue, Apr 27, 2010 at 10:14 PM, Clark Morris > wrote: > > > .Many of the applications currently running on z are > > > in need of serious overhaul or replacement... > > > > Based on what? Do they work? If so, why do they need overhaul or > replacement? > > That's a straight question. Most are 3270 oriented. In today's world, that is difficult for end users to comprehend. So, "webifying" an application so that it can run on a browser makes it much easier for the typical end user to use. And that reduces cost by decreasing training costs and increasing productivity. Unfortunately, we did this by "screen scraping" and "automating" our existing 3270 applications. So the end user browses to a Windows IIS server, which somehow drives the 3270 application using a combination of 3270 "screen scraping" and CICS Web Services. We didn't "bite the bullet" to convert the 3270 portion to Web services. Of course, our old systems did not separate presentation from the business logic. NOTE TO VENDORS: Don't send me any information on how your product will make this easier. First off, I'm just a grunt with little influence on the powers that be. Second, we are still downsizing and are not acquiring __ANY__ new software. Period. End of Discussion. DON'T BOTHER ME! Your email will be summarily deleted. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell 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 -- 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: DFHSM QUESTION - MOVING TO DASD FROM TAPE - ML2
Mike, Well if you want any sort of decent, scalable performance you wouldn't want an SVA. You would want a USP-V. Ron > -Original Message- > From: Mike Baldwin [mailto:m...@cartagena.com] > Sent: Tuesday, April 27, 2010 11:39 AM > To: IBM-MAIN@bama.ua.edu; Ron Hawkins > Cc: Mike Baldwin > Subject: Re: DFHSM QUESTION - MOVING TO DASD FROM TAPE - ML2 > > Hi Ron, > > On Mon, 26 Apr 2010 22:39:53 -0700, Ron Hawkins > wrote: > >Mike, > > > >You'd probably want to disable compression for all datasets on Primary > >Volumes as well, and bypass migration to ML1 as there is no benefit (except > >for SDSP maybe). > > > >Ron > > That's a good point. Assuming that Primary is also on SVA, right? > Probably a good assumption, after all, what other kind of DASD > does one need. :-) > > Regards, > Mike Baldwin > Cartagena Software Ltd. > Markham, Ontario, Canada > http://www.cartagena.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
