Re: Seven-Digit JES2 Job Number
Seven digit JES numbers have existed since Z2 level in 2002, but as Mark just educated me, the first digit is always a zero! The seven digits do exist in the JCTJOBID field, where I found values of Jnnn, and thus in the MXG changes to extract that nnn value into variable JESNR, I referred to it as a seven-digit number, but didn't observe nor note that the first byte is always a zero, with 999,999 the actual maximum JES Number. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229-5112 214 351 1966 tel 214 350 3694 fax http://www.mxg.com ba...@mxg.com MXG Support: supp...@mxg.com MXG Admin: ad...@mxg.com Standard Answers: http://www.mxg.com/administration What's Supported: http://www.mxg.com/changes -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tapeless solution (IBM or Sun) Enterprise class
But isn't ACME's only customer a coyote? Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Malicious Software Protection
One of your postings reminded me of Pat Artis' statement: The difference between a Feature and a Benefit: A Feature is when your wife/girlfriend has large breasts. A Benefit is when she lets you touch them. Barry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Friday fun: Halon dumps and POK Resets
At State Farm in 1973, a new bank of tape drives were installed in late May, and they ran fine until Jun 15, when we began to see very strange tape ABENDS (starting with Fnnx as I recall), perhaps a dozen each day, that would then not occur until the next evening. After 10 days and much research by IBM, I decided to print the step records with those ABEND codes, and noticed that the time of the first instance of each day's ABEND was one or two minutes later than the prior day's first ABEND, but only up to June 22, when its first time was earlier than the first time on June 21, and subsequent days were also failing earlier by a minute or two on each successive day. I immediately concluded it must be somehow related to sunset, so the late Tim Wuthrich and I estimated the projected time of that day's first abend, stayed late, and were adjacent to the new drives when we saw the sun come thru the window, and one of the tapes that was being read immediately started to rewind! Those 3420 tape drives had an optical sensor that read the reflection from the silver strip at the end of the physical tape, and the sun got into that sensor, causing a false detection of end of tape. Installed blinds on that window and solved the problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Pre-Friday fun: Halon dumps and POK Resets
John Deere's data center in the 70's had two independent power supply companies, but with Midwest lightning strikes still had several to many outages each year. Data Center Manager could NOT get approval for a diesel power backup UPS because: The only backup system that was large enough for their power load was available from a single vendor and that vendor would ONLY use a caterpillar diesel engine. I think after the second year of outages, the data center manager was finally allowed to build a John Deere Green colored outbuilding building to hide the yellow Caterpillar engine. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Are LPAR names unique or effectively unique?
And LPAR NUMBER cannot be used; it is assigned based on the alphabetical order of the LPAR NAMES so adding or deleting an LPAR will cause subsequently higher LPARs to have different LPAR Numbers. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert historic STCK to local time?
FALSE: Sanely organized networks, even those that do not span multiple time zones, collect and store only UTC [GMT] STCKE values. TRUE: Truly sanely organized networks, of any description, collect and store EITHER the UTC datetime value OR the local datetime value, and the GMT Offset to the time zone of that system at that time of the UTC value, AND the Leap Seconds in effect at that datetime value. The first two are quite commonly stored in well designed data collection systems, leap seconds are almost never stored. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Life of a JOB
I believe the below ACHAP07 member of the MXG Source Library may be the information you requested, as it was presented at SHARE in the 70s and 80s. While it claims to be revised, it's still possibly out of date. Barry /* Copyright (C) 1984,1994 Merrill Consultants Dallas Texas USA */ Status: Has been completely revised. Chapter Seven Events in the Lifetime of an MVS Job/STC/TSO Session. To perform CPE analysis, the analyst must understand the computer system under investigation and know what functions the operating system performs for a task. Although operating systems are different, they all manage the shared resources in response to requests by tasks for those resources. Since the operating system is the manager of the many queues for these requests, a large part of CPE data analysis is to determine who is in what queue, for how long, and why. All operating systems provide some accounting data for each task (job, session, and so forth) that contain time stamps when certain events occur for that task. By comparing these time stamps to the logical structure of the services provided by the operating system, the analyst can understand how an operating system interaction is mapped to the CPE data. By subtracting adjacent time stamps, the duration in certain states (allocation, CPU execution, I/O execution, and so forth) can be determined at the task level. Documentation of CPE data from the vendor often does not tell enough about the meaning of these events. Sometimes you can read the microfiche (when the vendor makes the source available) and perhaps decipher the conditions under which a time stamp is valid, but even then, the experimental confirmation of suspicion is required. By executing tasks that you understand (that is, your own specific job) and by examining the detail data in those detail records written on your tasks, you can gain the necessary knowledge. For SMF data, the MXG program ANALALL will print all variables from all records for any job. The SAS System provides powerful features for manipulating numeric values that contain durations, time stamps, dates, and datetimestamps. All of these variables are stored as numeric values and manipulated as any other numeric value. It is the association of a SAS format (by using the FORMAT statement) that causes the numeric value to be printed as a date, time of day or duration, or datetimestamps: Dates are stored as the number of days (plus or minus) from Jan 1, 1960. MXG always assigns the format DATE7 to date variables, so that the name of the month is printed, and MXG avoids the ambiguity of the MMDDYY and DDMMYY formats (03/05/94 means 05MAR94 in the US but 03MAY94 in Europe!) Eg:DATA; DATE=1; PUT DATE DATE9.; prints as DATE=01JAN1960. Eg:DATA; DATE=1; PUT DATE DATE7.; prints as DATE=01JAN60. Times are stored as seconds (and fractions, if any), and are assigned the TIME12.2 format (for typical SMF time stamps with resolution of tenths and hundredths of a second). Eg: DATA; TIME=43200.99; PUT TIME TIME12.2; prints as 12:00:00.99, (there are 86,400 seconds in a day!). . Datetimestamps are stored as seconds (plus or minus) from midnight on January 1, 1960, and are assigned the DATETIME21.2 format (if they are standard SMF datetimestamp values). Eg.: DATA; DATETIME=1262217600.99; PUT DATETIME DATETIME21.2; prints as 31DEC1999:00:00:00.99. A note on the length of datetime variables. SAS numeric variables are floating point numbers, and are normally stored in 8 bytes (one for the exponent, seven for the mantissa). Prior to Change 19.272 in January, 2002 this was true: MXG overrides the stored length default and specifies LENGTH as DEFAULT=MXGLEN; only a few variables need the full 8 byte length, and using 4 bytes per variable saves significant DASD space in your MXG datasets. There is one class of variables, however, that do require 8 bytes of storage: datetimestamp values, because four bytes is not large enough to fully resolve the 10-digit value of current datetimestamps. In fact, if you should store a datetimestamp in only four bytes, the time values will be as much as 255 seconds less than reality. Thus MXG assigns a length of 8 bytes for all datetimestamp values. To further save storage, MXG may keep only the start datetime value and the duration, requiring only 12 bytes, instead of both timestamps which would require 16 bytes, since the end datetime can always be reconstructed by addition. Change 19.272 changed the default stored length from 4 to 5 on EBCDIC and from 4 to 6 on ASCII SAS systems. See that change text. Originally, all MXG datetimestamp variables ended with TIME (for example, READTIME), and all MXG duration/time variables ended with ...TM (for example, CPUTCBTM), but that was back when I created all of names of all of the variables. Now, I
Re: Dates of previous releases of the operating system
From MXG CHANGES member: MXG Version MVS/ESA 4.1 Oct 26, 1990 8.8 MVS/ESA 4.2 Mar 29, 1991 9.9 MVS/ESA 4.2.2Aug 15, 1991 9.9 MVS/ESA 4.3 Mar 23, 199310.10 MVS/ESA 5.1.0 - compatibilityJun 24, 199412.02 MVS/ESA 5.1.0 - Goal ModeMay 3, 199513.01 MVS/ESA 5.2.0Jun 15, 199513.05 MVS/ESA 5.2.2Oct 19, 199513.09 OS/390 1.1.0Feb 22, 199614.01 OS/390 1.2.0Sep 30, 199614.05 OS/390 1.3.0 Compatibility Mode Mar 28, 199714.14 OS/390 1.3.0 WLM Goal Mode Mar 28, 199715.02 OS/390 2.4.0Sep 28, 199715.06 OS/390 2.5.0Feb 24, 199815.06 OS/390 2.6.0Sep 24, 199816.04 OS/390 2.7.0Mar 26, 199916.09 OS/390 2.7.0 APAR OW41318 Mar 31, 200018.03 OS/390 2.8.0Aug 24, 199916.09 OS/390 2.8.0 FICON/SHARKAug 24, 199917.08 OS/390 2.8.0 APAR OW41317 Mar 31, 200018.03 OS/390 2.9.0Mar 31, 200018.03 OS/390 2.10.0Sep 15, 200018.06 OS/390 PAV Oct 24, 200018.09 z/OS 1.1 Mar 30, 200118.11 z/OS 1.1 on 2064sMar 30, 200119.01 z/OS 1.1 with correct MSUMar 30, 200119.02 z/OS 1.2 Oct 31, 200119.04 z/OS 1.1,1.2 APARs to 78 Oct 31, 200119.05 z/OS 1.2+ APAR OW52227 Apr 26, 200220.02 z/OS 1.3+ APAR OW52227 Apr 26, 200220.02 z/OS 1.2 JESNR Z2 MODE Apr 26, 200220.03 z/OS 1.3 JESNR Z2 MODE Apr 26, 200220.03 z/OS 1.4 TolerateSep 27, 200220.03 z/OS 1.4 Support Sep 27, 200220.06 z/OS 1.4 Over 16 CPUs/LPARs May 29, 200321.02 z/OS 1.4 DFSMS/rmm, RACF Aug 29, 200321.04 z/OS 1.5 Mar 31, 200421.21 z/OS IRD ASUM70PR/ASUMCECSep 22, 2003 *24.10 z/OS IRD TYPE70PRMar 11, 2004 *24.10 z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 *24.10 z/OS 1.6 - No IFAs Sep 30, 2004 *22.09 z/OS 1.6 - With IFAs Sep 30, 2004 *22.11 z/OS 1.7 (COMPATIBLE CHANGES)Sep 30, 2005 *24.10 z/OS 1.7 (SPLIT70 CORRECTION)Sep 30, 2005 *24.10 z/OS IFA data in RMF 79s Sep 30, 200523.10 z/OS 1.8 - ASMTAPEE assembly Sep 30, 2005 *25.03 z/OS 1.8 - SMF 119 INCOMPAT Sep 30, 2005 *25.06 z/OS More than 32 LPARs Jan 30, 2006 *24.24 z/OS SPLIT RMF 70 recordsJan 30, 2006 *24.24 z/OS Dupe SYSTEMs in a SYSPLEX Jan 30, 2006 *24.02 z/OS IRD errors correctedMay 15, 200624.03 z/OS ASUMCEC errors correctedMay 15, 2006 *24.24 z/OS ASUM70LP errors corrected Jun 13, 2006 *24.24 z/OS zIIP Processor Support Jun 22, 2006 *24.24 z/OS Dedicated zIIP Support Mar 8, 2008 *26.01 z/OS Dedicated zAAP Support Mar 8, 200826.01 z/OS 1.8 (COMPATIBLE CHANGES)Sep 20, 2006 *24.24 z/OS 1.9 (INCOMPAT, 54 CPs) Sep 27, 200725.10 z/OS 1.9 MXGTMNT at ML-39 reASM Sep 27, 200725.10 z/OS new z10 variables Mar 5, 200826.01 z/OS 1.8 With HiperDispatch Sep 15, 2008 *26.10 z/OS 1.9 With HiperDispatch Sep 15, 2008 *26.10 z/OS 1.10 (INCOMPAT, MXG code) Sep 15, 200826.07 z/OS 1.10 With HiperDispatch Sep 15, 2008 *26.10 z/OS 1.10 RMF III, SMF 119 Jul 20, 200927.05 z/OS 1.11Sep 2, 200927.08 z/OS 1.11 New 30 variables Apr 14, 2010 *28.02 z/OS 1.12Aug 17, 2010 *28.05 z/OS 1.12 SMF 85 Subtype 79 Aug 17, 2010 *29.03 z/OS 1.12 VMGUEST option Aug 17, 2010 *29.06 z/OS 1.13Sep 30, 201029.03 z/OS 1.13 - MXGTMNT only Dec 15, 201029.08 z990 CPUs - CPUTYPE '2084'x Aug 25, 200321.04 z890 CPUs - CPUTYPE '2086'x Jun 24, 200422.07 z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *24.24 z9EC CPUs - CPUTYPE
Re: Very Lage Page Datasets (was ASM and HiperPAV)
MXG added variable SLOTUTIL back in '97 with this change text: Change 15.064 Variable SLOTUTIL is added to dataset TYPE71 to measure VMAC71 the percentage of local page dataset slots that are in Apr 28, 1997 use. Find the maximum value of SLOTUTIL during the month to make sure you have enough page dataset slots defined. SLOTUTIL should always be less than 25% (because the ASM's contiguous slot allocation algorithm can move 30 pages in one SSCH only when there are 30 contiguous free slots, and at utilizations above 25%, ASM begins to not find 30 slots, so it tries to find 15, then 8... which causes lots of extra SSCHs to your page volumes at the very worst possible time - those few times when paging becomes a performance problem!). I have preached this concept, but had not provided the variable (and the value I used in class turns out to need to be changed): SLOTUTIL=(SLOTLOMN-SLOTUNMN)/SLOTLOMN; compares the minimum number of defined local slots with the minimum number of unused local slots to calculate the maximum utilization of slots during the interval. That note was based on a CMG or SHARE presentation I had attended years earlier, when the contiguous slot allocation algorithm was first being used, and the presentation was a smooth curve, output from a model, rather than actual measurements, so there was no real knee of the curve, but somewhere in the 25-30% range was noted as the beginning of possible pain. Since one of the consequences of breaking the contiguous slot allocation is an increase in the number of SSCHs to the paging volumes, and since you all have dedicated devices, you should be able to plot the SSCH count to your local page datasets from RMF 74 records versus the SLOTUTIL from the 71 to see where your site's knee is located. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Tuesday, January 31, 2012 10:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Very Lage Page Datasets (was ASM and HiperPAV) Writing to contiguous slots and over allocation is mentioned, but unless I missed it the old ROT (and health check) of not having more than 30% of the slots allocated is not specifically addressed. Certainly with 4K pages (for the most part) and 3390-27 (or bigger) that 30% ROT doesn't apply anymore?50% of a mod-27 is still a helava lot of free slots. I think it still applies. My understanding has always been that the 30% usage (after which paging effectiveness drastically drops) applies to the algorithm used on the in-storage control blocks to pick the next free slot in a page data set. Unless that algorithm was redesigned, 30% of 44.9GB per page dataset is what you should not exceed (just as the health check says) in AUX usage. Redesign of that is IMHO unlikely, just as using more than 2 IOs on a page data set simultaneously would require (an unlikely) redesign. Sometimes the need for the appearance of an autonomic, self-healing system becomes more important than the need for an autonomic, self-healing system. ;-) But, you're also saying close to 50% of health checks are useful, so that's good thing. I consider about 30 of the 180-200 checks (1.12) useful. Otherwise I'll stay out of *this* discussion. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock format
1. Dates beyond 2042 are nearly possible, since tape retention can be 30 years. 2. I have seen IMS APARs that indicate STCKE values are now stored in some control blocks. 3. The TODSTAMP wrap only impacts SMF record fields that are in TOD format; the SMFSTAMP format has no wrap because it's date is a separate 4-byte part of the 8-byte field, and the date contains the century bit, which won't wrap for 254 centuries. 4. TODSTAMP has microsecond resolution, while SMFSTAMP is limited to 10 milliseconds, so TODSTAMP is (IMO) preferred in new SMF records, except for the SMFTIME field in the header that still needs to be SMFSTAMP format. 5. In MXG processing members, I observed these counts: IBM SMF records Vendor SMF records Total Instances TODSTAMPs651 667 1318 SMFSTAMPs147 345 592 6. I plan to be here to observe the wrap; I'll be 101+six months in Sept 2042. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Charles Mills Sent: Tuesday, January 31, 2012 11:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: TOD clock format the programs that digest the records can actually deal with that If I had to venture a guess I would guess that 64-bit TOD clock fields will still be around post-2042 and programs will be using windowing techniques to decide if a particular 64-bit TOD value is a date and time in 1901 or a date and time in 2043 (with 2043 being a lot more likely, of course). The problem is of course somewhat more complicated than Y2K because the time and entire date will have to be adjusted as well as the year. 2042 sounds like it is a long way away, but 2000 seemed like it was a long way away in 1970. Are you kidding? We won't still be using my COBOL program in 2000 -- computers will just be reading our minds by then. Actually, I guess, the biggest problem is not that programs endure -- it is that record layouts (like SMF) and control block formats (like the 24-bit DCB) endure seemingly forever. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Phil Smith Sent: Tuesday, January 31, 2012 7:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: TOD clock format John Gilmore wrote: There is thus no excuse for any use of an STCK instruction in NEW code. Old code is a different matter, If it is judged that there is NO possibility that it will still be in use in 2042, STCKs in it need not be replaced. Otherwise they should be. How about code that's generating SMF records? That's what we're dealing with here. Yeah, 2042 might be an issue, but the programs that digest the records can actually deal with that (and will have to, or SMF in general will by then). ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backup drives for a PC
I've dropped my self-powered 1.5TB Seagate USB drive, purchased in Feb 2010, a number of times and have lost no data. But we did find that the self-powered USB drives can be considerably slower than the drives with external power supplies, if time to backup is a consideration, or if you are actively using them (as a second device for SAS work files!). Barry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Clark Morris Sent: Friday, January 20, 2012 11:40 AM To: IBM-MAIN@bama.ua.edu Subject: OT: Backup drives for a PC I have an external 2 terabyte hard drive that I use as a back up device by plugging it into each of the two computers I have and then returning it to a fire safe. I am planning to get a second drive so I can rotate the backups off-site and was wondering if the portable hard drives are worth the additional price for this usage. I am assuming that better shock protection is given the hard drive in the portable versions. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
AutoCoder
State Farm, in 1973, was completely dependent on AUTOCODER which was then running on 360/30s and 360/40s in the 25 regional offices, while the new Real Time replacement application was still being created (in PL/1). When the Real Time system ultimately failed, the next iteration was called DELTA as in Drop Everything, Let's Try Again). Those AUTOCODER compiles required very long run times and were CPU hogs on the home office 360/165 machines, so a team was assembled to rewrite the compiler in PL/1. The end result was a massive reduction in the compile time. But the team found on instance in which the IBM compiler generated incorrect code, and were going to fix that IBM error, but management decided the team should generate the exact same code as the IBM compiler, so they implemented their compiler to generate that same error. I was NOT a part of this team, but I think that at least one of that team is a semi-frequent poster to this forum. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, January 16, 2012 9:12 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM researchers make 12-atom magnetic memory bit In 8457a39f-5e00-40d7-9f52-3128d654d...@yahoo.com, on 01/16/2012 at 09:30 PM, Scott Ford scott_j_f...@yahoo.com said: Knew a guy 15 yrs a go made a lot of money still writing auto coder I might believe AUTOCODER. Would that be 1401, 1410, 7070[1] or 7080 AUTOCODER? [1] By far the most sophisticated of the lot. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: AutoCoder
Well, the runs counter to the many sites that moved their applications to PL/1, including State Farm (who trained 1,500 non-programmers to use PL/1 in a 9 week course - those with musical ability, mathematical degrees, or knowledge of two or more languages accounted for 90% of the folks who were retained after that class!). We benchmarked SAS, PL/1, and ASM programs in about 1973, and saw ASM's execution was faster than PL/1, which was only slightly faster than SAS, but the writing of the ASM program took 7 units of time, the PL/1 took 4 units of time, and SAS took 1 unit of time. Barry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford Sent: Tuesday, January 17, 2012 2:31 PM To: IBM-MAIN@bama.ua.edu Subject: Re: AutoCoder Barry, My experience with PL/1 wasnt so good. In the 70's and 80's it was pretty CPU intensive, i was on a 370/158 OS/VS2/HASP ...then later VSE on a 4381 , PL/1 probably is much better with the faster machines. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 17, 2012, at 3:18 PM, Barry Merrill ba...@mxg.com wrote: State Farm, in 1973, was completely dependent on AUTOCODER which was then running on 360/30s and 360/40s in the 25 regional offices, while the new Real Time replacement application was still being created (in PL/1). When the Real Time system ultimately failed, the next iteration was called DELTA as in Drop Everything, Let's Try Again). Those AUTOCODER compiles required very long run times and were CPU hogs on the home office 360/165 machines, so a team was assembled to rewrite the compiler in PL/1. The end result was a massive reduction in the compile time. But the team found on instance in which the IBM compiler generated incorrect code, and were going to fix that IBM error, but management decided the team should generate the exact same code as the IBM compiler, so they implemented their compiler to generate that same error. I was NOT a part of this team, but I think that at least one of that team is a semi-frequent poster to this forum. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, January 16, 2012 9:12 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM researchers make 12-atom magnetic memory bit In 8457a39f-5e00-40d7-9f52-3128d654d...@yahoo.com, on 01/16/2012 at 09:30 PM, Scott Ford scott_j_f...@yahoo.com said: Knew a guy 15 yrs a go made a lot of money still writing auto coder I might believe AUTOCODER. Would that be 1401, 1410, 7070[1] or 7080 AUTOCODER? [1] By far the most sophisticated of the lot. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: cpu / machine identification
I was involved in an audit of a VERY large outsourcer on behalf of a VERY large software vendor, some time ago. The only data required for the audit was the site's SMF data (and a smart program to read the SMF file!), plus a program that allocated and grazed the disk farm to capture all DSNAMES and attributes (which DCOLLECT would do now). From an intelligent examination of the names of datasets, which clearly indicated/suggested they were the software company's property, along with a listing of the names of the members of those load libraries, and a comparison to the SMF program names that had been executed, which demonstrated those programs were being executed from those libraries, the two companies withdrew their suit and countersuit, and reached agreements on licensing. And, after only the very FIRST report was reviewed by both parties! Quite a bit of additional analysis software had been prepared to tighten up the SMF-to-LoadLib connection, which would have analyzed the DDNAMEs used by these programs, but those programs were never used. Merrilly New Year, Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229-5112 214 351 1966 tel 214 350 3694 fax http://www.mxg.com ba...@mxg.com MXG Support: supp...@mxg.com MXG Admin: ad...@mxg.com Standard Answers: http://www.mxg.com/administration What's Supported: http://www.mxg.com/changes -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, January 01, 2012 9:12 AM To: IBM-MAIN@bama.ua.edu Subject: Re: cpu / machine identification In 9693770902631563.wa.brianwestermansyzygyinc@bama.ua.edu, on 12/31/2011 at 06:51 PM, Brian Westerman brian_wester...@syzygyinc.com said: Sorry Shmuel, I mind works on a different level than my fingers sometimes. I apologize for the mistake on your name. That's why I try to remember to cut and paste rather than retyping names. Of course, I sometimes slip :-( I'm still not too sure that there is a way to conduct an audit that would satisfy the vendor, that the site would agree to. Providing SMF data? Proving a userid with limited authority specifically for auditing? but if you limit the audit, then it's not an audit. Doesn't that depend on what the limitations are? The audit would have to allow a search of all load libraries at a minimum, and would entail loading each and every module to check internally, not doesn't that sound like a lot of fun, it would be cost prohibitive for both the vendor and the site. That would be more of a hassle for the vendor than for the site. I would expect a vendor to do random spot checks rather than running an audit, e.g., every 30 days. I think most would go for the key after that. I've seen products thrown out because of the keys. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Date and time of IPL API?
And, reading the time of an SMF ID=0 record will NOT prove that the system was IPL'd. The ID=0 (for MANY years) is written when SMF is STARTED or RESTARTED, and there's no flag to indicate which. The only SMF records that are guaranteed to report a SYSTEM IPL are the ID=90, subtype 8 (IPL PROMPT) or subtype 10 (IPL SRM). And, the IPLTIME field in those ID=90's is on GMT, with NO GMT OFFSET provided, so the SMFTIME, in the SMF header, which is on the local time zone, must be used. Merrilly New Year, Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229-5112 214 351 1966 tel 214 350 3694 fax http://www.mxg.com ba...@mxg.com MXG Support: supp...@mxg.com MXG Admin: ad...@mxg.com Standard Answers: http://www.mxg.com/administration What's Supported: http://www.mxg.com/changes -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: cpu / machine identification
Long ago I had a phone call from India (proves how long ago this was!) for technical support, and it was a one line change I gave over the phone, saying put this change in and let me know if there's a problem in the morning. He replied we won't know until Saturday, that's when we run SAS jobs, and when I asked why, he said Well, I probably shouldn't tell you, but we haven't paid our SAS License for several years; every Saturday we IPL with an ancient date and run our week's SAS jobs. MXG's prime motivation to not check CPUID when we created that software in 1984 was to avoid OUR need to keep track of CPU and to avoid having to take the time to provide each customer with a new key, so MXG Software has always been a single site license for ALL processors and ALL operating systems at the licensed address. I can recall the shock of many contract-admin folks in those early years when they were upgrading to a new CPU when my Vice President would reply we don't need your CPUID; it's a site license; you can run MXG on anything there, including the coke machine! Also, since MXG was always to be source code distributed, keys would not provide any protection! The combination of the volatility of the input data to MXG that requires frequent updates, so we can verify your license is active, a price so low that it can't be undercut, so we can distribute the source, and users who know we are Children of the 60's, giving away the keys to the kingdom, so our users are friends as much as customers, has kept us truckin' for the past 27 years. And, on the rare occasion where a consolidation did create an unlicensed situation, payment for those missed years has always been forthcoming, and usually because the techie want to make sure WE were paid. But our primary goal has ALWAYS been to provide the tool set to keep our users employed and happy! Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com P.S. When the first Gulf War started, one of (or the one?) Australian aircraft carrier was hastily deployed, only to discover their SAS License had expired, leading to a hasty series of radio messages to/from SAS Oz to get the new key. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.13 ASCENV incompatible change in Assembler
My motivation for MY text in the original post was simply to alert IBM-MAIN subscribers of the incompatible change in the assembler in z/OS 1.13 that our users, who presumably HAD read the Migration Guide, had encountered, and after my search of the IBM-Main archives found no prior cites of ASCENV. My asmguy's explains his comments that I chose to include in my post: I wasn't really complaining about anything, I was just explaining (in my perhaps less than elegant way) that the change required does not modify the code and therefore does not require reassembly for someone already running MXGTMNT. This type of thing affects us more directly than those who only distribute load modules and/or object code. For them the customer would never see this and it is merely an internal annoyance, for us it means a new ML. (ML=Maintenance Level of MXGTMNT because MXG IS 100% SOURCE CODE). While I agree I can't defend either of the practices he states I will still maintain that regardless of whether or not the assembler is told that the system is not in AR mode during OPEN/CLOSE it still could be (due to some coding error or assumption that the assemble can't know) and if it is OPEN/CLOSE will still abend and nothing has been prevented or avoided. I personally would prefer a warning like You've specified that the system is in AR mode and this macro does not support that... are you sure this is correct? While this warning would still be best eliminated, it doesn't require an immediate new source code member replacement for someone who is just trying to assemble MXGTMNT Merrilly Christmas, Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Peter Relson Sent: Monday, December 19, 2011 7:11 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS 1.13 ASCENV incompatible change in Assembler While it is admittedly unpleasant to have the system start enforcing requirements that it has documented, and I'll grant that we don't often make such runtime enforcement changes, here we are talking about assembly where it should be fairly easy to address, and might well help avoid a problem (as might happen if your ARs or register high halves contained some unexpected value) I'm curious whether the complaint is: -- My SYSSTATE does not represent my actual ASC environment or AMODE (or ARCHLVL or OSREL for that matter, although ARCHLVL and OSREL are not relevant to the macro changes being discussed) yet I expect macros to generate proper code that I can rely on working and continuing to work -- My SYSSTATE does represent my actual environment and I am invoking a service in an environment it is documented not to support but that I expect to work and continue to work -- Something else Aside from the annoyance, would anyone really defend either of those first two practices? FWIW, it was probably already mentioned that this information was conveyed to ISVs and is present in the migration guide. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
z/OS 1.13 ASCENV incompatible change in Assembler
Change 29.280 -z/OS 1.13 ASM ERROR when assembling ASMTAPEE/MXGTMNT: ASMTAPEEYOU SPECIFIED ASCENV=AR OR ANY ON THE SYSSTATE MACRO. Dec 15, 2011 THE OPEN MACRO SUPPORTS ONLY ASCENV=P. But there is NO NEED to ASM a new load module under 1.13; your currently executing MXGTMNT module works just fine! -This IBM note (migration guide) is the ONLY clue of the incompatible change, which impacts OPEN/CLOSE macros, but doesn't mention any by name: DFSMSdfp: Accommodate 64-bit AR mode rules enforcement in DFSMS macros; required if you have code that invokes DFSMS macros (but not all!). Before z/OS V1R13, many DFSMS macros that did not support 64-bit or AR mode did not react to being invoked in 64-bit or AR mode, and generated code that might have been invalid in 64-bit or AR mode. Starting with z/OS V1R13, these macros are changed to issue an assembly-time message and suppress expansion if they are invoked in 64-bit or AR mode. -But as noted above, you didn't really need to ASM. Now, from MXG's asmguy, his comments on this change: Nothing is going to happen to an existing site using MXGTMNT and in fact the modification I have to make for this does not result in any change to the executable code. The SYSSTATE macro is an assembler directive - it sets a flag that tells any macros that support AR mode (Access Register, used for cross memory access) to use their AR mode compatible expansion. Macros that don't have an AR mode expansion used to ignore this because they had nothing to do, and it's always the coder's responsibility to make sure that when those non-AR compatible macros are executed, that the system is not in AR mode. This is similar to switching back and forth from 24-bit to 31-bit mode: some macros can't tolerate 31-bit mode. Nothing has really changed though; it is still the coders responsibility to make sure the system is not in AR mode and macros that can't tolerate AR mode still can't, except now IBM is requiring the coder to explicitly set SYSSTATE to indicate to the assembler that the system is not in AR mode. Of course this is all very silly because the assembler can't know ahead of time that the system is or isn't in AR mode. So regardless of whether or not SYSSTATE is coded this way the system still could be in AR mode, OPEN/CLOSE will still expand the same way, and if the system really is in AR mode OPEN/CLOSE will abend when executed. So the bottom line is that nothing has changed except our need to do something for no reason at all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Carts Created with RECFM=N
SAS supports RECFM=N only on ASCII platforms; it has never been a usable RECFM on z/OS platforms. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Linda Mooney Sent: Wednesday, December 14, 2011 12:17 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Carts Created with RECFM=N Hi Jim, I have never used RECFM=N, but in some SAS doc for statements under UNIX, I found this - RECFM=N binary format. The file consists of a stream of bytes with no record boundaries. If RECFM=N, the value for the LRECL= option must be at least 256. http://www.sfu.ca/sasdoc/sashtml/unixc/z1main.htm HTH, Linda - Original Message - From: Jim Marshall jim.marsh...@opm.gov To: IBM-MAIN@bama.ua.edu Sent: Wednesday, December 14, 2011 9:01:06 AM Subject: Carts Created with RECFM=N Doing a VTS migration and have run across some DSNs which were created with RECFM=N. We are using Tivoli Tape Optimzer software to do mass copies of files. It chokes on these RECFM=N files.IBM is telling us they do not support RECFM=N files and have no clue how these could be created. Tracked it back to the developer and he is puzzled at how these could have been created with RECFM=N. Has anyone ran across software products which might have outputed RECFM=N files. Any clues appreciated. jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Java apps have most flaws, Cobol is cleanest.
A couple of years ago at SHARE, in a mostly-Java-folks session, I asked the IBM speaker why Java architected Garbage Collection (which I first encountered in Basic on my TRS-80, when a ham radio logging program stopped for 6 minutes in the middle of a contest), and his reply was that that was done because Java programmers didn't know how much memory their program needed, so I asked if that meant that COBOL programmers were smarter than Java programmers. Barry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Sambataro, Anthony (NIH/NBS) [E] Sent: Friday, December 09, 2011 6:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Java apps have most flaws, Cobol is cleanest. I'm unclear as to whether the COBOL code had fewer errors or cost less to fix each problem, or both? -Original Message- From: Ian [mailto:pcs...@gmail.com] Sent: Thursday, December 08, 2011 4:53 PM To: IBM-MAIN@bama.ua.edu Subject: Java apps have most flaws, Cobol is cleanest. Interesting article on clean code study. COBOL scored the highest on security while .NET scored the lowest. Link to Computer world news article: http://www.computerworlduk.com/news/applications/3323819/java-apps-have-most -flaws-cobol-apps-least-study-finds/ (If the link does not fold right, follow the links from here: http://www.cicsworld.com/node/4252) Ian http://www.cicsworld.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What SMF record types and formats does ACF2 write?
Not all IBM-created SMF records are documented in the SMF Manual. Many only have a reference to their own product manuals; see the 115, 116, 120 WebSphere, 118, and 119 TCP/IP, examples. Other records point to a manual (100, 101, 102, DB2, DB2 Administration Guide) that contains no DSECTS - the DB2 records are only documented in the DSECTS in the MACRO LIBRARY for the product. And 110 for CICS points to the CICS Customization Guide, which only has partial information, and only for the subtype 1; the subtype 2 data is only documented in the DSECTS in the MACRO LIBRARY. Some vendor products don't have DSECTS but instead have open systems structures (or whatever they are properly called), and I recall that some records are only described in the language of the product (Natural comes to mind, I think). Ain't nothing straightforward about locating the description of ALL SMF records, but ultimately between the users and the vendors, MXG does claim to support every SMF record on the face of the earth. Merrilly Christmas to all. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould Sent: Tuesday, December 06, 2011 11:23 AM To: IBM-MAIN@bama.ua.edu Subject: Re: What SMF record types and formats does ACF2 write? Seymore, The SMF record layouts ar in a GC manual. This also has DFSORT and a few other PP record layouts. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What SMF record types and formats does ACF2 write?
SMF 80 support in MXG code is 8293 lines of SAS and creates 61 discrete SAS datasets/tables. ACF2 support in MXG code is 1395 lines of SAS and creates 12 discrete SAS datasets/tables. No, the records have nothing similar in field names nor record structure, although clearly there is overlap in some of the contents. No, I can't share the DSECTS, since they claim the same legal protection COPYRIGHT (C) 1988 COMPUTER ASSOCIATES INTL,INC. the protects MXG Software from being accessed or shared without a license. But I would think that if you contact CA's ACF2 Product Manager directly, and have a legitimate non-competing use that would benefit THEIR CUSTOMERS and CA, that they would provide you with the documentation that you need. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229-5112 214 351 1966 tel 214 350 3694 fax http://www.mxg.com ba...@mxg.com MXG Support: supp...@mxg.com MXG Admin: ad...@mxg.com Standard Answers: http://www.mxg.com/administration What's Supported: http://www.mxg.com/changes -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Charles Mills Sent: Monday, December 05, 2011 6:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: What SMF record types and formats does ACF2 write? Thanks all. Don't see this information on Cheryl's site, but perhaps I am not looking in the right place. I have a CA support ID. The record layout specifics do not seem to be in the ACF2 documentation. (If I'm wrong, can someone supply a specific manual name?) I have figured out that ACF2 may be configured as John indicates to use any valid SMF record type number, with a default of 230. I'm prepared to be, as John says, parametric. Let's try a new question that is not very proprietary: Does anyone know if ACF2's SMF (Type 230 or whatever) records are more or less the same as RACF Type 80 records? By more or less the same I mean are the layouts apparently identical, perhaps with some small exceptions? Or is it a completely different layout (with, of course, roughly comparable information)? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Gilmore Sent: Monday, December 05, 2011 1:46 PM To: IBM-MAIN@bama.ua.edu Subject: Re: What SMF record types and formats does ACF2 write? Cheryl's website has this information, properly labeled. The problem with all such numbers for non-IBM SMF records is that ISVs, very properly, supply a default record number but permit it to be overridden when its use would conflict with another, preexistent use of that number. The only not very helpful thing that can be said about any such 'user' SMF record number n is that n 127 is certain. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Last use date of a PDS member
As I stated PROCs invoked can be determined from SMF step records. Absolutely FALSE. The PROC NAME is not written in ANY IBM provided SMF record, and there is no user SMF record that MXG processes that contains the name of the JCL Procedure that was executed (several PROCNAME variables do exist, but they are for PROCESS NAME!). The step record does contain the procstep name, the stepname, and the program name, and it may be possible to examine those three fields, and, with knowledge of those values in your JCL proclib members, to infer what the PROCNAME was probably used, but with no guarantee of 100% accuracy. The MXGTMNT Tape Mount monitor can also write an SMF record for any SYSLOG event, so you should be able to use it to write each and SMF record for each IEFC0001 SYSLOG message to capture the name of the JCL Procedure, but I've not actually done so. Merrilly Christmas, Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229-5112 214 351 1966 tel 214 350 3694 fax http://www.mxg.com ba...@mxg.com MXG Support: supp...@mxg.com MXG Admin: ad...@mxg.com Standard Answers: http://www.mxg.com/administration What's Supported: http://www.mxg.com/changes -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Expiration date
As originally published in the JIR, The Journal for Irreproducible Research, from the Society for Irreproducible Research, at least three decades ago, comparing Oranges to Apples, to imply non-similarity is not valid; if you consider their mass, conductivity, specific gravity, density, energy content, moisture content, value per gram, and many other physical attribute they are far more similar than dissimilar. If you wish to compare apples, that original article suggest, do it with England, Envelopes, or Orgasms. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Saturday, December 03, 2011 8:47 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Expiration date In 7A64EE34BA2BDC4093CCA94CE3153E6F06767A@TMPEXCHMB06.enterprise.corpad.timein c.com, on 12/02/2011 at 04:43 PM, Hervey Martinez hervey.marti...@custserv.com said: Does anybody know as to what takes precedence under SMS, either an expiration date(on a disk dataset) or expire non-usage on a management class? Isn't that an apples to oranges comparison? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSIEFSD.Q4 resource
The lock on Q4 was bad for a tape mount, but in those old days, we had lots of mountable 3330 volumes, and those mounts, which always took minutes, since the tape librarian had to dismount the existing volume after it spun down, then go find the disk (and visit with Sally on the way) and then mount the new volume. And during this locked time, not only were no jobs initiated, no TSO user could issue a SAVE or EDIT a new dataset. We ran into this 360 issue when we first began to use TSO in late 72 or early 73, and fortunately, made the connection to the disk mount, and eliminated the lock by requiring all users of mountable 3330 packs to insert an IEFBR14 step to premount the volume with DISP=SHR which eliminated the lock. And this was one of the items in my first SHARE presentation in 1974. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Thursday, December 01, 2011 7:05 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SYSIEFSD.Q4 resource Hello experts, One question regarding to SYSIEFSD.Q4 resource: What is it used? Where can I find information about it? If a job tried to allocate a tape drive, will iOS tries to communicate with tape drive first before it can get share access of SYSIEFSD.Q4? Or allocation only related with software control block manipualtion? Have you tried to search this on the internet? Have you looked in the PLANNING FOR GRS type manuals on IBMs website? A quick search turned up the following short answer snip Mon, 02 Oct 2006 10:54:27 -0700 This has been a problem of varying severity ever since OS/360 Release 10 back in 1967 or so. I think Q4 is/was the UCB resource - but SYSIEFSD Q4 and Q5 were locked during OS/360 allocation - the most egregious form being an AVR tape mount, which blocked all other initiator processing. (also from an IBM Apar OA12454 Nov 7 2006) The VARY OFFLINE command is changed to wait for 5 seconds for the SYSIEFSD.Q4 resource to be obtained. If it is not obtained within 5 seconds, the request for the resource is cancelled to allow stalled Allocations to proceed. New message MSGCNZ0010A is issued to indicate that the command is delayed. VARY will then request SYSIEFSD.Q4 again and repeat the wait/cancel/reobtain processing until the resource is finally obtained. The IEEVARYD offline service is also changed in the same way as the VARY OFFLINE command. However, for IEEVARYD callers that cannot tolerate a delayed return from the service, a new flag, VDEV_DO_NOT_WAIT_FOR_ENQ, can be set so that the IEEVARYD service returns to the caller if the SYSIEFSD.Q4 resource cannot be obtained within 5 seconds. In this case, register 15 will contain a new return code, RC0C, on return from the IEEVARYD service. The caller of the service can choose to retry the IEEVARYD request if appropriate. end snip Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Last use date of a PDS member
Scanning SYSOUT was actually an IBM plan prior to SMF. From my length article The History of SMF' on the 20th Anniversary of SMF (http://www.mxg.com/newsletters) in Newsletter FIFTEEN (1989): IBM'S MOTIVATION FOR DESIGNING SMF: 1. User need to account time and resource usage. 2. IBM's need to know about how the system was being used, especially about which IBM Programs were used how much/often. A SYSOUT Project had already been started inside IBM. Originally the idea was to solicit customers to submit their SYSOUT on tape, which would then be analyzed after the fact (for compiler messages, link editor, etc.) to count program usage! Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bill Fairchild Sent: Thursday, December 01, 2011 7:16 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Last use date of a PDS member What constitutes using a PDS member? When should a PDS member's access be audit-trailed? [1] The reason for some accesses seems to be more important uses than others. E.g., if a PDS member contains JCL and it is read for the purpose of starting an address space, constructing a job to be submitting into a JES, expanding a cataloged procedure, etc., then this would appeal to some users as justification for writing an SMF record, or at least putting the member name in a field in an SMF record. Likewise, using a macro or copy book at compile time seems a compelling use of the PDS member involved. At least the Assembler documents the use of such PDS members in the cross-references produced at the end of the SYSOUT for each Assembly. If such SYSOUTs were saved, then they could be scanned for particular macro names, and thus writing SMF records in this case would be redundant (although a saved SYSOUT takes a lot more storage space than a saved SMF record). Executable programs and pieces of programs are stored in PDS members, and their use typically involves an e! xecuting program, which might make this usage important enough to be documented. And object modules used in linking and building new executable modules should be given the same importance as the use of macros and copy books by compilers. But what about copying a PDS? Are its members being used? What about compressing a PDS in place, or compressing while copying elsewhere? The members are not really being used for any productive purpose, but probably in a housekeeping operation to reclaim unusable disk storage. Each member is not really being changed when it is copied, as the copy is logically identical to the original, but the metadata describing the entire member and the metadata surrounding each piece of the member are changed when its pieces are written to new disk locations. And metadata within the member's directory entry, as in the case of a load module, may change if the load module is copied to a new disk location. If a PDS member is deleted, has that member been used? When a member is deleted, often a large number of other members in the same PDS must have their metadata (directory entries) changed. Are these other members being then used when the directory is being updated to reflec! t the removal of one entry from its middle and all entries after that point must be shifted towards the front of the directory? Or is only the directory itself being used when the directory is compressed, expanded, or copied? What about an ISPF 3.14 scan of a vast library for all occurrences of a character string? Is this a use of each member? Maybe a member's access in which a string is found is important enough to document but not that of the members not containing that string. Yet all the members were accessed and thus used, FSVO use. Then there are SMP libraries. Oy vey. Each of these many different uses of a PDS member would require different logic placed in different system components to effect an audit trail, which would explain why there is no simple solution for logging any use of a PDS member. Bill Fairchild Rocket Software, Inc. [1] I believe this is the first time I have ever verbed a noun all on my own authority. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF Records
If you have SAS, there is a very powerful but also trivial technique to read any file and only keep the records with a desired string of text, // EXEC SAS //SMF DD //SMFOUT DD DATA _NULL_; INFILE SMF; INPUT @; IF INDEX(_INFILE_,'LOOKFOR') GT 0 THEN DO; FILE SMFOUT DCB=SMF; PUT _INFILE_; FILE LOG; END; Will write to SMFOUT only records containing LOOKFOR text string. For MXG users, the (new) SMFSRCH program in 29.07 enhances this technique to select records, by then reading those selected records to create all possible MXG datasets from those SMF records, but then goes further to filter and keep only the individual observations that have that text string in a variable in a created dataset. Why? Consider an SMF 30 step termination record that contains that string. MXG creates multiple datasets, in particular, TYPE30_D that has an observation for each DD segment. But if the LOOKFOR string was a USERID, TYPE30DD doesn't have the userid field, so those observations can never have the LOOKFOR text and thus the TYPE30_Deated from thosd selected records are NOT kept, but the TYPE30_4 dataset with step term info will be kept if they have that USERID name. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ravi Gaur Sent: Tuesday, November 29, 2011 11:37 PM To: IBM-MAIN@bama.ua.edu Subject: SMF Records Does anybody give me idea how can i copy only the smf records from given dataset which does contain a particular string(dataset name) ..well while dumping using ifasmfdp i used (0:255) now need to figure out the dataset name I am looking is associated with which smf records..since as i thought it may be 14/15 it does however want to know what other records are associated with it.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: units (was: Out damn'd GMT ...)
A one kilogram fig, undergoing an acceleration of one meter per second per second could aptly be called a fig newton. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Friday, November 04, 2011 3:00 PM To: IBM-MAIN@bama.ua.edu Subject: Re: units (was: Out damn'd GMT ...) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Friday, November 04, 2011 2:52 PM To: IBM-MAIN@bama.ua.edu Subject: units (was: Out damn'd GMT ...) snip Go to your hardware store and ask to buy a rope with a load-bearing strength rated in newtons. All terracentric thinking. -- gil My stomach strength is measured in fig newtons! -- 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...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Data offload to DVDs or external drives
With the reference to moving data files from z/OS to an ASCII platform and intending to read that archived data, for any binary file, that is, a file that can contain non-pure-text data, the PGM=FTP on z/OS will delete ALL of the BDWs and RDWs from any dataset with RECFM=V or VB or VBS, and you end up with a serial file of bytes of binary data, on your PC, with no way to know where a record started or ended. You must use specialized JCL around your PGM=FTP to preserve the BDWs and RDWs Example i., below), or use PGM=IEBGENER to create a block-for-block copy of the z/OS file, but with RECFM=U (Example iv. below), since RECFM=U prevents PGM=FTP from mucking about with the BDWs and RDWs). i. ftp instructions for sending data to the MXG ftp site Using the IBM ftp program, you can ftp any MVS data file to the MXG ftp site with this syntax; do NOT change the DCB attributes of the //SMFFILE DD: even though it points to a VBS DSNAME, the RECFM=U,BLKSIZE=32760 must be used to include BDW and RDWs. //FTP EXEC PGM=FTP,PARM='(EXIT=4' //SYSPRINT DD SYSOUT=* //OUTPUT DD SYSOUT=* //SMFFILE DD DSN=YOUR.SMF.DATA,DCB=RECFM=U,BLKSIZE=32760,DISP=SHR //INPUT DD * ftp.mxg.com userid password quote PASV bin put //DD:SMFFILE yourname.smf close quit /* IMPORTANT: userid/password may be mixed case do NOT change the DCB attributes of the //SMFFILE DD. This ftp can be used for MVS files with RECFM=U,F,FB,V,VB, or VBS, but for F/FB files, please email us the LRECL value of each file. The SYSPRINT output will tell you if the ftp transfer succeeded or not; in a production environment, you probably want a Return Code set if there was any error; the syntax for the IBM ftp program to set Return Code 12 on any error is //FTP EXEC PGM=FTP,PARM='FTP.MXG.COM (EXIT=12' iv. If you simply try to ftp a V/VB/VBS file, it will be unreadable because when PGM=FTP sees those RECFMs, it shows how smart it is and sends only the data, stripping the BDW and RDW. The previous PGM=FTP with its special references solves that problem. But an alternative is to create a RECFM=U copy of the V/VB/VBS file, and then that copy can be ftp'd and the BDW/RDW will be preserved. // EXEC PGM=IEBGENER //SYSUT1 DD DSN=YOUR.VB.FILE,DISP=SHR,RECFM=U,BLKSIZE=32760 //SYSUT2 DD DSN=YOUR.NEW.RECFMU,DISP=(,CATLG),RECFM=U, // BLKSIZE=32760,UNIT=SYSDA,SPACE=(CYL,(50,50)) //SYSIN DD DUMMY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Checking CRITICALPAGING status for an AS
I'm not sure if this is what you're looking for: SMF30PF1: X'01' (SMF30CSP) Service class assigned to the address space was designated storage-critical in the WLM service definition. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe article
I didn't check all of the postings under this thread, but all of the buttons cited are viewable, and most credit the author and many have some history, at http://www.mxg.com/thebuttonman plus there is the parody recording of Hoyt Axton's Boney Fingers, new words written by Anne Ashley and Dave Thewlis, and played at the very first VS2 Performance session at SHARE in 1975. Barry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IFCID Product section layout
You have to start at the offset to the header section(s), read it's length (always 2 bytes) and the header type, (first is the always-present standard header), then test that there is more data present (headers are at the END of the physical record) and if so, read the next header's length and type, decode it, etc, until you've exhausted the record length. Or, you can use MXG Software to do this for you. Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF timestamps
There are MANY datetime values in SMF records, and in MANY formats. The 8-byte SMFSTAMP format with time to 2 decimals and Julian date is used not only in the standard timestamp in the SMF header bytes 3-10, which is ALWAYS on the LOCAL time zone, but SMFSTAMP8 is used for many other datetime values, especially in the job-related records, like the READTIME. However, some of the job event records contain only the four-byte time so their datetime values must be inferred from the Date part of READTIME or SMFTIME (notable, INITTIME and ALOCTIME in the 30s are only provided as LOCAL times without a date). There are 634 datetime fields that are input with SMFSTAMP8 in MXG Software). I believe all of these SMFSTAMP instances in SMF records are on the LOCAL time zone, although any vendor can write any SMF record with any value in that format. However, there are many other instances of datetime values that are written in 8-byte TODSTAMP format, (1145 instances in MXG) and I believe they are all on the GMT/UTC Time Zone, although there are instances of two TODSTAMP values in some records, with one on LOCAL and the other on GMT. And there are some really strange-looking character date and time and datetime values scattered throughout SMF data, especially for newer records that may come from opensystems sources. In many SMF records, the GMT Offset value (CVTTZ) is provided, but by no means is it always present; in some records, there may be two datetimestamps for the same event that can be compared to determine the GMT offset, but that can require fuzzy logic, for example in the SMF 30s, since SMF30IST is in SMFSTAMP8 format, rounded, and with 10 millisecond resolution, while it's GMT event counterpart, SMF30ISS is in TODSTAMP format with microsecond resolution. And, SMF30ISS only exists in the Subtype 2 and 3 Interval Records. And, SMF30IST does NOT exist in the MULTI-DD records, which contain only the ID and EXCP segments (for steps/intervals with more DDs that will fit in a single 32K SMF record). And, some SMF vendor-created records have only GMT fields, and in the long past, there were user-written records with the header SMFTIME in GMT, but I've not seen that in the current millennium. So, it ain't simple, and each record can only be examined for its specific contents. Merrilly yours, Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com P.S. Long ago, I had discussions with IBM SMF developer Bill Richardson for a proposed extension to every SMF record precisely to contain the GMT OFFSET, since expanding the SMF header would have been a VERY incompatible change to the many programs that read SMF with expected fixed field locations, but because many records do not contain a version number, causing the length of the record to be required to determine version (e.g., JES 26 records), that extension was never implemented. P.P.S But there is currently a SHARE Requirement in development that is looking at a suite of fields that are needed for all JOB-related records, for cost-recovery, including JCTJOBID, ACCOUNTn, and SYSPLEX, so the addition of the GMT Offset might be a future consideration, if IBM reviews that requirement in a favorable light. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cobol and large QSAM record length
While I'm no BSAM/QSAM expert, and while it is possible to create sequential files with LRECL=32767, I do know that very few, if any, applications, other than perhaps a rose-colored ASM program, can actually process that record length. VBS records written to SMF are limited to LRECL=32760 and exceptions to that LRECL for IBM records have been APARed and corrected in the past. VB records are limited to LRECL=32756. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Last card reader?
Related: when did IBM create the last IBM cards? I believe that the plant in Greencastle, Ind was supposed to be the creator of all (USA?) card blanks. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF hierarchy
I am NOT anything close to a RACF expert, but I think the IRDBU00 utility program unloads all of the RACF definitions, and (SALES CAP ON:) MXG Software reads those data to create the below individual SAS tables (a/k/a SAS datasets) that can readily be imported into Excel. SALES CAP OFF. /* RAC100 RACF0100 GROUP BASIC DATA PDB */ /* RAC101 RACF0101 GROUP SUBGROUPS PDB */ /* RAC102 RACF0102 GROUP MEMBERSPDB */ /* RAC103 RACF0103 GROUP INSTALLATION DATA PDB */ /* RAC110 RACF0110 GROUP DFP DATA PDB */ /* RAC120 RACF0120 GROUP OMVS DATA PDB */ /* RAC200 RACF0200 USER BASIC DATA PDB */ /* RAC201 RACF0201 USER CATEGORIES PDB */ /* RAC202 RACF0202 USER CLASSES PDB */ /* RAC203 RACF0203 USER GROUP CONNECTIONS PDB */ /* RAC204 RACF0204 USER INSTALLATION DATA PDB */ /* RAC205 RACF0205 USER CONNECT DATAPDB */ /* RAC210 RACF0210 USER DFP DATAPDB */ /* RAC220 RACF0220 USER TSO DATAPDB */ /* RAC230 RACF0230 USER CICS DATA PDB */ /* RAC231 RACF0231 USER CICS OPERATOR CLASSES PDB */ /* RAC240 RACF0240 USER LANGUAGE DATA PDB */ /* RAC250 RACF0250 USER OPERPARM DATA PDB */ /* RAC251 RACF0251 USER OPERPARM SCOPE PDB */ /* RAC260 RACF0260 USER WORKATTR DATA PDB */ /* RAC270 RACF0270 USER OMVS DATA PDB */ /* RAC2A0 RACF02A0 USER OVM DATAPDB */ /* RAC400 RACF0400 DATA SET BASIC DATA PDB */ /* RAC401 RACF0401 DATA SET CATEGORIES PDB */ /* RAC402 RACF0402 DATA SET CONDITIONAL ACCESS PDB */ /* RAC403 RACF0403 DATA SET VOLUMES PDB */ /* RAC404 RACF0404 DATA SET ACCESS PDB */ /* RAC405 RACF0405 DATA SET INSTALLATION DATA PDB */ /* RAC410 RACF0410 DATA SET DFP DATAPDB */ /* RAC500 RACF0500 GENERAL RESOURCE BASIC DATA PDB */ /* RAC501 RACF0501 GENERAL RESOURCE TAPE VOLUME PDB */ /* RAC502 RACF0502 GENERAL RESOURCE CATEGORIES PDB */ /* RAC503 RACF0503 GENERAL RESOURCE MEMBERS PDB */ /* RAC504 RACF0504 GENERAL RESOURCE VOLUMES PDB */ /* RAC505 RACF0505 GENERAL RESOURCE ACCESS PDB */ /* RAC506 RACF0506 GEN RES INSTALL DATA PDB */ /* RAC507 RACF0507 GEN RES CONDITIONAL ACCESS PDB */ /* RAC510 RACF0510 GEN RES CONDITNL SESS DATA PDB */ /* RAC511 RACF0511 GEN RESRC CONDITNL SESS ENTITY PDB */ /* RAC520 RACF0520 GEN RES CONDITNL DLF DATAPDB */ /* RAC521 RACF0521 GEN RES DLF JOB NAMESPDB */ /* RAC540 RACF0540 GEN RES STARTED TASK PDB */ /* RAC560 RACF0560 GEN RES CERTIFICATE DATA PDB */ /* RAC561 RACF0561 GEN RES CERTIFICATE REFERENCEPDB */ /* RAC562 RACF0562 GEN RES KEY RING DATAPDB */ /* RAC5C0 RACF05C0 GEN RES CDTINFO DATA PDB */ /* RAC900 RACF0900 USS RACF BASIC RECORDPDB */ /* RAC901 RACF0901 USS RACF FILE ACCESS PDB */ /* RAC902 RACF0902 USS RACF DEFAULT ACCESS PDB */ /* RAC903 RACF0903 USS RACF DIRECTORY DEFAULT ACCESSPDB */ /* RACID RACFIDRACF IRRDBU00 RECORD COUNT PDB */ Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Finding abnormal events
SMF 30 subtype 5 won't report abends; PROGRAMs abend, not JOBs, and the subtype 4 must be used to identify PROGRAMS that abended. The contents of the 30 subtype 5 might reflect an abend in the LAST step, but not the CONDCODE nor ABEND type. From MXG Documentation in its ADOC30 member: Jobs do not abend, steps do. If the last step executed had an ABEND, this field in TYPE30_5 will have meaning, but if there were flushed steps after an abending step, this field could contain the indication of an ABEND, but the variable CONDCODE in TYPE30_5 will be blank, as only the TYPE30_4 record for the ABENDING step will have the actual condition code associated with the ABEND. Thus all ABEND analysis must be done from the TYPE30_4 (or its PDB equivalent, PDB.STEPS). Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FW: Mysterious Email (original had no subject)
PROFS was Ollie North's downfall Actually, it was the site's VERY GOOD backup philosophy that kept backups long-term, and the PROFS implementation at that site that when the user deleted a message, it wasn't deleted. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MFNetDisk another dramatic performance improvement
Shai: 1. Deliver your product in Source Code and price it so low your competitors can't undercut it (works for me!). 2. Place your source code in escrow with instructions to pass it to the CBT tape or other open source group if you have no replacement. Merrilly yours, Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An upbeat story
In the early 70s, State Farm ramped up its Application Development to PL/1 and hired a massive number of new programmers (in excess of 1000, I think), and sent them thru a 9 week course, and those that learned well were hired. The analysis of the chosen found that the key factors were that they had backgrounds or skills in musical instruments, or were competent in multiple spoken languages, or were strong in math, or had engineering skills, especially Electrical Engineering. Very few were computer science majors. Herbert W. Barry Merrill, PhD (in EE, of course!) President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSLOG saving
Dunno what zip you guys use, but I zipped a 171 Million byte file into 14 Million bytes, for a 12.2 compression ratio, which is what I would expect for pure text with lots of blanks. I typically see 6 or 8 to one for more complex data like SMF. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 2107 - alpha serial number
I believe that CUSERIAL, at least in SMF 74 records, has always been 12 EBCDIC characters, substring-ed from R745CCMT starting in byte 15. Barry Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU consumption - how to measure it?
See MXG Newsletter TWENTY-THREE, at http://www.mxg.com/newsletters for the article titled: 6. MVS/ESA Resource Accounting, Cost Transfer, and Billing Issues While originally written/presented in 1993, it has been updated internally many times, and is accurate for z/OS now; it also includes the impact of the OTE environment on DB2 CPU accounting. Merrilly yours, Barry Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IKJEFT01
I know that, in the past, TSO in Batch only executed commands that used
GETLINE/PUTLINE,
and that any command that instead used GET and PUT caused the input stack of
commands
to simply stop at that command. I don't know if this is still true, but if
the command
doesn't execute, perhaps it's still true.
Barry Merrill
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Barkow, Eileen
Sent: Tuesday, May 03, 2011 8:39 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IKJEFT01
If you mean that you want the commands to run from a job stream, then just
run a clist from batch or invoke the IKJEFT01 Module passing it the name of
the clist to run in the first parameter and pass parms to the clist in the
following parms:
/***
/TSO EXEC PGM=IKJEFT10,
/ PARM=('CLIST PARM1 PARM2'),
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Bill Johnson
Sent: Tuesday, May 03, 2011 9:14 AM
To: IBM-MAIN@bama.ua.edu
Subject: IKJEFT01
I'm trying to run a TSO command using IKJEFT01 but I want the command to
work on a dataset. Possible?
TIA
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
3480 Cartridges available
I found four 30-each unopened boxes of new 3480 tape cartridges that are probably 10 years old, and I'll be glad to UPS Ground to anyone who can use them. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DATACLASS
It's all a matter of attitude; I turn 70 on April 19th, but that's only 21 Celsius. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Service Class zIIP CPU Time
If the Specialty Engine is faster than the CP engine, the normalized CPU time for the Specialty Engine can easily exceed the wall time. From MXG Newsletter FIFTY-TWO from 2008, although the variable names are MXG-Specific: 12. zIIP and zAAP measurements when they are faster than CPU engines. When specialty engines are faster than the speed of your CPs, there is a normalization factor to convert the recorded seconds to their NORMALIZED (EQUIVALENT) time, as if they had executed on your CPs. In all MXG workload datasets, TYPE72GO and RMFINTRV, (and TYPE30), (and DB2ACCT), all time variables for zIIPs and zAAPS are NORMALIZED seconds, and all of the service units are segregated by engine type. However, the IBM RMF reports present these data quite differently. This system has the normalization factor, R723NFFS=569/256=2.222, that is, one second of zIIP is equal to 2.222 seconds of CP time. MXG Dataset TYPE72GO dataset values: SERVICE CPUUNITS ZIPUNITS CPUTCBTM CPUZIPTM 3,932,0911,793,9202,137,167 178.92 213.16 RMF WORKLOAD REPORT: Under SERVICE TIMES, the RMF CPU value of 392.9 seconds is the total of the real CPU time on CP engines, plus the NORMALIZED CPU time on the zIIP and zAAP engines; it is NOT the CPU TCB time. ( 392.9 = 178.92 + 213.16RMF CPU = CPUTCBTM + CPUZIPTM ) But also under SERVICE TIMES, the RMF IIP (zIIP) value of 96.1 seconds is the UN-NORMALIZED, raw, seconds on the zIIP engine. And the RMF AAP value for zAAPs is also the UN-NORMALIZED value. And under SERVICE, the RMF CPU value of 3931K is the TOTAL SERVICE units from CPs, zIIPs, and zAAPs. REPORT BY: POLICY=OWLWORKLOAD=CSSDDF TRANSACTIONS---SERVICE SERVICE TIMES ---APPL %--- AVG 0.23 IOC 0 CPU392.9 CP 4.98 MPL 0.23 CPU 3931K SRB 0.0 AAPCP 0.00 ENDED 51 MSO 0 RCT 0.0 IIPCP 0.07 END/S0.01 SRB 0 IIT 0.0 #SWAPS 0 TOT 3931K HST 0.0 AAP N/A EXCTD 0 /SEC 1092 AAP N/A IIP 2.67 AVG ENC 0.23 IIP 96.1 While the workload datasets have normalized CPU time, in all of the hardware datasets, TYPE70, TYPE70PR, ASUM70PR etc., the CPU times for the zIIP and zAAP engines are the raw seconds of CPU Dispatch Time on those engines, and is NOT normalized. As a result, then, the total ZIPACTTM recorded in TYPE70 for the above system for the day was 10,887 seconds, but the total CPUZIPTM in TYPE72GO for the day was 23,079 seconds. Those 10,887 raw hardware seconds would be 24,190 normalized seconds so the zIIP capture ratio at this site is 23079/24190 = 95.4%. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: creating mainframe bookmanager from pdf documents???
You can search all pdf documents in a directory; open any pdf document and then use CTRL-SHIFT-F to open the SEARCH WINDOW that lets you select the directory and search all pdf's in that directory. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer ba...@mxg.com Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3694 fax www.mxg.com technical: supp...@mxg.com admin: ad...@mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
FW: Adding Lines to End of Member
You've got SAS; use IEBUPDTE to create a sequential file, and then add the two extra lines with this SAS program, then rebuild the new PDS with IEBUPDTE: DATA; INFILE IEBUPDTE END=END; INPUT CARD $80.; IF ( CARD=:'./' and _N_ GT 1 ) OR END THEN DO; FILE NEW; PUT 'line 1 text '; PUT 'line 2 text '; FILE LOG; END; FILE NEW; PUT CARD $80.; Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: digitize old hardcopy manuals
The best pdf freeware I just recently found is in the Adobe/Acrobat pdf reader itself: if you open any pdf document, and then press CTRL-SHIFT-F, you get a pop up Search window that lets you search for text in all pdf files in the directory you navigate to. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IFCID trace header error
Where in the sequence of triplets is this triplet located, and what is the count of triplets in the record. Some records have more physical triplets, always, but only populate the first n for some events, more n's on others. The existence of a COUNT field is the ONLY guarantee that the segment exists; the LENGTH field is now very frequently zeros in the triplet, which only means that the true length is in the first two bytes pointed to by the offset. Merrilly New Year, Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF30 step termination time
It all depends on what you mean by STEP Termination Time. There can be multiple SMF 30 subtype 4 records written for a step termination event, when there are more DDs that can fit in a 32K SMF record. The SMFTIME (SMF30DTE/TME) of each of those multiple records is the actual time when the record was put in the SMF buffer, so you can see how long it takes to write these multiple records. It can take minutes of CPU and Elapsed time. It is the datetime in SMFTIME of the FIRST subtype 4 record that I must use for the Step Termination time, TERMTIME, with the meaning that this is the time when the USER'S program terminated its execution and gave control back to the operating system. (The real terminate was slightly earlier than the time of the first subtype 4, but it's as close as we've got.) But when there are multiple records, it's only after that last record has been written that the system is really finished with this step, so maybe it is that last SMF 30 subtype 4 timestamp you want to use to now the full lifetime of that step. It all depends. Merrilly Christmas, Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Field that contains timestamp of when current jobstep started?
The Allocation time and Program Load time do NOT have dates in the SMF 30 record; only those times. The Initiate time does have its date field, so the (MXG) construction of the Allocation date-time value uses the Initiate date and a comparison of Init/Aloc times to determine if the allocation occurred on the same date as the Initiate, and then repeated logic for the Program Load Date. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: does an UCB include any info on how many systems the given device is online?
RMF 74 records from all systems contain an ONLINE bit that could be used to count, if you have all of the system's SMF 74s. That could be a lot of data, and you'd only know at the granularity of your RMF interval duration. Barry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Processing Compressed SMF Records with MXG
I changed the subject from the How Log For SMF to Switch to answer the question posed in that thread with regard to MXG and it's handling of compressed SMF records from CICS and (new in V10) DB2: For sites executing on z/OS, MXG 28.07 provides the ASM code in member EXITCICS to create a SAS Infile Exit that decompresses the SMF 110-1 CICS records and the SMF 100,101, and 102 DB2 records, transparently, once the load module is created and stored in a STEPLIB, and MXG is informed the exit exists with //SYSIN DD * %LET SMFEXIT=CICS; to enable MXG to use that decompression infile exit. In addition, if the infile exit is not installed on z/OS, or if MXG is executed on ASCII SAS (which does not provide Infile Exits), the compressed records are transparently processed using an internal SAS code algorithm, which, unfortunately is VERY CPU EXPENSIVE on z/OS. (So expensive MXG prints ERROR messages when the internal algorithm is used on z/OS where the EXITCICS algorithm should be used.) On z/OS, for CICS, the IBM utility DFH$MOLS will decompress the SMF 110 subtype 1 records, but there is (at present) no IBM utility that decompresses the DB2 V10 SMF records. The below note from the NEXT MXG NEWSLETTER www.mxg.com/newsltrs compares processing of compressed CICS SMF records. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75229 ba...@mxg.com http://www.mxg.com admin questions: ad...@mxg.com technical questions: supp...@mxg.com tel: 214 351 1966 fax: 214 350 3694 1. Processing Compressed CICS data on z/OS and on Windows. An SMF file of 125,712 ID=110 records that created 267,899 CICSTRAN transactions was 212 MB when IBM Compression was enabled, and was 970 MB when uncompressed by the IBM utility DFH$MOLS. The example JCL for CICS decompression is in new DFH$MOLS member in MXG 28.06. On z/OS, three alternatives exist to process compressed CICS data: a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED. b. Use EXITCICS (SAS Infile Exit) to read COMPRESSED WITH EXIT. c. Use MXG's internal SAS code to read COMPRESSED WITH INTERNAL. Average 7 runs:ElapsedTCBSRB EXCP Connect Size (min)(min) (min) (sec) a. DFH$MOLS.8 .07.00 53158 11.2 212/970 UNCOMPRESSED 2.0 .62.01 47934 11.3 970 MB total 2.8 .69.01 101092 22.5 b. COMP WITH EXIT 2.3 .70.00 145495.7 212 MB c. INTERNAL SAS 22.4 9.88.00 145545.7 212 MB As previously reported, the INTERNAL SAS algorithm on z/OS is VERY CPU intensive (and it takes a long time, too!). DFH$MOLS and read UNCOMPRESSED is only slightly slower than reading COMPRESSED+EXIT, but the uncompressed file needs nearly 5 times the disk space for the (temporary) uncompressed file, and I/O activity with DFH$MOLS (read compressed, write uncompressed, then read uncompressed) took six times the EXCPs and four times the IOTM (Connect Time), so the reading of the compressed file with the EXITCICS exit is best. On Windows/ascii platforms, SAS Infile Exits do not exist (and, if they existed, the ASM code in EXITCICS couldn't execute on ASCII), so if the SMF data file is downloaded and then processed, there are only two ways to process compressed CICS data: a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED. c. Use MXG's internal SAS algorithm to read COMPRESSED NO EXIT. Elapsed User SYSSize a. DFH$MOLS.4 .07.00 212/970 ftp download 2.0 .04.00970 MB UNCOMPRESSED.4 .23.05970 MB total2.8 .34.05 c. ftp download 2.0 .04.00212 MB INTERNAL SAS 3.8 2.71.05212 MB total5.8 2.75.05 The internal algorithm on Windows is only ten times as CPU intensive reading the compressed file, compared to reading uncompressed, but a lot more disk space is needed for the uncompressed file. Unfortunately, at this test site, we were not able to use the SAS ftp access method on ASCII to read the uncompressed and compressed files directly from z/OS, without download, for that comparison, but prior tests using the access method to directly read z/OS files have always been cheaper and faster than reading the downloaded files, so I would expect that if you can tolerate the temporary disk space on z/OS for the uncompressed file, using DFH$MOLS first would be best. -- For IBM-MAIN subscribe
Re: jcl vs pgm call
The part of file allocation that has significant cost is basically the same whether the allocation is via JCL or dynamic allocation. While the true cost in CPU seconds for a dynamic allocation might be exactly the same as for a static allocation, where those CPU seconds are recorded in RMF and SMF are quite different. The Initiator CPU time records the CPU time for allocation of all of a step's static DD statements (CPITCBTM/CPISRBTM/SMF30ICU/SMF30ISB). This is the CPU time from initiate until PROGRAM FETCH loads the program at LOADTIME, and includes the cost of the ACS allocation rules, static allocations, static HSM recalls, and possibly VAM and SMS Trace. But these Initiator CPU time also records the CPU time for creation of and writing out of the SMF records, which occurs after program terminate and before SMFTIME. -The Initiator CPU time is ONLY recorded in SMF 30 records, and only in the Step Terminate records. -They are NOT recorded in SMF 30 Interval records. -They are ONLY recorded in SMF 30 Termination records. -THEY ARE NOT RECORDED IN RMF TYPE72GO Service/Reporting Class records. -They are NOT shown in any IBM messages printed on the Job log. Instead, the CPU time for dynamic allocations occur after the step's program has been loaded, so that CPU TCB/SRB time will be recorded in the normal CPUTCBTM/CPUSRBTM/SMF30CPT/SMF30CPS CPU time variables, which ARE recorded in SMF 30 interval and termination records, and in RMF 72 service classes. So comparing dynamic to static allocation requires looking at all seven CPU times in the two step's type 30 termination records. Note that prior to z/OS 1.12 there was only one TCB and one SRB bucket for the Initiator CPU time, which contained both the INIT and TERM CPU times. In z/OS 1.12, the SMF 30's now contain four new CPI buckets, a TCB/SRB pair for the 'INIT' time, and a pair for the 'TERM time, so you can get much closer to the cause of high CPI times. This will make it possible to assign these CPI CPU times into the correct interval when they were consumed, and thus can be used to improve capture ratio metrics. But: CPI CPU times are NOT captured in RMF type 72 subtype 3 records, so if you use the CAPTURAT in RMFINTRV (or compare 70 to 72 Service Class), it does NOT include any of the CPITCBTM/CPISRBTM, which must be considered if you are concerned with low RMF capture ratio. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: eliminate the duplicate SMF records
From my class notes: What Causes Duplicate SMF Data? Must have a software/hardware failure followed by human error. When IEAFSMDP program fails, you must determine where it failed a. First phase, copies (dumps) data from VSAM to BSAM file. Must delete the BSAM output from failed run if IFASMFDP fails in this First phase. Then rerun IEASMFDP. b. Second phase, writes EOF in each VSAM block Dumped data is good if IFASMFDP fails in this Second phase. Rerun IEASMFDP with only CLEAR option (to write EOFs). c. How to tell where failure occurred, first or second phase? If the last physical record on output BSAM is ID=3 (Trailer) then First phase completed successfully, ELSE NOT. MXG Users can give this program to tell Operations in which Phase the IFASMSDP program failed: %INCLUDE SOURCLIB(VMACSMF); DATA; _SMF IF ENDOFSMF AND ID=3 THEN PUT 'FAILED IN 2ND PHASE'; ELSE IF ENDOFSMF AND ID NE 3 THEN PUT 'FAILED IN 1ST PHASE'; d. MXG prints each Header (02) and Trailer (03) SMF time on log Plus time of first and last record in each Chunk. Can see how the SMF dump tape was created. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FW: The meaning of SCIDS.
The true facts, verbally to me, from Tom Steele, SHARE Historian, and Mort Bernstein, Founder, in 1980 when I was documenting my collection of SHARE buttons for the SHARE 25th Anniversary Button Show in Atlanta, GA. When SHARE started, there was no fee nor organization, so there was no funding for a reception in the evening, and as many of the attendees then were military or government, they couldn't just put - booze - on their travel expenses, but they could be reimbursed for an official, but special session, that charged admission. So an official evening session was added to the agenda: Session Concerning Interdisciplinary Studies SCIDS as the official name with a $5.00 fee. But Tom and Mort both said that that name was created as an afterthought, for the agenda, as the TRUE NAME of Session Containing Inebriates, Drunks, and Sots. had always been what SCIDS stood for. I believe that fee was only charged once or twice, as SHARE became more organized with an attendance/membership fee. My BUTTON 792 note says this took place in 1958. The ButtonMan at SHARE. http://www.mxg.com/thebuttonman Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75229 ba...@mxg.com http://www.mxg.com admin questions: ad...@mxg.com technical questions: supp...@mxg.com tel: 214 351 1966 fax: 214 350 3694 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 Control Block
There is extensive information on NJE jobs in the TYPE 26 JES2 Purge Record, since there is a purge record created every time any job leaves any node for any purpose. While the data may not be left on the SPOOL dataset, you can identify which node and job numbers in these SMF fields: EXECNODE='NJE*EXECUTION*NODE NAME' /*SMF26NXM*/ LASTNODE='LAST*NODE*NAME'/*SMF26NLM*/ NEXTNODE='NEXT*NODE*NAME'/*SMF26NNM*/ ORIGJBID='ORIGINAL*JOB*IDENTIFICATION' /*SMF26NJB*/ ORIGNODE='ORIGIN*NODE*NAME' /*SMF26NON*/ SYSTRANS='JOB*TRANSMITTER*SYSTEM ID' /*SMF26NID*/ XMENTIME='END OF JOB*TRANSMISSION*TIME' /*SMF26NPT,NPD*/ XMITTIME='START OF JOB*TRANSMISSION*TIME'/*SMF26NST,NSD*/ where ORIGJBID/SMF26NJB is the 8-byte JCTJOBID field that includes Type of Task and the JES Number. I have it buried in my mind that when a job comes to a new node, if the original Job Number is not in use at that node, that the original Job Number is used for the job, otherwise the job gets a new number on the new node, but I have absolutely no documentation to support that memory. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Reports for GB per hour to tape
SMF 21 records contain byte counts, compressed and uncompressed, read and written, with ONLY the dismount time of the tape. But MXG users can use the MXGTMNT Tape Mount Monitor, which not only generates an SMF record for each mount of each volser, with mount start and mount satisfied time stamps, to measure waiting to mount time, and provides JOB, READTIME, JESNR, etc in an SMF record, it also captures all SYSLOG mount-related events into SMF. These three sources, MXGTMNT, SYSLOG, and TYPE21s are then merged to create a single tape event record for each mount which can be aggregated across each day to get a very accurate total GB statistics. And since JOB information is known, totals for different applications can also be measured. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Channel path acronym's
Here's MXG's past and present mappings for SMF73CPD values: /* $MG073CD FORMAT FOR VMAC73 */ VALUE $MG073CD '00'X='00X:UNKNOWN' /*UNDEF*/ '01'X='01X:PARALLEL BLOCK MPX' /*BLOCK*/ '02'X='02X:PARALLEL BYTE MPX'/*BYTE*/ '03'X='03X:ESCON POINT TO POINT' /*CNC_P*/ '04'X='04X:ESCON SWITCHED OR POINT TO POINT' /*CNC_?*/ '05'X='05X:ESCON SWITCHED POINT TO POINT'/*CNC_S*/ '06'X='06X:ESCON PATH TO A BLOCK CONVERTER' /*CVC*/ '07'X='07X:NATIVE INTERFACE' /*NTV*/ '08'X='08X:CTC POINT TO POINT' /*CTC_P*/ '09'X='09X:CTC SWITCHED POINT TO POINT' /*CTC_S*/ '0A'X='0AX:CTC SWITCHED OR POINT TO POINT' /*CTC_?*/ '0B'X='0BX:COUPLING FACILITY SENDER' /*CFS*/ '0C'X='0CX:COUPLING FACILITY RECEIVER' /*CFR*/ '0D'X='0DX:UNKNOWN' /*UNDEF*/ '0E'X='0EX:UNKNOWN' /*UNDEF*/ '0F'X='0FX:ESCON PATH TO A BYTE CONVERTER' /*CBY*/ '10'X='10X:OSA EXPRESS' /*OSE*/ '11'X='11X:OSA DIRECT EXPRESS' /*OSD*/ '12'X='12X:OSA CHANNEL' /*OSA*/ '13'X='13X:INTERNAL SYSTEM DEVICE' /*ISD*/ '14'X='14X:HSSI OPEN SYSTEM ADAPTER CHANNEL' /*OSC*/ '15'X='15X:ETHERNET OPEN SYSTEM ADAPTER CHANL' /*OSN*/ '16'X='16X:CLUSTER BUS SENDER' /*CBS*/ '17'X='17X:CLUSTER BUS RECEIVER' /*CBR*/ '18'X='18X:INTERNAL COUPLING ISC SENDER' /*ICS*/ '19'X='19X:INTERNAL COUPLING ISC RECEIVER' /*ICR*/ '1A'X='1AX:FICON POINT TO POINT' /*FC */ '1B'X='1BX:FICON SWITCHED' /*FC_S*/ '1C'X='1CX:FICON TO ESCON BRIDGE'/*FCV*/ '1D'X='1DX:FICON INCOMPLETE' /*FC_?*/ '1E'X='1EX:DIRECT SYSTEM DEVICE' /*DSD */ '1F'X='1FX:EMULATED I/O' /*EIO */ '20'X='20X:RESERVED' /*UNDEF*/ '21'X='21X:INTEGRATED CLUSTER BUS PEER' /*CBP*/ '22'X='22X:COUPLING FACILITY PEER' /*CFP*/ '23'X='23X:INTERNAL COUPLING PEER' /*ICP*/ '24'X='24X:INTERNAL QUEUED DIRECT COMM' /*IQD*/ '25'X='25X:FCT CHANNEL' /*FCP*/ '26'X='26X:COUPLING OVER INFINIBAND' /*CIB*/ '30'X='30X:OSA ZBX DATA' /*OSX*/ '31'X='31X:OSA ZBX MANAGEMENT' /*OSM*/ Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Multiple logon SMCS possibility
Dr. Alan Scherr told me over dinner years ago that on the final night of testing TSO before it's first release, they had taken a dinner break at 2am, and when he came back, he logged on and could enter commands, but there was no reply to his terminal, until, many minutes later, a co-worker across the room noticed that there were a bunch of replies to his commands on a different terminal. Alan then realized he had previously been logged on at that terminal, and after dinner had logged on at a different terminal, and there was no protection nor design for multiple logons, so at 3am he added the exclusive enqueure for userid in SYS1.UADS to prevent multiple logons, and TSO shipped at 7am on schedule to PID. As an aside, he reminded me that when the initial TSO performance did not match his model, his team modified the product to match the model. He then went on to develop VS2/MVS, immortalized in John Chapman's 1976 SHARE button http://www.mxg.com/thebuttonman/resultPOP.asp?d1=buttond2=167 Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Saturation Data Point (SDP)
The issue with RLS, the Rand PL/S Compiler, was not just copyright, but it had been created from IBM Confidential documents and Rand had violated the contract that gave them access to that material. http://www.mxg.com/thebuttonman/resultPOP.asp?d1=buttond2=213 Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IMS log record sequence number first byte 'F1'x - why?
Hoping to find my answer within this esteemed group, rather than finding/subscribing/posting to an IMS equivalent, does anyone know the significance of the first byte of the 8-byte IMS Log Sequence Number (the last eight bytes of each record)? I'm seeing log records with 'F1'x (e.g., '1' EBCDIC) in the first byte in IMS 11, with one-to-several bytes with hex-zeros, and then the sequence number in the low bytes. Spent almost an hour searching with no clue before asking. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: sendmail on the mainframe strange behavior
APAR Identifier .. OA31624 Last Changed 10/01/26 Z/OS 1.11 IEFACTRT EXIT IN SYS1.SAMPLIB HAS A FIELD FOR THE TOTAL SERVICE UNITS THAT IS USING SMF30SRB_L Symptom .. IN INCORROUT Status ... OPEN Severity ... 3 Date Closed . Component .. 5752SC100 Duplicate of Reported Release . 760 Fixed Release Component Name SMF SCHEDULERSpecial Notice Current Target Date ..10/02/26 Flags SCP ... Platform Status Detail: REVIEW - APAR solution is being reviewed. PE PTF List: PTF List: Parent APAR: Child APAR list: ERROR DESCRIPTION: At z/OS 1.11 HBB7760 the IEFACTRT exit in SYS1.SAMPLIB uses the field that gets displayed in the job log (total srvc units) and it is using the new SMF30SRB_L field instead of the SMF30SRV_L field for total SU. LOCAL FIX: Reassemble the exit and change the label under the GET INFORMATION FROM PERFORMANCE SECTION from LGR01,SMF30SRB_L GET SERVICE UNITS USED to LGR01,SMF30SRV_L GET SERVICE UNITS USED -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pommier, Rex R. Sent: Friday, February 05, 2010 9:33 AM To: IBM-MAIN@bama.ua.edu Subject: Re: sendmail on the mainframe strange behavior Alan, Yeah, I knew the problem was in this exit. I had just grabbed the exit source that I have running on my 1.7 system and installed it on 1.10. I first noticed the TCB time problem when I was putting the e-mail together asking for help with sendmail. A simple pull of the latest sample code from samplib fixed the problem for me. However, that does bring forth a curiosity question. IBM has (at least) 2 IEFACTRT exit routines in samplib. The one I am using is member ieeactrt. There is another sample in member smfexits. I grabbed this one first and the linkedit failed with unknown external references. It was/is looking for TSMFWTM and IEFYS. Any idea what these modules are? A quick google search tells me that IEFYS is supposed to be in SYS1.AOSB3, but it ain't there. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Field, Alan C. Sent: Wednesday, February 03, 2010 4:02 PM To: IBM-MAIN@bama.ua.edu Subject: Re: sendmail on the mainframe strange behavior You know what the TCB problem is don't you? You need an updated IEFACTRT exit. I don't remember the details but its something like what was a halfword is now a fullword. Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pommier, Rex R. Sent: Wednesday, February 03, 2010 15:54 To: IBM-MAIN@bama.ua.edu Subject: sendmail on the mainframe strange behavior BTW, never mind the outlandish TCB time. That is another problem for another time... JOBNAME STEPNAME PROCSTEPRC EXCP CONNTCBSRB CLOCK SERV RRPXSEND S30 00 89 0 551177.00 .0 306 RRPXSEND *OMVSEX 00 1424 19 551177.001.0 2101 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subject: Re: VTOC Fmt6
For 90% of messages the explanation will say to read the Language Reference Manual about the statement pointed to by the error message in question. The only other option we see is for us to copy the information from the LRM into a message manual. Why not just copy the information INTO THE MESSAGE instead of making me look it up somewhere else; put the manual text in a disk file and read the text into my error message in my listing. Barry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Speed up module load , program test
Don't overlook the DCB attributes of the Load Library; although your modules may be small enough that it doesn't matter. I recall an IMS transaction that took seconds to load because the load library still had an ancient BLKSIZE=1000. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Miklos Szigetvari Sent: Wednesday, January 13, 2010 6:23 AM To: IBM-MAIN@bama.ua.edu Subject: Speed up module load , program test Hi We have to test an application with several hundred test cases, every case is short batch job , call TMP (IKJEFT01) and a REXX script calls via CALL the main program. I would like to speed up the program fetch, load (as the modules are all very large) Occurs to me DYNAMIC LPA or LNKLST. -- Miklos Szigetvari Development Team ISIS Information Systems Gmbh tel: (+43) 2236 27551 570 Fax: (+43) 2236 21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our Website: http://www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to Identify when an alias was deleted
SMF 17 is only for non-VSAM deletes. (But, if you are looking for a non-VSAM delete, always also look at SMF 18, RENAMEs - I've seen them Rename the dataset and THEN delete it.) SMF 62 are VSAM Open Records. SMF 64 are VSAM Close/EOV records. SMF 61, 65, 66 are ICF Catalog Records, and (I think) will identify Alias Deletes. VSAM Catalogs have been long-gone, but when they existed the created the other 6x records, 63, 67, and 69. Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Tuesday, January 12, 2010 3:10 PM To: IBM-MAIN@bama.ua.edu Subject: How to Identify when an alias was deleted I am trying to remember how to see who and when an alias was deleted. I was going to use DAF but I was not sure if it could tell me this information. I was then going to go after only the SMF 17 records but was not sure if that would include the alias entry. What is my best option? Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CAPS Fantasia (was: argv for z/OS C++ batch)
The Radio Shack TRS-80 was Upper Case only as delivered; I remember opening the case and mounting a switch on the bottom (from Radio Shack, of course) and soldering it so that the editor recognized lower case, so my 1980 book, written on that machine, had mixed case. Of course, the OS didn't support the switch, and produced garbage from key strokes if the switch was in the mixed case position. MXG was ALWAYS upper case only, until the nix's came into being, forcing some members to be case-dependent, which I abhor, but now must live with. FOO, foo fOO and Foo to whomever made that unwise choice. Happily New Year, Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF30 record length
1. The CPITCBTM and CPISRBTM are not only the result of DDCONS: The Initiator TCB/SRB CPU time is not only due to DDCONS, but is all of the CPU time that occurs between Initiation and Program Load time, which includes DSENQ time, the cost of execution of your SMS Allocation Rules, HSM Recalls, VAM product, and SMS Trace CPU time, PLUS the CPU time after the Loaded Program has terminated, which includes the DDCONS CPU TIME and Catalog CPU time. And, there may be other contributors to those CPU times. 2. But the original issue of size of 30s can also be impacted by your choice of INTERVAL and DETAIL options in SMFPRMxx: 10. No EXCP data for type 30 subtypes 4 and 5 from STCs. SMF Type 30 subtypes 4 and 5 for STCs (Started Tasks) do not contain an EXCP segment when INTERVAL and NODETAIL is specified in SMFPRMnn member of SYS1.PARMLIB, even though the EXCP segment does exist in subtypes 2 and 3 (the interval records). This is documented under the DETAIL parameter in Initialization and Tuning (but not mentioned in SMF Manual). What is not documented is that NOINTERVAL and NODETAIL options DO create EXCP segment for STCs in subtypes 4 and 5! Thus a site which had not specified INTERVAL and had NODETAIL by default was recording EXCP counts in STC step and step termination records, but when the site decided to record INTERVAL data, the STC EXCP counts all became zero! The moral: ALWAYS specify DETAIL for STCs so that EXCP counts are in the subtype 4 and 5 records, no matter what the INTERVAL/NOINTERVAL parameter specifies. Originally printed in MXG NEWSLETTER SIXTEEN. 26Apr02 revision to the preceding ALWAYS specify DETAIL: - IBM Information APAR II07124 discusses why you might need to specify NODETAIL for your STC's: When DETAIL is specified, the DD and EXCP information will be stored in 32K memory blocks in SP230, and those blocks (in virtual storage) are kept for the entire life of the address space. For an STC like DBM1, which can have 10,000 DDs, its SP230 can grow and run out of private area storage, both high and low, requiring a restart of the DB2 system to clear the Sub Pool. Instead, with NODETAIL, the DD information is only kept for each interval record, i.e., in PDB.SMFINTRV, so the data is available in SMF, and DBM1's SubPool 230 does not grow over time, so you don't have to stop and restart your DB2 subsystem. - That APAR also recommends DDCONS=NO, a parameter that was created by IBM as a result of an MXG user's discovery of the problem it corrects, so MXG has always recommended DDCONS=NO be specified. - Specifying NODETAIL for STCs has no direct impact on MXG logic. Your STC observations in PDB.JOBS/PDB.STEPS will have zero for the EXCP/IOTM variables, which might affect your chargeback for STCs, but STCs are usually an internal charge; furthermore, only those STCs that are terminated normally (created subtype 4/5) could have been billed for STC EXCP counts. But the EXCP/IOTM variables for STCs will exist the PDB.SMFINTRV dataset for each interval, even with NODETAIL, as long as INTERVAL is enabled to write subtype 2/3 records, (and MXG member IMACINTV was enabled to populate TYPE30_V and PDB.SMFINTRV datasets). And with a large value for SPINCNT in your MXG member IMACSPIN, dataset PDB.SMFINTRV will contain the ACCOUNTn and SACCTn accounting fields for the STC, so those EXCP counts for your STCs can still be charged back with PDB.SMFINTRV. 12May03 addition: - To keep DB2 up forever, you do NOT have to turn off SMF interval recording, which is a mis-reading of that APAR. As long as both NODETAIL and DDCONS=NO are specified, the NODETAIL eliminates the SP230 growth issue, and DDCONS=NO eliminates the CPU spike, so you can continue to write SMF type 30 interval records for your DB2 that is designed to never end. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF70PDT - COMPLEX_SEC
I could venture a guess. SMF70PDT is recorded for each LCPUADDR for each LPAR in the SYSPLEX (and each segment identifies the type of engine in SMF70CIN). Perhaps CPU_DISPATCH_SEC is the total of the CP engines just for one LPAR, while COMPLEX_SEC is the total across all LPARs, so you can calculate the portion of CEC CPU time from the LPAR of interest. Merrilly Christmas, Barry Merrill P.S. Sometimes, free advice may only be worth its price. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF30 record length
In 1987, Diane Eppestine at Southwestern Bell saw that whenever their SAR job (a SYSOUT processing subsystem) was cancelled, the CPU went to 100% busy for 30-60 minutes. Instruction traces found the loop was in DD Consolidation. SAR dynamically allocates a DD for each SYSOUT file it processes; by the end of the week that step had over 75,000 DD entries! DD consolidation reads the first DD segment, scans the remaining 74,999 segments for a match, reads the second and scans the remaining 74,998 for a match, etc. etc., etc., all at DPRTY=FE! In response to Diane's discovery, Bill Richardson, IBM SMF Development, subsequently provided a new SMF option, DDCONS(NO), specified in SYS1.PARMLIB(SMFPRMxx), so that you can disable this very unwise (in my opinion) algorithm, and thereby eliminate its wasted CPITCBTM and CPISRBTM (MXG names for SMF30ICU and SMF30ISB, the Initiator CPU time that occurs before Step Program Load and after Step Program Termination). All of those empty SYSOUT DD segments can now be removed in z/OS 1.10 with the EMPTYEXCPSEC(SUPPRESS) option: 1. APAR Identifier OA29582 adds new EMPTYEXCPSEC(SUPPRESS) option in SYS1.PARMLIB to suppress all empty EXCP entries. The option prevents the creation of null segments in SMF 30 records for SMS Candidate Volumes, and could significantly reduce the size of your step and job termination records, especially if your site has a default of (SYSDA,5) for every allocation!! The MVS Initialization and Tuning Reference, under the SMFPRMxx parmlib parameter definitions, EMPTYEXCPSEC: SUPRESS specifies that the system suppress the creation of empty EXCP sections. Empty sections can be the result of non-dataset allocations, such as DD DUMMY, or for spool file allocations (i.e., SYSIN, SYSOUT JES DDs), or for non-allocated candidate volumes in the SMS storage group. One MICS site reported a 28% reduction in CPU time with removal of all of their empty EXCP segments. New EMPTYEXCPSEC option in PARMLIB is z/OS 1.10 only. While EMPTYEXCPSEC option is documented in the z/OS 1.9 SMF manual in Section 13.34.2.7 (Execute Channel Program (EXCP) Section) of z/OS MVS System Management Facilities (SMF) Document SA22-7630-16, for z/OS 1.9, testing on a z/OS 1.9 system resulted in IEE945I UNRECOGNIZABLE OPTION 'EMPTYEXCPSEC' IN PARMLIB INPUT IEE947I '/* DEFAULT RETRY */ EMPTYEXCPSEC(SUPPRESS)' SKIPPED DUE TO PREVIOUS ERROR IBM has confirmed that the option only exists in z/OS 1.10, where it is listed in the Release Guide as a 1.10 enhancement Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Future of MXG?
I surely would have appreciated if you had checked your facts before broadcasting such a scurrilous statement, especially since I specifically stated in our User Group/Vendor Session yesterday evening that I have EVERY INTENTION OF LIVING TO 100 AND HAVE NO PLANS TO EVER RETIRE. Merrilly yours, Barry Merrill P.S. While our intentions on our demise are still personal, I am quite certain that MXG Software will exist long after I do. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF Image counts and physical page counts
These notes from my old paper on z/OS Resource Accounting have not been updated in several years, but I believe they are still correct with regard to what is counted where. Barry Merrill PRINTERS The TYPE6 record data in the PDB.PRINT data set provides the data needed to distribute the cost of printing to the end-user. The method used in distributing these costs depends on the type(s) of printers used. What works for one class might not work for other classes of printers. For older line printers, charges based on the number of lines printed is probably the most accurate and equitable method. For some of the the early laser printers (like the IBM 3800-1) the line count can be distorted by font changes within lines but counting lines printed is still the best method. The PDB.PRINT variable TOTLINES, which is TOTLINES=SUM(PRINTLNE,PUNCHCRD,EXTWTRLN), must be used to count lines. Almost all lines printed now are counted in the EXTWTRLN field, because IBM changed OUTDEVCE (it used to contain the name of the printer or punch, but it now contains the VTAM node name, so PRint versus PUnch can not be detected, and EXTWTRLN is the fall-thru bucket!). PSF printers should be billed based on the number of sheets printed, SHEETPRN, which is the number of physical page sides that were printed. SHEETPRN per minute is a good printer throughput measure; the printer can never produce sheets at more than the rated speed of the printer, and thus using SHEETPRN recovers the cost of the individual pieces of paper, and the exclusive use of the printer. Alternatively for PSF, you may want to consider the use of DOCLENFT (the length of the paper printed). This number is useful because the meter that is read by the CE each month is measuring the number of feet of paper that passes beneath the print head and thus your printer maintanence bill is directly related to DOCLENFT. There is one small problem with this number that only applies to continuous form printers like the IBM 3800-3. DOCLENFT is always measured in the direction of paper flow. In the case of a cut sheet printer, this is ALWAYS across the 8.5 inch side of a standard size sheet of paper. Continuous forms can be obtained with the tractor feed on either the 8.5 inch sides or the 11 inch sides and the same document can be produced on either stock simply by rotating the text (which may be as simple as changing the form number.) Thus a 100 page job could potentially reflect 70.8 feet one day and 91.75 on another simply by changing the paper. If you are still using the forms with the feed on the long side, you may want to evaluate the possible cost savings of using the other orientation of the paper. What about PAGECNT? Don't use it. To PSF printers, one page is one sheet of paper whether SIMPLEX or DUPLEX. Thus a user printing a 100 page document DUPLEX would be billed for 50 pages while a SIMPLEX user would be billed 100 pages for the same document. What is in TOTLINES under PSF? It all depends: line-mode data counts the number of line images spooled in TOTLINES, and PSF-mode data counts the number of records spooled, but a record could be single line or a multi-page graph. You can tell that PSF created the type 6 data because variable SUBSYS6='PSF' (others are: JES2,JES3,EXTW,SAR,EXD,CADI,BUND), but there's nothing in the type 6 to identify the print's data mode. Nov 2005 notes: 1. TOTLINES can be very large when the record has a file transfer segment (variable SMF6BYTE will be non missing). 2. IBM variable SMF6PRMD does identify LINE vs PAGE mode in SMF 6 PSF records. Print workstation printers (Xerox printers like the 4050, 4090, 4135, and 9700s) present other challenges, because they contain their own operating systems and disk storage (early Xerox used a PDP 11 inside), and the PDB.PRINT information represents only what was sent by JES or PSF to the print workstation. PRINTIME/PRENTIME are the time print was transmitted, and not when actually printed. These printers can store the SYSOUT, print the SYSOUT, copy it to tape or floppy, or purge the output prior to printing all without notifying the MVS host of the action taken! To further muddy the water, there are commands, called DJDEs, that can be sent along with the datastream to modify the number of copies, to set print to SIMPLEX or DUPLEX, to set how many logical pages are on a physical page, etc. This all means that any relationship between the TYPE6 record and what actually happened on these printers is purely coincidental. The good news is that there is a Xerox-provided facility, SFS, that will create a billing record of each job printed with the print facilities actually used, including the number of sheets of paper printed and which bins were used. The bad news is that SFS does not automatically send these data records to the mainframe, and that you must modify SFS (see the example in member ADOCSFS) to add the JOB name and JESNR to the SFS record. Although
Re: Lookafter tool
The MXG program ANALALL selects ALL records for desired JOBs, reading all of these SMF records IBM created: 4 5 6 10 14 15 16 17 18 20 24 25 26 30 32 33 34 35 36 40 41 42 59 60 61 62 64 65 66 78 80 83 91 92 101 Vendor/Product User Records: ACC ACF2 CTLD DALO EDGS HIPR TMNT and printing all of the fields in all of the records and subtypes. So even if you don't have MXG, you at least now have a list of the size of your task to examine them all (and I think there are some new user SMF records not in the above list). Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Can CICS region share more than one processor
In the old days, a CICS subsystem's capacity was limited by the amount of CPU TCB time needed for that single QR TCB. Based on my analysis when OTE was brand new, of the CPU time consumed by each of these new CICS TCBs, I planned this post to argue that going to OTE didn't help much, because most of the CICS CPU time was still being spent under the QR TCB. I could NOT have been more wrong! Analyzing new CICS/TS 4.1 Open Beta data from a VERY aggressive OTE exploiter site shows (from their SMF 110, subtype 2 Dispatcher Statistics segments, MXG CICDS and CICINTRV datasets): Total TCB CPU in Dispatcher Records = 13,080 seconds Total TCB CPU in QR TCB = 2,776 seconds Total TCB CPU in L8 TCB = 10,298 seconds Total TCB CPU in all other TCBs = 6 seconds Aha, you say, OTE still doesn't help; the CPU time just moved from the QR TCB to the L8 TCB, so the capacity limit just moved from one TCB to the other, right? Wrong again. While the QR TCB can attach only a single TCB, these new TCBs can attach multiple TCBs; in fact, the SMF data shows that the L8 TCB attached a maximum of 22 TCBs, each of which is a separate dispatchable unit. So, it REALLY does look like that these multiple OTE TCBs do eliminate the old one-TCB CICS capacity limitations, and does indeed spread your CICS time across MANY TCBs. (Total SRB time in the Dispatcher Records was only 65 seconds.) Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75229 ba...@mxg.com http://www.mxg.com admin questions: ad...@mxg.com technical questions: supp...@mxg.com tel: 214 351 1966 fax: 214 350 3694 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking (getting back on topic)
At the Chicago SHARE 43 meeting in August, 1974, IBM had invited attendees to a demonstration of the new MVS operating system on the 145 at the Chicago Ed center. At 8 p.m. Tuesday, three attendees found the IBM demonstrator on duty was enthralling an attractive lady with his expertise. Not wanting to be interrupted by three males, he said, Go play with the system on that user TSO terminal over there -- you can find out how good the security of an MVS system is for a typical TSO user. The challenge was accepted, and in short order, Tim W. observed that SYS1.NUCLEUS was not protected, so he scratched it. Tim W. knew that once the system is up, the dataset SYS1.NUCLEUS is not read again, so the SHARE demonstration continued without a flaw. It was later heard that IBM took the SHARE MVS demonstration down at 11 p.m. to IPL for a customer benchmark; it took until 3 a.m. for IBM to find a CE who could correctly decipher the wait state code and explain that the IPLs kept failing because there was no SYS1.NUCLEUS on the IPL volume. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: My Green Screen IBMLink is still working
You reminded me that back in 1976 when I had just joined Sun Oil, and we were a big IBM datacenter, I requested a new feature in our 3270s that led to several phone calls from the IBM'er responsible to answer the request (and my first call from IBM Japan!). He sincerely examined the request in several calls, but finally convinced himself that it couldn't be done, or couldn't be done with then-current technology. All I wanted was a key that would take my cursor back to where it was just before it's current location (i.e., after I had hit something and didn't know what I had done, and wanted to go back to where I had been!). Barry Merrill -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Saturday, July 04, 2009 9:19 AM To: IBM-MAIN@bama.ua.edu Subject: Re: My Green Screen IBMLink is still working Edward Jaffe wrote: Today is the day the IBMLink 3270 interface is supposed to no longer work. But, I've been logged on since Monday and it's still up. Am I on borrowed time? It is Saturday morning, Independence Day in the USA, and my Green Screen IBMLink session is *still* working! I updated an existing ETR. (Not that I expect a response before Monday.) SIS is still working too! I might be the last customer in the country or even in the world with a fully-functioning IBMLink Green Screen session. I'm feeling VERY independent right now! :-D -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Anyone Know of a Good Pocket Calculator Like HP with Hex capabilities
There are free apps for iPhones; one is called Missing Calc and it has Hex, Decimal, Octal, and Binary Radix as well as ASCII, UTF 8 and UTF 16 Encodings. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New TOD (Was:Howard Turetzky has a NEW EMAIL ADDRESS)
With regard to the 8-byte clock wrapping in 2042, I believe that IBM has to resolve this issue not later than 2011 or 2112, because tapes can have a maximum retention period of 30 years. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New TOD
My full 1989 note contained: o. An important date: When DATETIME clocks wrap: A date for your grandchildren. At 23:53:48 on Sep 17, 2042, the IBM 8-byte hardware clock will fill and reset to Jan 1, 1900. With regard to the IBM clock date, it must be corrected by year 2011, as the retention period for a cataloged tape volume can be as long as 30 years. And it turns out the Open Systems wrap earlier: The year 2038 problem (Unix Millennium bug), is UNIX result of storing its system time as a 32-bit signed integer with the number of seconds after the Unix/POSIX epoch time of midnight, January 1, 1970. This value will roll over on February 19, 2038. As for the 30 year tape issue, I know that there was a BOF at a SHARE in 1988 on the Year 2000 issue, and a comment on tapes by an attended. I think he was an IBM'er, but might have been another vendor, but he implied that the calculation of a future expiration date of a tape used the current TODSTAMP to figure out the actual expiration date (maybe when the retention period was stated in days from now??) But that was 20 years ago, and may no longer be true. Free advice is often only worth the price. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Copy SMF Records With Syncsort
You could also have corrected those records with just SAS, i.e., MXG not required: DATA _NULL_; INFILE SMF; INPUT @11 SYSTEM $EBCDIC4. @; IF SYSTEM='1234' THEN SYSTEM='5678'; ELSE ... change system to desired; FILE SMFOUT DCB=SMF; PUT _INFILE_ @11 SYSTEM $EBCDIC4. ; FILE LOG; -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Bob Yelavich passed away on January 18
Would someone please post on CICS-L. From his son: His funeral will be held at: Moore and Sons Funeral Home 1219 N Davis Dr Arlington, Tx 76012 Friday 1/30 @ 9:39 AM Since we had no idea who would make the trip to Dallas, or who our dad knew. We have not made any formal get together afterwards. But knowing me, something we'll get put together. Even if it is at Joe's Crab Shack! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG Question
You may be recalling this incident from 2005: Change 23.219 The ICF Catalog 05 record variable GATGEN should have VMAC6156 been input as PIB.2., instead of one byte, and variable VMACCTLG GATWRAP='Y' is now set if the first bit of GATGEN is on, Aug 29, 2005 to mark that this GDG member has wrapped; i.e., its generation number has exceeded . If GATWRAP is on, GATGEN=GATGEN-32768 to contain the correct Gen number. This discovery was precipitated by IGD07001I ABENDs in production, which occurred when a GDG that had GATWRAP on for some members, and GATWRAP off for others, when that GDG generation number goes from 999 to 1000. Normally, when all members of a GDG have wrapped, the next catalog action turns off the wrap bit in all of the catalog records. For a normal GDG, that should happen when the +256th gen is created after wrap, as only 255 members can exist in the catalog. But this site had had a very old application that originally created +1 thru +5 each day, and then deleted +1 thru +4, leaving only +5 in the catalog. However, back when Clinton was President, an application change was made that created on +1 thru +3 and deleted only +1 and +2, so there were 2 old GVoo's left in the catalog. When the GDG wrapped, and when the create of +1 would have created G1000V00, those old GVoo's still had their wrap bit off, and the production job failed: IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122 Return Code 140: Inconsistent or conflicting arguments were provided. Reason Code 122: Catalog G1000Vxx will cause the GDG to exceed the limit of 10,999. Programmer Response: Clean up the GDG in error then catalog G1000Vxx. The site found Information APAR II07276, which explained how wrap works, but it says to 'see the Z page for internal details of the wrap bit interface'. So the site asked IBM Support: We need to identify other GDGs that have the same exposure to causing ABENDs. Can I look at the 'Z' page? Does the 'wrap bit' appear in SMF 61, 65, 66 ICF Catalog records? IBM Level 2 Catalog Support refused to answer the quite valid question, with this answer: Unfortunately, the 'Z' page in our info APARs refer to information meant for IBM eyes only, for helping us get to problem determination quicker. We are not at liberty to dicuss any control block internals that are not provided in our published manuals. As for information in SMF records relating to this, this info would be included in the updated record portion portion of the SMF record, however we cannot discuss offsets for those either. I am sorry I cannot be more helpful. Please let me know if there are any other questions that I can answer for you. Even escalation to my IBM Poughkeepsie z/OS support did not convince IBM Level 2 Catalog Support to identify which bit is the GATWRAP bit. The ICF Support and Developers hid behind OCO, Object Code Only, as the reason they could not provide catalog record documentation (but DSECTS are NOT CODE!). So I suggested the site could create a GDG and force it to wrap, and by examining SMF records, we concluded that first bit of GATGEN was the GATWRAP bit. Then, I remembered I still had lots of archaic printed manuals, and located the very old MVS/XA Catalog Diagnosis Reference for DFP Release 1.2, which confirmed that the GATWRAP bit was indeed the first bit of the GATGEN field in the 05 Catalog Record! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Has your company outsourced to Satyam?
http://www.nytimes.com/2009/01/08/business/worldbusiness/08satyam.html?ref=technology -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
Sounds like the file was created with RECFM=V writes, and was never blocked when created, inspite of the DCB attributes. Barry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort Oddity
Use SAS to find the actual physical block size of the two files: // EXEC SAS //FILEONE DD DSN=FILEONE,DISP=SHR //FILETWO DD DSN=FILETWO,DISP=SHR //SYSIN DD * DATA SIZEONE; INFILE FILEONE RECFM=U BLKSIZE=32760 LENGTH=LEN; INPUT; LENGTH=LEN; PROC FREQ: TABLES LENGTH; TITLE TABULATION OF BLOCK SIZES IN FIRST FILE; DATA SIZETWO; INFILE FILETWO RECFM=U BLKSIZE=32760 LENGTH=LEN; INPUT; LENGTH=LEN; PROC FREQ: TABLES LENGTH; TITLE TABULATION OF BLOCK SIZES IN SECOND FILE; By specifying RECFM=U, SAS will read each block and store its physical length in temporary LEN variable with the LENGTH=LEN option, and then LENGTH=LEN; statement will create kept variable LENGTH, which is then tabulated by the PROC FREQ. Barry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Computer History Museum
In 1966 at Purdue's Labratory for Agricultural Remote Processing, LARS, later renamed to the Labratory for Applied Remote Sensing, where K.S. Fu's pattern recognition algorithms were implemented and validated (using 16 channels of spectral data with 6 bits for the amplitude of each channel, gathered on a DEC PDP- in a DC-3 that flew at 2000 feet over a 5 mile long strip of Indiana fields), we took delivery of S/360-44 serial number two (number one was in Pook). I had implemented the Cooley-Tukey Fast Fourier Transform in Fortran directly from their original paper on the University's 7090, and had moved it and my programming of the Karhunen-Loeve transform using polynomial approximation for my Masters Thesis to the new Model 44, using an AM radio to listen to the program execution to detect when programming errors send it into a never-ending loop, and to hear when it went from slow to fast loops. Diagnosis of those never-ending loops involved using address stops and single step instruction toggles from the console. Twice, my program abruptly stopped, redlighting the console, and IBM engineers came on site, both times finding that I had actually burned out the transistors in the floating point divide unit. After the second failure, they returned with a floating point divide unit that had been redesigned with a new heat sink added to fix the problem. Originally, there was no disk with the Model 44, running TOS as I recall, with five tape drives, and the Fortran compiler was only on tape - it took all five drives to compile and punch out the deck which was then read in and executed, and all five tapes were spinning during every compile. After writing my own program for the FFT, the Lab directory and my major professor, Dave Landgrebe, gave me a note from the computer center that there was a new FFT subroutine that had been written by Tukey himself available from something called the SHARE library. Upon examination, I discovered I was at best only a coder and Tukey was a real programmer; whereas my major loop was 250 or so Fortran statements, I marvelled at the correct way to do it, in about 25 statements, and thus was introduced to the SHARE program library. My part-time job at LARS was to create the Ground Truth data base, well before the actual flight. On the day of the flight, the agronomists were going to photo and measure and record the plant statistics from each field and then populate my database for correlation with the spectral data, but as there was no actual field data yet, I created several sample fields of opium poppies and cannibis to show the agronomists what the reports would eventually look like, and they were all humoroed by my samples. However, one Saturday afternoon the campus police showed up at my apartment and told me I was urgently needed at LARS and took me there; it seems that the U.S. State Department had been discussing with their Turkish counterparts the future possibility of using the LARS programs to detect those crops, but had assurred the Turks that the project was still in its infantcy, and had not been trained on any of those crops. Unfortunately, one of the agronomists had shown the Turks one of my sample reports, so they assumed they were being lied to by the State Dept rep, who dragged me out to the site to meet with the Turks and, finally, having accepted that I was the author and just a college student programmer, they did finally realize this was just a joke. The Ground Truth was written in FORTRAN II, which did not have character literals; to print CORN, I had to set the variable CORN equal to the decimal value that, when written with A4 (as I recall) format, would print CORN, etc., for each text value. Just as I finished, Fortran IV became available. Merrilly Christmas Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75220 214 351 1966 tel 214 350 3694 fax www.mxg.com ba...@mxg.com P.S. I first programmed a digital computer, an IBM 610 in September, 1959 as a Sophomore at the University of Notre Dame; who of you all will I have to outlive to claim to have been programming digital computers longer than anyone else?? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FALL BACK TIME CHANGE EST
Changes to Daylight Saving Time: MXG Software code is impervious to Daylight Savings Time; we give you the data that is in your RMF,SMF, etc. data, as you choose to create it. If you choose to set your clocks back on an active system, you corrupt many datetime values (i.e, jobs end before they start, negative elapsed times, intervals end times before their begin time, etc.), and you will create multiple records with the same STARTIME in all RMF datasets, as well as CICINTRV, SMFINTRV, and any other interval datasets, but that's the result of your choice to set back clocks on an active system, and not of MXG's doing. If the records also contain an actual GMT Offset field, those pairs of same-STARTIME observations can be identified, but your hourly reports for the hour of time setback will have pseudo-duplicate data. Note that if your installation uses the TIMEBILD architecture (to tell MXG to change all datetime variables from SYSTEM's that are on different time zones to a common timezone), as long as you correctly update the mapping table in advance of the time change, MXG will correctly handle each system's time change, but, again, if you choose to set clocks back on an active system, all of the preceeding caveats apply. It is precisely when you have local time as a result of the GMT Offset that you are exposed to errors if you change the time (i.e., change the GMT Offset) backwards on an active system. If you have a GMT Offset of zero, and you keep all your clocks on GMT, there there is no change in your timestamps. This information was posted to our MXG-L ListServer in Dec, 2006. Herbert W. Barry Merrill, PhD -- 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: Measuring performance with job elapsed time
While I agree that the elapsed time of a batch job is subject to some uncontrollable variation, it, or more accurately, a subset of the job elapsed time, the step residency time, can indeed be used to compare before and after changes in many cases, especially when there was a significant improvement (or degredation!) due to the changes you made. By using the step records, for the program that was changed, rather than job record for all steps, you exclude job scheduling delays, and you don't get confused by any variation in the other steps that are not germane to your changes comparison. By using the residency time, (RESIDTM in MXG, SMF30RES in the SMF 30 step records) you eliminate any delays due to allocation, swapout, and first-volume-tape mounts. SMF30RES is the duration when the program was resident in real memory, i.e., either executing CPU or doing I/O - transferring data or waiting on data transfer. By comparing runs made over several days at the same time of day, i.e., when the system load is comprable, you should be able to conclude that a big positive change occurred, or that a big negative change occurred, or that there was relatively little changed. My personal experience is that, in the absence of wild system variations, steps run at the same system load/time of day vary on the order of 10-15%, whereas runs at different loadings/times may vary more like 30%, but not typically by 50% or more, so if you have made significant improvements, they should be measurable. You should also compare the total CP CPU time and its components, any zIIP or zAAP CPU times, and both the EXCP count and the IO Connect times to see if they are consistent with expectations. For example, if you increased blocksize or buffers for file I/O, you would expect a reduction in both EXCP counts and IOTM, and a similar decrease in the CPU TCB and especially CPU SRB time. Of course, if the I/O is going thru a database manager, you might not see any of the I/O resources recorded in the step record change. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75220 214 351 1966 tel 214 350 3694 fax www.mxg.com [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problem Allocating DSN - 5000 CYl
From MXG NEWSLTRS: 5. SAS Note SN-V9-017038 reports that SAS V9.1.3 with Service Pack 4 and with that Hot Fix can use DSNTYPE=LARGE datasets under z/OS 1.7 and later for bound SAS data libraries on disk. DSNTYPE=LARGE z/OS datasets can occupy more than 64K tracks on a single volume, so those datasets can fill all available tracks on the largest volumes (54GB) that are currently available, reducing the number of volumes for large SAS data libraries. To create a direct access bound library that resides in a DSNTYPE= LARGE data set, you must externally allocate the library data set with the DSNTYPE=LARGE parameter: // EXEC MXGSASV9 //LARGEDB DD DSN=YOUR.DSNTYPE.LARGE,DISP=(,CATLG),UNIT=SYSDA, // SPACE=(CYL,(5000,5000)),DSNTYPE=LARGE Nov 7, 2007 update: Prior to z/OS 1.7, there was an IBM limit of 64K tracks when the I/O access method was EXCP, but IBM removed that limit in 1.7, and the SAS Hot Fix above revised SAS EXCP code so the DSNTYPE=LARGE can be fully exploited. Barry -- 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
BCP New Function Support Hardware instrumentation services OA25755+
Data is preented in the new SMF 113 record. Pubs SA23-2260 and SA23-2261 http://www-01.ibm.com/support/docview.wss?uid=isg26fcd1cc32246f4c8852574ce0044734a http://www-01.ibm.com/support/docview.wss?uid=isg20ab3047d13672ab6852574ce0044b445 Barry Merrill -- 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: Space problem
SMF 14/15 records identify is space is released, or at least if RLSE was specified, so you could examine all of those close records to see if any or all actually specified RLSE. In MXG, variable RLSE='Y' is set IF JFCBIND1='11..'B and JFCBIND1 is in byte 151 of the data portion of the SMF record. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75229 [EMAIL PROTECTED] http://www.mxg.com admin questions: [EMAIL PROTECTED] technical questions: [EMAIL PROTECTED] tel: 214 351 1966 fax: 214 350 3694 -- 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: OSA performance and utilization
From a post to MXG-L last week: In the TYPE73 channel records, look for smf73cpd = '11'x. Barry Merrill -- 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
Overland TapeXpress T490E drive available
I have the Overland TapeXpress T490E cartridge tape drive that reads and writes 3480/3490/3490E cartridges that has been unused for several years, and I'd be happy to give it away, if someone can use it. Overland doesn't support the drive, but they did give me the url www.sprague-magnetics.com that should/maybe have the drivers for it. I used it last on Windows-whatever that was prior to Windows NT 4.0, so what floppies I still have probably won't work. Of course, a local pickup in Dallas would be preferable, but if there are no local takers I'll consider packaging and shipping the 35 pound 10x8x17 inch device. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75229 [EMAIL PROTECTED] http://www.mxg.com admin questions: [EMAIL PROTECTED] technical questions: [EMAIL PROTECTED] tel: 214 351 1966 fax: 214 350 3694 -- 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: Monitor use of Load-Library as JOBLIB/STEPLIB
Bob is correct that the SMF 42 Subtype 6 record will identify each DSNAME in a STEPLIB concatenation, but that record contains only the DSNAME - it provides no information about the MEMBER that was loaded. But ONLY if just one DSNAME in the //STEPLIB concatenation was the source of ALL of the modules loaded from STEPLIB by the step during that interval, then it could be used to identify the DSNAME. Barry Merrill -- 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: Monitor use of Load-Library as JOBLIB/STEPLIB
Unfortunately, the SMF 14 records do NOT contain all DSNAMES. Specifically, in the case of interest, whenever there are concatenated BPAM libraries, (e.g., STEPLIB, JOBLIB, SASLIB, and even MXG's SOURCLIB DD) you ONLY get the DSNAME of the FIRST DD in the concatenation. You do get a separate UCB segment for the second and subsequent contactenations, but only DEVNR, VOLSER, and EXCPCNT. (MXG's 'solution' is to create a false DSNAME=' CONCAT BPAM' with a blank in the first position, so that if you should sort the TYPE1415 SAS dataset, those instances will be printed first - no help with the DSNAME, but at least you'll know there were missing DSNAMES). But even if the full DSNAMEs were provided, you'd have no way of knowing which PDS actually had the member that was loaded/referenced. Barry Merrill -- 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 audit the usage of IND$FILE
The SMF 30 contains no TSO COMMAND usage information by command name, but any DDNAMEs allocated during the TSO session are recorded in the SMF 30s, so you can often/sometimes recognize what TSO command was used from recognizable unique DDNAMEs in the SMF 30, but without 100% accuracy. And you could map the JOB/JESNR/READTIME triplet to select the TYPE1415 for non-VSAM or TYPE64 for VSAM and identify the DSNAME of that DDNAME, which often is needed to identify which version. Barry -- 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 audit the usage of IND$FILE
I believe IND$FILE is implemented as a Command Processor (and not a CLIST that CALLs a program); therefore you can create an SMF type 32 record for each use of the command. The SMF Manual discusses enablement in Chapter 4. Barry Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75229 [EMAIL PROTECTED] http://www.mxg.com admin questions: [EMAIL PROTECTED] technical questions: [EMAIL PROTECTED] tel: 214 351 1966 fax: 214 350 3694 -- 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
