Re: Gartner: Stop Outsourcing Now
Ed Gould [EMAIL PROTECTED] writes: 1. Gartner Analyst: Stop Outsourcing Now Gartner's chief of research for outsourcing says companies have become compulsive about outsourcing... and it's creating chaos and hurting business. Does anyone think outsourcing is _not_ about punching up financials to inflate executive compensation packages? Unless the FASB (and similar bodies in the rest of the G-8) brings the gravy train to a halt, asking executives to stop outsourcing is like asking them to trade in their 7-series Beemers and S-class Benzes for Corollas and Civics. John R. Grout [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF WSA (Was: TN3270 Emulator)
Gray Maddry [EMAIL PROTECTED] wrote: That kind of cutting is sometimes called block or column mode and many PC editors support that. Ultraedit, ConText, Crimson Editor to name three. And Kedit, which is a CMS XEDIT clone and is thus a lot closer to ISPF than most (and is highly customizable). www.kedit.com. ...phsiii (unpaid shill) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3745 cable pin out.
From: R.S. GREAT! Wonder why it's not linked in the Hardware section? It would be against IBM mainframe rules. It could be *convenient*. It's very good that IBM publishes so much. I really appreciate it. However it's a pity that all the publications are not accessible from single site. Radoslaw could be said to have a bit of an attitude proble. Except that he's *very* close to the bone ... 8-( Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E: Deleting SMPPTS entries
You could delete the fmid from the global zone through the dialogs. Then run an SMPE REJECT NOFMID and see what that gets you. On Thu, 27 Oct 2005 16:25:43 -0600, Paul Gilmartin [EMAIL PROTECTED] wrote: Way back in: Linkname: Re: SMPE Problem URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0403L=ibm-mainD=1O=DI=1P=273501 It was suggested: ... In my opinion, deleting a member from the PTS is a reasonable approach to the problem you are trying to solve. (Badly out of context, but the citation is above.) Today, I had a typo in a DISTLIB entry in a FUNCTION. Of course this resulted in: GIM54502E ** ALLOCATION FAILED FOR ... BECAUSE THERE IS NO DD STATEMENT IN THE JCL AND NO DDDEF ENTRY IN TARGET ZONE ... I corrected the DISTLIB, and rebuilt the tape. Hastily, I deleted the member from the SMPPTS, and deleted all the TLIBs and re-received. The APPLY failed identically. The SMPPTS member shows the corrected DISTLIB regardless of the failure. Would the SMP/E panels explain what's going on? Where is the rogue DISTLIB DDNAME hiding? Would REJECT have repaired the problem? Would bumping the REWORK have repaired the problem? Apparently deleting the SMPPTS entry isn't always enough to clean the slate. I created a new CSI and RECEIVED into it, and APPLYed. The APPLY disclosed further errors, but the GIM54502E is gone. SMP/E 32.16 -- gil StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
I apologize in advance for not knowing the best list to send this question to. (Perhaps ISPF-L? But I'm not a subscriber there.) I'm proposing to our systems folks that we allow a user to use TSO to get to the Zeke Work Center function. I'm being told that there is no way for us to limit what the user can do if we let them intoTSO. Sounds like bullshirt to me. Any user with ATTRIBUTES=RESTRICTED will require that _every function_ they need be explicitly authorized, regardless of any existing UACC settings. I find this interesting. Just recently, list members were objecting that limiting a user's access to resources (in that case it was memory) was probably keeping them from doing their job. Where are they now? The argument was that if a user was requesting a resource, they MUST NEED IT for their job. This seems like a very similar situation. Why not allow the users access to all of ISPF, and depend on their honorable nature to only use those functions that they need to do their job? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
In a recent note, Martin Kline said: Date: Fri, 28 Oct 2005 07:41:03 -0500 I find this interesting. Just recently, list members were objecting that limiting a user's access to resources (in that case it was memory) was probably keeping them from doing their job. Where are they now? Weary from the last time around? But since you ask ... The argument was that if a user was requesting a resource, they MUST NEED IT for their job. This seems like a very similar situation. Why not allow the users access to all of ISPF, and depend on their honorable nature to only use those functions that they need to do their job? depend on their honorable nature is appropriate for functions, but inadequate for resources. But the approach should be to protect resources with RACF, not to restrict a targeted class of users. Don't stigmatize a group and confine them to reservations, or to ghettos, or with house arrest; rather secure the bank vaults to prevent theft. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Gartner: Stop Outsourcing Now
Gartner's chief of research for outsourcing says companies have become compulsive about outsourcing... ...and, since nobody should make a business decision compulsively, companies should turn to Gartner for advice and consulting services first. :-) Seriously, the article makes a good point. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect IBM Americas zSeries/z9 Software Phone: +1 312 529 1612 E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
HI Gil. You said: depend on their honorable nature is appropriate for functions, but inadequate for resources. So, you believe that resources, e.g. memory, should be protected, while functions, like TSO commands, should not? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Gartner: Stop Outsourcing Now
Gartner's chief of research for outsourcing says companies have become compulsive about outsourcing... A new illness: Compulsive Outsourcing Disorder or COD Does NIH have funding for this? Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What causes this?
In a message dated 10/28/2005 4:30:36 A.M. Central Standard Time, [EMAIL PROTECTED] writes: You may wish to consider taking a stand-alone dump, if you aren't able to collect any other information, Most of the time it's a missing $s? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3745 cable pin out.
In a message dated 10/28/2005 6:13:21 A.M. Central Standard Time, [EMAIL PROTECTED] writes: It's very good that IBM publishes so much. I really appreciate it. However it's a pity that all the publications are not accessible from single site. Take a PFCSK about two minutes to link them together given the authority! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ISPF member list
Few years ago ISPF changed behavior of member list, I'l try to explain: When you select a member (for Browse, Edit, View) from middle of the screen, you enter into edit session, exit the editor, the list of members is automatically scrolled up, so just-editer member is on the top of the list (I mean the part of the list, visible on the screen). It's not big pain, but I'd like to know how to switch it off. Any clue ? -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
In a recent note, Martin Kline said: Date: Fri, 28 Oct 2005 08:15:26 -0500 So, you believe that resources, e.g. memory, should be protected, while functions, like TSO commands, should not? I was thinking more of data sets than memory (Resources like the R in RACF), but yes. If you wish to prevent a user's deleting SYS1.LINKLIB, don't try to prevent the user's use of the TSO DELETE command, and ALLOC DISP=(...,DELETE), and IDCAMS, and any number of commands that might delete a data set. Simply protect SYS1.LINKLIB with RACF (probably a good idea anyway). -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF member list
Rad, I think there is an ISPF member list exit. You have to turn it on via the ISPCCONF panels and write the exit. Some of the details are in the ISPF Planning and Customization Guide. Though, IMHO, if this is just an annoyance and does not fill a business need, I would just live with it. HTH Thanks, Fletch -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Friday, October 28, 2005 8:53 AM To: IBM-MAIN@BAMA.UA.EDU Subject: ISPF member list Few years ago ISPF changed behavior of member list, I'l try to explain: When you select a member (for Browse, Edit, View) from middle of the screen, you enter into edit session, exit the editor, the list of members is automatically scrolled up, so just-editer member is on the top of the list (I mean the part of the list, visible on the screen). It's not big pain, but I'd like to know how to switch it off. Any clue ? -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
Martin Kline wrote: I find this interesting. Just recently, list members were objecting that limiting a user's access to resources (in that case it was memory) was probably keeping them from doing their job. Where are they now? The argument was that if a user was requesting a resource, they MUST NEED IT for their job. This seems like a very similar situation. Why not allow the users access to all of ISPF, and depend on their honorable nature to only use those functions that they need to do their job? Your confusion is due to an unfortunate use of the word resource in two wholly-different contexts. RACF stands for Resource Access Control Facility. But, the resources it protects have nothing whatsoever to do with CPU time or virtual storage. I suppose, if we could convince Mr. Peabody to use the Wayback Machine to take us to the meeting where RACF's moniker was invented, we could insist on a more-appropriate one, like PCF = Permissions Control Facility. :-\ -- .-. | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | '-' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF member list
On Fri, 28 Oct 2005 15:52:47 +0200, R.S. [EMAIL PROTECTED] wrote: Few years ago ISPF changed behavior of member list, I'l try to explain: When you select a member (for Browse, Edit, View) from middle of the screen, you enter into edit session, exit the editor, the list of members is automatically scrolled up, so just-editer member is on the top of the list (I mean the part of the list, visible on the screen). It's not big pain, but I'd like to know how to switch it off. Any clue ? -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html In ISPF for z/OS 1.5 and above there is an option in the ISPF Configuration Table, in the ISPF Site-Wide Profile Customizations section, called SCROLL_MEMBER_LIST, which gives you control over this function. This is described in the Planning and Customizing manual. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GDPS possibilities across distances
Thanks you for all of the help I've received in investigating the problems with running a fully duplexed GDPS across distances. There are several users in Europe running GDPS with data sharing/CF duplexing, and possibly one in Australia. My company is very interested in this approach, and would like to work toward a better understanding of all of the experiences of other users. Who would be interested in getting together for some discussions? I can host some WEB sessions, and would be glad to pay a visit to any of you who think it worthwhile. Please let me know: If you are interested in some user-experience discussions about GDPS If I can contact you directly (via email) to set something up If you think this subject deserves coverage in conference and what conference you think would fit best Feel free to contact me directly. Clark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MEMLIMIT and IEFUSI
On Thu, 27 Oct 2005 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: The number eventually gets stored into an MVS control block which is examined by various system services. ... I don't think you want to touch DB2 V8+ as far as MEMLIMIT is concerned. It is architected (and expects) to use all that memory. Only a couple of pools are left below the bar. You would kick the snot out of any performance gains that this gives you, if it would even come up. -teD Surely you jest! What don't you (and IBM) get?! If DB2 were to use all that memory I would need a large portion of my entire DASD farm dedicated to page data sets. Isn't the max real supported by z/OS still 128G? What's the point of hard coding 4T? For as long as I can remember IBM has told us to protect ourselves from wait03C with IEFUSI (and a robust paging subsystem). It hasn't really mattered in the recent past with large systems and 31-bit, but now it is more important than ever. I can no longer rely on a robust paging system alone to protect the system. I just don't get it. Vendors PLEASE. If you are going to need oodles of storage above the bar, just document your requirements just like you would for common storage. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America and Farmers Insurance Group mailto: [EMAIL PROTECTED] Systems Programming expert at http://Search390.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
Walt Farrell wrote: On 10/28/2005 10:16 AM, Edward E. Jaffe wrote: RACF stands for Resource Access Control Facility. But, the resources it protects have nothing whatsoever to do with CPU time or virtual storage. I suppose, if we could convince Mr. Peabody to use the Wayback Machine to take us to the meeting where RACF's moniker was invented, we could insist on a more-appropriate one, like PCF = Permissions Control Facility. :-\ The internal tool which became RACF did have controls for CPU and DASD storage utilization (though I don't think it had controls for virtual storage). If you were going to go back and change something, I'd prefer you convince them to make those controls part of the product, too, rather than changing the product name. If such controls were present in the product, the RACF name might have been more appropriate. In any case, you guys have already changed its name more than enough times. :-D -- .-. | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | '-' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
== Steve Grimes == wrote2005-10-26 01:11: Our application programmers no longer, for instance, have update access to SYS1.PARMLIB, etc. 8-O :-D ROFL! -- -- Mundus Vult Decipi -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF member list
So you belong to the same organization as the Three Stooges, the AMA (Amalgamated Moron's Association). [EMAIL PROTECTED] 10/28/2005 11:41:32 AM And I disagree entirely with your opinions. I am quite pleased with the functionality you describe. Perhaps I'm a moron... :-) Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Paul Gilmartin Sent: Friday, October 28, 2005 10:11 AM OTOH, it's simply moronic that when the member list is small and fits entirely on a single screen, and I browse the last member and exit, the screen is scrolled so only one member shows. Such automatic scrolling should never go farther than the effect of DOWN MAX. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
Your confusion is due to an unfortunate use of the word resource in two wholly-different contexts. You're getting waaay off track here... I'm confused and off track? Please do not attacking me personally. I got into this discussion just to highlight the inconsistency of two arguments. In one case it was argued that any user who used a resource must need it to do their job, otherwise they would never have used it. In the other case, it's argued that all resources should be protected, and only specific authorizations given out, because accidents and bad intentions happen. The resources involved are different, but the reasons for protecting them are essentially the same. If the business requires that a user access a specific set of resources, and no other resources, then the other resources have to be protected. If the business would like a user to access a set of resources and would like (but not require) them NOT to access other resources, then a note saying, Please don't touch these other resources might suffice. Each business' requirements are different. Perhaps the originator is satisfied with a logon proc that only points Joe user to Zeke. Maybe the requestor isn't interested in the myriad methods of bypassing security, and is only interested in satisfying the immediate needs of Joe user. After all, the original request said, I'm hoping no RACF changes will be required, except perhaps for authorization to execute the sign-on proc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
Martin, If a persons job function requires that they be able to use ISPF and edit a file that requires 128M of virtual storage, then they should have access to that much storage. If their job functions requires that they have update access to SYS1.PARMLIB, then the should have it. However, giving them update access to the FILE that requires 128M of virtual storage to edit, but limiting the user to 32M of virtual storage will not allow them to perform there job function. I don't believe that anyone is saying don't have limits, just that the limits should be so restrictive that the computer doesn't get used. Wayne Driscoll Product Developer Western Metal Supply NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Martin Kline Sent: Friday, October 28, 2005 9:37 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Allowing Joe User into TSO Your confusion is due to an unfortunate use of the word resource in two wholly-different contexts. On the contrary, I am not confused at all. Clearly, users should be prevented from deleting datasets they shouldn't delete. However, who's to say Joe user shouldn't delete dataset JOE.yyy.zzz? Is it a requirement of the job? Likewise, who's to say Joe user shouldn't allocate 100Gb of virtual memory to load a table? Is it a requirement of the job? Should the approach be to protect all datasets, and require every user to get authorization before accessing them? Won't this interfere with their ability to do their jobs? What about memory? Shouldn't excessive memory requests be restricted, and require authorization as well? Would that interfere with the ability of users to do their jobs? Is it any worse than setting up dataset protection? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
Martin Kline wrote: Each business' requirements are different. Perhaps the originator is satisfied with a logon proc that only points Joe user to Zeke. Maybe the requestor isn't interested in the myriad methods of bypassing security, and is only interested in satisfying the immediate needs of Joe user. Perhaps. But he solicited advice from the list and that's what he got. After all, the original request said, I'm hoping no RACF changes will be required, except perhaps for authorization to execute the sign-on proc. And I'm hoping to win the MEGA Millions California Lottery. Chances are both Steve and I will be disappointed. ;-) -- .-. | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | '-' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: allowing Joe User into TSO
There are two polar attitudes toward problems of this sort, viz., Was ist nicht erlaubt is verboten (What is not allowed is forbidden). and Was ist nicht verboten ist erlaubt (What is not forbidden is allowed). The second of them has three great merits: o It does not require uncommon, even God-like prescience; o It does not cumber the working environment with barred windows and culs de sac; and o It is much less labor-intensive than the first. Computer-security problems are real; but we now have a large and growing group of computer-security specialists who have a vested, bureaucratic interest in devoting more and more resources to treating these problems simplistically; and these 'specialists' are hard to oppose without being attacked as naif or in league with the villains. John Gilmore Ashland, MA 01721-1817 USA _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
If a persons job function requires that they be able to use ISPF and edit a file that requires 128M of virtual storage, then they should have access to that much storage. If their job functions requires that they have update access to SYS1.PARMLIB, then the should have it. I agree, Wayne. just because one user needs to have update access to parmlib does not mean all users should have update access. But the previous discussion had some users suggesting that memory limits for all users should be set higher than the maximum requirement for any user. I believe this leave the organization vulnerable to problems. Instead, allow the one user to have lots of memory, and restrict others to a lower limit, that the system can tolerate. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Kline Your confusion is due to an unfortunate use of the word resource in two wholly-different contexts. On the contrary, I am not confused at all. I'm inclined to think you are, because you're in effect comparing a restriction on how fast you can drive a car (storage/CPU) vs. a restriction on where you can or cannot drive it (TSO, SDSF, Zeke, etc.). -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
[Fwd: Re: SMP/E: Deleting SMPPTS entries]
-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---BeginMessage--- Today, I had a typo in a DISTLIB entry in a FUNCTION. Of course this resulted in: GIM54502E ** ALLOCATION FAILED FOR ... BECAUSE THERE IS NO DD STATEMENT IN THE JCL AND NO DDDEF ENTRY IN TARGET ZONE ... I corrected the DISTLIB, and rebuilt the tape. Hastily, I deleted the member from the SMPPTS, and deleted all the TLIBs and re-received. The APPLY failed identically. The SMPPTS member shows the corrected DISTLIB regardless of the failure. Would the SMP/E panels explain what's going on? Where is the rogue DISTLIB DDNAME hiding? You didn't state what element type contained the bad DISTLIB value. Was it a ++MOD? Did you need to correct the JCLIN? Remember, link edit INCLUDE statements define the DISTLIB for MODs. Would REJECT have repaired the problem? REJECT should have given equivalent results... it deletes the SMPPTS member and the global zone SYSMOD entry. Would bumping the REWORK have repaired the problem? Incrementing the REWORK also should have given equivalent results... RECEIVE would overlay the SMPPTS member and replace the global zone SYSMOD entry with that from the higher level SYSMOD. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---End Message---
Re: Allowing Joe User into TSO
On the contrary, I am not confused at all. I'm inclined to think you are, because you're in effect comparing a restriction on how fast you can drive a car (storage/CPU) vs. a restriction on where you can or cannot drive it (TSO, SDSF, Zeke, etc.). If this discussion is about a car, then I am definitely confused. ;) But, if we were talking about cars, I think we'd be discussing you stealing 100 gallons of my gas (Gb of memory) vs. you driving on my lawn and running over my azaleas (anything other than poor ol' Zeke). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E: Deleting SMPPTS entries
Hello I need information about a DEFINE of alias in catalog user wich is under master of production for clonning other system. The job and msg of IDCAMS follow: //DEFSSA EXEC PGM=IDCAMS //STEPCAT DD DISP=SHR,DSN=CATALOG.ZOSP3 // DD DISP=SHR,DSN=CATALOG.MASTCAP3 //SYSPRINT DD SYSOUT=* //SYSIN DD * DEF ALIAS(NAME(JAVA) REL(CATALOG.ZOSP3)) DEF ALIAS(NAME(JAVA) REL(CATALOG.ZOSP3)) IDC3022I INVALID RELATED OBJECT IDC3009I ** VSAM CATALOG RETURN CODE IS 80 - REASON CODE IS IGG0CLEK-28 IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 12 Best regards Jorge Arueira Campos System Support Caixa Economica Federal São Paulo - Brazil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E: Deleting SMPPTS entries
The Messages manual gives a clear explanation of the problem. Is there something about the message that you do not understand? Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jorge Arueira Campos Sent: Friday, October 28, 2005 2:20 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SMP/E: Deleting SMPPTS entries Hello I need information about a DEFINE of alias in catalog user wich is under master of production for clonning other system. The job and msg of IDCAMS follow: //DEFSSA EXEC PGM=IDCAMS //STEPCAT DD DISP=SHR,DSN=CATALOG.ZOSP3 // DD DISP=SHR,DSN=CATALOG.MASTCAP3 //SYSPRINT DD SYSOUT=* //SYSIN DD * DEF ALIAS(NAME(JAVA) REL(CATALOG.ZOSP3)) DEF ALIAS(NAME(JAVA) REL(CATALOG.ZOSP3)) IDC3022I INVALID RELATED OBJECT IDC3009I ** VSAM CATALOG RETURN CODE IS 80 - REASON CODE IS IGG0CLEK- 28 IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 12 *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
On 28 Oct 2005 09:14:03 -0700, [EMAIL PROTECTED] (Martin Kline) wrote: But the previous discussion had some users suggesting that memory limits for all users should be set higher than the maximum requirement for any user. I believe this leave the organization vulnerable to problems. Instead, allow the one user to have lots of memory, and restrict others to a lower limit, that the system can tolerate. If it's not good for the system, I like working on a way to allow anybody to get those resources - but to have to do a bit of work every time, so that they don't set up parameters to *always* use those resources. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time change this weekend.
On Thu, Oct 27, 2005 at 06:51:51PM -0400, Ed Finnell ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] writes: ACROBAT READER 7.0.5 was recently released and so far it seems to be working fine. It's a big update, something like 9+ Mb. Yup, autoupdate picked it up and another reboot. Aren't you glad that you don't have to IPL MVS every time some applications programmer recompiles a COBOL or C program? Some readers apparently missed the point in a previous post of mine asking about rebooting their PCs. It was a snide rhetorical question. If Winblows wasn't fundamentally broken at an architectural level it wouldn't be necessary to reboot for trivial applications program installs/updates. Getting back onto the topic of this thread: One selling point of z/OS is supposedly continuous operations. So if you have to shut down an application or the system for the time change, then that application or the system is not in compliance with the continuous operations philosophy. If the code in question is current level supported by IBM, I'd be pushing hard for a fix through the APAR process. /Leonard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
Hello again! We'll I'm certainly enjoying the exchange. I think the initial responses covered what I was after. An additional detail for the curious -- Joe User currently has a Roscoe account and uses it to submit jobs that do updates. So, he has a reasonable amount of RACF authority already. But, alas, not enough due to recent (long overdue) tightening of RACF rules.So he calls us, and we submit this one job. Zeke has the authority to submit what they want, and the Work Center function (within) can be set up so they can only submit that -one- job. This would also serve as a proof of concept for migrating JCL stuff away from users (and Roscoe) and toward better (I think) control via the Zeke Work Center. Stg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
We got around the TSO need by implementing Zeke's CICS interface, then controlling it with transaction security. I think that interface comes standard with Zeke. Another option to consider for you. Local policies and politics notwithstanding. Also assuming you have CICS/TS. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Steve Grimes Sent: Friday, October 28, 2005 2:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Allowing Joe User into TSO Hello again! We'll I'm certainly enjoying the exchange. I think the initial responses covered what I was after. An additional detail for the curious -- Joe User currently has a Roscoe account and uses it to submit jobs that do updates. So, he has a reasonable amount of RACF authority already. But, alas, not enough due to recent (long overdue) tightening of RACF rules.So he calls us, and we submit this one job. Zeke has the authority to submit what they want, and the Work Center function (within) can be set up so they can only submit that -one- job. This would also serve as a proof of concept for migrating JCL stuff away from users (and Roscoe) and toward better (I think) control via the Zeke Work Center. Stg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html # Attention: The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. # -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Grimes Sent: Friday, October 28, 2005 2:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Allowing Joe User into TSO Hello again! We'll I'm certainly enjoying the exchange. I think the initial responses covered what I was after. An additional detail for the curious -- Joe User currently has a Roscoe account and uses it to submit jobs that do updates. So, he has a reasonable amount of RACF authority already. But, alas, not enough due to recent (long overdue) tightening of RACF rules.So he calls us, and we submit this one job. Zeke has the authority to submit what they want, and the Work Center function (within) can be set up so they can only submit that -one- job. This would also serve as a proof of concept for migrating JCL stuff away from users (and Roscoe) and toward better (I think) control via the Zeke Work Center. Stg I know nothing about Zeke. But would it be possible for Joe to submit a job which triggers the actual job to be run? I know that CA-7 can do this. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MEMLIMIT and IEFUSI
On Fri, 28 Oct 2005 10:28:14 -0500, Wayne Driscoll [EMAIL PROTECTED] SUPPLY.COM wrote: since the vast majority of the storage that DB2 uses above the bar is for Bufferpools, the EDM pool and other pools whose sizes is set by the user, via DB2 commands and customization, the only way that DB2 SHOULD cause a problem would be if the DB2 systems programmer (or sysadm) incorrectly sizes these pools. I don't trust them either. :-) However, I do agree that DB2 should play by the rules and not override a system limit. Exactly. Nothing (that I know of) in the system (including *MASTER*) has ever bypassed IEFUSI before. side bar I remember being at a shop once (not all that long ago) that had REGION=32M coded in MSTJCLxx. No problem until they coded some job that issued several hundred operator commands. /side bar Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America and Farmers Insurance Group mailto: [EMAIL PROTECTED] Systems Programming expert at http://Search390.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Gartner: Stop Outsourcing Now
According to an article in Z-Journal by Jon William Toigo, titled IT SENSE, Words of Caution some executives ARE outsourceing a major portion of their function if not of their fat salaries. He contends they have outsourced their thinking to the leading vendor of X partially on the old FUD, No one ever lost their job . The other part was as perverse an interpetation of capitalism as can be imagined, which he refutes. If his father in laws ideas are a correct description of the way things work then capitalism does indeed belong in the dust bin of history. What the inlaw recommends to him for career purposes would put his integrity one attometer ahead of the white smocked intellectual whores the cigarette industry used to parade around on leashes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MEMLIMIT and IEFUSI
Vendors PLEASE. If you are going to need oodles of storage above the bar, just document your requirements just like you would for common storage. ... It is documented! IBM just gave a WEB presentations about how you can use (cheap) memory in version 8 to undo some of the things you did in versions 6 7, that cost you (expensive when you include S/W) CPU because of all the constraints there were below the bar. The removal of hiperpools is also a bonus. It may not be of benefit to all, but I know two organisations (first hand) that will definitely enjoy it. -teD In God we Trust! All others bring data! -- W. Edwards Deming -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF member list
- Original Message - From: [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Friday, October 28, 2005 11:17 AM Subject: Re: ISPF member list In a recent note, Gary Green said: Date: Fri, 28 Oct 2005 10:38:31 -0400 Funny thing, I like this behavior. If one is manually searching/looking-in different members in the member list, it's a pain to scroll down a few lines to get to the next member that is off-screen. With this auto-scroll of the selected member name to the top makes it so much easier... OTOH, it's simply moronic that when the member list is small and fits entirely on a single screen, and I browse the last member and exit, the screen is scrolled so only one member shows. Such automatic scrolling should never go farther than the effect of DOWN MAX. And there you have the tastes great, less filling argument that this issue brings up. Back in the mid-90's we were having MAJOR problems trying to debug member list scrolling issues because of inconsistent behavior amongst all the different member lists. We decided to standardize on the scrolling behavior because it fixed a major problem when processing lots of members. Let's say you selected 100 out of 500 members to process. The resulting member list would be at the top of the list and you would have to scroll down a number of pages to take up where you left off. The problem with handling all the exceptions (like single pages, etc.) is the complications that it introduces to the member list code. We've tried to streamline it to make it simple, but we've had to re-introduce the non-intuitive behavior for those who only work with member lists on a single screen. I won't even get into the complications if an error occurs while you're processing multiple members. It's not as easy as it seems. If you think you can do better, be my guest. Fill out your SHARE requirements and then spend time with the ISPF development team beta testing the prototypes. Can't wait to see what you come up with. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MEMLIMIT and IEFUSI
However, I do agree that DB2 should play by the rules and not override a system limit ... I disagree! I'd rather have my business stay up, than fail because a system programmer 'knew better'! We just had the argument about resources needed to do the job! Right backatchya! -teD In God we Trust! All others bring data! -- W. Edwards Deming -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MEMLIMIT and IEFUSI
On Fri, 28 Oct 2005 00:00:00 GMT, Ted MacNEIL [EMAIL PROTECTED] wrote: However, I do agree that DB2 should play by the rules and not override a system limit ... I disagree! I'd rather have my business stay up, than fail because a system programmer 'knew better'! We just had the argument about resources needed to do the job! Right backatchya! No comparison with that conversation. Sorry to say Ted, but I think you've really missed the boat on this one. If that system programmer is the DB2 sysprog that decided to play with his test subsystem and define 30G of buffer pools, he will quickly put my system in a wait state (assuming DB2 actually tried to use that storage). The DB2/CICS/WAS/ISV/etc. folks typically look at things from their own perspective only. Part of the job in my group is to be the gate keeper. As a capacity guy you should understand that because you have the same responsibilities to the health of the overall system. What if every authorized program / product felt they knew more and bypassed IEFUSI and just used whatever above the bar storage they wanted with no overall system control? I'd rather have the one DB2 subsystem or program abend than the entire system in a wait state. Using your argument, IBM should remove the ability of IEFUSI to influence region size and MEMLIMIT altogether. Sorry, given the past history this makes no sense at all to me (IMHO). This is the same place 31-bit was when systems only had 16M (or less) of central storage - only worse. 64-bit potential is just too big. Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America and Farmers Insurance Group mailto: [EMAIL PROTECTED] Systems Programming expert at http://Search390.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
I think we'd be discussing you stealing 100 gallons of my gas (Gb of memory) vs. you driving on my lawn and running over my azaleas (anything other than poor ol' Zeke). ... To quote the Great Monty Python: “Stop that! It's silly! It was funny once. But, now it's just silly!” The issue is not how big is my banana. Rather, do I have enough bananas to do my job! It is not up to some SYSPROG who 'knows better' to decide that. Remember, the reason we are employed is to facilitate the business. NOT, to hinder it. If I need an 8GB dataspace to do my job (not that far into the future), your job is to get it for me. NOT, to complain that nobody else has one bigger than 20MB. If the business has justified it, implement it! Don't P*SS MOAN about it. Remember what NIKE said! “Just do it!” -teD In God we Trust! All others bring data! -- W. Edwards Deming -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MEMLIMIT and IEFUSI
Sorry to say Ted, but I think you've really missed the boat on this one Possibly, but I don't think so.I was probably over-reacting.We don't implement a 4TB system overnight.We plan and understand (sometimes on both points) If that system programmer is the DB2 sysprog that decided to playwith his test subsystem and define 30G of buffer pools, he willquickly put my system in a wait state (assuming DB2 actually tried touse that storage)... Again, we plan.If a SYSPROG doesn't know better, I don't want him on my account.Gone are the days where you ask: 'what would happen if I did this?'.If I really needed 30GB of storage I would put it into the box.THEN, I would define it. We don't suddenly drop DB2 V8 (for example) into the environment, and say: 'Oh crap! We forgot about MEMLIST and IEFUSI!'.We say: “Let's change IEFUSI to allow DB2 to do what is required.IE: It's DB2. Salute, and let it enter.' The DB2/CICS/WAS/ISV/etc. folks typically look at things from their ownperspective only. Part of the job in my group is to be the gate keeper Again, it's documented.We don't complain about the amount of resource (within reason).If the business needs it, it needs it. As a capacity guy you should understand that because you have the sameresponsibilities to the health of the overall system What if every authorized program / product felt they knew more andbypassed IEFUSI and just used whatever above the bar storage theywanted with no overall system control?... Again, we don't blindly implement, do we? My point was more of don't mess with it.Let it go through.Only, because it's documented and we understand it.If I inadvertently implied a blind 'the vendor said so, so it must be true', that is my error. What I meant was, don't limit DB2, but make sure you know what the DBA's are doing. I also meant that SYSPROG-types should not be applying arbitrary limits and impacting the business. DB2 V8 can save a ton of money because of the cost of CPU (hardware software) that has been consumed in V6 V7 to reduce the impact of the 2GB limit and the use of HIPERPOOLs. Staple additional memory on the box, back out the unusual acts you had to perform to get around the 2GB limit.And, accept that IEFUSI has no effect with DB2.Don't mess with DB2's decisions.But, plan -- so it doesn't take you by surprise.Implement -- in chunks, in case something goes South.And, monitor. But, don't impose arbitrary limits.SYSPROGs don't always 'know better'. -teD In God we Trust! All others bring data! -- W. Edwards Deming -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MEMLIMIT and IEFUSI
I don't know what happened this time.But, this looked like garbage (poorly formated on my BlackBerry), so I'm trying again with better formatting.If it came out better for everybody else, I'm sorry for the duplicate post. Sorry to say Ted, but I think you've really missed the boat on this one Possibly, but I don't think so. I was probably over-reacting.We don't implement a 4TB system overnight. We plan and understand (sometimes on both points) If that system programmer is the DB2 sysprog that decided to playwith his test subsystem and define 30G of buffer pools, he willquickly put my system in a wait state (assuming DB2 actually tried touse that storage)... Again, we plan. If a SYSPROG doesn't know better, I don't want him on my account. Gone are the days where you ask: 'what would happen if I did this?'. If I really needed 30GB of storage I would put it into the box. THEN, I would define it. We don't suddenly drop DB2 V8 (for example) into the environment, and say: 'Oh crap! We forgot about MEMLIST and IEFUSI!'. We say: “Let's change IEFUSI to allow DB2 to do what is required. IE: It's DB2. Salute, and let it enter.' The DB2/CICS/WAS/ISV/etc. folks typically look at things from their ownperspective only. Part of the job in my group is to be the gate keeper Again, it's documented. We don't complain about the amount of resource (within reason). If the business needs it, it needs it. As a capacity guy you should understand that because you have the sameresponsibilities to the health of the overall system What if every authorized program / product felt they knew more andbypassed IEFUSI and just used whatever above the bar storage theywanted with no overall system control?... Again, we don't blindly implement, do we? My point was more of don't mess with it. Let it go through. Only, because it's documented and we understand it. If I inadvertently implied a blind 'the vendor said so, so it must be true', that is my error. What I meant was, don't limit DB2, but make sure you know what the DBA's are doing. I also meant that SYSPROG-types should not be applying arbitrary limits and impacting the business.DB2 V8 can save a ton of money because of the cost of CPU (hardware software) that has been consumed in V6 V7 to reduce the impact of the 2GB limit and the use of HIPERPOOLs. Staple additional memory on the box, back out the unusual acts you had to perform to get around the 2GB limit. And, accept that IEFUSI has no effect with DB2. Don't mess with DB2's decisions. But, plan -- so it doesn't take you by surprise. Implement -- in chunks, in case something goes South. And, monitor. But, don't impose arbitrary limits. SYSPROGs don't always 'know better'. -teD In God we Trust! All others bring data! -- W. Edwards Deming -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MEMLIMIT and IEFUSI
I give up. Yet another reason to complain to RIM! -teD In God we Trust! All others bring data! -- W. Edwards Deming -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF WSA (Was: TN3270 Emulator)
In [EMAIL PROTECTED], on 10/28/2005 at 07:17 AM, Phil Smith III [EMAIL PROTECTED] said: And Kedit, which is a CMS XEDIT clone No, it's missing key pieces of XEDIT. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MEMLIMIT and IEFUSI
Mark Zelden wrote: If that system programmer is the DB2 sysprog that decided to play with his test subsystem and define 30G of buffer pools, he will quickly put my system in a wait state (assuming DB2 actually tried to use that storage). The DB2/CICS/WAS/ISV/etc. folks typically look at things from their own perspective only. Part of the job in my group is to be the gate keeper. As a capacity guy you should understand that because you have the same responsibilities to the health of the overall system. What if every authorized program / product felt they knew more and bypassed IEFUSI and just used whatever above the bar storage they wanted with no overall system control? I'd rather have the one DB2 subsystem or program abend than the entire system in a wait state. Hopefully, DB2 uses SYSEVENT STGTEST or similar service to help it intelligently use large virtual storage. -- - | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
3333 weight
I am looking to find the weight of the old Disk Storage Control box (the head of string of 3330s). Anyone have and old site planning guide with the data handy? Thanks! -- William Donzelli [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MEMLIMIT and IEFUSI
From: Edward E. Jaffe
Hopefully, DB2 uses SYSEVENT STGTEST or similar service to help it
intelligently use large virtual storage.
Last time (a while ago) I looked at STGTEST, I seem to recall I wasn't
overly impressed.
Will have to see if I can find the code next week.
As for hoping that DB2 will take a {w}holistic view and intelligently use
virtual ... m
I'll have to wait till I can get hold of a Version 8 system to judge that.
Shane ...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
On Oct 28, 2005, at 7:41 AM, Martin Kline wrote: I apologize in advance for not knowing the best list to send this question to. (Perhaps ISPF-L? But I'm not a subscriber there.) I'm proposing to our systems folks that we allow a user to use TSO to get to the Zeke Work Center function. I'm being told that there is no way for us to limit what the user can do if we let them intoTSO. Sounds like bullshirt to me. Any user with ATTRIBUTES=RESTRICTED will require that _every function_ they need be explicitly authorized, regardless of any existing UACC settings. I find this interesting. Just recently, list members were objecting that limiting a user's access to resources (in that case it was memory) was probably keeping them from doing their job. Where are they now? The argument was that if a user was requesting a resource, they MUST NEED IT for their job. This seems like a very similar situation. Why not allow the users access to all of ISPF, and depend on their honorable nature to only use those functions that they need to do their job? Martin, One of the main objections I have to a common logon is that there is no accountability. I would run the concept by the auditors. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allowing Joe User into TSO
On Oct 28, 2005, at 9:16 AM, Edward E. Jaffe wrote: --SNIP I suppose, if we could convince Mr. Peabody to use the Wayback Machine to take us to the meeting where RACF's moniker was invented, we could insist on a more-appropriate one, like PCF = Permissions Control Facility. :-\ -- Already taken PCF = Program Control Facility. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time change this weekend.
I'm not sure, but I think IDMS (we are 14.2) still can't handle moving back an hour so we need to leave it down. Last year (2004) for the change to EDT we had an operator who thought they remembered how to change the time on the sysplex timers, ended up changing GMT time instead of the local offset. We had to leave DB2 down for an hour when we changed it back. I think if you use the oder NetView time commands instead of newer cron based ones it still needs to be bounced after the time change, both to and from EDT. McGee, Cletus wrote: I am new to this company here and one of the things they do is to shut the system down on the fall time change and wait one hour before they bring the system back up. Outside of scheduler issues, is there any reason to do this? One that keeps coming up is the timestamp on VSAM files being an issue. Some questions. One does anyone else do this and if so why? Second, is there real reason why this should happen, if so what are they? Or are they just working off one bad past experience. Thanks in advance. *** Cletus McGee Technical Services (334) 394-3320 Have a grand day -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
