Outsourcing
With due respect to all the fellow listers, I would like to request everybody on the list to kindly avoid any comments that directly or indirectly hurt anybody's sentiments. I have felt, that some of the comments (recently) were not intentional, but may just have been a result of the outsourcing and the resulting job-cuts in US and other countries. I am working for a company in India, and I must say that it gives us no pleasure to know the fact that a lot of us have got our jobs at the expense of some other folks around the world. All of us know that these are not employee decisions but the company's higher management politics to gain more and more stock value. Again the decision makers are not the ones who get hired ,not are those who very sadly lose their jobs, but the ones who only see the bottomline. I'm pretty much sure that Indians will start losing their jobs to some other countries, when the time comes. I am not writing this to start a debate. I just wanted to show the other side of the coin as well. -- 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 FREED SYS1.PARMLIB
Thanks to everyone that contributed! As suggested, SETLOAD was the way to go for me. I once again have a properly sized SYS1.PARMLIB. However, while reviewing SETLOAD documentation, questions spring to mind: Do you folks concatenate your SYSx.IPLPARM (if you use it) to PARMLIB in LOADxx? I was also curious if IEFPRMLB could be made to include by default the PDS where LOADxx was found at IPL time, much like it includes by default SYS1.PARMLIB. I've recently taken to using LOADxx found in SYSx.IPLPARM on the IODF volume instead of finding LOADxx in SYS1.PARMLIB. When I first issued my SETLOAD command, it failed because I didn't specify DSN=SYSx.IPLPARM as I should have, because at this time, I don't concatenate SYSx.IPLPARM. I know, how I concatenate PARMLIB is my choice, but I'd hate to be viewed as 'out there' if this isn't considered standard practice! ;) I don't know if I'm OCD, but I like having any/all of my LOADxxs found in one place. I happen to choose SYSx.PARMLIB for that. I've also considered creating a SYS1.LLA.PARMLIB (and system specific SYS1.LLA.PARMLIBs) to contain CSVLLAxx members, excluding CSVLLA00. I guess there's a line to draw between being organized and easily maintainable. Thanks again for being the group that you are! On Thu, 30 Aug 2007 17:57:48 -0500, Steve Horein [EMAIL PROTECTED] wrote: Hi all, Ugh - Long days short nights has taken it's toll on me. Instead of viewing our shared SYS1.PARMLIB with 'V' in ISPF, I instead freed it with 'F'. Yeah I know, F V are not even on the same row on the keyboard. Now SYS1.PARMLIB is 100% used. I've allocated 'SYS1.PARMLIB.SIZE' with the original primary, 0 secondary. Would it be safe to: 1) IEBCOPY the freed SYS1.PARMLIB into the SYS1.PARMLIB.SIZE, 2) rename the freed SYS1.PARMLIB to SYS1.PARMLIB.DONT.DELETE, 3) finally rename SYS1.PARMLIB.SIZE to SYS1.PARMLIB? Searching the archives makes me think I'd be fine, what with all of the topics relating to compressing PARMLIB, but I'd rather ask outright about the whole rename/swap idea. I have system specific PARMLIBs concatenated before SYS1.PARMLIB, so any required changes could be made there if D37 issues arise before the next IPL. Thanks, and any suggestions would be helpful! -- 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: ISPF FREED SYS1.PARMLIB
On Sep 1, 2007, at 10:23 AM, Steve Horein wrote: Thanks to everyone that contributed! -SNIP Steve, Indeed this was an interesting discussion. What got me curious is that quite a few people do not run with SYS1.PARMLIB without an expiration date. I have *ALWAYS* put expdt on all sys1 libraries. I do it for two reasons. 1. Its a double check incase I finger check and save something that was not to be saved. 2. its a double check against the security people to make sure they haven't oops'd a definition. I think if you would have (in this case) did a F to the library it would have asked the operator and you could have called them and said reply M But it also asks the first question I have does every one put expdt on all sys1 libraries (or some) ? 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: Permission Problems On 3rd Open Of Same PDS
On Fri, 31 Aug 2007 21:18:58 -0700, Harry Goldschmitt wrote: My application gets an EDC5111I Permission denied. (errno2=0x5b450002) DD:TEST3 message. My code does: fh1 = fopen(DD:TEST1); fclose(fh1); fh2 = fopen(DD:TEST2); fclose(fh2); fh3 = fopen(DD:TEST3); failure The DD statements for the program look like: //TEST1 DD DISP=SHR,DSN=USERID.TEST(TEST1) //TEST2 DD DISP=SHR,DSN=USERID.TEST(TEST2) //TEST3 DD DISP=SHR,DSN=USERID.TEST(TEST3) As far as I can see, this code should not require an OMVS segment. I'd report it as a bug. If the problem didn't likewise occur with RACF, I'd suspect ACF2's technique of protecting individual PDS members (or was that Top Secret). Does ACF2 not allow for a default OMVS segment? -- gil -- 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: Virtual Storage implementation
On Fri, 31 Aug 2007 16:22:18 -0600, Mark Post wrote: On Fri, Aug 31, 2007 at 6:08 PM, in message [EMAIL PROTECTED], Tom Marchant [EMAIL PROTECTED] wrote: On Fri, 31 Aug 2007 15:07:53 -0600, Mark Post wrote: -snip- Even on midrange systems it isn't all that cheap when you get into shared/virtualized environments. If the admin wants to give 64GB to every guest, you won't get many guests. Oh, really? Sure you can. z/VM can handle it very nicely, thank you. Not without a lot of paging space to back it up, and not without a severe performance hit if the machine only has, for example, 64GB of real to start with. Regardless of how you implement large numbers of Linux images, there will be paging. My comments were in response to the creation of Linux images that did not include swap space, and that were therefore not going to do any paging on their own. It is not obvious to me under those conditions that it is a bad idea to provide a sufficiently sized virtual guest is a bad idea. Indeed, I wonder if it might be better to define Linux guests that way and let z/VM handle all the paging for all of them. As Lynn pointed out, strange things can happen when you run a paging guest in a virtual machine My point being that the RAM is cheap mantra starts to fail when a box is only so big, and it needs to be shared among numerous entities. We've been doing it in the mainframe world for a long, long time. The midrange folks are just now starting to get an inkling of what shared/virtualized means in terms of application design, system requirements, etc., etc. Oh, and if you create a 64GB z/VM guest, shame on you. The potential problem is not with the virtual machine's memory size, but with the working set size. A 64 GB z/VM guest is only a problem if it has a large working set. Linux will use what it needs, not necessarily all that is available. And if it has a 16 GB working set, what happens to it if it is in a 4 GB virtual machine? As someone who is very heavy into z/VM performance once told me, z/VM is very good at managing large numbers of small things. It's not so good at managing a smaller number of very large things. I tend to agree. The z/VM scheduler isn't too happy about guests with large working sets. I'm not impressed with any quote of an anonymous authority. To answer your question, yes, that would mean they have no virtual storage. I take it you disagree with Tony Harminc's post. Paging is only one part of virtual storage. The other part is the mapping of virtual addresses to real addresses. I would take the position that the two are both necessary, but not sufficient. I really think you need both of them to achieve what most people think of as virtual storage. On this, you and I can simply disagree. -- Tom Marchant -- 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: Virtual Storage implementation
I'm not impressed with any quote of an anonymous authority. The same presentation was given at SHARE and CMG Canada, by John Anderson of IBM Canada, about the Quebec Government's conversion to LINUX under z/VM (three IFL's), from over a 100 servers. He stated two things: 1. Don't consolodate; just move them over. 2. Even though the paging overhead is reduced, there is still some, and with enough guests it can become an issue. So, define the LINUX guest as small as possible. - Too busy driving to stop for gas! -- 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: Permission Problems On 3rd Open Of Same PDS
Harry, when this problem occurs, are there any other error messages in the Joblog or elsewhere in SYSOUT? Are you sure, that the third member exists in the PDS at the time of error and that it does contain valid data? What does a TSO command bpxmtext 5b450002 tell you (for whatever it's worth?) I've been looking all over the IBM website and I can't find an explanation for errno2=0x5b450002, so I'm at a loss to try and explain the problem. If the program doesn't use any OMVS services, such as try to access HFS files, your users shouldn't need an OMVS segment in their RACF / ACF2 profile, not even a default ACF2 - OMVS segment. So, all I can guess is that the problem has to do with the third file existing or being valid. If not, C++ goes off into the wild blue, trying to create / access an HFS file. Regards, Ulrich Krueger -- 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: Virtual Storage implementation
On Sat, Sep 1, 2007 at 1:04 PM, in message [EMAIL PROTECTED], Tom Marchant [EMAIL PROTECTED] wrote: -snip- My comments were in response to the creation of Linux images that did not include swap space, and that were therefore not going to do any paging on their own. It is not obvious to me under those conditions that it is a bad idea to provide a sufficiently sized virtual guest is a bad idea. It is a very bad idea, for all the reasons we've been talking about, and the one I talk about below. It would be a bad idea on VMWare or Xen as well. The only place it would make sense is on discrete servers that aren't sharing any resources with other system images. Indeed, I wonder if it might be better to define Linux guests that way and let z/VM handle all the paging for all of them. As Lynn pointed out, strange things can happen when you run a paging guest in a virtual machine No, that would not be better, at all. It would be much, much, worse, and cause you to spend far too much money on real storage, and still not utilize as much of the rest of the hardware as you should. -snip- The potential problem is not with the virtual machine's memory size, but with the working set size. A 64 GB z/VM guest is only a problem if it has a large working set. Linux will use what it needs, not necessarily all that is available. And if it has a 16 GB working set, what happens to it if it is in a 4 GB virtual machine? If you give a Linux guest a 4GB virtual machine, it will have very close to a 4GB working set. If you give that same Linux guest 64GB, it will have very close to a 64GB working set. The fact that you say Linux will use what it needs tells me that you have little or no experience running Linux, either on midrange systems or on the mainframe. Linux will _always_ use everything you give it, if for nothing else than buffers and cache. Hence the constant battle we have with midrange Linux sysadmins, DBAs, etc., regarding this topic. It's also a recurring topic with the midrange performance/capacity folks, since we keep getting concerned phone calls and emails about how we have to add more RAM to a Linux system because it's running out. It hasn't run out, it is just using all the otherwise unused storage for buffers and cache, but that's not the behavior they're used to seeing from AIX, Solaris, HPUX, etc. As someone who is very heavy into z/VM performance once told me, z/VM is very good at managing large numbers of small things. It's not so good at managing a smaller number of very large things. I tend to agree. The z/VM scheduler isn't too happy about guests with large working sets. I'm not impressed with any quote of an anonymous authority. That's OK, I wasn't expecting anyone to be impressed, just take the point at face value. It has been everyone's experience that this is the case, including mine. Major surgery had to be performed on z/VM 5.x to get it to work reasonably well with some number of large guests. It's still not as good at it as we would like, but I know the z/VM developers are working on that too. Mark Post -- 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: Virtual Storage implementation
Mark Post wrote: If you give a Linux guest a 4GB virtual machine, it will have very close to a 4GB working set. If you give that same Linux guest 64GB, it will have very close to a 64GB working set. The fact that you say Linux will use what it needs tells me that you have little or no experience running Linux, either on midrange systems or on the mainframe. Linux will _always_ use everything you give it, if for nothing else than buffers and cache. Hence the constant battle we have with midrange Linux sysadmins, DBAs, etc., regarding this topic. It's also a recurring topic with the midrange performance/capacity folks, since we keep getting concerned phone calls and emails about how we have to add more RAM to a Linux system because it's running out. It hasn't run out, it is just using all the otherwise unused storage for buffers and cache, but that's not the behavior they're used to seeing from AIX, Solaris, HPUX, etc. past posts in this thread: http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation http://www.garlic.com/~lynn/2007o.html#45 Virtual Storage implementation http://www.garlic.com/~lynn/2007o.html#46 Virtual Storage implementation http://www.garlic.com/~lynn/2007o.html#47 Virtual Storage implementation http://www.garlic.com/~lynn/2007o.html#48 Virtual Storage implementation http://www.garlic.com/~lynn/2007o.html#52 Virtual Storage implementation unix/linux will use its (virtual) machine storage for running applications and file caching. if there is enough machine storage ... the application storage is whatever the page requirements for the collection of the running appliications (linux kernel code, demons, etc). if the machine storage is at least as large as the total program execution storage ... then the system may not have to do any paging operations. the remaining (potentially virtual) machine storage will be used for file record caching is analogous to the operation of dbms systems with database record caching. lots of dbms systems have configuration parameters for total size of record caching ... attempting to tune them when running in a virtual memory environment. this is similar to the description of the (storage management) changes migrating apl\360 (assuming the available storage was real) to cms\apl (where there was enormously larger amount of virtual, paged storage). The implicit assumption was that the available configured storage was real and could be used arbitrarily w/o regard to potential working set size implications and effect on demand paging. http://www.garlic.com/~lynn/2007o.html#45 Virtual Storage implementation one of the other projects at the science center http://www.garlic.com/~lynn/subtopic.html#545tech involved application instruction and storage access tracing. this was used in modeling possible page replacement algorithms and working set sizes. Eventually some of this was released as VS/REPACK product which would do semi-automated program reorgnization to optimize virtual storage operation. Early version of what became VS/REPACK was used in assisting with migrating apl\360 to virtual memory environment as cms\apl. Various versions of VS\REPACK were also used be other corporate product groups aiding in the migration from real storage paradigm to virtual storage paradigm. One such early user of the package was the organization developing and supporting IMS. A side-effect of the package tracing/monitoring ... in addition to helping analyzing execution characteristics in virtual storage environment, it was also used for straight-forward execution hot-spot analysis. random past posts mentioning vs/repack: http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc) http://www.garlic.com/~lynn/97.html#20 Why Mainframes? http://www.garlic.com/~lynn/99.html#7 IBM S/360 http://www.garlic.com/~lynn/99.html#61 Living legends http://www.garlic.com/~lynn/99.html#68 The Melissa Virus or War on Microsoft? http://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems http://www.garlic.com/~lynn/2000d.html#12 4341 was Is a VAX a mainframe? http://www.garlic.com/~lynn/2000g.html#11 360/370 instruction cycle time http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back? http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic) http://www.garlic.com/~lynn/2001c.html#31 database (or b-tree) page sizes http://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...) http://www.garlic.com/~lynn/2001j.html#3 YKYGOW... http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning) http://www.garlic.com/~lynn/2002c.html#46 cp/67 addenda (cross-post warning) http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names http://www.garlic.com/~lynn/2002d.html#7 IBM
Re: Virtual Storage implementation
On Sat, 1 Sep 2007 13:17:36 -0600, Mark Post wrote: On Sat, Sep 1, 2007 at 1:04 PM, Tom Marchant wrote: -snip- -snip- The potential problem is not with the virtual machine's memory size, but with the working set size. A 64 GB z/VM guest is only a problem if it has a large working set. Linux will use what it needs, not necessarily all that is available. And if it has a 16 GB working set, what happens to it if it is in a 4 GB virtual machine? If you give a Linux guest a 4GB virtual machine, it will have very close to a 4GB working set. If you give that same Linux guest 64GB, it will have very close to a 64GB working set. The fact that you say Linux will use what it needs tells me that you have little or no experience running Linux, either on midrange systems or on the mainframe. Linux will _always_ use everything you give it, if for nothing else than buffers and cache. Hence the constant battle we have with midrange Linux sysadmins, DBAs, etc., regarding this topic. It's also a recurring topic with the midrange performance/capacity folks, since we keep getting concerned phone calls and emails about how we have to add more RAM to a Linux system because it's running out. It hasn't run out, it is just using all the otherwise unused storage for buffers and cache, but that's not the behavior they're used to seeing from AIX, Solaris, HPUX, etc. -end_snip- How much progress has been made (if any?) towards setting up the Linux instance to have a maximized number of read-only memory segments that are able to be defined as shared (in VM's terms)? It seems that VM's shared segment support could do wonders to reduce the Linux working set. Mark, are you aware of any such activity to date? -- Tom Schmidt Madison, WI -- 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: Virtual Storage implementation
On Sat, 2007-09-01 at 18:09 -0500, Tom Schmidt wrote: How much progress has been made (if any?) towards setting up the Linux instance to have a maximized number of read-only memory segments that are able to be defined as shared (in VM's terms)? It seems that VM's shared segment support could do wonders to reduce the Linux working set. Mark, are you aware of any such activity to date? Tom, I don't know how much this will (positively) affect the buffer/cache issue Mark raised. Best bet on (particularly virtualized) servers might be to play with the swappiness sysctl. On non file-servers you might go all the way to 0 (zero) and allow the old 2.4 behaviour to predominate. This significantly biases the memory allocation toward application storage in preference to disk cache. Then the guest could hopefully be sized more confidently. Last I looked, the kernel devs were dis-inclined to countenance something like a sysctl to cap the disk cache, although (*very*) recent kernels do offer drop_caches. However this simply releases the cache(s) at that point in time. 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: Outsourcing
On Sat, 1 Sep 2007 11:47:57 +0530 Mainframe Sysprog [EMAIL PROTECTED] wrote: :With due respect to all the fellow listers, I would like to request :everybody on the list to kindly avoid any comments that directly or :indirectly hurt anybody's sentiments. :I have felt, that some of the comments (recently) were not intentional, but :may just have been a result of the outsourcing and the resulting job-cuts in :US and other countries. I am working for a company in India, and I must say :that it gives us no pleasure to know the fact that a lot of us have got our :jobs at the expense of some other folks around the world. All of us know :that these are not employee decisions but the company's higher management :politics to gain more and more stock value. Again the decision makers are :not the ones who get hired ,not are those who very sadly lose their jobs, :but the ones who only see the bottomline. I'm pretty much sure that :Indians will start losing their jobs to some other countries, when the time :comes. :I am not writing this to start a debate. I just wanted to show the other :side of the coin as well. People would have a lot more respect for your statement if you put your name and reputation behind it. By concealing your identity ... -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: SHARE San Diego Snubbery
On Mon, 13 Aug 2007 14:23:42 -0500, Chase, John [EMAIL PROTECTED] wrote: I dunno. I've snubbed Ed Jaffe and Mark Zelden so far (oh, yeah Scott Fagen, too), but didn't see any other recognizable faces at the Sunday night gathering. Maybe tonight... -jc- (Sorry for the delay in replying due to extended vacation...) Can one who was not a SHARE attendee (I was merely my wife's GUEST at this particular event) be snubbed? Scott Fagen -- 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: Outsourcing losing steam? (was: ...loosing...)
On Tue, 14 Aug 2007 09:47:05 -0400, Veilleux, Jon L [EMAIL PROTECTED] wrote: Brian you are correct. When I open ETRs on these problems the respondants have very heavy accents. Not that I am a xenophobe but I see the quality (or lack there of) of work we get from outsourcers, so I suspect that IBM has slipped down that slope also, to the detriment of those of us who rely on IBMLINK. Jon L. Veilleux Jon, I don't think Mr. Palmisano would suggest it's 'slipping down any slope'. You can read his treatise on 'globalization' at: http://www.ibm.com/ibm/governmentalprograms/samforeignaffairs.pdf Scott Fagen -- 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: Stand-Alone Dump Process
On Fri, 31 Aug 2007 13:22:33 -0400 Jim Mulder [EMAIL PROTECTED] wrote: :IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 08/31/2007 :12:55:59 PM: : The advice I've heeded for years is NOT to perform STORE STATUS for : standalone dump because MVS itself sets a flag that requests STORE :STATUS : on the next IPL in the same LPAR. So manual action is not only :unnecessary, : but you might inadvertently get status stored from SAD itself rather :than : from the running OS. That would be appropriate only if you're trying to : debug standalone dump code. :From the archives: :http://bama.ua.edu/cgi-bin/wa?A2=ind0403L=ibm-mainP=R9199I=1X=- :archive start :Subject: Re: Stand-Alone Dump Questions :From: Jim Mulder [EMAIL PROTECTED] :Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU :Date: Tue, 2 Mar 2004 14:28:00 -0500 :Content-Type: text/plain : I've seen posting from Greg Dyck that say not to set store status, : because it's already done for you by z/OS. : That doesn't make sense. You use a SA dump when z/OS is dead in the : water. I suspect that he was telling you not to do a double store : status. : During IPL processing, MVS tells the machine to do a store status :as part of the next LOAD (IPL) operation under the assumption that :the next LOAD *might* be an IPL of SA dump. If it isn't, no harm is :done. This function was introduced in MVS/370 SP1.3 as part of the :RAS enhancements package for the 3033 processor, to deal with the :problem of operators forgetting to do a store status. Unfortunately, :VM never implemented this function (unless it was done recently :and I didn't hear about it), so you still need to do it manually :when running MVS on VM. :archive end : One update: :That support was added to z/VM 5.1, which became generally available in :September, 2004. Can issuing a STORE STATUS directly hurt? Or does the IPL store status save the exact same data? -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: SPAM: Re: Password expiration message at every SUBMIT at z/OS 1.8?
On Fri, 31 Aug 2007 16:54:27 -0500 Rick Fochtman [EMAIL PROTECTED] wrote: :---snip- :Wouldn't PUTLINE be a better choice than TPUT? :---unsnip :That would depend on how early in the process. Remember that some :control blocks may not be fully populated yet. If I recall correctly, PUTLINE could be used at TSO pre-prompt time, which is before RACF validation. On the other hand, as this code is guaranteed to be running on real TSO and will be running where nothing is trapping the stack, there ain't much difference. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: SHARE San Diego Snubbery
Can you actually be snubbed, if you didn't know you were snubbed? Tree- forest, sound, you know the rest. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Fagen Sent: Saturday, September 01, 2007 SYSN 07:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SHARE San Diego Snubbery On Mon, 13 Aug 2007 14:23:42 -0500, Chase, John [EMAIL PROTECTED] wrote: I dunno. I've snubbed Ed Jaffe and Mark Zelden so far (oh, yeah Scott Fagen, too), but didn't see any other recognizable faces at the Sunday night gathering. Maybe tonight... -jc- (Sorry for the delay in replying due to extended vacation...) Can one who was not a SHARE attendee (I was merely my wife's GUEST at this particular event) be snubbed? Scott Fagen -- 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
