Re: IBM(r) z/OS(r) Management Facility (z/OSMF)
On 5/24/2012 8:46 AM, Martin, Larry D wrote: I think it is a really good tool. The security, however, is very complex. If you are a RACF shop then you are in good shape. We are Top Secret and it was a real struggle. Lol! z/OSMF security has been a struggle for RACF shops too! :D This is primarily due to the fact that there are many components (CIM, CEA, WebSphere, etc.) that most shops have never configured before. Doing it all from scratch can be quite a bit of work. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBM(r) z/OS(r) Management Facility (z/OSMF)
On 5/24/2012 9:44 AM, Knutson, Sam wrote: z/OS role of Explorer Eclipse GUI was updated to use that in V1.1.1 but it does require z/OS 1.13. That combination will let you look at running jobs with Explorer. The price on Explorer is right... Free. I don't think CICS Explorer depends on any interfaces provided by z/OSMF. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
SHARE in Anaheim Schedule Available Online
The SHARE in Anaheim schedule is now available online here: https://share.confex.com/share/119/webprogram/start.html -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink outages in 2012
On 5/19/2012 8:20 PM, Pinnacle wrote: Let me know if I missed any. Clearly we still have a way to go for 24/7. 100%, 99%, 98.4%, 97.5%, 97.4%: clearly trending in the wrong direction. The average up-time so far in 2012 is 98.46% ... not even two nines. Of course, things look far worse if you consider weekends -- when most customer scheduled outages take place -- to be 'prime time' for IBMLink availability. :-\ -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Early IPL problems
On 5/18/2012 11:22 AM, Mark Zelden wrote: No, the complaint is that on emulated consoles attached via Tn3270 (2074, OSA-ICC and I assume Visira which I've never worked with) any messages that come out on the console along with the wait disappear immediately due to the RESET that happens along with the wait. Sounds like z/OS sysprogs need to ask their employers to pay for Evelyn Wood speed-reading classes. ;-) Seriously, I remember OS/2 had a similar issue. Before you could write down the information about a catastrophic trap, it would restart and blow away the screen. There was a special CONFIG.SYS parameter you had to code to prevent it from automatically restarting itself. Oh what fun... -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Servicelink, ETR and SR
On 5/17/2012 8:17 AM, Skip Robinson wrote: Same result here. It's nice to know that when IBM finally rolls out the big guns, they can still hit their own foot. And, after a 54-hour outage for the 'upgrade' ... smh -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Servicelink, ETR and SR
On 5/16/2012 3:46 AM, Barbara Nitz wrote: Given that IBM took away ETR yesterday and has by now forced SR upon the mainframe world - do Americans coming from servicelink also have to login again to get to their ETRs??? Or is this 'privilege' reserved for EMEA? Until ETR was taken away (yesterday morning our time) no extra login from Servicelink was required, SR was reachable using the normal servicelink login. I consider this an error and have opened a ticket. I complained about this behavior during a closed meeting with Christian Gilmore and other IBMers at SHARE in Orlando back in February. Christian acknowledged the problem and made a note of it at the time, but nothing has been done to change it (yet). -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: EXCP count like (E)JES
On 5/15/2012 11:23 AM, Miklos Szigetvari wrote: Is it possible to find the actual EXCP count value in the address spac ? ASCBIOSC DSF - I/O SERVICE MEASURE.@G381PXU * SERIALIZATION - CS. @G381PXU * UPDATED BY JES2,JES3,SMF. @G381PXU * READ BY RMF,SMF,SRM.@G381PXU -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: EXCP count like SDSF
On 5/15/2012 11:37 AM, Rob Scott wrote: Look at ASCBIOSX and ASCBIOSC in the ASCB (IHAASCB) ASCBIOSX DSD - I/O service measure extended. @0AC * This is like ASCBIOSC but it is @0AA * extended to 8 bytes, so its @0AA * value continuestto grow past the@0AA * 4GB ASCBIOSC maximum capacity. @0AA * Serialization - CSG.@0AA Oops. I forgot to mention the newer 8-byte IOSX field. Thanks, Rob! -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: EXCP count like SDSF
On 5/15/2012 12:20 PM, Bill Fairchild wrote: ... the comment in the ASCB's DSECT does not state whether or not the counter is reset at the end of each step or even at the end of each job. Reset at the end of each step. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SVC 99 trace
On 5/15/2012 11:26 AM, Miklos Szigetvari wrote: Searching for a tool to trace SVC 99(i.e. see the text units) (I had this several years ago, SLIP or GTF ?, unbale to find now) Use SLIP IF with A=SYNCSVCD to produce an SVC dump just after the SVC99 is issued. In IPCS select 'SVC99RB' from the 2.6i menu. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Reducing Common Area below 16M line
On 5/13/2012 8:24 AM, Lim Ming Liang wrote: I need some lesson on reducing Common Area below the 16M line. Anyone can give me some 101 on increasing the private area size below 16M line ? Or any guides or manual will help me to embark on this ? First you need to determine the actual size of your private area and common areas below the line. Look at any SVC dump on your system using IPCS. Selection Option 2.6I. From that list select 'VSMINFO'. You will see a virtual storage map similar to the one I've pasted below from one of my systems. To increase the private area, you need to move MAX USER REGION ADDR up by one 1 MB. As you can see, my MAX USER REGION ADDR (and CSA BOTTOM) is x'B0' and PLPA BOTTOM is x'D2D000'. The size of my CSA is therefore x'22D000' or 2228K. My CSA= specification is IEASYSxx is CSA=(1536,81920) so I was given an additional 698K of CSA due to rounding. So, if I were to increase my private area 1 MB (1024K) by donating CSA, I would need to reduce my CSA specification to CSA=(1204,81920). You can also donate from anything below R/W NUC BOTTOM such as SQA, PLPA, FLPA and MLPA. CVT: 00FDCF48 GDA: 022DF3B0 LDA: 7FF19E10 PRIVATE STORAGE DATA SHOWN IS FOR DEFAULT ASID: X'44' STORAGE MAP ___ 8000 - TOP OF STORAGE | : EXT LSQA/SWA/229/230 | 8000 - MAX EXT USER REGION ADDR |E:_| 7F07 - ELSQA BOTTOM |P: (FREE EXTENDED STORAGE) | |V:_| 13B24000 - EXT. USER REGION TOP |T: EXTENDED USER REGION | |===| 0C40 - EPVT BOTTOM | EXTENDED CSA (ECSA) | -- NO ECSA TO ESQA CONVERSION -- |___| 073F5000 - ECSA BOTTOM | : EXTENDED MLPA (EMLPA) | |E:_| 073E7000 - EMLPA BOTTOM |L: EXTENDED FLPA (EFLPA) | |P:_| 073E4000 - EFLPA BOTTOM |A: EXTENDED PLPA (EPLPA) | |___| 03B44000 - EPLPA BOTTOM | EXTENDED SQA (ESQA) | |___| 01ADF000 - ESQA BEGINS | :_| 01ADEFFF - EXT. R/W NUC TOP |E: | |N: EXT R/W NUCLEUS | |U:_| 01A7F000 - EXT. R/W NUC BOTTOM |C: | | :_| 01A7E9FF - R/O NUC TOP = 00FF - 16M LINE | : R/O NUCLEUS | |N:_| 00FE3000 - R/O NUC BOTTOM |U: | |C:_| 00FE2D07 - R/W NUC TOP | : R/W NUCLEUS | |___| 00FD4000 - R/W NUC BOTTOM | SQA | |___| 00F07000 - SQA BOTTOM | : PLPA| |L:_| 00D2D000 - PLPA BOTTOM |P: FLPA| |A:_| -- NO FLPA DEFINED AT IPL -- | : MLPA| |___| -- NO MLPA DEFINED AT IPL -- | CSA | -- NO CSA TO SQA CONVERSION -- |===| 00B0 - CSA BOTTOM | : LSQA/SWA/229/230 | 00B0 - MAX USER REGION ADDR |P:_| 00A9E000 - LSQA BOTTOM |V: (FREE STORAGE) | |T:_| 0057B000 - USER REGION TOP | : USER REGION| |___| 6000 - USER REGION BOTTOM : SYSTEM STORAGE: :___: -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/11/2012 8:47 AM, Shmuel Metz (Seymour J.) wrote: In3058465022590439.wa.wkkelleyoptonline@bama.ua.edu, on 05/10/2012 at 08:28 PM, W. Kevin Kelleywkkel...@optonline.net said: Based on the feedback that we had received from the ESP customers, the comments that I have received here were a surprise; I had expected the comments to have gone in other directions. Why? The comments here were that it should be under the control of the site; I doubt that any of the ESP customers would object. Precisely! Why on Earth would 'overreactive' ESP regressives wish to prevent me from getting the behavior I want so long as they are able to get the behavior THEY want? Perhaps some of them strive to be politicians... -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Multiple waiting tasks, one control block?
On 5/5/2012 8:43 AM, Charles Mills wrote: I have a situation in which it would be a wonderful thing if I could have multiple tasks waiting for a single event, without having a separate wait control block of some sort for each task. This is supported on z/VSE. Why? I have no control over what the tasks have in advance (system exit situation) and doing a GETMAIN or the like so that each task could have its own ECB, and then chaining them all together, following the chain with POSTs, FREEMAINs, etc., etc., would be a real pain, a lot of overhead, and a real risk of mucking it up. I know WAIT/POST/ECB does not support multiple tasks waiting on a single ECB. I guess that EVENTS does not support this either -- but I don't see it explicitly in the documentation -- is my assumption correct? There is no support in z/OS for what you want. Is there any other way to do this? Some clever use of ENQ or something like that? Some other z/OS wait service besides WAIT and EVENTS? You must build your own queue of requesters (LIFO is the easiest to create, but FIFO is the best way). I recommend a CPOOL. When the ECB gets posted, pull an entry from your queue and POST, RESUME, or IEAVRLS the waiting unit of work. Continue for every entry on the queue until exhausted. Note that a similar (but opposite) issue exists for not being able to wait on multiple events with IEAVPSE. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Old timer question
On 5/5/2012 12:44 PM, Mark Zelden wrote: On Fri, 4 May 2012 14:45:21 -0700, Edward Jaffeedja...@phoenixsoftware.com wrote: I thought it was MVS/ESA 3.1.2. Was that the first release to support SMS? -- No. It was MVS/XA 2.2.3 + DFP 3.1. MVS/XA 2.2.3 (compared to 2.2.0) is what was required to install DFP 3.1 under MVS/XA. But you could have MVS/XA 2.2.3 and still run DFP 2.4. Now I remember. MVS/ESA 3.1.2 was the first release with PDSE. That's why it sticks in my mind... -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/3/2012 7:15 PM, Mark Zelden wrote: If the new MPFLSTxx option has it disabled by default or enables the verbose messages, what purpose does the OCE_ABEND_DESCRIP=YES serve in DEVSUPxx? What if you want the original behavior? I ask, because I like it. I also like the current behavior. Job logs come and go, but the system log is forever. ESP for z/OS 1.13 began in late spring 2011. Some of the participants probably overreacted. People don't like change. The release went GA in September 2011. Many shops have already migrated and many more are doing so. There was no 'blood in the streets'. I can't recall hearing or reading any negative mention of this new functionality until Kevin's post. When I first read the ICN (Interface Change Notification) about this new 'verbose' message support, I thought This is much ado about nothing. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/4/2012 8:56 AM, Skip Robinson wrote: I like the solution. The installation can turn verbose on or off globally. The new 'filter' allows us to direct long explanations to just the programmer--my preference--or to syslog/operlog. Why complain about 'too much control'? You misunderstood. With the new design, the messages will NEVER appear on syslog/operlog. This is the complaint. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/4/2012 7:52 AM, Thomas Conley wrote: I think the MPFLST option should be something like JOBLOG, SYSLOG, or BOTH. That should satisfy the needs of all parties. My choice would be BOTH. Thanks again for this enhancement. I like this idea. However, I would caution against the use of the word 'BOTH' since that would preclude a third verbose message destination being added in the future. I would suggest a simple list of possible verbose message destinations. Currently, the list would support zero, one or two destinations. Perhaps keyword=SYSLOG, keyword=JOBLOG, and keyword=(SYSLOG,JOBLOG) or some such... -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: It's feeding time in Jurassic Park . . .
On 5/4/2012 11:01 AM, George Henke wrote: I need to migrate 50 Solaris servers to zLinux under z/VM on a z114 and about the same number of Windows servers to zBx. Congratulations! You wanna come share your experience at SHARE in Anaheim in August? -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: It's feeding time in Jurassic Park . . .
On 5/4/2012 11:10 AM, George Henke wrote: ty. I would, but I doubt it will have been completed by then. OK. We'll 'pencil' you in for 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: It's feeding time in Jurassic Park . . .
On 5/4/2012 1:22 PM, Mark Pace wrote: I just don't the FOX channel reference. I assumed this was a reference to Hell's Kitchen since they serve duck on that show and it is on FOX. Otherwise, I'm stumped... -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: It's feeding time in Jurassic Park . . .
On 5/4/2012 1:31 PM, Bernd Oppolzer wrote: Another source of problems might be the different character set; the Sparc machine uses ASCII. Linux on z also uses ASCII. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Old timer question
On 5/4/2012 1:55 PM, Mark Zelden wrote: Is there a way to not have it set up? I do remember an MVS system long ago in a galaxy far far away where there was a JES2 exit that changed the internal text from your JCL to have half track blocking for DASD. But BLKSIZE=0 has worked since... well, for so long I don't even remember. MVS/XA? Or was it DFSMS V1 with MVS/ESA or MVS/XA 2.2.3? I thought it was MVS/ESA 3.1.2. Was that the first release to support SMS? -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: It's feeding time in Jurassic Park . . .
On 5/4/2012 3:01 PM, Rich Greenberg wrote: In article4fa41a98.9020...@phoenixsoftware.com you write: Congratulations! You wanna come share your experience at SHARE in Anaheim in August? Which August? 2013, 2014, 20. Lol! August 2012 is Anaheim. August 2013 is Boston. August 2014 and beyond are not yet announced. See http://www.share.org/p/cm/ld/fid=58 -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: /usr/lpp
On 5/4/2012 4:02 PM, Frank Swarbrick wrote: Unimportant question, probably, but I've long wondered... What exactly does lpp stand for in this instance? I have long assumed it stood for 'licensed program products'. But I know not for sure... -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: It's feeding time in Jurassic Park . . .
On 5/4/2012 6:11 PM, George Henke wrote: When you say You can couple up to eight nodes, do you mean 8 CECs to a zBx, that 8 CECs can share a zBx? Each node has its own zBX. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
IBMLink Outage May 4-7
27 April 2012 This is to inform you that IBMLink will have a planned outage for a system upgrade starting on Friday, May 4th at 9:00 PM MT through Monday, May 7th at 3:00 AM MT. During this time IBMLink will be down. Thank you for your patience and understanding. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink Outage May 4-7
On 5/2/2012 11:24 AM, Mary Anne Matyaz wrote: Wow. That's...a lot of downtime. :( Do you know if that includes SR? No idea. The news article is very brief. (See below.) https://www.ibm.com/ibmlink/news/NewsServlet.wss?referrer=newsMaincommand=Getnews_item_id=5446lc=encc=US I agree. It is a LOT of downtime! I hope nobody has any serious sysprogging scheduled for this weekend... -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink Outage May 4-7
On 5/2/2012 3:35 PM, Gibney, Dave wrote: With the new ERP system they are moving us to, scheduled outages of this length are routine. :( but it's better than the working legacy :) Double standard. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink Outage May 4-7
On 5/2/2012 7:27 PM, John Gilmore wrote: IBM should explain what it expects to accomplish during this--on the face of it--absurdly long interval. Absurd indeed! When was the last time one of IBM's mainframe customers enjoyed a 54-hour maintenance/upgrade outage window? I have never seen anything like this myself, but I am relatively inexperienced compared to many on this list. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Programming languages can't have copyright protection, EU court rules
On 5/2/2012 7:33 PM, Scott Ford wrote: So how do you protect code, whatever language you have written in , in business ? You must treat it as trade secret information. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On 5/1/2012 4:39 AM, Andrew Rowley wrote: Hi, I have read a few articles that say that multiple periods are not recommended for batch service classes. Multiple periods seems to be considered a bit old fashioned. I haven't been able to find anything clearly explaining why. I have always felt that they worked well. My best guess is that it is something to do with the behaviour of WLM managed initiators but I'm not sure. Can anyone shed any light, or point me to some further reading? As I understand things, queue time (i.e., clock time accumulated from job submission through initiation) is associated with first period only. Therefore decisions based on queue time -- e.g., whether new initiators should be added -- will not take multiperiod batch transaction completions into account If only a small subset of batch transacations complete outside of first period, then this should not be a big problem. If most jobs complete outside first period, you get what you get. GIGO. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Java PTF Packaging Error Deletes the Java SDK With RC=0! (See APAR IV05507)
Real z/OS sysprogs be on the lookout for this... Still causing us grief (SMP/E RESTORE failed; 64-bit Java ZFS was restored but now APPLY REDO fails because RESTORE failed previously; in the process of restoring the SMP/E environment...) APAR Identifier .. IV05507 Last Changed 12/04/04 INSTALL PROBLEM WITH HJVA601 AND HJVB601 Symptom .. IN INCORROUT Status ... CLOSED PER Severity ... 3 Date Closed . 11/10/17 Component .. 620700130 Duplicate of Reported Release . 600 Fixed Release 999 Component Name JAVA CLASS LIBS Special Notice Current Target Date .. Flags SCP ... Platform .. .. .. PROBLEM SUMMARY: The installed SDK was deleted before checking the availability of Co-Req PTFs. Hence, if one PTF is not available, install script can delete the existing SDK and not install the new SDK. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/26/2012 3:46 AM, Shmuel Metz (Seymour J.) wrote: 3. Rexx does not have a GOTO. Those who try to use SIGNAL as if it were GOTO often shoot themselves in the foot as a result Wow! Not only does Rexx not support GOTO, but if you try to use it you get an infinite loop! Consider the following test program: /* REXX */ trace i goto a say 'the goto failed' exit a: say 'the goto worked' exit If you execute under TSO on z/OS 1.13 you get: 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A 3 *-* goto a L GOTO L A O GOTO A .. (never-ending loop...) -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/27/2012 2:40 PM, Steve Comstock wrote: But, Ed, it does have DO FOREVER. I like to joke You gotta' love a language that does not have a GOTO but does have a DO FOREVER LOL! Actually, DO FOREVER is _extremely_ useful. We have the same control structure in HLASM called DO INF (infinite). So somehow you've combined the two in one exec! Very strange behavior. Do you have a local TSO command called 'goto'? When REXX sees a command it does not know, it passes it to the underlying host as a host command. That's it, Steve! The name of my test EXEC is 'GOTO'. So, it was executing itself recursively! :-D -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/27/2012 3:18 PM, Edward Jaffe wrote: That's it, Steve! The name of my test EXEC is 'GOTO'. So, it was executing itself recursively! :-D Now that I've renamed it, I get the following expected behavior: 3 *-* goto a L GOTO L A O GOTO A IKJ56500I COMMAND GOTO NOT FOUND +++ RC(-3) +++ 4 *-* say 'the goto failed' L the goto failed the goto failed 5 *-* exit *** -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT ALLOCATION.
On 4/26/2012 2:32 PM, John Gilmore wrote: The backup is essential if IBM's help is to be solicited. I would ask for that help before doing anything more. I have never seen or heard of such an error, and it may be hard to reproduce. And, I recommend DUMP TRACKS. Do NOT use any sort of logical dump. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Mainframe Skills Scarce? (z/OS Mainframe CA Product training ...)
On 4/26/2012 9:09 PM, Scott McFall wrote: MAINFRAME SKILLS ARE BECOMING SCARCE!particularly Systems Programmers. I hear this paradoxical conjecture all the time. If true, why are so many skilled mainframe professionals -- particularly sysprogs -- looking for work? IJS... -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Progress Toward z/OS Personal Use License
The march toward a personal use z/OS license takes another step forward ... http://www.ibm.com/common/ssi/rep_ca/5/897/ENUS212-145/ENUS212-145.PDF ... Additionally, the [Rational Developer and Test Environment for System z] product can now be purchased as a stand-alone entry point into the Rational development solutions for System z. This lowers the cost of initial purchase, opening the environment for use by developers, testers, and operations personnel, and provides an easier path to adoption for traditional mainframe developers looking to modernize their development and test processes and infrastructure. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Progress Toward z/OS Personal Use License
On 4/25/2012 5:38 AM, McKown, John wrote: Interesting. How does this differ from zPDT? It sounds like a development only option, perhaps for ISVs or maybe commercial shops. I'll never see it, given the company's attitude about the z. zPDT is still available only for ISV and internal IBM use. It is the platform upon which the RDz DTE offering is based. The technology works very well. (We have one running on a Thinkpad W700.) Previously, RDz UT was made available to commercial customers that also had an RDz license on a big box somewhere. Starting 10 May 2012, RDz DTE may now be licensed as a stand-alone system, without the need for the big box license. This is an important step. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Progress Toward z/OS Personal Use License
On 4/25/2012 7:27 AM, Alvaro Guirao Lopez wrote: You can acquire Red Hat that have support, Suse doesn't have support... He was referring to the following statement: The included IBM software products are provided for development purposes only on an as-is basis. No technical support or APAR/PTF deliverables are provided for the included software as listed in the Supporting Programs section of the product license with your purchase of the Rational Development and Test Environment for System z. The underlying operating system and middleware have been certified by IBM for use on the RDz DTE. It is obviously intended as a turn-key system that you don't need to service with APARs/PTFs etc. (That way you can't introduce any new problems either.) I have no idea how thorough IBM's certification process is, but until this announcement RDz UT was still stuck on back-level z/OS because the latest releases had not yet been certified. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Progress Toward z/OS Personal Use License
On 4/25/2012 7:24 AM, Joel C. Ewing wrote: The big problem with something like zPDF was that it still had a minimum $20K - $30K per year cost. What was zPDF and why was it so expensive? -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Where to find out about PER zero-address detection?
On 4/25/2012 6:53 AM, McKown, John wrote: I've tried finding about this using the -08 version of the Principles of Operation. I got a few hits, but nothing which described what it actually __does__. I can guess from the phrase, but I'd like something documented. The description for z/OS msgIEE735I (output of D SLIP= command) contains: | PER-ZAD | PER zero address detection trap. This suggests strongly that you can issue a SLIP SET,ZAD,... command to capture/track ZAD events on a z/OS system. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/24/2012 4:33 AM, David Crayford wrote: snip http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.pdf That's a very interesting presentation. If I were coding in assembler I would follow! If IBM had made PL/X generally available would you have used that, or still used assembler? PL/X? Possibly. It would have required a firm support commitment from IBM. My fervent hope is that HLASM will eventually support these constructs (and my extensions to the language syntax provided by FLOWASM) natively, without requiring the use of macros or exits. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WTOR macro conflicting/confusing info?
On 4/25/2012 4:26 PM, Paul Schuster wrote: In the WTOR documentation (SA22-7607-17 and earlier versions[z/OS V1R13.0 MVS Assembler Services Reference IAR-XCT]), there is this in the LIST form description: The message parameter must be provided in the list form. Later, in the EXECUTE form description there is this: The message cannot be modified on the execute form of the macro if you code inline text (‘msg’...) on the list form. What is the point of having a TEXT=(textaddress) if you can't use it on the MF=E form? Or am I missing something too obvious? I believe they are referring to the first positional parameter of the WTO macro as the so-called 'inline' text message. TEXT=(textaddress) is not the same as the inline message. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/23/2012 2:13 PM, Shmuel Metz (Seymour J.) wrote: In4f931b2a.9020...@phoenixsoftware.com, on 04/21/2012 at 01:40 PM, Edward Jaffeedja...@phoenixsoftware.com said: Good compiler optimization depends on the compiler understanding what your code is attempting to do and structured, GOTO-less, code is FAR easier to optimize than its GOTO-laden counterparts. That's an issue for ALTER and its equivalents in other languages, not for the GOTO itself. You might find the following of interest: Wolfgang Gellerich, Markus Kosiol and Erhard Plödereder, Where does GOTO Go to?, Reliable Software Technologies — Ada-Europe '96, Montreux, Switzerland, June 10–14, 1996 Proceedings, Lecture Notes in Computer Science, Volume 1088/1996, pp. 385-395 This paper documents the disastrous effects GOTO can have on compiler optimization for RISC, superscalar, out-of-order execution and other non-obvious, but important execution efficiencies of which optimizers are increasingly aware. It finds that GOTO is most often used when the programmer is attempting to write more efficient code yet tends to have exactly the opposite effect. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Explination of S0C4 reason code 4 and related data areas
On 4/24/2012 8:23 AM, Binyamin Dissen wrote: They are not - 0C4's - they are pic-10/11/3E/etc. I once saw an 0C5 in an MVS guest running under VM. Turned out to be a bug in VM. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/23/2012 10:48 AM, Clark Morris wrote: If IBM had implemented the EXIT enhancements in the 2002 standard we would have available EXIT PERFORM (for inline PERFORMs which are like DO loops) EXIT PERFORM CYCLE which allows iteration without having to do unnatural things in the code EXIT PARAGRAPH EXIT SECTION. I know I could have used them. Unfortunately many companies seem stuck on coding standards last updated for COBOL VS. Though not specific to COBOL, there are two excellent studies/papers worth reading on this subject: Wolfgang Gellerich, Markus Kosiol and Erhard Plödereder, Where does GOTO Go to?, Reliable Software Technologies — Ada-Europe '96, Montreux, Switzerland, June 10–14, 1996 Proceedings, Lecture Notes in Computer Science, Volume 1088/1996, pp. 385-395 This paper documents the disastrous effects GOTO can have on compiler optimization for RISC, superscalar, out-of-order execution and other non-obvious, but important execution efficiencies of which optimizers are increasingly aware. It finds that GOTO is most often used when the programmer is attempting to write more efficient code yet tends to have exactly the opposite effect. W.Gellerich and E.Plödereder, The Evolution of GOTO Usage and Its Effects on Software Quality, Informatik'99, K.Beiersdörfer, G.Engels, and W.Schäfer, Eds., Springer-Verlag, Berlin, 1999 This paper presents the results of a study in which the frequency and typical applications of GOTO in over 400 MB of C and Ada source code were analyzed. The analysis demonstrated that the availability of sufficiently powerful control structures in a language significantly reduces the frequency of GOTO. Relating these results to error rates reported for large software projects indicates that programs written with lower GOTO density are more reliable. Though tangential to the core discussion, the following article references the above studies and might be of interest to those involved with this platform: W.Gellerich, T.Hendel, R. Land, H.Lehmann, M. Mueller, P. H.Oden, H.Penner, The GNU 64-bit PL8 compiler: Toward an open standard environment for firmware development, IBM Journal of Research Development, 48, No. 3/4, May/July 2004, pp. 3-4. This paper compares GOTO density metrics for Fortran, C, Ada, and PL8 (the language in which System z firmware is written). I added HLASM to the chart for a SHARE presentation I gave back in 2008 in San Jose (link below). ___ | | Fortran | C | Ada | PL8 | HLASM | |Files without GOTO | none | 81.5% | 99.4% | 98.5% | none | |Lines/GOTO | ~10 | 386 |13614 | 1310 | 8 | '-' http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/23/2012 11:03 AM, Edward Jaffe wrote: ___ | | Fortran | C | Ada | PL8 | HLASM | |Files without GOTO | none | 81.5% | 99.4% | 98.5% | none | |Lines/GOTO | ~10 | 386 |13614 | 1310 | 8 | '-' Ugh. Hopefully this formats better: ___ | | Fortran | C| Ada | PL8 | HLASM | |Files without GOTO | none| 81.5% | 99.4% | 98.5% | none | |Lines/GOTO | ~10 | 386 | 13614 | 1310 | 8| '-' http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/21/2012 12:52 PM, Clark Morris wrote: On Thu, 19 Apr 2012 04:42:55 +0200, Fritz Wuehler | ... Practical experience | beats the college boys every time, especially burnt-out duffers like | Dijkstra who never sold a line of code and probably never wrote one either. Based on presentations by Tom Ross at SHARE (IBM COBOL representative) and my reading of the generated assembler code, I changed my coding practices to make sure all GO TO statements were eliminated because they mess up PERFORM optimization. This is good general programming advice -- not just for COBOL programmers, but for for anyone writing in any modern compiled language. The behavior of well-defined coding structures like IF/THEN/ELSE, DO, SELECT, CASE, etc. are extremely well understood--both by programmers and by code optimizers no matter which language is being employed. This is one of the chief reasons why structured programs are so much more maintainable than unstructured ones. Every programmer understands a-priori how the control structures work without tedious inspection of the logic to understand the possible paths taken. Good compiler optimization depends on the compiler understanding what your code is attempting to do and structured, GOTO-less, code is FAR easier to optimize than its GOTO-laden counterparts. A GOTO will often serve as a monkey wrench thrown into the works of the compiler optimization algorithms. GOTOs are unpredictable; compilers don't know in advance where they will appear in the code; they don't know in advance what the target of the GOTO will be. The optimization algorithms must adapt to a surprise situation they best they can. In some cases the GOTO will be highly disruptive; in other cases less so. Most modern languages disallow GOTO. IMHO it's usually better, even when programming in older languages, to avoid their use unless the language's control structures are truly insufficient to handle a specific, necessary case. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Execute certain steps based on input parm
On 4/19/2012 2:56 PM, Roberts, John J wrote: For the code critics: I know it could be better with UNSTRING, and it would be trivial in PL/I or C. But as it is, it works. Improvements are for the young. Us old-timers have only so many more clock cycles left. It has no GOTOs. Gasp! :-) -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Origins of numeric assignation of z196 z114
On 4/16/2012 7:33 AM, Alvaro Guirao Lopez wrote: I have seeked but found nothing about this, why the new servers have been named z196 z114 and not Z11 EC Z11 BC? zEnterprise is an entirely new class of hybrid server (see zBX and Unified Resource Manager) whose traditional mainframe product component designations are currently z1xx where z1 = 'generation 1' and 'xx' = the number of 'cores' on the machine. z196 has 96 cores; z114 has 14 cores. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: System completion code 201
On 4/10/2012 3:07 PM, Micheal Butz wrote: I have a piece of CSA storage sp 241 That I am obtaining in key 8 (I know this is a no no) If you are working for a commercial ISV, I recommend AT LEAST the following in DIAGxx on all systems (it's what we use): Vsm Track Csa(ON) Sqa(ON)/* Track common stg allocation*/ Vsm AllowUserKeyCsa(NO) /* Disallow user key common stg */ Vsm CheckRegionLoss(512K,25M)/* Restart INITs when fragmented */ Vsm UseZosV1R9Rules(NO) /* Use faster GETMAIN/FREEMAIN*/ ReusAsid(YES)/* Allow reusable ASIDs */ CbLoc Virtual31(IHALCCA,IHAPCCA, /* Move control blocks above 16MB */ IHAASVT) Traps Name(IeaCmSetV,/* Ensure disabled CMSET caller */ IeaInitArSrb, /* Initialize registers for SRBs */ IeaInitRegsTask, /* Initialize registers for TCBs */ IeaSpinLockV, /* Verify spin lock environment */ IeaScheduleV, /* Verify schedule environment*/ IeaScheduleTrace, /* Trace SCHEDULE IEAMSCHD */ IeaRpsgnlTrace, /* Trace RPSGNL calls */ /* Slw IgvCpoolGetV, /* Validate CPOOL GET environment */ IgvInitCpool, /* Initialize CPOOL GET elements */ IgvInitGetmain, /* Initialize GETMAINed storage */ IgvInitFreemain, /* Initialize FREEMAINed storage */ IarSt64InitGet, /* Initialize gotten 64-bit stg. */ IarSt64InitFree, /* Initialize freed 64-bit stg. */ IarCp64InitGet, /* Initialize gotten 64-bit cells */ IarCp64InitFree /* Initialize freed 64-bit cells */ IosZdacMsgs /* Generate zDAC Messages */ ) -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Modernizing the BCP code ?
On 4/12/2012 9:03 AM, David Crayford wrote: AFAIK, the PL/X compiler shares a back-end with the other code optimizers, so should produce excellent code. Not yet. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Modernizing the BCP code ?
On 4/13/2012 10:46 AM, David Crayford wrote: On 14/04/2012 1:38 AM, Edward Jaffe wrote: On 4/12/2012 9:03 AM, David Crayford wrote: AFAIK, the PL/X compiler shares a back-end with the other code optimizers, so should produce excellent code. Not yet. So does that mean that the PL/X compiler produces inferior code to the Metal/C compiler? That would be disappointing considering the majority of the operating system is writen in PL/X! Yes. This has been one of the justifications for not having a new z/OS Architectural Level Set i.e., the existing PL/X compiler cannot generate code that takes advantage of the newer hardware features, so why force customers to upgrade unnecessarily? The compiler was given to the folks in Toronto a couple/few years ago with the intent of having it enhanced with the smart back end used for other IBM compilers. Given that z/OS V2.1 will require z9 processors there is even more pressure on Toronto to deliver this much needed plumbing enhancement. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Secure FTP (Was: z/OS every two years)
On 4/13/2012 5:04 PM, Art Gutowski wrote: I see. Anyone else share in Mary Anne's sentiment? In other words, is FTPS (or SFTP?) as much a requirement/priority notwithstanding the impending ShopzSeries / RECEIVE ORDER requirement? If so, and you can respond, please drop me a line off-list. Nothing detailed... just curious. We have customers that insist on 'secure' FTP for sending dumps, downloading files, etc. We set up an SFTP server on our public Internet site and that seems to have satisfied all requirements thus far. We don't currently support FTPS with x.509 certificates. Hopefully, we'll never be asked to do so. It's a PITA. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Accessing USS on Mainframe thru Telnet
On 4/6/2012 6:09 AM, McKown, John wrote: I appreciate Chris' knowledge of most things, especially VTAM. But apparently he has a thing about USS. And also appears to believe that if he continues to be bothersome about the misuse of the term USS, that either: (a) people will be educated and will voluntarily change or (b) will become tired of hearing the rants and so change their usage just to shut him up. I chose option (c). ;-) -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Sclm / PDSE
On 4/4/2012 11:32 AM, Mary Anne Matyaz wrote: I was actually trying to break a PDSE last week, so that I could get an example of the IEBPDSE utility run against a hosed PDSE, and I couldn't seem to break one. I have two sysplexes so I was randomly back and forth updating from outside the sysplex, and it had no trouble at all. Does anyone have a fool proof way to break a pdse, on 1.13? You must live right. Almost every time I've accidentally updated a PDSE from outside the sysplex it has been immediately broken. I suggest you do concurrent ISPF 3.3 copy members to the target PDSE and/or LKEDs while also doing copy. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Is there a way to cause SRB to TCB percolation if an XCF exit fails?
On 4/4/2012 11:43 AM, Binyamin Dissen wrote: There was a recoverable abend in the message exit for which recovery was not performed. That caused a silent failure. The XCF FRR did not perform percolation. Strange. There are only two options on SETRP: percolate (RC=0) or retry (RC=4). If no SPRC action occurred, it would seem to imply a successful retry -- unless, of course, somehow the SRB is not properly associated with the TCB via SRBPASID/SRBPTCB. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/os every two years
On 3/28/2012 4:41 AM, Alvaro Guirao Lopez wrote: zOS V1R11 is out of support at 30/09/2011, with this new issue z/OS V1R14 will be available from 2013 and not 2012, so probably V1R12 will be out of support about from 2014? No. This is incorrect. z/OS 1.11 goes out of support _this_ year... in September 2012. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/os every two years
On 3/28/2012 5:08 AM, Bob Shannon wrote: I attended SHARE. I looked at the positions the speakers have at IBM and concluded it's a done deal. Too much horsepower to be sending the wrong message. Jeff Magdall (z/OS Product Development Team Leader) presented this information at the MVS Program Opening, Monday morning at SHARE in Atlanta. I believe he had charts showing all of the EOS dates for currently-supported and expected future releases. His entire presentation was only 10 minutes long. He didn't show any slide long enough for it to sink in. The room was dead quiet. I wonder if he uploaded his presentation to the SHARE proceedings? -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/os every two years
On 3/28/2012 7:16 AM, Dana Mitchell wrote: But as long as we are supposing here. Will they not extend the service discontinued date for 1.11 also? Asked and answered at the MVS Program Opening in Atlanta. The answer (paraphrased) from Jeff Magdall was, z/OS 1.11 will go out of service as already announced at the end of September 2012. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
On 3/12/2012 7:40 AM, Mark Zelden wrote: I don't know what you are doing wrong. You can use my CLIST as is and it should work. The key is the TSOLIB prior to invoking ISPF and using a modified BLSCLIBD that has LIBRARY ID instead of DATASET in the libdef. I didn't post that CLIST and left that as an exercise for the reader, but if it helps, I'll post that also. Remember BLSCALTL needs one line changed too (I called my IPCSALTL). I won't post that CLIST, but here is the line: ALTLIB ACTIVATE APPLICATION(CLIST) DDNAME(SBLSCLI0) Our back-level IPCS execs require manual re-invocation under ISPF. I like you approach much better! -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
SHARE in Atlanta -- Good Venue Choice!
So far, I commend SHARE on its choice of venue. The Omni Hotel at CNN Center in Atlanta is NICE! All SHARE guests get Select Guest privileges and the price is one of the lowest in recent memory. Good job, SHARE! -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/8/2012 6:40 AM, Charles Mills wrote: From a non-technology point of view, we need some sort of industry agreement on what is good behavior in an authorized program. I am thinking of something like a standardized set of questions that a vendor could answer and have an officer certify: Mr./Ms. Customer, we are asking for APF authorization. I certify under penalty of fraud that our program uses APF authorization to do X, and Y, and Z but does not do A, and B, and C. You have no integrity statement?? Wow! You might consider drafting one... Here is IBM's you can use as a template: http://www.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statement.html -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tips for continuing DD statement with only one parameter field
On 3/8/2012 7:28 AM, Paul Gilmartin wrote: o Pathnames must be absolute (start with /) This is an inconvenience I wish could be rectified. No leading slash should default to one's home directory. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LAE instruction
On 3/7/2012 6:34 AM, Ngafei Huang wrote: I think you meant SSAR. This requires another set of setups. To SSAR to other than yourself, you need to be AX authorized. Thankfully, SSAR doesn't work with reusable ASIDs. Best to avoid it completely. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
On 3/7/2012 12:47 PM, Ed Mackmahon wrote: How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Web services? -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/6/2012 7:40 AM, Clark Morris wrote: On 5 Mar 2012 23:38:50 -0800, in bit.listserv.ibm-main you wrote: To understand what it does study the two trace entries below (GTF is your friend): SVC CODE 109 ASCB 00F95200 CPU. PSW. 0785 806D 0C53B222 TCB. 00AC8300 R15. 000B R0.. R1.. 0001 GMT-03/06/2012 06:59:08.693767 LOC-03/05/2012 22:59:08.693767 SVCR CODE 109 ASCB 00F95200 CPU. PSW. 0714 806D 0C53B222 TCB. 00AC8300 R15. R0.. R1.. 0001 GMT-03/06/2012 06:59:08.693799 LOC-03/05/2012 22:59:08.693799 How does the system verify that the caller is the intended caller versus an impostor? Suffice to say that it does. My intent was not to explain the intricacies of this interface -- smart programmers can likely figure that out for themselves -- but rather to dispel the myth that such interfaces necessarily represent an exposure. This is IBM code!! The above notwithstanding, I don't think anyone at IBM or elsewhere would recommend this technique for brand new, 21st-century development. Making it secure is a tricky business that requires a deep understanding of system internals. There are much better interfaces available to modern developers on z/OS that guarantee integrity without having to work so hard. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LAE instruction
On 3/6/2012 1:35 PM, Bill Fairchild wrote: I use GRx to mean the 64-bit Register x (aka Grande) and Rx to mean the 32-bit Register x (aka pequeño). If the low halves are called the pequeño registers then what are the high halves called? -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/5/2012 6:06 PM, Shmuel Metz (Seymour J.) wrote: In4f540cf5.3080...@phoenixsoftware.com, on 03/04/2012 at 04:46 PM, Edward Jaffeedja...@phoenixsoftware.com said: Look more closely. In the PLM that IBM doesn't publish? Peter? Could you comment on what IGX00011 does? To understand what it does study the two trace entries below (GTF is your friend): SVC CODE 109 ASCB 00F95200 CPU. PSW. 0785 806D 0C53B222 TCB. 00AC8300 R15. 000B R0.. R1.. 0001 GMT-03/06/2012 06:59:08.693767 LOC-03/05/2012 22:59:08.693767 SVCR CODE 109 ASCB 00F95200 CPU. PSW. 0714 806D 0C53B222 TCB. 00AC8300 R15. R0.. R1.. 0001 GMT-03/06/2012 06:59:08.693799 LOC-03/05/2012 22:59:08.693799 You need to look more closely at IGX00011. Hint: the secure implementation is not just in the SVC(ESR) routine itself but also in the caller What caller? It might not be the intended caller. Of course, I meant the intended caller. Unintended callers can't successfully use the service. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/4/2012 10:24 AM, Shmuel Metz (Seymour J.) wrote: The presence of SVC IGX00011 on z/OS systems *proves* that so-called magic SVCs that confer authority to their callers, The ESR's do notconfer authority to their callers, but rather invoke narrowly defined functions. The so-called magic SVC's return to their callers in a more privileged mode. Look more closely. That is exactly what IGX00011 does. It is called in problem state and returns in supervisor state. are NOT considered an exposure when implemented correctly. I have yet to see one that was implemented correctly. You need to look more closely at IGX00011. Hint: the secure implementation is not just in the SVC(ESR) routine itself but also in the caller which discards all information it had before the SVC(ESR) invocation, including base register contents, etc. and starts over with a clean slate. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/4/2012 10:28 AM, Shmuel Metz (Seymour J.) wrote: Speculative? Did you read what he quoted from Bill Fairchild's message? Yes. I read it before he quoted it. We don't even know the person's name or how long ago this happened (if at all). A lot can change in a decade. For the record, I once knew of a developer who claimed to have found an MVS back door because he wanted to appear cool like a phone phreaking hacker, but he was full of B.S. I also know someone that actually *did* find a back door (through an EXCP appendage) and IBM closed it. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
SMP/E Order Servers Problems (Was: SMP/E Order Server Pair)
On 2/29/2012 8:08 AM, Mary Anne Matyaz wrote: The PMR was updated stating that the issue has been resolved. My receive pointing to Boulder completed successfully. Now we have new problems. No matter if we use the boulder server address or the rochester server address, the package gets created on the IBM side, but all download attempts fail with: Connecting to: dispby-103.boulder.ibm.com 170.225.15.103 port: 21. Connection to server interrupted or timed out. Waiting for reply Server not responding, closing connection. Std Return Code = 1, Error Code = 8 SMP/E retries once per minute for ten minutes, then gives up. :-( -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/2/2012 1:29 AM, David Cole wrote: If the PFLIH hook is (as it has been described earlier in these threads) a mechanism by which a non-authorized process can become authorized, then its very existence is a substantive offense in and of itself. It is not just a template, it doesn't just show the way. It *is* the way. A magic PFLIH technique is not substantially different, from an integrity standpoint, than a magic SVC except that the code gets control for EVERY interrupt and so has the potential to slow things down if not implemented efficiently. The presence of SVC IGX00011 on z/OS systems *proves* that so-called magic SVCs that confer authority to their callers, while arguably not a 21st-century best practice, are NOT considered an exposure when implemented correctly. (Those last three words are very important!) The real question is whether an unintended third party can use the code to become authorized. Unlike the magic SVCs of the past, I'm confident that IGX00011 cannot be exploited by unintended third parties. The same might very well be true of the PFLIH approach being discussed here, despite any speculation or hearsay to the contrary. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/2/2012 9:09 AM, David Cole wrote: At 3/2/2012 10:25 AM, Edward Jaffe wrote: The real question is whether an unintended third party can use the code to become authorized. Yes. That absolutely is the real question. And absolutely, that is what Bill Fairchild's post asserts. So that absolutely is why I am concerned. The subject line of this thread started off (in the other list) as Program FLIH. Then, you renamed it to, Program FLIH backdoor - This is a criminal breach of security! Having concerns is one thing; making speculative accusations of criminal wrongdoing is quite another. Innocent until proven guilty is the American way; not the other way 'round. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On 3/2/2012 8:25 PM, Joel C. Ewing wrote: Particularly now that STP is just a matter of code rather than hardware, it makes less and less sense (from the customer's viewpoint of course) for this to be a chargeable feature, which was still the case when I last checked. As long as it is a chargeable feature it is hard to cost-justify unless you are running a multi-system sysplex environment that requires it or you have some unusual requirement that really demands your TOD clock be that accurate. That it is the best practice and the only sure way for keeping the TOD clock accurate makes it nice to have for a number of reasons; but if management asks if it is a must have additional expense or a feature you can live without, in many cases the latter response must be given. IMHO, STP should be included in the price of the machine. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/28/2012 11:46 PM, Andrew Rowley wrote: I get the impression that once Thunderbird has the messages in its local database, it is difficult or impossible to change the way they are threaded. I think (based on my experiences) that these options apply only to new messages. That makes sense. I'll watch future threading behavior. I much preferred Thunderbirds threading behaviour prior to version 3. Threading based on subject is a much more intuitive system - even with its occasional failings. It's guesswork. The In-ReplyTo: tag gives perfect results, but only if used by everyone. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/28/2012 8:51 AM, McKown, John wrote: IOW, damned if I do and damned if I don't (insert hard line breaks, that is). My advice is not to ever insert any hard breaks. That just makes things worse. When one relies on software that properly handles format=flowed everything should work beautifully. Thunderbird seems to support this very well. I assume Outlook does as well. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/28/2012 4:09 PM, Paul Gilmartin wrote: On Tue, 28 Feb 2012 14:51:31 -0800, Edward Jaffe wrote: On 2/28/2012 8:51 AM, McKown, John wrote: IOW, damned if I do and damned if I don't (insert hard line breaks, that is). My advice is not to ever insert any hard breaks. That just makes things worse. When one relies on software that properly handles format=flowed everything should work beautifully. Thunderbird seems to support this very well. I assume Outlook does as well. I'll take the contrary position. This ain't a word processor. I learned long ago to insert line breaks where I want them -- it's the big key to the right of the home row. Allow me to restate. What I actually meant to say was not to insert any GRATUITOUS hard breaks. Obviously, hard breaks between paragraphs is a good idea. But, hard breaks in the middle of a paragraph become unreadable when quoted. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/26/2012 3:23 PM, Andrew Rowley wrote: Thunderbird can be configured to also use the subject for threading: https://wiki.mozilla.org/MailNews:Message_Threading This sounded promising. But, no matter how I set the threading options I still have multiple threads with the same subject. :-( -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/27/2012 3:57 AM, Mary Anne Matyaz wrote: I've noticed for a long time now that every time you respond on IBM-MAIN it starts a new thread in my mail client (Thunderbird). I also use the web client, do my responses show the same way? That now you mention it, yes they do. :-( -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/27/2012 8:35 AM, Mark Zelden wrote: I have used the web interface for posting / replying to posts exclusively for over 10 years. My former employer started blocking all NNTP at some point so I couldn't use the news servers from my ISP and reply via normal email. I've used a combination of Firefox (Netscape prior to that) and IE. Do you see the problem with my posts? Yes. Same issue. No In-Reply-To: tag in the header causes a new thread to be started. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Unwanted New Threads (Was: SMP/E Order Server Pair)
Paul Gilmartin, I've noticed for a long time now that every time you respond on IBM-MAIN it starts a new thread in my mail client (Thunderbird). I finally decided to compare headers from your non-threaded posts to other peoples' threaded posts. What I see is that the requisite In-Reply-To: header element, necessary to properly thread messages together, is missing from your responses. Is there any way to fix 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: TCBTQE
On 2/26/2012 12:04 PM, Micheal Butz wrote: Does the TCBTQE contain the TQE (time slice for that task to run) TCBTQE points to the chain of TQEs mapped by IHATQE. You can create TQEs using STIMER or STIMERM. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: TCBTQE
On 2/26/2012 1:08 PM, Micheal Butz wrote: Are these created by Z/OS or by the user or both I can't think of any z/OS services right now that will implicitly issue STIMER[M]. That doesn't mean there aren't any. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/26/2012 3:01 PM, Paul Gilmartin wrote: On Sun, 26 Feb 2012 17:51:33 -0500, Rich Greenberg wrote: No, its not a problem, its just an artifact of how this list works. Are you perhaps addressing a different problem from the problem (or non-problem, in your perception) that Ed reported? That's what I'm thinking -- Rich is discussing an entirely different issue... The missing In-Reply-To: tag seems to be a failure of the web interface, perhaps due misconfiguration or running a back-level release -- OR perhaps this tag is simply not supported AT ALL by the L-Soft web interface and an enhancement is needed. I tried to Google this, but there are a lot of hits that use those words and I don't have the time to research it. (I only use the web interface to conduct searches.) -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unwanted New Threads (Was: SMP/E Order Server Pair)
On 2/26/2012 3:29 PM, Rich Greenberg wrote: Inserting a Reply-To: header by the Listserv is an option that must be turned on. Rich, you're discussing a different problem. It's not the Reply-To: tag that is missing; it's the In-Reply-To: tag that is missing. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
SMP/E Order Server Pair
Last night's automatic SMP/E RECEIVE ORDER job failed with: GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ - java.net.NoRouteToHostException: EDC8130I Host cannot be reached. GIM20501IRECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. After being resubmitted this morning, it failed with the same issues. TSO TRACERTE to ECCGW01.BOULDER.IBM.COM shows: CS V1R13: Traceroute to ECCGW01.BOULDER.IBM.COM (207.25.252.197): 1 gateway10.phx (192.168.10.1) 6 ms 2 ms 3 ms 2 209.203.78.177 (209.203.78.177) 3 ms 4 ms 3 ms 3 lax2-pr2-xe-0-3-0-0.us.twtelecom.net (66.192.253.170) 3 ms 3 ms 3 ms 4 vlan60.csw1.LosAngeles1.Level3.net (4.69.144.62) 8 ms vlan90.csw4.LosAngeles1.Level3.net (4.69.144.254) 5 ms vlan80.csw3.LosAngeles1.Level3.net (4.69.144.190) 2 ms 5 ae-82-82.ebr2.LosAngeles1.Level3.net (4.69.137.25) 6 ms ae-62-62.ebr2.LosAngeles1.Level3.net (4.69.137.17) 2 ms 2 ms 6 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 13 ms 23 ms 19 ms 7 ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 22 ms 13 ms 14 ms 8 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 14 ms 13 ms 14 ms 9 ae-3-3.ebr1.Denver1.Level3.net (4.69.132.58) 49 ms 42 ms 50 ms 10 ae-1-51.edge5.Denver1.Level3.net (4.69.147.73) 39 ms 38 ms 39 ms 11 ATT-CORPORA.edge5.Denver1.Level3.net (4.53.6.66) 39 ms 40 ms 39 ms 12 170.225.30.182 (170.225.30.182) 40 ms 40 ms 40 ms 13 * * * .. 29 * * * 30 * * * hop limit reached: *** We manually switched to ECCGW02.ROCHESTER.IBM.COM, restarted the job and now it seems to be working. Unfortunately, this happens quite often. If one server is down, switch over to the other one. Wouldn't it be nice if you could specify a pair of server addresses to SMP/E such that if one failed it would automatically try the other? -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: VARY ON/ VARY OFF COMMAND IN BATCH
On 2/25/2012 9:19 PM, Henrichon, Ryan wrote: I have a job that I use to execute all sorts of operator commands via batch: //STEP1 EXEC PGM=IKJEFT1A,DYNAMNBR=300 //SYSPROC DD DSN=SYS1.SISPEXEC,DISP=SHR //SYSPRINT DD SYSOUT=R //SYSTSPRT DD SYSOUT=R //SYSTSIN DD * cf chp(Bf,d3,bb,da,c1,01,a0,04,06,09,ba,0f,17,d1,1b,c3,35),off cf chp(d8,80,85,87,8e,94),off /* // There is no 'CF' TSO command. This is likely a command processor unique to your environment. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: DU-AL in IPCS dump
On 2/24/2012 9:00 AM, Micheal Butz wrote: Can you please elaborate is this a parameter on VERBEXIT SUMDUMP CR2 is a register on the machine. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Difference between DREF storage and Page fixed storage
On 2/22/2012 12:51 AM, Micheal Butz wrote: Please explain I/O should not be done to DREF using DREF storage as buffer area for I/O Anything referenced by the I/O channel program should be fixed. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: VARY ON/ VARY OFF COMMAND IN BATCH
On 2/22/2012 9:23 AM, John Dawes wrote: I have several hundred volumes to put online/offline and I thought I could try it in batch mode. I dug up an old JCL which I tried but the job failed because of the following: READY CONSOLE SYSCMD(V (AA50),ONLINE) IKJ55303I THE CONSOLE COMMAND HAS TERMINATED.+ IKJ55303I AN ERROR OCCURRED DURING CONSOLE INITIALIZATION. THE MCSOPER RETURN CODE WAS X'0004' AND THE REASON CODE WAS X''. READY END According to the manual, RC=4 on MCSOPER ACTIVATE means, Environmental error. For REQUEST=ACTIVATE, the console was already active. You most-likely already had an EMCS console by the same name active in your TSO/ISPF session. To test this, go back to READY, issue 'CONSOLE DEACTIVATE' and then resubmit your job using the TSO SUBMIT command. See what happens. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Request for comments on the GDG IEFAB461 exit
On 2/22/2012 12:35 PM, Jousma, David wrote: - how does one implement such a EXIT or PARMLIB change? To Change the behavior, requires mass change of JCL in the shop coordinated at the same time as the change, because now STEP2 SYSUT1 has to be referenced as (0), instead of (+1). Or visa versa if going back to standard IBM behavior. I believe the 21st-century suggestion will be to implement this behavior as an option on the job card and/or job class. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Difference between DREF storage and Page fixed storage
On 2/21/2012 2:26 PM, Art Celestini wrote: DREF Storage is still pageable except that the system resolves page faults synchronously. There are some caveats, like when a page fault occurs and there is no suitable frame available. And, this is fully documented in the topic entitled, Obtaining and using disabled reference (DREF) storage in z/OS MVS Programming Authorized Assembler Services Guide. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Difference between DREF storage and Page fixed storage
On 2/21/2012 10:47 PM, Jim Mulder wrote: The operating system reserves the right to exchange the frame backing any DREF page (LSQA or SQA) at any time. Which is why I/O should not be done to DREF storage, only to fixed storage. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Linux LVM vs z/OS SMS Storage Group
On 2/20/2012 5:34 AM, John McKown wrote: On Mon, 2012-02-20 at 08:42 +0100, R.S. wrote: snip What is cool is that SMS storage group. Usually users do not see the volumes, they see dasd space. In case of shortage you can simply add some volumes to the group. You can even buy new box and simply add it to the group. And that's really cool IMHO. You'd like LVM2 on Linux. You assign your physical disk partitions to a physical volume group (conceptually like an SMS volume group). You can then divvy up the space in that group into various sized logical volumes. This is then initialized with a filesystem with mkfs (equivalent to ICKDSF, I guess). If the filesystem runs out of space, and you used the proper type of filesystem (there are many), you simply expand the size of the logical volume into unused space in the group. You then resize the filesystem. If you used ext4 or btrfs, I think you can do this while it is in use. If you used ext3, I think you need to unmount it (take it offline) to resize it. If you're out of space in the volume group, buy another disk and initialize it into the physical volume group, then expand. logical volume space does not need to be physically contiguous. We use LVM on Linux for System z. Unfortunately, it can't handle physical disks that dynamically grow in size. :-( On z/OS, we have two options for enlarging the space available in an SMS storage group: a) we can define new volumes and add them to the group or b) we can dynamically increase the size of the volumes already in the group. We have used the latter approach many times because device addresses are at a premium here, fewer, larger volumes are easier for us to manage, and we don't have to mess with the z/OS IODF, IOCDS, SCDS/ACDS, etc. The new space is just magically available. To grow LVM physical volumes in Linux for z (RHEL6) we had to one-by-one drain (pvmove) the volumes to be resized, remove from LVM, vary offline, dynamically grow, vary online, reformat and add back to LVM. If not enough free space is available in the LVM group to hold the contents of one physical volume, you must temporarily add another appropriately-sized volume to the group before beginning this process and then remove it at the end. Whew! It was so involved that the last time we had a Linux on z space issue, we bit the bullet and just added a new physical volume to the LVM group (after first updating the IODF/IOCDS). :-( -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
On 2/19/2012 4:40 AM, R.S. wrote: W dniu 2012-02-19 08:30, Edward Jaffe pisze: On 2/18/2012 4:45 PM, Paul Gilmartin wrote: Remember that if z/OS didn't impose a factitious limit on volume size, there'd be little need for multivolume data sets. In that case, widespread adoption of 1TB volumes on z/OS should significantly decrease the number of multivolume data sets in use... 1TB ??? Why so huge? It's... it's... it's almost as much as single HDD in my PC! vbg What's especially cool is that mainframe volumes can by dynamically configured to be any size between Mod1 and 1TB. If you ever run out of space on a volume, just turn the magic screwdriver on the remote DASD HMC (SSPC) to make the volume larger and keep on going. The new size is immediately seen by z/OS. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
On 2/18/2012 4:45 PM, Paul Gilmartin wrote: Remember that if z/OS didn't impose a factitious limit on volume size, there'd be little need for multivolume data sets. In that case, widespread adoption of 1TB volumes on z/OS should significantly decrease the number of multivolume data sets in use... -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
