Re: Determining 3390 Model
On 2/16/2013 8:29 AM, Skip Robinson wrote: 2. I tried DS P on one of our 'Mod27' volumes. It's reported as a Mod-9 rather than Mod-A: We have various odd-sized volumes, so I did some experimentation. A Mod-51 shows as Mod9. A Mod-81 shows as ModA. I don't have a Mod-54 or Mod-55 to see for sure where the device number changes, but I suspect Mod-54 and lower is shown as Mod9 and Mod-55 and higher is shown as ModA. Does anyone have empirical evidence to confirm this? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining 3390 Model
On 2/16/2013 11:04 AM, Mike Schwab wrote: A is when you get to EAVs with Cylinder Allocations. 9 is non-EAV without Cylinder Allocation areas. The problem with this theory is that EAV is a z/OS software concept only. It does not apply to other operating systems. More to the point, the hardware doesn't know about track-managed space, cylinder-managed space, break-point values, etc; it knows only about the size of the volume in cylinders (or Mod1 multiples). Yet, the DS8100 (2107) hardware console--whose display I would paste in if IBM-MAIN allowed anything other than plain text--shows 3390-9 as the model number for the Mod-51 volume and shows 3390-A as the model number for the Mod-81 volume. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining 3390 Model
On 2/15/2013 3:47 PM, Mike Schwab wrote: Divide the Cylinder count by 1113. And be prepared to handle greater than two-digit model numbers. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determining 3390 Model
On 2/15/2013 4:19 PM, Dale McCart wrote: Any thing larger than a Mod 1 is listed as Mod 3 if not larger than a 3 Any thing larger than a Mod 3 is listed as Mod 9. Not true. If not Mod1, Mod2, Mod3 or Mod9, it is reported as ModA. This is true for both DS8xxx HMC and z/OS displays. DS P,8339 IEE459I 17.08.42 DEVSERV PATHS 648 UNIT DTYPE M CNT VOLSER CHPID=PATH STATUS RTYPE SSID CFW TC DFW PIN DC-STATE CCA DDC CYL CU-TYPE 08339,3390A ,A,041,MVSEV0,12=+ 2E=+ 2107 8003 Y YY. YY. N SIMPLEX 39 39262668 2107 SYMBOL DEFINITIONS A = ALLOCATED + = PATH AVAILABLE Note this volume is listed as 3390A aka ModA. (Mod9 would be listed as 33909.) Since the volume has 262,668 cylinders, it would be listed as Mod236 using the technique suggested earlier in this thread. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Change in PDSE Architecture (Was: SMPPTS Spill Data Set)
On 2/13/2013 11:08 AM, Mark Zelden wrote: On Wed, 13 Feb 2013 12:07:17 -0600, Paul Gilmartin paulgboul...@aim.com wrote: On Wed, 13 Feb 2013 08:40:43 -0800, Skip Robinson wrote: 3. In the case of a PDSE growing excessively large, you may want to shrink it manually now and then. Will MIGRATE/RECALL accomplish this for a PDSE? (I believe it will for PDS, and for PS, but only if secondary extents are defined.) Is there a better way? You can just use FREE on ISPF 3.4 to release unused extents. Partial release has never worked well for PDSE because of the way PDSE is architected internally. Only tracks above the highest active block can be released; there can be big gaps inside the PDSE of unused data; free blocks were obtained using an algorithm that did not care where the blocks were located in the data set. Wayne Rhoten discussed at SHARE in San Francisco improvements to PDSE (V1) such that it now prefers lower-numbered RBNs to higher-numbered RBNs when looking for free blocks to store new member and directory data. This should make partial release work much better for PDSE going forward. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Change in PDSE Architecture (Was: SMPPTS Spill Data Set)
On 2/13/2013 1:37 PM, John Gilmore wrote: When I first heard about the scheme Edward Jaffe has just mentioned I did some simulations. If optimality is identified with extents-used minimization they suggest that the new scheme will work better than the old one but not nearly so well as a full optimization, which would require the solution of an integer linear-programming problem having smallish embedded knapsack problems, a variant of the newsprint-roll cutting problem. But would that not require active data movement/cleanup whenever a block is freed? I think they settled for something they could pull off without radical re-architecture to the library or its serialization mechanisms. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: User Internal
On 2/12/2013 1:44 AM, גדי בן אבי wrote: My boss asked me to produce a report of all RESET commands that changed the Service Class of a job. Commands only? What about issuers of the IWMRESET macro? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS v2.1 preview
On 2/8/2013 7:41 AM, John Eells wrote: Edward Jaffe wrote: On 2/6/2013 6:16 AM, Paul Gilmartin wrote: FTPS, but not SFTP? Is this retroactive to products older than 2.1? As I understand things, this really has nothing to do with z/OS V2R1. Not sure why it's in the announcement. How else would (or should) we let people know? I was under the impression that this secure FTP requirement was across-the-board and not just z/OS 2.1. Perhaps I'm wrong. IBM is not limited to one announcement per Tuesday. Often, there are multiple announcements in one day. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS v2.1 preview
On 2/6/2013 6:16 AM, Paul Gilmartin wrote: o IBM plans to remove support for unsecured FTP connections used for z/OS software and service delivery October 1, 2013. At that time, it is planned that new System z software (products and service) downloads will require the use of FTPS (FTP using Secure Sockets Layer) or of Download Director with encryption. FTPS, but not SFTP? Is this retroactive to products older than 2.1? As I understand things, this really has nothing to do with z/OS V2R1. Not sure why it's in the announcement. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1?
On 2/5/2013 6:20 AM, Tom Marchant wrote: On Tue, 5 Feb 2013 09:08:53 -0500, John Gilmore wrote: Is this release in fact to be denominated 2.1? Doing so would break with IBM's tradition of beginning the numbering of new versions with 2.0 and the like That's version 2, Release 1. I don't think I've ever seen any release of IBM software denoted as release 0. Exactly. What IBM has done is entirely consistent with past numbering schemes. As always, with any version change, be on the lookout for changes in your EULA and other TCs. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe selling points
On 1/30/2013 9:13 PM, Itschak Mugzach wrote: I don't think that the writer of the document (Dr. Rubin) compares apples to apples. IBM mainframe does not operate the network (DNS, DHCP, AD, email servers and many other base services). there are some tens of servers that has no comparable service in the mainframe world. The mainframe, from this point of view, is just another server, and the comparison should compare mainframe applications vs alternatives (re-hosting, rewrite), or the other hand - moving a server application into the mainframe. Rubin asked the best question of all. Does the presence of mainframe(s) at the heart of an IT infrastructure make a business more efficient and save them money? No matter which industry he surveyed, the answer was a resounding yes. The only difference was by how much. There are many questions to be asked about IBM marketing strategy, most has been asked in this thread. Have you even thought why does Cobol program runs much faster on wintel then a mainframe? Why is sorting much efficient on wintel? A URL or official reference would be useful to help justify these assertions. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: mainframe selling points
On 1/31/2013 8:40 AM, Don Williams wrote: Does this mean a M/F developer needs to have deep pockets to be successful? Depends on your definition of deep. Last I checked it was $500/month for fully-supported remote development out of Dallas. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: mainframe selling points -- Start up Costs
On 1/31/2013 9:37 AM, Steve Thompson wrote: One programmer, who has roughed out a system, using VSAM or DB2, has, for the sake of argument, 2-3 man years of coding to do with debugging. So we will say 3 to include documenting and testing. US$500 * 12 * 3 = US$19,500Just for the system out of Dallas. Having paid many tens of thousands of $ in my younger days on a per-CPU-second basis for time-sharing to develop my software ideas, a flat $500/month for multiple developers using a fully-supported, private z/OS system with the latest hardware, an exhaustive software stack, and expert technical support seems pretty darn reasonable to me! By comparison, an MSDN Visual Studio Ultimate subscription from Microsoft is $13K + $5K/year PER DEVELOPER, doesn't include hardware or system configuration expertise, and provides only four tech support incidents per year. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe selling points
On 1/29/2013 10:27 PM, David Crayford wrote: It offers vendors who have no need for a sysplex a cheap development/testing/demo environment that they can run on a laptop, desktop or rack server. As of December 2010, zPDT supports virtual coupling facilities for z/OS guests running under z/VM. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe selling points
On 1/30/2013 10:30 AM, John McKown wrote: From what I remember, zPDT can only be used for software development activities. Yes, you can run CICS and DB2 on it. But not production work. I.e. you can't have your company's general end-users logging onto CICS and doing production work which runs the business. I guess they could do QA testing. zPDT is for software developers only. RDT (based on exactly the same technology) is for customers. http://www.ibm.com/software/rational/products/devtest/systemz/ -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe selling points
On 1/30/2013 1:32 PM, Dana Mitchell wrote: Thanks Tony! thats exactly my point. Since IBM sells z, Power and intel boxen, they don't have to be competetive with themselves, that could be seen as canabilazation. IBM i is in a similar position in IBM as z/OS customers. Most that could easily convert off have done so. The ones left must pay the premium price to continue running. The cross-industry study conducted by Rubin Worldwide found that businesses with mainframes are more efficient and less expensive to operate. http://rubinworldwide.com/files/Mainframe_Economics.pdf Specifically: o 44% lower cost per credit card transaction o 31% lower IT spend per consumer loan o 26% lower cost per new vehicle o 25% lower cost per mega watt hour produced o 25% lower cost per retail store o 24% lower cost per hospital bed o 23% lower cost per barrel of oil o 20% lower cost per airline passenger Exhaustive TCO studies, conducted in actual customer environments, continue to show that mainframes are less expensive Enterprise technology to own, operate and upgrade that alternative platforms. https://share.confex.com/share/117/webprogram/Handout/Session9795/SHARE%20Orlando%2009795.pdf -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe selling points
On 1/29/2013 11:39 AM, Don Williams wrote: System z is not cheap (does it start around $1M?). OMG. I hope not! According to http://tech-news.com/publib/, a z114 2818-A01 lists for around $75K. I suspect in practice you can get them for far less, especially at the end of a quarter. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe selling points
On 1/29/2013 1:51 PM, Don Williams wrote: Good. I was skimming somewhere and I though I saw an small EC12 listed near a $1M. Of course, that a good bit bigger than an small z114. Right. Smallish shops like ours are hoping/praying for a zBC12(?) model to arrive some time this year. Even the smallest zEC12 is too large. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM documentation - anybody know the current tool? (from Mislocated Doc thread)
On 1/28/2013 7:17 AM, John McKown wrote: I guess in the past IBM was using DCF for their z series documentation. Apparently they are getting away from this. Out of curiosity, does anybody know what tool they are using now to create the Information Center abomination? All IBM documentation is authored in DITA, an XML-based documentation format which transforms easily into Eclipse plugins which are then displayed by the IBM Eclipse Help System (IEHS). http://www.ibm.com/developerworks/xml/library/x-dita1/ -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mislocated doc (was: ... STOW Initialize?)
On 1/28/2013 10:29 AM, John McKown wrote: I don't know much about Information Center. But I would likely be tempted to use wget or curl to clone the entire web site. Probably not within IBM's terms of service, but there are ways to slow down the cloning so that it does not swamp the site. However, once I had done that, I don't really know what I'd do with the data. Part of my dislike is that I sometimes just don't get the best response time. Of course, the Internet does not have any kind of guaranteed quality of service. Too many different paths possible. Another thing I don't like is being dependent on _our_ LAN people for Internet access. Especially during off hours, like the weekends. We run an InfoCenter on z/OS. It has many of IBM's books as well as ours. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO ALLOCATE REUSE ENQ?
On 1/21/2013 3:08 PM, Paul Gilmartin wrote: So much background for such an apparently simple command. MVS allocation is not a simple topic. Never has been. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running the RB chain of an inactive TCB
On 1/17/2013 11:12 AM, Mark Henderson wrote: Can someone explain to me the apparent contradiction in the following two pieces of information ? From the serialization section of SYS1.MACLIB(IHARB): If the task is not running and the local lock is held, the RB chain will not change. From APAR PQ81630: PQ76702 introduced code for MVSTCB TCB statistics. DFHDSMT calls DFHDSAUT for these statistics in routine CREATE_SNAPSHOT. DFHDSAUT will loop in routine TCB_SCAN due to not serializing the RB chain. A MVS local lock is not enough to serialize the RB chain. When begs the question: if local lock is not enough, what serialization should be used? ;) More than likely the RB chain of a dispatchable TCB can be 100% safely traversed only while running in that TCB. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SHARE Tailgate Party
SHARE in San Francisco begins on Sunday, February 3rd, 2013 -- the same day as the Super Bowl. SHARE is taking the opportunity to create a tailgate party themed reception so that everyone can watch the game together: 2:30pm – 7:00pm: SHARE Tailgate Party. This party will replace our Sunday evening reception. All attendees and volunteers are welcome. The SHARE Board and Staff have been working to create a fun atmosphere with large-screen TVs, tailgate food and beverages for us to watch the big game with our friends and colleagues. This should be a blast so pass the word about this event! See you then... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beware BPXWDYN (Was: Problem with REXX using OMVS stuff...)
On 1/14/2013 8:38 AM, Kirk Wolf wrote:
Right: It makes sense to me that BPXWDYN would have to dub if you had
MSG(2).
Ed: is that what you had?
The REXX consists of simple free statements (e.g.):
rc = BPXWDYN(free dd(SYSPROC))
rc = BPXWDYN(free dd(SYSEXEC))
rc = BPXWDYN(free dd(ISPLLIB))
rc = BPXWDYN(free dd(ISPPLIB))
...
followed by simple alloc/concat statements:
/* Allocate SYSPROC */
say *** Allocating SYSPROC ***
rc=BPXWDYN(alloc dd(SYSPROC) shr reuse da('clist'))
rc=BPXWDYN(alloc dd(CLIST2) shr reuse da('SYS2.CMDPROC'))
rc=BPXWDYN(concat ddlist(SYSPROC,CLIST2))
rc=BPXWDYN(alloc dd(CLIST3) shr reuse da('USER.CLIST'))
rc=BPXWDYN(concat ddlist(SYSPROC,CLIST3))
rc=BPXWDYN(alloc dd(CLIST4) shr reuse da('ADCD.adcdver.CLIST'))
rc=BPXWDYN(concat ddlist(SYSPROC,CLIST4))
...
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New Blog
On 1/11/2013 1:12 PM, Mary Anne Matyaz wrote: For those interested, Marna Walle has a new blog on the SHARE website...you can read it at http://www.share.org/p/bl/bl/blogid=12 Also, Mary Anne's always-entertaining 'MVS blog' is now accessible without the need to login to the SHARE web site: http://www.share.org/p/bl/et/blogid=9 -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More eBay Mainframes
On 12/14/2012 12:27 AM, Timothy Sipples wrote: Among the more interesting ones are a ~25 MIPS System z10 BC listed at $35,000 (which would be eligible for zELC licensing and which has a full capacity of 3 MSUs), a ~50 MIPS z890 listed at $9,999, and a ~46 MIPS z890 also listed at $9,999. Shipping seems to be free within the U.S... When we ran up against the No z10 memory upgrade MES issue, we were going to buy this machine and donate it to our IBM business partner (Mainline) in exchange for the 8GB of memory inside. But, the outrageous price IBM wanted to enable that memory put the kybosh on the deal. It would have been fun to buy a z10 on eBay!! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OOCoD Question
On 12/12/2012 5:58 PM, Alan Field wrote: If I turn on Capacity on Demand (i.e. make our 507 look like a 509 say) will our software that looks at CPU model recognise the change? Software will obtain the configuration information on its own schedule. Some will get your configuration at startup. Some will listen for ENFs to detect increases and decreases and get your configuration dynamically. Some will check periodically or when someone uses the product interactively. All should see current model=509, permanent model=507, and temporary model=509 but only enlightened software will care about or do anything with the second two values. For example, (E)JES compares your license against your permanent model only, so you get to run temporarily upgraded mode with no warnings, messages, or other encumbrances and best of all--for free. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AMODE and RMODE for tables above the bar
On 12/10/2012 7:58 AM, John Gilmore wrote: Now it is clear that these addresses (or null pointers) must be doubleword, AMODE(64) ones and that executables that access them and make use of these addresses must also be AMODE(64)... It is and has been my contention that to mark such table objects as AMODE(x) when x is not 64 is hubristic at best. It would now, I think, be perverse to do so. They can be loaded below the line (sic). They cannot usefully be accessed by other than AMODE(64) code, wherever they may be resident. I agree you should mark these modules AMODE(64). Why? Because it is in keeping with the existing rule that AMODE cannot be more restrictive than RMODE and you've made it perfectly clear that you would link these modules RMODE(64) if you could. Consider a module with AMODE(24), RMODE(24). One can readily change it to AMODE(31),RMODE(24) or even AMODE(64),RMODE(24). But, the moment you try to link the module with RMODE(31), the AMODE(24) option is disallowed: IEW2322I 1220 25 MODE AMODE(24),RMODE(31) IEW2658E 5119 USER-SPECIFIED AMODE(24) AND RMODE(ANY) ARE INCOMPATIBLE. Likewise, it's pretty obvious that AMODE(64) will be the only allowable addressing mode in a hypothetical future in which the binder allows direct specification of RMODE(64). Why not get a head-start and specify that now? P.S. the binder already supports RMODE(64) program objects that contain C_WSA64 data classes only. These program objects will be loaded above the bar by program fetch. I have not yet seen them used, but I suspect the AMODE values on such program objects are always AMODE(64). -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
I/O Control Blocks Below 16MB (Was: Who loaded me?)
On 12/9/2012 7:19 AM, John McKown wrote: I use RMODE(SPLIT) all the time to put my I/O CSECTs into RMODE(24) storage, while leaving the other CSECTs in RMODE(31) storage. I assume this is for non-reentrant code only. Of course, DCBs and DECBs must still reside below 16MB (that usually works out to somewhere around 100 bytes of LOC=24 virtual storage per file--a little more if you use exit lists). But, there is no need for the code that performs OPEN, CLOSE, GET, PUT, READ, WRITE, or even EXCP or STARTIO to be RMODE(24). -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage Obtained By an SRB
On 12/9/2012 2:56 PM, Micheal Butz wrote: Can you issue STORAGE OBTAIN,LENGTH=LENGTH_VALUE,SP=0 In Srb mode RTFM. It took me less time to look up than it did to copy/paste below! :0 STORAGE: Environment: Dispatchable unit mode: For LINKAGE=SVC: Task For LINKAGE=SYSTEM, LINKAGE=BRANCH, or LINKAGE=GLOBALBRANCH: Task or SRB -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Long PDSE Member Names (Was: LOAD and DELETE ...)
On 12/7/2012 5:22 AM, McKown, John wrote: I've read that PDSE's can even have member names 8 characters, but I've not run across one yet which does. (We're a small shop and don't have much advanced software installed). Much of our software supports 64-character PDSE member names. Long names look great! ISPF should support them... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On 12/6/2012 10:47 PM, Robert A. Rosenberg wrote: It is if the module contains relocatable doubleword pointers to locations within itself and these would not be resolved correctly if you just coded AMODE(31). Note that I am not sure what resolution would occur with AMODE(31) but the module residing above the bar - I am just suggesting that it is safer to code AMODE(64) even if AMODE(31) would still fill in the high word. AFAIK, program object fetch performs ADCON relocation without caring at all about the module's AMODE. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Who loaded me?
On 12/6/2012 2:09 PM, McKown, John wrote: My mistake. A major CDE points to a XTLST, IHAXTLST macro, which contains the load point and length. Interesting question on RMODE(SPLIT). Guess I'll need to code up something and ABEND it to get a dump to see what I can see. XTLST is an extent *list* -- both extents are shown. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Changing PMR Severity (Was: Makes me love most of my z/OS software vendors)
On 11/29/2012 10:55 PM, Timothy Sipples wrote: Nevertheless, you are allowed to mark the problem incident as Severity 1 whenever you have somebody on shift.(*) Therefore it's possible to have your first qualified support person come in at, say, 8:00 a.m. and raise the PMR to Severity 1. Then, as your last qualified support person turns the lights out, that person lowers the PMR to Severity 2 (or lower if appropriate). Loop, repeat if necessary. That's entirely within the rules and even expected/recommended if you have a problem requiring Severity 1 attention from IBM. Interesting concept. Is this a common practice? Is anyone on IBM-MAIN routinely doing this? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing PMR Severity (Was: Makes me love most of my z/OS software vendors)
On 11/30/2012 10:20 AM, McKown, John wrote: To me, and to every shop I've ever worked at, SEV 1 means we're dead and we are all staying here until we are working again. One time, this meant a 36 hour shift for all 3 sysprogs. I was much younger then. The inability to run daily system backups doesn't, on the surface, seem to rise to the level of SEV1. (Your systems are not DOWN!) OTOH, if while waiting for a diagnosis/fix you lose an important data set or even an entire DASD volume and don't have a suitable backup, things could get VERY painful VERY quickly. Maybe they need a SEV 1.5. ;) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing PMR Severity (Was: Makes me love most of my z/OS software vendors)
On 11/30/2012 12:12 PM, Gibney, Dave wrote: I have become curious. I know you run multiple Lpars at different levels of z/OS. It seem s unlikely to me that HSM is failing in all of them. And that you should be able to get your back-ups, at least temporarily form a working copy :) In this particular parallel sysplex we happen to be running three systems: two at z/OS 1.13 and one 'other' z/OS release. IBM's support structure for the 'other' z/OS release is not as robust as for z/OS 1.13, so we run the daily backups under z/OS 1.13 only. Follow-up: Based on the PDA logs, IBM thought that one large (5000 cylinder) ZFS seemed to be a trigger for whatever the problem was. We backed that up manually via BACKDS command and then the normal dailies started working again. (Whew!) In fairness, a big part of the delay in analyzing this SEV2 problem was the Thanksgiving holiday and the weekend. That added four days right there. If it's been a week since your last good backup, people start to get a little nervous... :-\ -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing PMR Severity (Was: Makes me love most of my z/OS software vendors)
On 11/30/2012 12:44 PM, Mark Zelden wrote: With all the EAV fun you've already had, was that on an EAV volume in cyl managed space? Lol! You call that fun?? :D This most recent issue was on, what some people on this list would call, a 'MOD-81' volume. It is an EAV, but the 5000-cylinder ZFS in question has no extents in the EAS. The pervasive data set corruption problems we had (that eventually led to the creation of APAR OA40210) were on, what some people on this list would call, a 'MOD-236' volume. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Makes me love most of my z/OS software vendors.
On 11/26/2012 8:01 AM, Mark Zelden wrote: Lucky you! It takes me at least 2 hands to count the times an ISV product has crashed a system I've worked on. And these were supported versions. Things like PSA overlays, UCB overlays etc. Of course over the years IBM has added lots of code and features to repair critical control blocks and there are captured UCBs etc., so it less frequent. None of these comments include IBM's own bugs that have crashed systems. Not a crash per se, but we have not been able to back up our z/OS systems for over a week because HSM is crashing on a wild branch. We can't make PMRs Sev1 because we don't have a 24/7 response team and without Sev1 IBM works much more slowly than we do. :( -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On 11/28/2012 12:39 PM, John Gilmore wrote: I must, however, add that unpredictable is sometimes in some IBM publications used as a polite euphemism for It's too complicated to explain here, and you wouldn't understand anyway. Sometimes they do that because they get pressured to retrofit a cool new instruction back to an older model and there is no way to make the older model work correctly. For example, it used to be undefined which space instructions were fetched from while in cross-memory mode. The logical choice was primary (and the hardware designers knew that) but they were unable to make it work on the older processor to which the function was being retrofit. We (software developers) suffered for at least a decade with that ugly restriction. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On 11/29/2012 4:29 AM, Lloyd Fuller wrote: The latter can also run into issues in AMODE 64. The index register is always 32 bits, not 24, 31, or 64 depending upon AMODE. Waste the extra nano-second, use the comma. It is meaningful. In forming the intermediate sum, the base address and index are treated as 64-bit binary integers.A 12-bit displacement is treated as a 12-bit unsigned binary integer, and 52 zero bits are appended on the left. A 20-bit displacement is treated as a 20-bit signed binary integer, and 44 bits equal to the sign bit are appended on the left. The three are added as 64-bit binary numbers, ignoring overflow. The sum is always 64 bits long and is used as an intermediate value to form the generated address. The bits of the intermediate value are numbered 0-63. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SYNCSVCD (Was: What happens when an LPAR gets interupted.)
On 11/21/2012 1:04 PM, Jim Mulder wrote: So if you have changed your program to take work which used to run under a TCB and instead run it under an enclave SRB so that you can run it on a zIIP, you may experience some reduction in serviceability because this work will no longer be automatically stopped by SDUMP while SDUMP is capturing the address space. And this restriction is *highly* inconvenient! :0 In the old days an instruction fetch PER SLIP could be specified with A=SYNCSVCD and a sticky problem could be solved. Now you get msgIEA426I and a dump that is worthless. Our zIIP-enabled code is designed to run in TCBs when no zIIPs are configured. Therefore, we can issue the customer a one-byte ZAP to disable enclave SRB use when a SYNCSVCD is needed to solve a problem. It's inconvenient, but it works. Any ISV with a design that *always* uses enclave SRBs is SOL. :( -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What happens when an LPAR gets interupted.
On 11/22/2012 6:49 AM, Ron MacRae wrote: 99% of the work in the PAS comes from other SASs via XMS PC calls and gets routed to long running SRBs via wait/post. That would be a neat trick since an SRB cannot WAIT or be POSTed. Perhaps you're using pause/release or suspend/resume? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic DCB [was New way to do UCB lookups]
On 11/19/2012 2:48 PM, Farley, Peter x23353 wrote: You do know that the DCBE's can be in 31-bit storage, right? That's the one address in a DCB that is a 31-bit address. And you can share them among DCB's, so you don't have to have a 1-to-1 correspondence between DCB's and DCBE's. Really? You can share a DCBE among several DCBs? I'm skeptical. Where is that documented? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding Time Sharing
On 11/17/2012 2:30 AM, Quasar Chunawala wrote: ... why should a time-slot be given to a TSO user, who hasn't pressed an AID key(like Enter)? Maybe, he's just staring at a dataset. Isn't this a waste of processor-time? Or am I missing out something. No CPU time slice is provided to any unit of work that is suspended for any reason, including terminal I/O. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Z196 and z/OS 1.4
On 11/12/2012 10:13 PM, Andre Massena wrote: Some bits need to be massaged (STCP) but all old releases of z/OS and OS/390 for that matter will run under z/VM. They said it would not work. But, we run z/OS 1.4 under z/VM 6.1 on a z10BC. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Z196 and z/OS 1.4
On 11/14/2012 12:52 PM, Bob Shannon wrote: Ed - In our environment it didn't work. They said it wouldn't work and for us it didn't. That's all I know. Our z/OS 1.4 z/VM guest is vanilla, brand new out-of-the-box, completely unserviced without any optional feature downloads applied (e.g., the console restructure). How about yours? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SRB
On 11/9/2012 4:30 AM, Peter Relson wrote: The Space Token (STOKEN) for an address space is in ASSBSTKN. It used to be that this was not considered a programming interface and that you were expected to use ALESERV EXTRACTH to obtain it. We decided that was relatively ridiculous since internal usage of ASSBSTKN was pervasive, so you now may reference this field. Glad to hear it. I'm pretty sure 'external' references to this field are also pervasive. ;) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z10BC Memory Upgrade All-But Impossible
On 11/10/2012 12:10 PM, Thomas Conley wrote: From what I can see, IBM announced the z10EC in February 2008, and the z10BC in October 2008. Consider that most clients did not get them for 6-12 months after the announcements, and the June 2012 end of life statement gives just a little over 3 years useful life. You can't even depreciate a mainframe over 5 years now, let alone 7. While I can appreciate that IBM is innovating the platform, economics like this is really putting the squeeze on many IBM customers. How about government, where procurement can delay new systems for years? This is a very disturbing trend in zSystem economics, which IBM should reverse but likely won't. I guess I was researching this at the exact same time you were... z10BC became first available in 4Q08 and was withdrawn from marketing after 2Q12; the life cycle of these machines was 3 1/2 years. By comparison, z9BC first became available in 2Q06 and was withdrawn from marketing after 2Q10. So, its life cycle was FOUR years! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z10BC Memory Upgrade All-But Impossible
On 11/10/2012 2:25 PM, John Gilmore wrote: It is possible, even usual in many shops, to continue to use machines well after they have been withdrawn from marketing. The inability to obtain more storage or to activate a spare, already acquired CP is another, much more serious matter. That sort of thing apparently came later. How much later? Hardware memory upgrade MES for z10BC was discontinued after June 2012--coincident with marketing withdrawal. If you have pre-planned memory installed but not activated, you can still get the microcode memory activation MES until June 2013. But, the price has been jacked up so high ($8K/GB) that it might as well not be available at all! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z10BC Memory Upgrade All-But Impossible
On 11/10/2012 4:11 PM, John Gilmore wrote: Thank you. It's difficult to avoid the conclusion that the objective of these moves was the very short-term replacement of the z10BC by another, newer and less 'specialized' model. Or perhaps a way to increase hardware revenues? -- Edward E Jaffe Chief Technology Officer Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z10BC Memory Upgrade All-But Impossible
Those of you with z10BC machines waiting for the z12BC to come out had better learn to make do with what you have. Keep in mind that z10BC is just _one_ generation removed from the current z114 business class machine. Nevertheless, hardware MES were withdrawn earlier this year and microcode MES are announced withdrawn as of June 2013. A memory upgrade is both hardware (the physical DIMMs) and microcode (enabling the memory). The only way to get additional memory for a z10 these days is to buy it on the used market. And, IBM is charging a premium price for the magic screwdriver to enable this memory: $8K/GB! Thus, a 16GB memory upgrade would cost $128K in services PLUS the cost of the memory itself! (FYI. You can buy a brand new z114 machine for that...) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z10BC Memory Upgrade All-But Impossible
On 11/9/2012 5:46 PM, Shane Ginnane wrote: Customers rebelled against the constant need to update the OS we've had to dance to over the last few years, and IBM changed its tune. To the best of my knowledge, there was no customer rebellion. Rather, customers were taken completely by surprise by IBM's sudden z/OS release schedule change. There never was a constant need to upgrade the OS; upgrading every year was optional. Now that choice has been stripped away in an effort to reduce costs. Maybe the same will come to pass on the hardware side as well. I don't follow processor hardware life cycle details quite as closely as z/OS, but it seems to me that memory upgrades were withdrawn much earlier for z10 than for previous models. That is perception only; I have not verified as fact. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NY Metro NaSPA Chapter Meeting: Tuesday, 30 October 2012
On 10/14/2012 9:29 PM, Mark Nelson wrote: The next meeting of the NY Metro NaSPA Chapter will be on Tuesday, 30 October, 2012, in room 1219 at the IBM Building at 590 Madison Avenue, New York City, from 10:00 AM until 4:30 PM. We are following the same registration process as we followed for our March 2012 meeting. Please see below for the details. Sessions for the day include: What System z can do that Intel based Systems can’t, David Rhoderick, Manager of the IBM Software Group System z Competitive Project Office The What and Why of System z Millicode, Bob Rogers, Distinguished Engineer, IBM Wow! Talk about distinguished guests! It's not often I wished I lived in the New York City area... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
On 10/9/2012 8:16 AM, John Eells wrote: Edward Jaffe wrote: snip Oh, and did I mention that this is done on a LIVE system? We have no time or personnel to 'clone' systems, switch between res packs, etc. for regular maintenance. OK, Ed, I gotta say it: Tick...tick...tick... LOL! Did you read that we have been doing it this way for 15 years? We idle a system, run the APPLY, and then re-IPL immediately afterwards. What could be simpler? It's not unlike what Windows Update does to my PC every few weeks. In the rare event that the system won't IPL, we use other systems sharing the same DASD to solve the problem e.g., update a parmlib or proclib member, rebuild the IPL bootstrap, RESTORE or APPLY a PTF, etc. Thus far (knock on wood) such issues have been only occasional, minor inconveniences. Of course, full volume DASD backups are available should it ever come to that. Did you attend Ed Webb's SHARE presentation in Anaheim? I'm not sure how long they've been applying service to live systems, but his abstract says he has 40 years of experience so he's not a noob. It was a popular session. If you missed it, I believe the MVS Core Technologies Project is planning a repeat for SHARE in San Francisco in February. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
On 10/7/2012 8:43 AM, Jeremy Nicoll - ls mainframes wrote: Edward Jaffe edja...@phoenixsoftware.com wrote: As a part-time sysprog, I abbreviate your approach even more. I have no time for pesky 'CHECK' operations. Do you chase down the prereq/coreq chains by hand then? No. Unless you use BYPASS for other than HOLDSYS (which I don't), APPLY will automatically refuse to install anything with missing pre- or co-reqs. This is exactly the behavior I want. There's nothing required of me to make SMP/E do the right thing. I do remember that many, many years ago I used to run APPLY CHECK so that I could see which libraries were going to be affected by the APPLY. I would inspect the FILE ALLOCATION REPORT at the bottom of SMPRPT and that would tell me which libraries to compress and which HFS/ZFS to mount read-write. I've since found it easier to always blindly compress everything and mount all HFS/ZFS read-write in preparation for the APPLY. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
On 10/7/2012 3:33 AM, Gibney, Dave wrote: I learned the hard way. It was the first upgrade I was part of, I came in in the middle and they were cutting corners applying to the live system. It really breaks when the attempt to apply a PTF to IEBCOPY blows space in LINKLIB and retry attempts to use the partially done copy of IEBCOPY to compress that active LINKLIB. I noticed that, on slide 22 of his SHARE presentation, Ed recommends compressing SYS1.LINKLIB (and a few other key libraries) in advance of actually running the APPLY. That step might be intended to avoid exactly the sort of issue you're describing. ISTR that in the old days IEBCOPY was designed differently than it is now; multiple load modules, perhaps even an overlay structure. Not any more. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
n 9/6/2012 8:31 PM, Skip Robinson wrote: I have never understood the fixation with rock bottom return codes. SMP/E maintenance is so much simpler without agonizing over every uneven cobblestone along the path. LOL. You have provided an excellent description of, what I consider to be, the most logical way to use SMP/E. Unless you're trying to fix a specific problem with a specific PTF, just put on the service that goes on smoothly and leave everything else alone. Don't sweat the details! As a part-time sysprog, I abbreviate your approach even more. I have no time for pesky 'CHECK' operations. I submit a job that does an ACCEPT for all 14 DLIB zones we actively maintain. Space problems and the like are corrected and the job resubmitted if necessary (usually not). I then submit the job that does an APPLY for all 14 actively-maintained target zones. Again, space problems etc. are corrected and the job resubmitted if necessary. The whole thing usually takes about an hour when there are no space or other issues. Then we conduct a rolling IPL. Oh, and did I mention that this is done on a LIVE system? We have no time or personnel to 'clone' systems, switch between res packs, etc. for regular maintenance. Our philosophy is similar to that described by Ed Webb at SHARE in Anaheim in session 11581: A Different Way to Perform z/OS Maintenance. https://share.confex.com/share/119/webprogram/Handout/Session11581/A%20Different%20Way%20to%20Perform%20zOS%20Maintenance.pdf -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E question
On 10/6/2012 1:03 PM, Skip Robinson wrote: Would not APPLY CHECK have revealed the missing PTF before any real harm had been done? If not, then never mind. No. The APPLY CHECK would not have helped in that case. Nothing was missing and there was nothing SMP/E could have done differently. Both co-req PTFs were available and were being installed together in the same APPLY but there was an out-of-space space failure on the ZFS at APPLY time. A logic error in the z/OS UNIX install shell script caused it to do the wrong thing such that, after the space issue was resolved, a second APPLY attempt of the PTFs would always result in a deleted JDK. (The script made an invalid assumption that one of the PTFs was already fully installed because it found a build part from that PTF in the target directory.) The fix was to correct the erroneous logic in the z/OS UNIX install shell script. See http://www-01.ibm.com/support/docview.wss?uid=swg1IV05507 I recognize that, compared to the experience of some of the old-timers on this list, I've been servicing our systems this way for a relatively short time (only about 15 years or so). I'm prepared for the very real possibility that I might come across a pathological situation that will be inconvenient enough to convince me to do things differently. Or perhaps I will retire first, who knows? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Proof That Dinosaurs Can Learn New Tricks
Proof that dinosaurs can learn new tricks, I wrote my first 'blog' entry -- EVER -- and it is on SHARE's web site. http://www.share.org/p/bl/ar/blogaid=167source=6 -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zOSMF Zones
On 8/21/2012 12:36 PM, Bob Shannon wrote: Having been forced to order zOSMF, does one install it in the z/OS zones or in its own zones? Dunno which way is best, but IBM installs z/OSMF into its own zones on the ADCD. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Communications Server
On 8/20/2012 11:34 AM, Skip Robinson wrote: How about Netview questions? There is netv...@yahoogroups.com where Tom Howe is an active participant; the best Netview list in cyber-space! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The IBM zEnterprise EC12 announcment
On 8/28/2012 7:27 AM, Knutson, Sam wrote: The biggest surprise for me was zAware the new monitoring appliance running in an LPAR. This appears to be chargeable and currently just monitoring messages but moving infrastructure overhead and function out of the z/OS space into an LPAR is the MIPS Vacuum for this type of workload I have hoped to see for a while now. When I first heard about this, I thought of you right away, Sam! I sorely wanted to ask if you had any direct input into this design! :-) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: X86 server
On 8/13/2012 10:01 PM, Jake anderson wrote: Does IBM provides support running Z/OS on X86 ? Yes, with its RDT offering: http://www.ibm.com/software/rational/products/devtest/systemz/ -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mvcl/mvcle padding byte
On 8/16/2012 6:45 AM, zMan wrote: I suspect Ed was pointing out that the content of the padding byte can affect the result of an MVCL -- that is, the resulting *data*. I was talking about using the 'cache bypass' capability of MVCL (also MVPG). Dragging large amounts of memory around from one place to another through L1 cache is expensive and also has the side effect of flushing other lines that probably need to be immediately brought back in after the MVCL completes. Of course, the source and target memory addresses must be aligned just right to take advantage of cache bypass. But, if you're moving (for example) 4K pages on a 4K boundary you should see measurable performance differences. If your addresses are unaligned, then there is no difference. -- Edward E Jaffe Chief Technology Officer Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GOFF
On 8/20/2012 3:11 PM, Frank Swarbrick wrote: I am converting to assembler subroutines, which are called by (Enterprise) COBOL programs to do various things, to make them re-entrant. Is there any reason I should not change my assembler options to specify GOFF? GOFF is only a problem if you need to link on a severely back-level binder or linkage editor or on a non-z/OS system. Otherwise, it's great! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SHARE MVS Program Survey - Your Participation Requested
The SHARE MVS Program has created a survey to help determine which topics to include in upcoming conferences. The survey contains a list of z/OS enhancements that we think should be implemented in most installations. Many of these aren't implemented and we'd like your input to understand why. Our Projects will use the survey results to help adapt session focus in these areas. The list itself is very interesting and you'll be able to compare your installation to others after the survey concludes. Already a SHARE member? Go to http://www.share.org/MVS and use your existing SHARE login and password, or click the link at the bottom of the page for reset options. From http://www.share.org, you can also select 'Our Community', and then select the 'MVS Program' as the Area of Interest. Not a SHARE member? It’s easy to create a web user profile! * Visit http://www.share.org/membership * Check to see if your company is already a SHARE member – there’s no cost to you or your company to be added to the membership, and you’ll receive full member benefits! * If your company is not a member, select “Non-Member Account”. You’ll be asked to provide your contact information and optional demographic information. This should take less than 5 minutes to complete. * Your request to access SHARE.org will be approved within one business day. If you need to expedite this process, please call (888-574-2735) or email SHARE HQ (shar...@share.org) and request immediate access. * Follow the instructions above to access the survey. [Shameless Plug: If you haven't seen the new SHARE website, you'll be impressed by the many new features such as a z/OS blog, user forums, access to prior years' proceedings, free webcasts, and additional publications.] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Show the //SYSIN DD * lines when using TYPRUN=SCAN?
On 7/12/2012 3:57 PM, Paul Gilmartin wrote: On Thu, 12 Jul 2012 21:27:37 +, Gibney, Dave wrote: Using the ST(atus) display instead of I, H, or O generally shows all the info you want. However, IIRC, it does not show SYSOUT dynamically allocated from a z/OS UNIX (USS) session. Something about such sessions are not jobs, thus not eligible for ST. Ed Jaffe, whom I trust fully, has said that (E)JES has an all-in-one display. I wish we could afford (E)JES for all our systems. I value your trust... :-) Yes, we go to great lengths to display so-called spin-off 'jobs' (those created via subtask JSAB) as if they are 'normal' jobs. For example, they are surfaced on STATUS and other job-oriented tabular displays. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Show the //SYSIN DD * lines when using TYPRUN=SCAN?
On 7/13/2012 5:47 AM, Shmuel Metz (Seymour J.) wrote: In 6700504004248585.wa.paulgboulderaim@listserv.ua.edu, on 07/12/2012 at 10:41 PM, Paul Gilmartin paulgboul...@aim.com said: TYPRUN=SCAN's checking is a bad joke. IIRC, it fails to report errors as fundamental as DSNAME 44 characters. Is that true in JES3 or only in JES2? That particular error should be caught be the Interpreter, which JES2 does not invoke until the job is selected for execution. Not true in JES3. Both converter and interpreter are invoked at C/I time before the job is queued to wait for an initiator. The JCL errors JES2 does not catch are caught by JES3. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Moving JES2 spool volumes
n 7/10/2012 3:02 PM, Skip Robinson wrote: We need to move an R13 JES2 MAS onto new spool volumes. R13 introduced the $MSPL command to migrate/move spool dynamically. We have not used $MSPL. Any advice? Make sure all of your IBM and ISV products can support remapped JES2 SPOOL addresses (MTTRs and MQTRs). If they use only standard, JES2-provided facilities to read SPOOL then all should be fine. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Quantas hit by leap second issue?
On 7/4/2012 5:11 PM, zMan wrote: On Wed, Jul 4, 2012 at 4:25 PM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: He started out right but then got turned around. Homonyms are words that are spelled the same but mean something *different*; he was confusing homonym with synonym. So USS and USS would be a case of a ... Dead horse. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBPTPCH questions
On 6/19/2012 7:02 AM, McKown, John wrote: AMATERSE ... With PARM=UNPACK, it restores the original dataset while dynamically allocating it (and can create it as well). AMATERSE can dynamically allocate the original data set? It can create it as well?? Is this behavior documented??? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF volume - follow-up
On 6/22/2012 7:00 AM, Mark Zelden wrote: Reminds me of a joke in the recording studio when doing a mix and to make everything louder than everything else. :-) Or when on-stage and everyone keeps turning up their volume... :-) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why is GRS ENQ needed in SMFDUMP program?
On 6/22/2012 5:37 AM, McKown, John wrote: I am fairly sure that Shmuel's comment was about the RESERVE macro, not the hardware function. The RESERVE macro is logically equivalent to a SYSTEMS level ENQ plus a hardware reserve (unless the GRSRNL converts it to not do the hardware RESERVE). And, IIRC, the RESERVE macro generally does not immediately result in the hardware reserve being done before returning to the user. It simply marks the UCB somehow so that the hardware reserve is done at the beginning of the next I/O operation on the device. I'm not sure that this is still true or not. Still true unless SYNCHRES(YES) is specified on the GRSDEF statement in GRSCNFxx. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
