Re: Tape Encryption Products List - Version 3.0
As SLIKZIP's feature load has grown the release rate has dropped from every six months to more like every 12, but that in no way justifies the statements that Ted has made in this influential forum. How about it Ted? I've already appologised offline. But, I would like to make a public clarification. I made the statements from (an obviously not working) memory. I'm sorry for any confusion I caused. And, there was no intention of malice. We did go with a different product to replace PKZIP, for the simple reason that we did not want to change the control cards for over 900 jobs. We did not have the resources to do that, so we ruled out thoses that required us to make any changes. Even the one we picked was not 100% compatible, but we only had to change (maybe) 5 jobs and two programmes using the COBOL API. I looked at quite a few products, at the time. There was one that had a name similar to SLIKZIP (that had been stabilised at OS/390 2.10), and I confused the two, since I didn't have my notes with me. Again, I appologise for any confusion/mis-information. I always intend to be accurate, but we all nake mistakes. . Questions? Concerns? (Screams of Outrage?) -- 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: Cart Disk Allocation
Jim, since, as you say, this issue goes back an awfully long way, it seems very odd that IBM never implemented any facility to achieve the same result as in your solution in the OS code - i.e. an additional subparameter to the VARY command to set the bit you mention, or even a new command to achieve the same result. It seems like a number of people have been impacted by this issue over a long period of time - to the point (in your case) of writing code to circumvent the problem. Perhaps there is a good reason why they never have - does anybody know what that is? -- 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: LPAR performance questions ?
Hi, We have the following IBM box : *IBM z890-2086-A04 Model 6260 with SN 2549A ; with zOS 1.7. in 64 bit mode ; z990 Exploitation Feature (there are two IFL in this configuration). We have 5 LPAR's defined on this box and 1 Linux Lpar. None of these LPAR's are capped and we are running at 150% CPU busy on the Production Lpar. Questions : 1. Would these different LPAR's not effect each other 2. Why do I need 2 test LPAR's in this setup 3. Should it not be more beneficial to remove some of these LPAR's. So instead of 5 , I rather define 3. Some people are arguing that we should move some of the Test CICS'se , off the Prod LPAR and into a Test LPAR. I prefer to run less LPAR's and keep everything on the Prod Lpar. What do you think ? Anton -- 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: LPAR performance questions ?
---snip- Hi, We have the following IBM box : *IBM z890-2086-A04 Model 6260 with SN 2549A ; with zOS 1.7. in 64 bit mode ; z990 Exploitation Feature (there are two IFL in this configuration). We have 5 LPAR's defined on this box and 1 Linux Lpar. None of these LPAR's are capped and we are running at 150% CPU busy on the Production Lpar. Questions : 1. Would these different LPAR's not effect each other ---unsnip-- Yes, the LPARs will affect each other. There's only so much CPU service in the pie, no matter how you slice it. Dividing it up 5 ways instead of three means that each LPAR could get a smaller slice. Plus you have the overhead difference between 5 LPARs and 3 LPARs. ---snip- 2. Why do I need 2 test LPAR's in this setup ---unsnip-- I know of no technical reason; perhaps there are political or business reasons in your shop. ---snip- 3. Should it not be more beneficial to remove some of these LPAR's. So instead of 5 , I rather define 3. -unsnip I would recommend removing 2 LPARs and consolidating workloads. But I'm thinking from a technical standpoint; you may have other considerations, as in point 2. YMMV. Beware of possible turf wars within your shop. You may also have to rethink LPAR weighting factors. snip Some people are arguing that we should move some of the Test CICS'se , off the Prod LPAR and into a Test LPAR. I prefer to run less LPAR's and keep everything on the Prod Lpar. What do you think ? unsnip- I'm a firm believer in separating TEST workloads from PROD workloads and keeping each in its own LPAR. This way, a run-away CICS transaction in a test CICS can't have anywhere near as much impact on the overall PROD workload. Again, YMMV. -- 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
Announcement: New Release of XMITIP 5.58
This e-mail is to announce a new release of XMITIP - version 5.58. This release can be found at http://www.lbdsoftware.com and comes with updated Users Guide and Installation Guide. The update includes the following enhancements over the prior 5.56 release: - Support for correctly recognizing the start and end of Daylight Savings Time for those installations who require it plus the code is easy to customize if you are not using the U.S. flavor of DST - Support for SLIKZIP as a zip tool - Support for installation defined symbolics that can be used in Subject, Filenames, and Message Text (MSGT) As with all prior releases this code is being made available for free and comes with no guarantee, no warranty, and no recourse should it not work for you. You should verify that this update works for you before using it in your environment. Comments, suggestions and bug reports are welcome. Lionel B. Dyck, Consultant/Specialist zLinux Platform Client and Platform Engineering Services (CAPES) KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We’re here to make lives better.” If you take care of your character, your reputation will take care of itself. NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
Re: LPAR performance questions ?
In a message dated 1/20/2007 9:21:05 A.M. Central Standard Time, [EMAIL PROTECTED] writes: I would recommend removing 2 LPARs and consolidating workloads. But I'm thinking from a technical standpoint; you may have other considerations, as in point 2. YMMV. Beware of possible turf wars within your shop. You may also have to rethink LPAR weighting factors. I agree and would CAP the Test and Development LPARs significantly. Again assumptions are made as to business model. I've seen financial institutions where Production and Test were mandated electronically separate and developmental environments where 'testing is our priority'. Further at 150% utilization WLM doesn't function well. I'll plug Cheryl's Goal Tender software(_www.watsonwalker.com_ (http://www.watsonwalker.com) ) to see how your goals are fairing against reality. It may be that you're only buying time for the next upgrade, but at least you'll have corroboration/justification. -- 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: LPAR performance questions ?
Hi, One more question : If the LINUX Lpar is running at 110% busy, does this LPAR take power away from the 2 physical engines ? Anton -- 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: Cart Disk Allocation
Steve O'Connell wrote: Perhaps there is a good reason why they never have - does anybody know what that is? They probably wanted to reduce call center work load? A drive flagged with the OLTEP bit is not considered for allocation under any conditions. When a job requests more units than are currently available, it waits, but the available count does not include the OLTEP units, and can thus result in allocation failures. E.g., if you ran a tape sort with one input and output tape, and six work tapes, and you had one string of 8 drives, it would sit in allocation until all 8 drives were available. But if even one drive were flagged for OLTEP, the allocation would fail, resulting in an irate user. OTOH, I used this under normal conditions to reduce SYSGENs for MVT MVS. I included additional strings of DASD and tape, but after the GEN zapped the non-existent UCBs in the nucleus to include the OLTEP bit, and used DYNAMASK to remove them from the name tables. Gerhard Postpischil Bradford, VT new e-mail address: gerhardp (at) charter (dot) net -- 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: LPAR performance questions ?
In a message dated 1/20/2007 12:13:16 P.M. Central Standard Time, [EMAIL PROTECTED] writes: One more question : If the LINUX Lpar is running at 110% busy, does this LPAR take power away from the 2 physical engines ? Yes, but only due to the fact that it's an LPAR not that it's running at 110% busy. IBM has worked on the state space switching algorithms in uCode and it's gotten better over the years but it's still overhead and still hard to measure precisely without large expenditures in hardware and people. Remember one large shop gave a user benchmark(late eighties) with and without PR/SM and it was near 30% overhead on a 400J. -- 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: LPAR performance questions ?
Ed, Are you sure about this because I was led to believe that the LINUX LPAR runs off it's own processors ? Anton Ed Finnell wrote: In a message dated 1/20/2007 12:13:16 P.M. Central Standard Time, [EMAIL PROTECTED] writes: One more question : If the LINUX Lpar is running at 110% busy, does this LPAR take power away from the 2 physical engines ? Yes, but only due to the fact that it's an LPAR not that it's running at 110% busy. IBM has worked on the state space switching algorithms in uCode and it's gotten better over the years but it's still overhead and still hard to measure precisely without large expenditures in hardware and people. Remember one large shop gave a user benchmark(late eighties) with and without PR/SM and it was near 30% overhead on a 400J. -- 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: Shadow 6.1.3.6289
Hi, Is there anybody out there that is running this version of Shadow yet ? VErsion 6.1.3.6289.. Anybody, it does not matter how big you are or who you voted for in the last election. Anton -- 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: LPAR performance questions ?
On Sat, 2007-01-20 at 15:04 -0500, Ed Finnell wrote: Remember one large shop gave a user benchmark(late eighties) with and without PR/SM and it was near 30% overhead on a 400J. Muggs- they should have used Amdahl kit, then they could have benefited from MDF :o) Anyway back to Antons questions. Presumably the Linux LPAR is running on the 2 IFLs. It is not a consideration in performance terms at 110%. To all intents and purposes it is running dedicated (unless there is a VM LPAR we don't know about lurking around), and below capacity. That leaves 2 engines for the other 5 LPARs - with at least one having two logical engines defined. Makes for a bad logical~physical ratio. So ... as the others have said, get the number of MVS LPARs down. 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: LPAR performance questions ?
In a message dated 1/20/2007 2:18:42 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Are you sure about this because I was led to believe that the LINUX LPAR runs off it's own processors ? I'd have to have more information. If it's running on dedicated IFL's I'll retract. If it's running on own LPAR or under VM LPAR then I'm sure. Don't run SHADOW at all. -- 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: Status Stop and REXX
In [EMAIL PROTECTED], on 01/17/2007 at 12:46 AM, Craddock, Chris [EMAIL PROTECTED] said: It will work FSVO of work but the proposed solution has the same set of issues that STATUS does. No, it has a different set of issues. Several of the cases where STATUS STOP is dangerous will delay the IRB until it is safe. The flip side is that you have to be very careful what you do in the IRB. Either approach looks risky, but the problems are not the same. -- 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: PULL? PUSH? STEM? (was: REXX EXECIO changing LOWERCASE TO UPPERCASE)
In [EMAIL PROTECTED], on 01/16/2007 at 09:43 AM, Charles Mills [EMAIL PROTECTED] said: It would be great to be able to pass stems to Rexx functions, internal or external. Well, if you could convince IBM to port OOREXX to MVS, ... -- 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: Risks (Was Re: Decoding the encryption puzzle)
In [EMAIL PROTECTED], on 01/19/2007 at 11:03 AM, Eric Chevalier [EMAIL PROTECTED] said: Come on, folks; let's have a little perspective on this issue! Perhaps you can't find laptops with ECC memory because the non-ECC memory is completely reliable for all _practical_ purposes? Perhaps it is. And perhaps you'll win $1,000,000,000 in the lottery. Google for Gresham's Law. -- 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: Status Stop and REXX
In [EMAIL PROTECTED], on 01/17/2007 at 08:15 AM, Binyamin Dissen [EMAIL PROTECTED] said: Another TCB could be created in the interval. Not if you acquire the LOCAL lock. Perhaps 90%+ of the time. I'd guess 99%+, but when it does break that will make up for all of the times that it didn't. I wouldn't do it, but it's not my dog. -- 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: Status Stop and REXX
In [EMAIL PROTECTED], on 01/17/2007 at 07:14 PM, Shane [EMAIL PROTECTED] said: I had an inkling this was the case, but couldn't find it documented at the time. It was in the PLM at one time. -- 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: SYSPLEX for PDS-E Sharing
In [EMAIL PROTECTED], on 01/18/2007 at 12:48 PM, Rugen, Len [EMAIL PROTECTED] said: The alternative is to go over to the dark side.. Or to *bsd or Linux. -- 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: SYSPLEX for PDS-E Sharing
In [EMAIL PROTECTED], on 01/18/2007 at 01:30 PM, Craddock, Chris [EMAIL PROTECTED] said: Don't forget that (AFAIK) all currently supported processors support some form of xMIF, EXPN? The last I heard, PR/SM still didn't provide any form of virtual CTCA. Or are you alluding to the fact that one pair of channels, cross connected[1], can serve as CTCA's for every pair of LPAR's? [1] Or connected to the same director/fabric. -- 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: SYSPLEX for PDS-E Sharing
In [EMAIL PROTECTED], on 01/17/2007 at 01:42 PM, Rugen, Len [EMAIL PROTECTED] said: Do I need to setup GRS (yuck) in a ring to safely share PDSES? Star is preferred, but you do need GRS. I don't think I want or need XCF. XCF is part and parcel of sysplex. In [EMAIL PROTECTED], on 01/17/2007 at 03:39 PM, Rugen, Len [EMAIL PROTECTED] said: Isn't XCF the coupling facility? No; XCF can run over a CTCA for basic sysplex. I'm only a 2-way processor, wouldn't I have to sacrifice one processor to the CF LPAR? No. You don't need a CF for basic sysplex, and you can[1] share a process for the CF LPAR if you go that route. [1] There are, of course, performance ramifications. -- 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: SYSPLEX for PDS-E Sharing
In [EMAIL PROTECTED], on 01/17/2007 at 05:45 PM, Jim Mulder [EMAIL PROTECTED] said: Basic sysplex came in MVS/ESA SP4.1. PDSE came in MVS/ESA SP4.3. PDSE came in as part of DFSMS. I don't recall which release. -- 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: PULL? PUSH? STEM? (was: REXX EXECIO changing LOWERCASE TO UPPERCASE)
I'll give Sam a call on Monday. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.) Sent: Saturday, January 20, 2007 3:20 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PULL? PUSH? STEM? (was: REXX EXECIO changing LOWERCASE TO UPPERCASE) In [EMAIL PROTECTED], on 01/16/2007 at 09:43 AM, Charles Mills [EMAIL PROTECTED] said: It would be great to be able to pass stems to Rexx functions, internal or external. Well, if you could convince IBM to port OOREXX to MVS, ... -- 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: Cart Disk Allocation
Gerhard, I may be missing something, but I don't follow the logic in your example about a single job wanting 8 drives being worse off if a drive is flagged as unavailable. If a job wants 8 drives, and 1 is broken, then surely that job isn't going to run either way without a JCL change, is it? The only difference I see is that with the broken drive being flagged unavailable the job may fail, whereas if it tries to assign the broken drive because it is flagged as available it will hang indefinitely. Personally, I'd rather the job failed and freed up all 7 other tape drives for use by other work if the drive is broken. ?? Steve O. -- 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: Cart Disk Allocation
Steve O'Connell wrote: The only difference I see is that with the broken drive being flagged unavailable the job may fail, whereas if it tries to assign the broken drive because it is flagged as available it will hang indefinitely. In practice the job that hangs in allocation can be held and restarted, thus allowing the operator to release it when the drive does become available. In many installations a job with such a requirement would be likely to run at night, when the originating programmer would not be available to resubmit it. Personally, I'd rather the job failed and freed up all 7 other tape drives for use by other work if the drive is broken. Even if it's your company's money maker? Or perhaps the payroll run? Gerhard Postpischil Bradford, VT new e-mail address: gerhardp (at) charter (dot) net -- 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
