Re: How to change the ISPF code page?
>They're both wrong Mine are x'BA' and x'BB', and they work
>wonderfully.
These are their code points in CP037.
I'm working with CP0500, so mine are at x'4A' and x'5A', and believe
me, they work wunderfully, too. It's simply a matter of consistent
code page settings ;-) ("Simply" is a slight understatement, I admit.)
--
Peter Hunkeler
Credit Suisse
--
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: How to change the ISPF code page?
Maybe this was already mentioned inthe thread, but I've been verifying effects of the changes to "Terminal type" by looking at the output from man commands issued from an ISHELL panel (in addition to viewing the macros mentioned). Square brackets look great there. But not so the square brackets I enter from my keyboard. I'm using PComm with "Session parameters - Host Code-Page" set to 1047. It was probably mentioned somewhere in this thread, but I don't know if that specification effects both keyboard mapping and display or just display. >The square brackets that display correctly are x'AD' and x'BD'. These are their code points in CP1047. This is the default for the z/OS UNIX shell and utilites. So, as long as the terminal emulator is set to CP1047, they'll show up as expected. >The square brackets from PComm are x'B0' and x'6A'. I've seen the brackets assigned to various code points in various code pages, but I could not find the code page that maps then to x'B0' and x'6A'. Does anybody know which code page this might be? >I know I can change the keyboard mapping. Sure, but as far as PComm is concerned you would use the keyboard mapping tool and there you only assign characters "visibly", i.e. you select from a list or you type them in. I've not seen a place where you can specify a hex value to be sent. IHMO, PComm will use the current Windows code page for the ASCII side (i.e. your keyboard) and the Host Code Page setting to translate from the character typed to the hex value to be sent to the host. If you open the keyboard utility, what character is shown as being the character assigned to the "bracket" keys? '¬' and '¦'? -- Peter Hunkeler Credit Suisse -- 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: HSM Recalls
Bob, Yes, I think we mean the same: IF you have to migrate, migrating a small number of large datasets is more efficient than migrating many small ones. Your answer "You don't" made me think that, when migrating, it was useless to differentiate in small and large datasets. Kees. "Richards, Robert B." <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Kees, > > Am I missing something? You stated that you didn't agree with me and > then proceeded to agree with my premise. Stated another way: "Only > migrate when you need more free space in your volume pools. Otherwise, > leave it there". > > This is obviously a generalization on my part and leaves a lot to the > imagination of the reader. Things like cost of CPU, DASD for > migrate/recalls, etc. were intentionally left out of my response as I > was addressing the point of migration based on size, which, in my > opinion, is putting the cart before the horse. I fear we may be talking > semantics here and are actually in agreement. > > Bob > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Vernooy, C.P. - SPLXM > Sent: Monday, July 28, 2008 10:06 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: HSM Recalls > > I don't agree. > First, "You don't" is not an answer to the question "how do I". > "in my opinion you shouldn't" is and I think that's what you intend to > say and I have a different opinion. > > Your reasoning is correct, until the point where you don't take the cost > of migration and recalls into consideration when doing the "balancing > act". I have determined that it saves me a lot of cpu not to > migrate/recall "small" datasets and it only costs me a fraction more on > my storagegroups. > > This is something missing in storage management. > Fase 1 "should I start migrating" is realized, but fase 2 "how do I > migrate efficiently" is not, that is what I bring into the system with > leaving small datasets outside migration and what Michael also already > regarded useful, but was not sure how to realize it. > > Kees. > > > "Richards, Robert B." <[EMAIL PROTECTED]> wrote in message > news:<[EMAIL PROTECTED]>... > > The question posed by Michael was how does someone select datasets for > > migration based on size. The answer, "You don't". Let me explain. > > > > The purpose of space management is to make sure that you have enough > > available space in your storage pools to handle new allocations and > > extending of existing allocations. Movement of datasets should only > > happen to meet that end. The only reason "size matters" is > > because the larger the allocation of the migration-eligible dataset > is, > > the easier the goal is met to provide available free space in the > > storage pool. > > > > To that end, I agree with Ted. Migrating datasets based solely on some > > minimum size is ludicrous, especially if it is a very small value. > > > > We all know that placing datasets on L0, L1 and L2 is a balancing act > > based on constraints that vary shop-to-shop and definitely change over > > time. > > > > Bob > > > > - > > Robert B. Richards(Bob) > > US Office of Personnel Management > > 1900 E Street NW Room: BH04L > > Washington, D.C. 20415 > > Phone: (202) 606-1195 > > Email: [EMAIL PROTECTED] > > - > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > > Behalf Of Vernooy, C.P. - SPLXM > > Sent: Monday, July 28, 2008 9:12 AM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: Re: HSM Recalls > > > > The down side of this method is that you only have one chance to > > determine the size, at dataset creation. Whatever happens to (the size > > of) the dataset afterwards is out of ACS routines control. > > We have CA-DISK and there I can (and do) explicitely exclude datasets > > from archiving/migration based on the size at that moment. > > > > Kees. > > > > "O'Brien, David W. [C] , NIH/CIT" <[EMAIL PROTECTED]> wrote in > > message > > news:<[EMAIL PROTECTED]>... > > > Not HSM, selection is done by assigning SMS Management class based > on > > size in the SMS ACS routine. > > > > > > > > > > > > From: Michael Wickman [mailto:[EMAIL PROTECTED] > > > Sent: Mon 7/28/2008 8:55 AM > > > To: IBM-MAIN@BAMA.UA.EDU > > > Subject: Re: HSM Recalls > > > > > > > > > > > > Just curious how you select for migration base on size. Do you set > > > special management class based on primary space at allocation time? > > Or > > > are there HSM commands that help with this selection process? > > > > > > > > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > > Mike Wickman > > > Technical Services > > > email mwickman at waddell dot com > > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Re: XCF Coupling Facility Space vs In-Memory Buffers
Martin, I don't even understand what you're wondering about :-( >So, I'm wondering whether it's better to place the memory centrally in the >CF structures. Or distributed via the various in-memory buffer pools. And, >yes, I know CTCs don't have an in-built queue (other than the buffer pools >I've already mentioned). What exactly do you mean by 'place the memory centrally in the CF structures'? For a list structure, please (like the XCF signalling structure)! And how does a CTC have a buffer pool? Completely clueless here, Barbara -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[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
Filezilla 3.1.0.1 broken for z/OS 1.7 and 1.9
If you use the filezilla client, don't upgrade to the lastest release just recently out. It's broken for SSL/TLS connections from both Vista and XP -- 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: DFSORT Functionality to OVERLAY in non-specific columns
Hank Medler wrote on 07/28/2008 01:26:39 PM: > Frank, > > Thank you very much for the quick reply and I saw your post regarding the > new functionalities with the latest PTF almost immediately after I posted my > message. Funny how timing works out like that sometimes. I checked out the > PDF doc after your initial post and FINDREP will handle exactly whatI want to > do. Thank you for your continued remarkable support and enhancements to > DFSORT functionality. > > Thanks, > Hank I'm glad to hear FINDREP will do what you need. And thanks for the kind words. Frank Yaeger - DFSORT Development Team (IBM) - [EMAIL PROTECTED] Specialties: FINDREP, WHEN=GROUP, DATASORT, ICETOOL, Symbols, Migration => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ -- 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: DFSORT Functionality to OVERLAY in non-specific columns
Frank, Thank you very much for the quick reply and I saw your post regarding the new functionalities with the latest PTF almost immediately after I posted my message. Funny how timing works out like that sometimes. I checked out the PDF doc after your initial post and FINDREP will handle exactly what I want to do. Thank you for your continued remarkable support and enhancements to DFSORT functionality. Thanks, Hank On Mon, 28 Jul 2008 12:17:13 -0700, Frank Yaeger <[EMAIL PROTECTED]> wrote: >IBM Mainframe Discussion List wrote on 07/28/2008 >11:30:56 AM: >> ... >> The problem I am having is attempting to perform an OVERLAY in varying >> positions of the record for static and varying lengths. For >> instance, multiple >> long records within a fixed dataset may have a sequence of consecutive >> 1's, '', but they may appear anywhere from position 1 until >> the end of >> the record. So I would like to perform an overlay of the 1's with spaces >> whenever there are 8 consecutive 1's, but not perform it if there are >only 6 >> consecutive 1's. >> >> I have investigated using ALTSEQ with TRAN and it doesn't appear to allow >for >> multiple consecutive characters for the translation. Basically, I >> could change >> all 1's to spaces, but that isn't what I want. I also tried using the >PARSE >> function with STARTAT to position me at the beginning of C'' in >> conjunction with an OVERLAY in hopes that it would overlay at that >> position in >> the record. I know, wishful thinking because SORT normally doesn't >function >> like that. > >I'm not sure I understand what you're trying to do. An example of your >input >records and what you expect for output for various cases would help. > >However, if you're looking for something that will find and replace >multiple >consecutive characters like TRAN=ALTSEQ does for one character, DFSORT now >has that capability. Find and replace is one of the new features in >z/OS DFSORT V1R5 PTF UK90013 (July, 2008) which is described in detail at: > >www.ibm.com/systems/support/storage/software/sort/mvs/ugpf/ > >If you install that PTF, you'll be able to use FINDREP to do various types >of find and replace operations. > >Frank Yaeger - DFSORT Development Team (IBM) - [EMAIL PROTECTED] >Specialties: FINDREP, WHEN=GROUP, DATASORT, ICETOOL, Symbols, Migration > > => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ > >-- >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: Share Attendance
In a message dated 7/28/2008 3:10:53 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: This may have happened when "SCIDS" was replaced by "Meet the Projects". >> Fraid it's more subliminal than that. So you have a list that transmogrifies most projects and has been in existence since 1986 irrespective of politics and reorgs...and SHARE won't let it have one little peep of recognition-Shame, shame. **Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr000520) -- 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 Attendance
Yes, IBM-MAIN no longer has an "official" table, but you can usually spot IBM-Main members at either the MVS, JES2 or JES3 table. However, I generally find that the easiest way to meet IBM-Main'ers at SCIDS to stand around the "unofficial" IBM-Main table (aka the Bar). And regardless of whatever others may say, that is the one and only reason I hang out around the Bar (that's my story and I'm sticking with it). Wayne Driscoll Product Developer NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Patrick O'Keefe Sent: Monday, July 28, 2008 2:20 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Share Attendance On Mon, 28 Jul 2008 13:22:50 -0500, Miller, Pat <[EMAIL PROTECTED]> wrote: >There used to always be an IBM-MAIN table at SCIDS. I think it had disappeared last time I was there. >... I heard SHARE requested it be disbanded because only SHARE projects or programs were allowed official tables. This may have happened when "SCIDS" was replaced by "Meet the Projects". I won't be there. Snub someone for me. :-) Pat O'Keefe -- 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: Example of what a very small JCL Interpreter can do to your installation.
In a message dated 7/28/2008 10:55:50 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: >I certainly remember (though obviously not as clearly as Mr. Blair) a day and age when overriding DD statements were required to appear in the same order as the overridden DDNAMEs in the proc. I was delighted to see the constraint relaxed. Suppose someone who does not know that proc X is used by 10 other jobs with overriding DDs in them decides to rearrange the DD statements within proc X. Which mode of processing by IBM would be better? Another possibility is that beaucoup jobs use overrides for a universally available vendor proc like ASM, LKED, FDRxxx, CAwhatever, etc., and then the vendor decides to rearrange the DD statements within the distributed machine-readable PROCLIB containing that proc. Yes, I know, we can blame change control when the inevitable errors are found. But it would be better to avoid the errors than to find someone to blame when they occur. This situation seems to me to be analogous to users' building job streams that use output from utilities like IDCAMS as their input and require data set names to begin in column X and volser in column Y, e.g. Then IBM changes the format of the utility's output. And it's not limited to IBM. Data centers also have locally developed programs that generate SYSOUT which is then used as input for other programs, and the developer in charge of a utility cannot be expected to know all the downstream users of his SYSOUT. Bill Fairchild Rocket Software **Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr000520) -- 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 Attendance
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Patrick O'Keefe > > [ snip ] > > I won't be there. Snub someone for me. :-) I'll be absent as well. Please snub Ed Jaffe, Chris Craddock, Bob Yelavich, and whoever else comes to mind for me. :-) -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
Re: DFSORT Functionality to OVERLAY in non-specific columns
IBM Mainframe Discussion List wrote on 07/28/2008 11:30:56 AM: > ... > The problem I am having is attempting to perform an OVERLAY in varying > positions of the record for static and varying lengths. For > instance, multiple > long records within a fixed dataset may have a sequence of consecutive > 1's, '', but they may appear anywhere from position 1 until > the end of > the record. So I would like to perform an overlay of the 1's with spaces > whenever there are 8 consecutive 1's, but not perform it if there are only 6 > consecutive 1's. > > I have investigated using ALTSEQ with TRAN and it doesn't appear to allow for > multiple consecutive characters for the translation. Basically, I > could change > all 1's to spaces, but that isn't what I want. I also tried using the PARSE > function with STARTAT to position me at the beginning of C'' in > conjunction with an OVERLAY in hopes that it would overlay at that > position in > the record. I know, wishful thinking because SORT normally doesn't function > like that. I'm not sure I understand what you're trying to do. An example of your input records and what you expect for output for various cases would help. However, if you're looking for something that will find and replace multiple consecutive characters like TRAN=ALTSEQ does for one character, DFSORT now has that capability. Find and replace is one of the new features in z/OS DFSORT V1R5 PTF UK90013 (July, 2008) which is described in detail at: www.ibm.com/systems/support/storage/software/sort/mvs/ugpf/ If you install that PTF, you'll be able to use FINDREP to do various types of find and replace operations. Frank Yaeger - DFSORT Development Team (IBM) - [EMAIL PROTECTED] Specialties: FINDREP, WHEN=GROUP, DATASORT, ICETOOL, Symbols, Migration => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ -- 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 Attendance
On Mon, 28 Jul 2008 13:22:50 -0500, Miller, Pat <[EMAIL PROTECTED]> wrote: >There used to always be an IBM-MAIN table at SCIDS. I think it had disappeared last time I was there. >... I heard SHARE requested it be disbanded because only SHARE projects or programs were allowed official tables. This may have happened when "SCIDS" was replaced by "Meet the Projects". I won't be there. Snub someone for me. :-) Pat O'Keefe -- 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: z/OS 1.9 Catalog Enqueue Problems
In a message dated 7/28/2008 1:35:48 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Ed - I don't know what you mean by a "build problem." >> In our case the builder put high use catalog entries in the MCAT instead of in a UCAT so when the STC fired up(every twenty minutes) the MCAT was locked up for the duration of the run. Anyway only had to REPRO MERGECAT one HLQ to fix it. **Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr000520) -- 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
New DFSORT/ICETOOL Features (July, 2008)
(Darren pre-approved this post.) PTF UK90013 for z/OS DFSORT V1R5 (July, 2008) provides important enhancements to DFSORT and DFSORT's ICETOOL for find and replace (FINDREP), group operations (WHEN=GROUP); sorting data between headers and trailers (DATASORT); keeping or removing the first n records, last n records and/or specific relative records (SUBSET); selecting the); first n duplicate records (SELECT with FIRST(n) and FIRSTDUP(n)); splicing with non-blank fields (SPLICE with; WITHANY); displaying and writing counts (DISPLAY with COUNT, EDCOUNT, BCOUNT and EDBCOUNT, and COUNT with ADD, SUB, WRITE, TEXT, DIGITS, EDCOUNT and WIDTH); reports with, multiple and multipart titles (DISPLAY and OCCUR with TITLE, TLEFT and TFIRST); reports without carriage control characters (DISPLAY and OCCUR with NOCC); additional defaults (BLKSIZE for DUMMY, SKIP=0L for SECTIONS, and SORTOUT=ddname for FNAMES); easier migration from other sort products, and more. For complete details on these new features, see my "User Guide for DFSORT PTF UK90013" paper (sortugpf.pdf) at: www.ibm.com/systems/support/storage/software/sort/mvs/ugpf/ Note: z/OS DFSORT V1R5 is used on all currently supported z/OS releases (up to z/OS 1.9). Frank Yaeger - DFSORT Development Team (IBM) - [EMAIL PROTECTED] Specialties: FINDREP, WHEN=GROUP, DATASORT, ICETOOL, Symbols, Migration => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ -- 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: z/OS 1.9 Catalog Enqueue Problems
It's been the same symptom each time: One LPAR has a hold of a user catalog and requests SYSIGGV2. The other LPAR has SYSIGGV2 and is requesting the user catalog. Thus, a deadlock. According to IBM (so far), it looks to them like MIM isn't requesting these resources in the correct order. CATALOG requests catalog name then SYSIGGV2 and MIM does the opposite. We have GRSRNL=EXCLUDE in IEASYS. Ed - I don't know what you mean by a "build problem." Thanks to everyone for the input so far. Luke -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Finnell Sent: Monday, July 28, 2008 1:14 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS 1.9 Catalog Enqueue Problems In a message dated 7/28/2008 12:48:32 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: What are your symptoms? Latches, Reservers? >> Likewise, I was wondering if it could be a build problem? Had a contractor put HLQ's for data mover in MCAT. When we tried to go live it'd lock up every 20 minutes. 'Didn't do it in TEST'...didn't have any data? **Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr000520) -- 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
XCF Coupling Facility Space vs In-Memory Buffers
For once *I* get to ask a question. :-) And perhaps a stoopid one. :-) As many of you - especially those who follow me on Twitter - know, I'm writing the Performance Metrics chapter of the new Redbook on Parallel Sysplex Performance... It has occurred to me that one can treat XCF as a sophisticated queuing mechanism and that path, transport class, and local buffers are really subqueues. As are the lists in any Coupling Facility List Structures you might use for XCF. So, I'm wondering whether it's better to place the memory centrally in the CF structures. Or distributed via the various in-memory buffer pools. And, yes, I know CTCs don't have an in-built queue (other than the buffer pools I've already mentioned). Note: Though we use the term "buffer pool" these aren't "reread-amenable" areas of memory (unless there's something missing from MY understanding). So I'd be interested in your opinions. Thanks, Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Twitter / identi.ca : MartinPacker Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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
DFSORT Functionality to OVERLAY in non-specific columns
To all, I have RTFM and also studied the Smart DFSORT tricks and DFSORT User Guide for PTFs UK90007/UK90006, but with no success in one particular area. I have requirements to dynamically create an output file of varying length based on values specified in the data itself, but I have that part down by taking an initial pass and creating dynamic BUILD statements for each type of record. The problem I am having is attempting to perform an OVERLAY in varying positions of the record for static and varying lengths. For instance, multiple long records within a fixed dataset may have a sequence of consecutive 1's, '', but they may appear anywhere from position 1 until the end of the record. So I would like to perform an overlay of the 1's with spaces whenever there are 8 consecutive 1's, but not perform it if there are only 6 consecutive 1's. I have investigated using ALTSEQ with TRAN and it doesn't appear to allow for multiple consecutive characters for the translation. Basically, I could change all 1's to spaces, but that isn't what I want. I also tried using the PARSE function with STARTAT to position me at the beginning of C'' in conjunction with an OVERLAY in hopes that it would overlay at that position in the record. I know, wishful thinking because SORT normally doesn't function like that. Here is how I coded that ICETOOL using the SS (Substring Search) in an attempt to change positioning as well (hard coded the 600 for testing): SELECT FROM(IN) TO(OUT1) ON(2,5,CH) ON(12,8,CH) ALLDUPS USING(CTL1) //CTL1CNTL DD * OUTFILE FNAMES=OUT1, IFTHEN=(WHEN=(1,600,SS,EQ,C''), PARSE=(%00=(STARTAT=C'',FIXLEN=8)), OVERLAY=(C'')), INCLUDE=(2,1,CH,EQ,C'$',AND,3,4,FS,EQ,NUM,AND,8,4,FS,EQ,NUM), TRAILER1=(C'T',20:X,COUNT=(M11,LENGTH=12)) I also tried using the CHANGE parameter, but also had issues getting the change to occur in the particular column where the search string was found. I am hoping I am missing something obvious in the SORT parameters that will make life easier for me. Let me note that the data coming in does not have any consistencies at all other than the first 20 positions are control statements and anything after that is the data to be massaged and sent to output based on the first 20 control statements (input/output record lengths, a selection indicator per record, and also a key that must match for all selected records). All of my studying of this lends me to believe I am going to need an E35 exit to traverse through the records and update them in the manner above by incrementing the position across. I really don't want to go there if I don't have to. If anyone wonders why I am using DFSORT instead of COBOL, the answer is that I am trying to eliminate a COBOL performing this will a simple callable SORT. If it isn't worth it or even possible, then so be it... at least I can say I gave it a shot. :) Thank you in advance for any assistance you can provide. Thanks, Hank BTW, DFSORT V1R5 from the SORT Displays -- 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 Attendance
There used to always be an IBM-MAIN table at SCIDS. I think it had disappeared last time I was there. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Lizette Koehler Sent: Monday, July 28, 2008 11:19 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Share Attendance Gang, My boss approved me going to Share in San Jose next weekend. If you would like to meet the face behind the emails, I will be wearing my Doctor Who Tee-shirt at SCIDS. Just come up and say hi. Would love to meet the faces behind the names. Lizette -- 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: z/OS 1.9 Catalog Enqueue Problems
In a message dated 7/28/2008 12:48:32 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: What are your symptoms? Latches, Reservers? >> Likewise, I was wondering if it could be a build problem? Had a contractor put HLQ's for data mover in MCAT. When we tried to go live it'd lock up every 20 minutes. 'Didn't do it in TEST'...didn't have any data? **Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr000520) -- 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: z/OS 1.9 Catalog Enqueue Problems
SORRY One should re-read before sending. In addition to that info please know we've had no problems. At 01:43 PM 7/28/2008, Brian France wrote: We are MIM 11.6, SP1 with z/OS 1.9 in about 1 1/2 mos ago. 0703 was the Service level with the Serverpak. If yor really need the exact level I will try to get it for you. At 01:25 PM 7/28/2008, Rabbe, Luke wrote: We've attempted to implement z/OS 1.9 throughout our sysplex twice and twice we've had to back out because of a catalog enqueue conflicts. We're running MIM version 11.6 and z/OS 1.9 put level 0804 with a fair amount of hypers. Has anyone run into anything similar with their 1.9 migration? Thank you, Luke -- 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 Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 [EMAIL PROTECTED] "To make an apple pie from scratch, you must first invent the universe." Carl Sagan Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 [EMAIL PROTECTED] "To make an apple pie from scratch, you must first invent the universe." Carl Sagan -- 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: z/OS 1.9 Catalog Enqueue Problems
I don't know if my experience on z/OS 1.8 applies. But I was having a number of problems. The first one was when I accidently had MIM and GRS attempting to manage the same ENQs. This was rather easy to diagnose, but did have weird error messages (ENQ conflicts with a job conflicting with itself). The other was an abend in MIM. I could not figure this one out. CA support told me that if I was using MIM to propogate ENQs, then I absolutely had to disable GRS by using the parm GRSRNL=EXCLUDE in PARMLIB. Or I had to tell MIM to not manage ENQs by using the MIMINIT GDIF=OFF parameter in MIM. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: z/OS 1.9 Catalog Enqueue Problems
We're at Z/OS 1.9 with MIM 11.6 with no catalog problem. Our EDIPARMS contains PREFIX, NAME=CATALOG., OPTION=(NOCONFLICTMESSAGES, SUPPRESSMESSAGES) Our GDIEXMPT contains LOCALRNAME=CATALOG* Also - QNAME SYSIGGV2 is commented out in MIMQNAME. HTH j -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rabbe, Luke Sent: Monday, July 28, 2008 1:26 PM To: IBM-MAIN@BAMA.UA.EDU Subject: z/OS 1.9 Catalog Enqueue Problems We've attempted to implement z/OS 1.9 throughout our sysplex twice and twice we've had to back out because of a catalog enqueue conflicts. We're running MIM version 11.6 and z/OS 1.9 put level 0804 with a fair amount of hypers. Has anyone run into anything similar with their 1.9 migration? Thank you, Luke -- 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: JES2-L is moribund!
Jack Kelly wrote: > I joined the list but never have been able to search it. I had the same problem, but I found it went away as soon as I established a ListServ password for the server (not the JES2-L list). It works for all lists on that server, but I didn't find any other lists that interested me. You can then "Search the archives" which should be the first link in the main list displayed after you click on "Server Archives" and then on the "JES2-L" list name in that list. -- WB -- 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: z/OS 1.9 Catalog Enqueue Problems
We did not have any catalog problems, even with the sysplex mixed between z/OS 1.7 and z/OS 1.9. We do not use MIM. Steve Conway Lead Systems Programmer Information Systems & Services Division Computer & Network Operations Phone: (703) 450-3156 Fax:(703) 450-3197 "Rabbe, Luke" <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 07/28/2008 01:25 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject z/OS 1.9 Catalog Enqueue Problems We've attempted to implement z/OS 1.9 throughout our sysplex twice and twice we've had to back out because of a catalog enqueue conflicts. We're running MIM version 11.6 and z/OS 1.9 put level 0804 with a fair amount of hypers. Has anyone run into anything similar with their 1.9 migration? Thank you, Luke -- 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: z/OS 1.9 Catalog Enqueue Problems
I am not running MIM, but we have had no catalog problems. What are your symptoms? Latches, Reservers? Lizette > >We've attempted to implement z/OS 1.9 throughout our sysplex twice and >twice we've had to back out because of a catalog enqueue conflicts. >We're running MIM version 11.6 and z/OS 1.9 put level 0804 with a fair >amount of hypers. Has anyone run into anything similar with their 1.9 >migration? > -- 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 Attendance
In my humble opinion - David Tennet is the BEST. Used to think it was Tom Baker, but I really like the way DT does it. Lizette -Original Message- >From: Gary Green <[EMAIL PROTECTED]> >Sent: Jul 28, 2008 1:11 PM >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: Share Attendance > >Not that I will be there, but I must ask... WHICH Doctor Who will it be? > > > On Mon Jul 28 12:19 , Lizette Koehler <[EMAIL PROTECTED]> sent: > >>Gang, >> >>My boss approved me going to Share in San Jose next weekend. If you would >>like to meet the face behind the emails, I will be wearing my Doctor Who >>Tee-shirt at SCIDS. Just come up and say hi. >> >>Would love to meet the faces behind the names. >> >>Lizette >> >>-- >>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 > -- 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 Attendance
As others have indicated they are returning to SHARE after a long absence I too will be returning to this SHARE after being away for over 5 years. Y'all have been warned :-) Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering 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." I never guess. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. - Sir Arthur Conan Doyle 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. -- 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: z/OS 1.9 Catalog Enqueue Problems
We are MIM 11.6, SP1 with z/OS 1.9 in about 1 1/2 mos ago. 0703 was the Service level with the Serverpak. If yor really need the exact level I will try to get it for you. At 01:25 PM 7/28/2008, Rabbe, Luke wrote: We've attempted to implement z/OS 1.9 throughout our sysplex twice and twice we've had to back out because of a catalog enqueue conflicts. We're running MIM version 11.6 and z/OS 1.9 put level 0804 with a fair amount of hypers. Has anyone run into anything similar with their 1.9 migration? Thank you, Luke -- 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 Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 [EMAIL PROTECTED] "To make an apple pie from scratch, you must first invent the universe." Carl Sagan -- 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 Attendance
I too, after being absent since San Francisco in '99 will be making the trip. Looking forward to seeing one and all. tb -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Monday, July 28, 2008 11:19 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Share Attendance Gang, My boss approved me going to Share in San Jose next weekend. If you would like to meet the face behind the emails, I will be wearing my Doctor Who Tee-shirt at SCIDS. Just come up and say hi. Would love to meet the faces behind the names. Lizette -- 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
z/OS 1.9 Catalog Enqueue Problems
We've attempted to implement z/OS 1.9 throughout our sysplex twice and twice we've had to back out because of a catalog enqueue conflicts. We're running MIM version 11.6 and z/OS 1.9 put level 0804 with a fair amount of hypers. Has anyone run into anything similar with their 1.9 migration? Thank you, Luke -- 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 Attendance
Not that I will be there, but I must ask... WHICH Doctor Who will it be? On Mon Jul 28 12:19 , Lizette Koehler <[EMAIL PROTECTED]> sent: >Gang, > >My boss approved me going to Share in San Jose next weekend. If you would >like to meet the face behind the emails, I will be wearing my Doctor Who >Tee-shirt at SCIDS. Just come up and say hi. > >Would love to meet the faces behind the names. > >Lizette > >-- >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
Share Attendance
Gang, My boss approved me going to Share in San Jose next weekend. If you would like to meet the face behind the emails, I will be wearing my Doctor Who Tee-shirt at SCIDS. Just come up and say hi. Would love to meet the faces behind the names. Lizette -- 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: DSN wirh LRECL > 32760 on Z/OS
On Fri, 18 Jul 2008 13:39:04 +0200, Sarel Swanepoel wrote: > >Even given that you can use VSAM spanned or variable spanned PS, the >next issue is how does he get the data into the dataset. He would have >to devise some funky way of reading the outside data in pieces, >assembling it into the 32761 byte record and writing it to the output >dataset.< > I believe you can do the latter (PS) with BSAM. But I grant that many regard BSAM as funky. -- 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: Example of what a very small JCL Interpreter can do to your installation.
On Mon, 28 Jul 2008 09:22:03 -0500, Jeff Holst wrote: >On Fri, 25 Jul 2008 17:56:35 -0500, William H. Blair wrote: > >>Jeff Holst noted that an IBM SRL states: >> >>> 1. Overriding statements can appear in any order when >>>they explicitly specify the step that is being >>>overridden. >> >If you go on to read the next paragraph it explains what happens when the >step is not specified (it uses the step name from the last DD statement that >did specify a step name, and if none exists the first step in the proc is >overridden.) The paragraph that follows further clarifies things by stating >that >overriding DD statements must appear in the order of the steps in the proc. > >It is misleading to take one paragraph in isolation. > I certainly remember (though obviously not as clearly as Mr. Blair) a day and age when overriding DD statements were required to appear in the same order as the overridden DDNAMEs in the proc. I was delighted to see the constraint relaxed. It makes JCL coding easier and more robust because it's easier to spot coding errors because of the decreased likelihood that the coded overriding SYSIN would have no effect. I don't know how long ago the ordering constraint was removed -- it's documented in 5.2.1.2 "z/OS V1R1.0 MVS JCL Reference", but surely that's the source of most of the objections in this thread, so I'm puzzled that there was no shrill outcry back then -- it should have created major incompatibilities. But the "reordering" occurs only when both DDNAMES match DDNAMES in the overridden PROC; else at least one is an added DD statement. Prior to the "reordering" facility, a misordering would have resulted in a duplicate DDNAME within a step, and I read in 12.1.2 "z/OS V1R1.0 MVS JCL Reference": 12.1.2 Name Field When specified, code a ddname as follows: * Each ddname should be unique within the job step. ... (yes, it then goes on to specify (partially) the effect of duplicate DDNAMES within a step, including different behavior for JES3 and JES3). So programmers who relied on the duplicate SYSIN introduced by the GENERATE STATEMENT were at least ignoring a "should" and "should" have recognized their behavior as risky and perhaps not portable between JES2 and JES3. I find the whining about APAR OA05951 simply incredible. As I read it, prior to the fix, contents of various instream data sets were treated positionally, ignoring the specific DDNAMES. With the fix, the content matches the DDNAMEs. I can see this only as repair of a blatant Programming ERror. Finally, I mostly concur with Tom Marchant's reply to Mark Zelden's "What's wrong with comments?" I use the bogus DDNAME largely to select among different versions of SYSIN for development and testing. One exception is when I have a large header comment. Then I may use: //DOC EXEC PGM=IEFBR14 //COMMENTS DD * Text that I can easily reflow and reformat. I suppose that if I were more proficient with ISPF's facilities for limiting column ranges and reformatting text, I would use those instead. But yet, it avoids the distraction of the "//*" for the reader. I'll sometimes disable a lot of JCL with IF. Which is why I regret that "IF FALSE" is documented as not supported and unpredictable in behavior (although no error is reported and the construct has (almost) the intuitive effect). -- 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: Transactional Memory
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (McKown, John) writes: > This is not from IBM or about mainframes. But I think it will be of > interest to the readers here. It is from Sun about "Transactional > Memory" and how that it can be used to more easily implement > threadsafeness and multiprocessors. > > > Transactional memory appears to be the key to unlocking the full > potential of next-generation chip multiprocessing (CMP) technologies and > accelerating both their performance and their adoption. It could also be > a core enabling technology for the massively powerful terascale and > petascale computing systems now on the drawing boards of advanced > research labs and government agencies. Why? Because transactional memory > can solve a very serious problem in software engineering-a problem that > is severely constraining application performance and draining countless > productive hours from skilled programmers. > > > http://research.sun.com/spotlight/2007/2007-08-13_transactional_memory.html 801/risc had "transactional memory" ... and was used in a kind of DBMS implementation under CPr. I have some vaque recollections about CPr having discussions with system/r people (original relational/sql done on vm370 platform) http://www.garlic.com/~lynn/subtopic.html#systemr 801 transactional memory was used in aix v3 to implement the journaled file system (JFS) ... collecting all the unix filesystem metadata in a "transaction memory" area ... and using it to capture metadata changes for journal/logging. misc. past posts mentioning 801, romp, rios, somerset, power, power/pc fort knox, etc http://www.garlic.com/~lynn/subtopic.html#801 there has been ongoing discussions about lack of an easily understood and useable parallel programming paradigm which has been a (unsuccesful) "holy grail" for a couple decades ... but is becoming much more critical with the growing pervasiveness of multi-core chips ... and paradigm shift that chips haven't been getting significantly faster ... and thruput increases only coming from being able to do more operations in parallel http://www.garlic.com/~lynn/2008k.html#63 Intel: an expensive many-core future is ahead of us misc older posts mentioning transactional memory http://www.garlic.com/~lynn/2003o.html#49 Any experience with "The Last One"? http://www.garlic.com/~lynn/2005r.html#27 transactional memory question http://www.garlic.com/~lynn/2007b.html#44 Why so little parallelism? http://www.garlic.com/~lynn/2007n.html#6 Is Parallel Programming Just Too Hard? http://www.garlic.com/~lynn/2007n.html#36 How to flush data most efficiently from memory to disk when db checkpoint? http://www.garlic.com/~lynn/2007o.html#12 more transactional memory for mutlithread/multiprocessor operation http://www.garlic.com/~lynn/2008d.html#50 CPU time differences for the same job http://www.garlic.com/~lynn/2008e.html#10 Kernels http://www.garlic.com/~lynn/2008h.html#27 Two views of Microkernels (Re: Kernels -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 -- 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
Transactional Memory
This is not from IBM or about mainframes. But I think it will be of interest to the readers here. It is from Sun about "Transactional Memory" and how that it can be used to more easily implement threadsafeness and multiprocessors. Transactional memory appears to be the key to unlocking the full potential of next-generation chip multiprocessing (CMP) technologies and accelerating both their performance and their adoption. It could also be a core enabling technology for the massively powerful terascale and petascale computing systems now on the drawing boards of advanced research labs and government agencies. Why? Because transactional memory can solve a very serious problem in software engineering-a problem that is severely constraining application performance and draining countless productive hours from skilled programmers. http://research.sun.com/spotlight/2007/2007-08-13_transactional_memory.h tml -- 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: HSM Recalls
There is a HSM migration exit(ARCMDEXT) that gets control when a dataset is going to be moved from L0 to L1, L1 to L2. The great thing about the exit is there is one piece of information that is not known where the management class is assigned: The actual size of the data set. That is passed to the exit so you could keep 100 5 cyl datasets around on L1 and send one 500 cyl dataset directly to L2 for the same amount of online storage. Duane Reaugh DTS Software (makers of Easy/Exit that supports this exit if you don't want to write and maintain a exit) sorry -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Vernooy, C.P. - SPLXM Sent: Monday, July 28, 2008 10:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: HSM Recalls I don't agree. First, "You don't" is not an answer to the question "how do I". "in my opinion you shouldn't" is and I think that's what you intend to say and I have a different opinion. Your reasoning is correct, until the point where you don't take the cost of migration and recalls into consideration when doing the "balancing act". I have determined that it saves me a lot of cpu not to migrate/recall "small" datasets and it only costs me a fraction more on my storagegroups. This is something missing in storage management. Fase 1 "should I start migrating" is realized, but fase 2 "how do I migrate efficiently" is not, that is what I bring into the system with leaving small datasets outside migration and what Michael also already regarded useful, but was not sure how to realize it. Kees. "Richards, Robert B." <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > The question posed by Michael was how does someone select datasets for > migration based on size. The answer, "You don't". Let me explain. > > The purpose of space management is to make sure that you have enough > available space in your storage pools to handle new allocations and > extending of existing allocations. Movement of datasets should only > happen to meet that end. The only reason "size matters" is > because the larger the allocation of the migration-eligible dataset is, > the easier the goal is met to provide available free space in the > storage pool. > > To that end, I agree with Ted. Migrating datasets based solely on some > minimum size is ludicrous, especially if it is a very small value. > > We all know that placing datasets on L0, L1 and L2 is a balancing act > based on constraints that vary shop-to-shop and definitely change over > time. > > Bob > > - > Robert B. Richards(Bob) > US Office of Personnel Management > 1900 E Street NW Room: BH04L > Washington, D.C. 20415 > Phone: (202) 606-1195 > Email: [EMAIL PROTECTED] > - > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Vernooy, C.P. - SPLXM > Sent: Monday, July 28, 2008 9:12 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: HSM Recalls > > The down side of this method is that you only have one chance to > determine the size, at dataset creation. Whatever happens to (the size > of) the dataset afterwards is out of ACS routines control. > We have CA-DISK and there I can (and do) explicitely exclude datasets > from archiving/migration based on the size at that moment. > > Kees. > > "O'Brien, David W. [C] , NIH/CIT" <[EMAIL PROTECTED]> wrote in > message > news:<[EMAIL PROTECTED]>... > > Not HSM, selection is done by assigning SMS Management class based on > size in the SMS ACS routine. > > > > > > > > From: Michael Wickman [mailto:[EMAIL PROTECTED] > > Sent: Mon 7/28/2008 8:55 AM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: Re: HSM Recalls > > > > > > > > Just curious how you select for migration base on size. Do you set > > special management class based on primary space at allocation time? > Or > > are there HSM commands that help with this selection process? > > > > > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > Mike Wickman > > Technical Services > > email mwickman at waddell dot com > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > > Behalf Of Ted MacNEIL > > Sent: Thursday, July 24, 2008 4:56 PM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: Re: [IBM-MAIN] HSM Recalls > > > > >We do not migrate anything smaller than 5mb since the overhead of > > migrating them and having them recalled later was greater than the > cost > > of just leaving them on disk! > > > > I mentioned this on IBM-Main many years ago. > > I was told I was full of s**t. > > Back then, it was any dataset a cylinder (.8 MB) or smaller. > > Now, I think even 5MB is probably small. > > > >
Re: HSM Recalls
Kees, Am I missing something? You stated that you didn't agree with me and then proceeded to agree with my premise. Stated another way: "Only migrate when you need more free space in your volume pools. Otherwise, leave it there". This is obviously a generalization on my part and leaves a lot to the imagination of the reader. Things like cost of CPU, DASD for migrate/recalls, etc. were intentionally left out of my response as I was addressing the point of migration based on size, which, in my opinion, is putting the cart before the horse. I fear we may be talking semantics here and are actually in agreement. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Vernooy, C.P. - SPLXM Sent: Monday, July 28, 2008 10:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: HSM Recalls I don't agree. First, "You don't" is not an answer to the question "how do I". "in my opinion you shouldn't" is and I think that's what you intend to say and I have a different opinion. Your reasoning is correct, until the point where you don't take the cost of migration and recalls into consideration when doing the "balancing act". I have determined that it saves me a lot of cpu not to migrate/recall "small" datasets and it only costs me a fraction more on my storagegroups. This is something missing in storage management. Fase 1 "should I start migrating" is realized, but fase 2 "how do I migrate efficiently" is not, that is what I bring into the system with leaving small datasets outside migration and what Michael also already regarded useful, but was not sure how to realize it. Kees. "Richards, Robert B." <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > The question posed by Michael was how does someone select datasets for > migration based on size. The answer, "You don't". Let me explain. > > The purpose of space management is to make sure that you have enough > available space in your storage pools to handle new allocations and > extending of existing allocations. Movement of datasets should only > happen to meet that end. The only reason "size matters" is > because the larger the allocation of the migration-eligible dataset is, > the easier the goal is met to provide available free space in the > storage pool. > > To that end, I agree with Ted. Migrating datasets based solely on some > minimum size is ludicrous, especially if it is a very small value. > > We all know that placing datasets on L0, L1 and L2 is a balancing act > based on constraints that vary shop-to-shop and definitely change over > time. > > Bob > > - > Robert B. Richards(Bob) > US Office of Personnel Management > 1900 E Street NW Room: BH04L > Washington, D.C. 20415 > Phone: (202) 606-1195 > Email: [EMAIL PROTECTED] > - > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Vernooy, C.P. - SPLXM > Sent: Monday, July 28, 2008 9:12 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: HSM Recalls > > The down side of this method is that you only have one chance to > determine the size, at dataset creation. Whatever happens to (the size > of) the dataset afterwards is out of ACS routines control. > We have CA-DISK and there I can (and do) explicitely exclude datasets > from archiving/migration based on the size at that moment. > > Kees. > > "O'Brien, David W. [C] , NIH/CIT" <[EMAIL PROTECTED]> wrote in > message > news:<[EMAIL PROTECTED]>... > > Not HSM, selection is done by assigning SMS Management class based on > size in the SMS ACS routine. > > > > > > > > From: Michael Wickman [mailto:[EMAIL PROTECTED] > > Sent: Mon 7/28/2008 8:55 AM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: Re: HSM Recalls > > > > > > > > Just curious how you select for migration base on size. Do you set > > special management class based on primary space at allocation time? > Or > > are there HSM commands that help with this selection process? > > > > > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > Mike Wickman > > Technical Services > > email mwickman at waddell dot com > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > > Behalf Of Ted MacNEIL > > Sent: Thursday, July 24, 2008 4:56 PM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: Re: [IBM-MAIN] HSM Recalls > > > > >We do not migrate anything smaller than 5mb since the overhead of > > migrating them and having them recalled later was greater than the > cost > > of just leaving them on disk! > > > > I mentioned this on IBM-Main many years ago. > > I was told I was full of s**t. > > Back then, it was any dataset a cylinder (.8 MB) or smaller. > > No
Re: Example of what a very small JCL Interpreter can do to your installation.
On Fri, 25 Jul 2008 17:56:35 -0500, William H. Blair <[EMAIL PROTECTED]> wrote: >Jeff Holst noted that an IBM SRL states: > >> 1. Overriding statements can appear in any order when >>they explicitly specify the step that is being >>overridden. > >This is apparently the "missing" documentation. However, >it is not completely technically correct, because it is >obviously not, in fact, necessary that "they explicitly >specify the step that is being overridden." > >Thanks for the heads-up. > >-- >WB > If you go on to read the next paragraph it explains what happens when the step is not specified (it uses the step name from the last DD statement that did specify a step name, and if none exists the first step in the proc is overridden.) The paragraph that follows further clarifies things by stating that overriding DD statements must appear in the order of the steps in the proc. It is misleading to take one paragraph in isolation. jh -- 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: HSM Recalls
The HSM migration exit (ARCMDEXT) is what we use to keep smaller datasets from migrating. You can find a sample in SYS1.SAMPLIB(ARCMDEXT). We set the exit up to not migrate any datasets smaller than 10MB for 60 days and to not migrate datasets smaller then 5MB for 400 days. After 60 days we saw a daily 89% decrease in the number of datasets that were being migrated (67,226 down to 7,153) and a decrease of 17% in the number of recalls (2719 down to 2263). The CPU utilization for migration/recall reduced 45%. We did this without having to increase the size of the pools - since the datasets not migrating were so small. This was a win-win situation for us. ThanksRick -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Michael Wickman Sent: Monday, July 28, 2008 7:55 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: HSM Recalls Just curious how you select for migration base on size. Do you set special management class based on primary space at allocation time? Or are there HSM commands that help with this selection process? *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Mike Wickman Technical Services email mwickman at waddell dot com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Thursday, July 24, 2008 4:56 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] HSM Recalls >We do not migrate anything smaller than 5mb since the overhead of migrating them and having them recalled later was greater than the cost of just leaving them on disk! I mentioned this on IBM-Main many years ago. I was told I was full of s**t. Back then, it was any dataset a cylinder (.8 MB) or smaller. Now, I think even 5MB is probably small. Analysis is required, but the concept is sound. - Too busy driving to stop for gas! "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." -- 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: HSM Recalls
The down side of this method is that you only have one chance to determine the size, at dataset creation I also believe that HSM's ARCMDEXT exit is the place to decide whether to migrate, either ML1 or ML2, or leave it spin a little longer. And the exit certainly isn't rocket science. The SMS Mclass is based on the total size of the DSN at allocation, ie primary and 15*secondary. In our case that tends to distort the actual size of the DSN. Jack Kelly 202-502-2390 (Office) -- 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: HSM Recalls
I don't agree. First, "You don't" is not an answer to the question "how do I". "in my opinion you shouldn't" is and I think that's what you intend to say and I have a different opinion. Your reasoning is correct, until the point where you don't take the cost of migration and recalls into consideration when doing the "balancing act". I have determined that it saves me a lot of cpu not to migrate/recall "small" datasets and it only costs me a fraction more on my storagegroups. This is something missing in storage management. Fase 1 "should I start migrating" is realized, but fase 2 "how do I migrate efficiently" is not, that is what I bring into the system with leaving small datasets outside migration and what Michael also already regarded useful, but was not sure how to realize it. Kees. "Richards, Robert B." <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > The question posed by Michael was how does someone select datasets for > migration based on size. The answer, "You don't". Let me explain. > > The purpose of space management is to make sure that you have enough > available space in your storage pools to handle new allocations and > extending of existing allocations. Movement of datasets should only > happen to meet that end. The only reason "size matters" is > because the larger the allocation of the migration-eligible dataset is, > the easier the goal is met to provide available free space in the > storage pool. > > To that end, I agree with Ted. Migrating datasets based solely on some > minimum size is ludicrous, especially if it is a very small value. > > We all know that placing datasets on L0, L1 and L2 is a balancing act > based on constraints that vary shop-to-shop and definitely change over > time. > > Bob > > - > Robert B. Richards(Bob) > US Office of Personnel Management > 1900 E Street NW Room: BH04L > Washington, D.C. 20415 > Phone: (202) 606-1195 > Email: [EMAIL PROTECTED] > - > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Vernooy, C.P. - SPLXM > Sent: Monday, July 28, 2008 9:12 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: HSM Recalls > > The down side of this method is that you only have one chance to > determine the size, at dataset creation. Whatever happens to (the size > of) the dataset afterwards is out of ACS routines control. > We have CA-DISK and there I can (and do) explicitely exclude datasets > from archiving/migration based on the size at that moment. > > Kees. > > "O'Brien, David W. [C] , NIH/CIT" <[EMAIL PROTECTED]> wrote in > message > news:<[EMAIL PROTECTED]>... > > Not HSM, selection is done by assigning SMS Management class based on > size in the SMS ACS routine. > > > > > > > > From: Michael Wickman [mailto:[EMAIL PROTECTED] > > Sent: Mon 7/28/2008 8:55 AM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: Re: HSM Recalls > > > > > > > > Just curious how you select for migration base on size. Do you set > > special management class based on primary space at allocation time? > Or > > are there HSM commands that help with this selection process? > > > > > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > Mike Wickman > > Technical Services > > email mwickman at waddell dot com > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > > Behalf Of Ted MacNEIL > > Sent: Thursday, July 24, 2008 4:56 PM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: Re: [IBM-MAIN] HSM Recalls > > > > >We do not migrate anything smaller than 5mb since the overhead of > > migrating them and having them recalled later was greater than the > cost > > of just leaving them on disk! > > > > I mentioned this on IBM-Main many years ago. > > I was told I was full of s**t. > > Back then, it was any dataset a cylinder (.8 MB) or smaller. > > Now, I think even 5MB is probably small. > > > > Analysis is required, but the concept is sound. > > > > -- > 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or a
JES2-L is moribund!
I have to second that opinion. I joined the list but never have been able to search it. I can't seem to subscribe to the 'lists' within JES-L not does it appear to have a email list. Due to the various suggestions to use that list,I have obviously missed something? Jack Kelly 202-502-2390 (Office) -- 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: HSM Recalls
The question posed by Michael was how does someone select datasets for migration based on size. The answer, "You don't". Let me explain. The purpose of space management is to make sure that you have enough available space in your storage pools to handle new allocations and extending of existing allocations. Movement of datasets should only happen to meet that end. The only reason "size matters" is because the larger the allocation of the migration-eligible dataset is, the easier the goal is met to provide available free space in the storage pool. To that end, I agree with Ted. Migrating datasets based solely on some minimum size is ludicrous, especially if it is a very small value. We all know that placing datasets on L0, L1 and L2 is a balancing act based on constraints that vary shop-to-shop and definitely change over time. Bob - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: [EMAIL PROTECTED] - -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Vernooy, C.P. - SPLXM Sent: Monday, July 28, 2008 9:12 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: HSM Recalls The down side of this method is that you only have one chance to determine the size, at dataset creation. Whatever happens to (the size of) the dataset afterwards is out of ACS routines control. We have CA-DISK and there I can (and do) explicitely exclude datasets from archiving/migration based on the size at that moment. Kees. "O'Brien, David W. [C] , NIH/CIT" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Not HSM, selection is done by assigning SMS Management class based on size in the SMS ACS routine. > > > > From: Michael Wickman [mailto:[EMAIL PROTECTED] > Sent: Mon 7/28/2008 8:55 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: HSM Recalls > > > > Just curious how you select for migration base on size. Do you set > special management class based on primary space at allocation time? Or > are there HSM commands that help with this selection process? > > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > Mike Wickman > Technical Services > email mwickman at waddell dot com > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Ted MacNEIL > Sent: Thursday, July 24, 2008 4:56 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: [IBM-MAIN] HSM Recalls > > >We do not migrate anything smaller than 5mb since the overhead of > migrating them and having them recalled later was greater than the cost > of just leaving them on disk! > > I mentioned this on IBM-Main many years ago. > I was told I was full of s**t. > Back then, it was any dataset a cylinder (.8 MB) or smaller. > Now, I think even 5MB is probably small. > > Analysis is required, but the concept is sound. > -- 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: Foreign 3590
That message is saying that the VOLSER is not in the ATL, or missing from the VOLCAT. On Fri, Jul 25, 2008 at 6:05 PM, Lucy Arnold <[EMAIL PROTECTED]>wrote: > Hello, > > We just got a 3590 from IBM and am not having any luck getting the ATL to > read it. We usually get electronic files or the old 3490. We put it in > the ATL door and the robot read it and stuck it in a slot - but when we try > to access it we get: > > REQUEST FAILED - NOT ENOUGH NON-SYSTEM MANAGED VOLUMES ELIGIBLE > > How do you get to the darn thing?? Here is the JCL: > > //STEP2 EXEC PGM=IEBCOPY PARM='DEBUG' > //SYSPRINT DD SYSOUT=* > //SYSUT3 DD UNIT=3390,SPACE=(CYL,(50,1)) > //SYSUT4 DD UNIT=3390,SPACE=(CYL,(50,1)) > //IN DD DSN=RIMLIB,UNIT=3590,VOL=SER=MP2869, > //DISP=SHR,LABEL=(2,SL,EXPDT=98000), > //STORCLAS=SC3590 > //OUT DD DSN=SYSJCN.PDO.RIMLIB,DISP=SHR > //SYSIN DD * > COPY INDD=((IN,R)),OUTDD=OUT > > Thanks in advance! > > > > Lucy Arnold > Storage Manager > U.C. Davis Medical Center > 916-734-5498 > > -- > 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 > > -- Mark Pace Mainline Information Systems -- 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: HSM Recalls
The down side of this method is that you only have one chance to determine the size, at dataset creation. Whatever happens to (the size of) the dataset afterwards is out of ACS routines control. We have CA-DISK and there I can (and do) explicitely exclude datasets from archiving/migration based on the size at that moment. Kees. "O'Brien, David W. [C] , NIH/CIT" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Not HSM, selection is done by assigning SMS Management class based on size in the SMS ACS routine. > > > > From: Michael Wickman [mailto:[EMAIL PROTECTED] > Sent: Mon 7/28/2008 8:55 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: HSM Recalls > > > > Just curious how you select for migration base on size. Do you set > special management class based on primary space at allocation time? Or > are there HSM commands that help with this selection process? > > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > Mike Wickman > Technical Services > email mwickman at waddell dot com > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Ted MacNEIL > Sent: Thursday, July 24, 2008 4:56 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: [IBM-MAIN] HSM Recalls > > >We do not migrate anything smaller than 5mb since the overhead of > migrating them and having them recalled later was greater than the cost > of just leaving them on disk! > > I mentioned this on IBM-Main many years ago. > I was told I was full of s**t. > Back then, it was any dataset a cylinder (.8 MB) or smaller. > Now, I think even 5MB is probably small. > > Analysis is required, but the concept is sound. > > - > Too busy driving to stop for gas! > > > > > > > > > > "This email is intended to be reviewed by only the intended recipient > and may contain information that is privileged and/or confidential. > If you are not the intended recipient, you are hereby notified that > any review, use, dissemination, disclosure or copying of this email > and its attachments, if any, is strictly prohibited. If you have > received this email in error, please immediately notify the sender by > return email and delete this email from your system." > > > -- > 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 > > ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Paging Question
Several things have to happen before storage will be backed on AUX. In simple terms. The storage has to be getmained. All this does is update the page tables. No real storage is allocated. The invalid flag is on in the page table. The first time the page is modified, the invalid flag triggers RSM to assign real storage. At this point it is eligible for AUX backing. If the page is highly dynamic, it may never be backed. If it becomes static, it may be backed to allow for rapid page stealing. This depends on the storage load on the system. BTW - we see the same thing. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Saturday, July 26, 2008 8:04 AM --- We have page datasets with 40% allocated slots. We do not page (have lots of free memory). D ASM,ALL But the allocated slots is less that the sum of all the address spaces. When is space allocated on a page dataset. I was thinking when virtual storage is requested. But this contradicts the process of spreading several pages across page datasets during page out. -- 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: HSM Recalls
Not HSM, selection is done by assigning SMS Management class based on size in the SMS ACS routine. From: Michael Wickman [mailto:[EMAIL PROTECTED] Sent: Mon 7/28/2008 8:55 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: HSM Recalls Just curious how you select for migration base on size. Do you set special management class based on primary space at allocation time? Or are there HSM commands that help with this selection process? *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Mike Wickman Technical Services email mwickman at waddell dot com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Thursday, July 24, 2008 4:56 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] HSM Recalls >We do not migrate anything smaller than 5mb since the overhead of migrating them and having them recalled later was greater than the cost of just leaving them on disk! I mentioned this on IBM-Main many years ago. I was told I was full of s**t. Back then, it was any dataset a cylinder (.8 MB) or smaller. Now, I think even 5MB is probably small. Analysis is required, but the concept is sound. - Too busy driving to stop for gas! "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." -- 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: control block including JOBID in case of WLM-managed jobs
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Fedtke > Sent: Monday, July 28, 2008 7:04 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: control block including JOBID in case of WLM-managed jobs > > hi z/os specialists, > > for batch jobs running JES2-managed you may determine the jobid > (JOB) in control block field SSIBJBID. this seems to differ > in case of WLM-managed jobs. > > does anybody has info or idea on where to get the jobid based on > passing thorugh control blocks (not via console command). > > thanks > stephen Why bother chasing chains? Use IAZXJSAB. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A281/27.0 IAZXJASB READ,JOBID=MYJOBID,JOBNAME=MYJOBNAME,USERID=MYUSERID ... MYJOBID DC CL8' ' JES JOB ID MYJOBNAME DC CL8' ' BATCH JOB NAME MYUSERID DC CL8' ' RACF ID THAT THE JOB IS RUNNING UNDER -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: HSM Recalls
Just curious how you select for migration base on size. Do you set special management class based on primary space at allocation time? Or are there HSM commands that help with this selection process? *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Mike Wickman Technical Services email mwickman at waddell dot com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Thursday, July 24, 2008 4:56 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] HSM Recalls >We do not migrate anything smaller than 5mb since the overhead of migrating them and having them recalled later was greater than the cost of just leaving them on disk! I mentioned this on IBM-Main many years ago. I was told I was full of s**t. Back then, it was any dataset a cylinder (.8 MB) or smaller. Now, I think even 5MB is probably small. Analysis is required, but the concept is sound. - Too busy driving to stop for gas! "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." -- 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: Tivoli Workload Scheduler using excessive CPU
I posted the following about 2 ½ weeks ago and got one response. I'm trying again. :-) "Our Tivoli Workload Scheduler (version 8.3) server task for communication between z/OS-USS and the distributed platform appears to be using excessive CPU at all times. No problem messages have been issued/noticed. Is anyone else running TWS 8.3 experiencing this problem? We are z/OS 1.9" Bob -- 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
control block including JOBID in case of WLM-managed jobs
hi z/os specialists, for batch jobs running JES2-managed you may determine the jobid (JOB) in control block field SSIBJBID. this seems to differ in case of WLM-managed jobs. does anybody has info or idea on where to get the jobid based on passing thorugh control blocks (not via console command). thanks stephen -- 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: Paging Question
Rick, A poorly typed sentence. It should read: " Pages are only allocated slots on AUX if they have been paged out and remain unchanged. There is no attempt to back a getmained page with an AUX slot." My meaning is that ASM is not called to allocate an AUX slot until RSM needs to do some management. If there is never an event that requires a page-out then ASM will never allocate a slot. My reference to unchanged was to acknowledge that after being paged out, a page can exist in both REAL and AUX until it is changed. I think you are referring to the same thing - page-in/page-out via bit flicks. Ron > > I was taught, at one time, that AUX storage slots were assigned by ASM > call from VSM, during the processing of a GETMAIN request, and were > released at FREEMAIN time. Since then, I learned that VSM pages that > were paged out were assigned slots "on the fly" and the various AUX > storage tables within the AS were updated at that time. Also, that > pages > that were unchanged since last page-in were not physically paged out, > but rather something akin to "stolen". > > (My assumption, provably invalid, was that storage was acquired to be > used, thus each page would be changed at least once.) > > Rick > > -- > 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
