Re: PDSE and DFDSS
Just to irritate a few people here grin. Too bad SMP/E does not support a UNIX subdirectory as an SMPPTS repository. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Paul Gilmartin Sent: Thursday, June 14, 2012 12:10 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: PDSE and DFDSS On Thu, 14 Jun 2012 16:15:06 +0200, R.S. wrote: BTW: I really don't like SMPPTS. This is cumbersome, especially with pseudo-conctatenations (SMPPTS, SMPPTS1, ...oops! I forgot to define one of them in some zone...). Sigh. The family of problems: o Limited number of tracks in a PDS o Limited number of records in a PDSE member o Neither PDS nor PDSE can span volumes. The biggest and most common mistake that can be made in computer design is that of not providing enough address bits for memory addressing and management, -- Gordon Bell -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE and DFDSS
On Thu, 14 Jun 2012 12:54:18 -0500, McKown, John john.mck...@healthmarkets.com wrote: Too bad SMP/E does not support a UNIX subdirectory as an SMPPTS repository. Be careful what you wish for. :-) Actually other than performance - which may (or may not) only be noticeably worse on more SMPPTS intensive functions like RECEIVE, that sounds like a pretty good idea. Even though a PDSE can be bigger than 64K tracks, it still is limited to a single volume and zFS (or HFS) file systems aren't. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE and DFDSS
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Paul Gilmartin Sent: Thursday, June 14, 2012 2:41 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: PDSE and DFDSS On Thu, 14 Jun 2012 12:54:18 -0500, McKown, John wrote: Just to irritate a few people here grin. Too bad SMP/E does not support a UNIX subdirectory as an SMPPTS repository. Why aren't such large SYMODs packaged in RELFILE format rather than with inline elements? That would enormously relieve the strain on the SMPPTS. Product Packaging Rules is not a satisfactory answer. And there's considerable irony that elements destined for installation in UNIX (USS) directories come in unloaded PDSes. -- gil And, to compliment that, GIMZIP uses compressed PAX files to contain datasets, including PDSs. Which leads to Internet downloads of SMP/E data into UNIX files which contain SMP/E PDS datasets which contain data which ends up in z/OS UNIX files. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT 180M recs
The error messages are crucial for this kind of problem. We had a case recently of a (DF)SORT job failing on an unusually large number of records. The error message contained a reference to '64K', which turned out to be the maximum number of tracks in a conventional data set. DFSORT assumes when calculating the number of SORTWKxx datasets that each can/will be huge with the DSNTYPE=LARGE attribute so that the data set can exceed the old 64K track limit. However, because we had specified VIO=Y in the installation parms (overriding the product default), DFSORT was constrained by design to allocate only non-large work files. I agree that the product should be allowed to analyze the input file for sizing. FILSZ should be needed only for tape input, where the actual size is indeterminate at the outset. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Gibney, Dave gib...@wsu.edu To: IBM-MAIN@listserv.ua.edu Date: 06/14/2012 12:33 PM Subject:DFSORT 180M recs Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu This is for a friend at another installation. I Sync rather than DF, so I'm not the best to answer the question. I have already asked for the error message detail :) I've also said to not use the FILSZ parm and let DFSORT figure it out. I am having trouble getting dfsort to sort 180,000,000 records. I think it is failing for a lack of space. The records have an average length of 261 bytes. The key is the first 25 characters of the record and there should be no duplicates. The dfsort parms I have tried include: OPTION MAINSIZE=64M,DYNALLOC=(SYSDA,20), FILSZ=E18000,AVGRLEN=261 The DYNALLOC tells the sort to create 20 sortwork files. Maybe I need to create 50 sortwork files? FILSZ tells sort approximately how many records are to be sorted and sort is supposed to get the space it needs to do it. If you were going to sort this in syncsort how would you do it? One idea I had was to break the main file up into 30 million record groups. Sort those and then merge them back together into one file. I haven't tried that yet. It seems like I should be able to sort the large number of records. Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Questions about WEBs (Dispatchable Unit identity)
1. Does an SRB have the same WEB for the entirety of its existence (that is, across suspension, pauses, interruptions)? Yes 2. Does a task have the same WEB for the entirety of its existence? Yes 3. Is it possible for a WEB to reside in private storage? No 4. Are there any plans to change the answers to the above questions in a future release of z/OS? Not that I am aware. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT 180M recs
This is hard to resolve without knowing where the error is occuring, It could be something like ICE083A at the very beginning or it could be running a while and getting ICE046A. If you can get the sysout or at least some of the messages, that would help. For now I have a few recommendaitons. 1. Instead of MAINSIZE=64M I would take the default of MAINSIZE=MAX and add DSA=128. The sort probalby won't use 128MB but DFSORT's dynamic storage adjustment will determine the optimal amount of virtual storage to use and won't be limited by the default DSA of 32. 2. We're sorting about 44GB here. Assuming no use of Hiperspace or Memory Object, you need to allocate at least that much space in the work files. The number of work data sets you need will depend on your available disk. The more work data sets you allocate, the less space you need available on a single volume. So right now with 20, you need 20 volumes that each have at least 2.4GB available. Actually more than that since DFSORT calculates a work space requirement somewhat higher than the actual file size. So maybe you go up to 40 and see if that helps. 3. Since you specified an estimated file size, it's ok to leave it there. If DFSORT can determine the files size of the input, it will use that instead. However, if it can't because this is a sort where records are being passed by an E15 or the input is on something like unmanaged tape, then you'll need that file size. Have a nice day, Dave Betten DFSORT Development, Performance Lead IBM Corporation email: bet...@us.ibm.com 1-301-240-3809 DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 06/14/2012 03:32:38 PM: From: Gibney, Dave gib...@wsu.edu To: IBM-MAIN@listserv.ua.edu, Date: 06/14/2012 03:33 PM Subject: DFSORT 180M recs Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu This is for a friend at another installation. I Sync rather than DF, so I'm not the best to answer the question. I have already asked for the error message detail :) I've also said to not use the FILSZ parm and let DFSORT figure it out. I am having trouble getting dfsort to sort 180,000,000 records. I think it is failing for a lack of space. The records have an average length of 261 bytes. The key is the first 25 characters of the record and there should be no duplicates. The dfsort parms I have tried include: OPTION MAINSIZE=64M,DYNALLOC=(SYSDA,20), FILSZ=E18000,AVGRLEN=261 The DYNALLOC tells the sort to create 20 sortwork files. Maybe I need to create 50 sortwork files? FILSZ tells sort approximately how many records are to be sorted and sort is supposed to get the space it needs to do it. If you were going to sort this in syncsort how would you do it? One idea I had was to break the main file up into 30 million record groups. Sort those and then merge them back together into one file. I haven't tried that yet. It seems like I should be able to sort the large number of records. Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem with SMP/E RECEIVE ORDER - SOLVED
Dear Kurt, good news, the FORTGTZONES parameter solved the problem. I didn't use it first, because there is only one target zone existing. But in some way, similar to what is described in APAR IO04020 there must be some more other FMIDs in GLOBAL, I didn't check for the details yet. So because there are in fact no PTFs in this (non-existing) target zone, SMP/E tries to collect ALL PTFs for these FMIDs, which leads to such a large amount of data. When I use the FORTGTZONES parameter, everything works as expected. From my point of view, from now on we will always use FORTGTZONES in future, because then we're sure not to receive unwanted PTFs for any additional (unused) FMID in GLOBAL zone. Thanks again for your comment. Am 14.06.2012 16:23, schrieb Kurt Quackenbush: ... AFAIK using parameters like FORFMID or EXCLUDE etc. will not help, because I think they are recognized after the package is transfered on the client side, what is too late here. Correct. FORTGTZONES however can be used to limit the scope of the order, but this is only helpful if you have several different target zones managed from your global zone. For your z/OS global zone, you may only have one target zone, therefore, FORTGTZONES may not help. So again my question is, is it possible to identify the very large PTFs somewhere to order them seperately? Unfortunately no, it is not possible for you to identify the culprits. I dare say even for IBM it would not be a simple task to identify the very large PTFs in your order. Certainly its not something Level 2 can manage, and they would need to find the right people at the production center to manually gather that information. In any case I agree with others that you should try to receive Java PTFs separately, maybe also WebSphere/MQ if you have that, then try RECOMMENDED again. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Freundliche Gruesse / Kind regards *Dipl. Math. Juergen Kehr * IT Schulung Beratung / IT Education + Consulting Elfbuchenstrasse 10 34317 Habichtswald Germany Tel. +49-5606-5337408 Fax +49-3222-9341387 Mobil +49-172-5129389 mailto:kehrjuer...@t-online.de mailto:kehrjuer...@googlemail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Change IEASYMxx via opartor prompt
I can think of something, but it seems strange to me (I work at a small shop). Imagine a sandbox system. This is a specific version and maintenance level of z/OS. So I want to only use up one set of RES volumes for different images. However, via the IEASYMnn, I set things up to properly emulate other systems at my shop which have some significant differences. So using the one sandbox system, I can IPL an DB2 sandbox system which is set up like my production DB2 system. And an IMS sandbox to emulate my production IMS system (without any DB2 modules in it). And so on. This saves me DASD volumes. But I'm not sure why the OP doesn't want to change the LOADPARM parameter on the HMC at the time that he IPLs the sandbox. If it were under z/VM, it would be even simplier since the LOADPARM value can be specified on the IPL command in the guest. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of retired mainframer Sent: Thursday, June 14, 2012 4:10 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Change IEASYMxx via opartor prompt Color me confused. Using different IEASYMxx members with different systems should be easier than trying to use the same system with different members. Aren't the two systems on different packs? Don't you have to change the IPL address when you change systems? If so, why not change the LOADxx suffix at the same time? Does each system have its own PARMLIB? If so, can't you call both IEASYMxx members by the same name since they are in different libraries? :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On :: Behalf Of Miklos Szigetvari :: Sent: Thursday, June 14, 2012 7:05 AM :: To: IBM-MAIN@listserv.ua.edu :: Subject: Re: Change IEASYMxx via opartor prompt :: :: We intend to swap the systems between two LPAR's. :: Till now LPAR1 was z/OS 1.12 and LPAR2 was z/OS 1.13 :: Now we would like to change :: :: On 14.06.2012 15:59, Lizette Koehler wrote: :: I would like to use at one IPL IEASYMxx and IEASYMyy at the next , :: without changing :: the LOAD member. :: I thought I could say SYM=xx or SYM=yy, but it is not the case. :: (Swapping LPAR's) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem with SMP/E RECEIVE ORDER - SOLVED
Mazel tov! I've always used FORTGTZONES just because. Never dreamed of possible problems in omitting it. The idea of trying to give you 'everything' for an empty zone seems wickedly bizarre, but you have to play the same game as your opponent. Er, benefactor. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Jürgen Kehr kehrjuer...@t-online.de To: IBM-MAIN@listserv.ua.edu Date: 06/14/2012 02:06 PM Subject:Re: Problem with SMP/E RECEIVE ORDER - SOLVED Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Dear Kurt, good news, the FORTGTZONES parameter solved the problem. I didn't use it first, because there is only one target zone existing. But in some way, similar to what is described in APAR IO04020 there must be some more other FMIDs in GLOBAL, I didn't check for the details yet. So because there are in fact no PTFs in this (non-existing) target zone, SMP/E tries to collect ALL PTFs for these FMIDs, which leads to such a large amount of data. When I use the FORTGTZONES parameter, everything works as expected. From my point of view, from now on we will always use FORTGTZONES in future, because then we're sure not to receive unwanted PTFs for any additional (unused) FMID in GLOBAL zone. Thanks again for your comment. Am 14.06.2012 16:23, schrieb Kurt Quackenbush: ... AFAIK using parameters like FORFMID or EXCLUDE etc. will not help, because I think they are recognized after the package is transfered on the client side, what is too late here. Correct. FORTGTZONES however can be used to limit the scope of the order, but this is only helpful if you have several different target zones managed from your global zone. For your z/OS global zone, you may only have one target zone, therefore, FORTGTZONES may not help. So again my question is, is it possible to identify the very large PTFs somewhere to order them seperately? Unfortunately no, it is not possible for you to identify the culprits. I dare say even for IBM it would not be a simple task to identify the very large PTFs in your order. Certainly its not something Level 2 can manage, and they would need to find the right people at the production center to manually gather that information. In any case I agree with others that you should try to receive Java PTFs separately, maybe also WebSphere/MQ if you have that, then try RECOMMENDED again. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Change IEASYMxx via operator prompt
Our operators never 'change IPL address'. They select the appropriate LOAD profile on the HMC before IPL. We don't find it necessary on a regular basis, but each LOAD profile can contain a unique LOADPARM value where the specified LOADxx suffix points to a unique IPLPARM member. That way no one has to edit anything on a regular basis. Each LOADxx can specify a unique concatenation of IEASYMxx members. All controlled by LOAD profile. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: retired mainframer retired-mainfra...@q.com To: IBM-MAIN@listserv.ua.edu Date: 06/14/2012 02:11 PM Subject:Re: Change IEASYMxx via opartor prompt Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Color me confused. Using different IEASYMxx members with different systems should be easier than trying to use the same system with different members. Aren't the two systems on different packs? Don't you have to change the IPL address when you change systems? If so, why not change the LOADxx suffix at the same time? Does each system have its own PARMLIB? If so, can't you call both IEASYMxx members by the same name since they are in different libraries? :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On :: Behalf Of Miklos Szigetvari :: Sent: Thursday, June 14, 2012 7:05 AM :: To: IBM-MAIN@listserv.ua.edu :: Subject: Re: Change IEASYMxx via opartor prompt :: :: We intend to swap the systems between two LPAR's. :: Till now LPAR1 was z/OS 1.12 and LPAR2 was z/OS 1.13 :: Now we would like to change :: :: On 14.06.2012 15:59, Lizette Koehler wrote: :: I would like to use at one IPL IEASYMxx and IEASYMyy at the next , :: without changing :: the LOAD member. :: I thought I could say SYM=xx or SYM=yy, but it is not the case. :: (Swapping LPAR's) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to Carbon Copy (Cc:) in Email from MVS?
In 0327319053108678.wa.lmburchcabq@listserv.ua.edu, on 06/14/2012 at 11:03 AM, Larry Burch lmbu...@cabq.gov said: Paul: Thanks for nothing! Other than refering to the RCPT TO: in the envelope as a header, Paul is correct. in the Bcc: construct What bcc construct. The bcc tag in the header is used in some e-mail clients to generate the correct RCPT TO: commands, but is not part of the SMTP routing mechanism. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
