Re: PDS/E, Shared Dasd, and COBOL V5
Peter Farley astutely points out: It seems to me that the first reason for the PDSE requirement was their choice to use the Java backend code generator Precisely. OK, let's summarize: 1. There is always a migration effort to upgrade anything, anywhere. It will cost millions or billions of dollars for the iPhone community to upgrade from iOS 6 to iOS 7 starting next week, yet it will be done. And for most people most of the time it'll be a smooth, low cost, value-adding experience because a lot of technical people did a lot of work. 2. Enterprise COBOL 5.1 has a PDSE prerequisite for important technical reasons which Peter Farley has helpfully explained. (Thanks, Peter.) 3. You may have a migration effort to get to PDSE. If so, there will be some cost/effort. I don't remember characterizing the size of that cost/effort except that it's far from the biggest in history. (Y2K? z/Architecture? VS COBOL II? Sysplex?) I do remember recommending an assessment of that cost/effort via a trial (for example). 4. The migration effort must be assessed along with the benefits -- and wow there are many of the latter. What's the continuing cost to run XX% less efficient code than now available? John Gilmore opines: I have made no secret of my view that the management of too many mainframe shops is compulsively risk-averse, suspiciously unanimous in its rejection of innovation, in a word, reactionary. These attitudes are destroying the mainframe I hope that's not going on here, this time. The existence of a cost/effort is not a sufficient justification for inertia and inaction -- agreed, John. I humbly suggest we now, constructively, focus on what's involved in moving to PDSE (if you haven't already), techniques for reducing the costs/risks/effort to move, and develop advice (and/or point to existing advice) on how to get the job done as quickly and efficiently as possible. We've got a prerequisite, yes. We've also got a fantastic new compiler, hurray! And if there's something IBM could or should do better to make PDSE better, yes, please let IBM know (the official ways). But don't wait for IBM unless that's the only business-justified choice available. Who's delivering friendly, responsive customer service? Who's delivering relevant, valuable innovation? Are you? Or is somebody else? *Somebody* will satisfy user and business demands. How about this community? How about mainframes *and the talented people who operate them*? Let's roll up our collective sleeves, figure this out, and get the job done, OK? Because the folks upgrading 10,000 blade servers from Windows Server 2003 to Windows Server 2012 are working, and they don't even have coexistence/fallback available (to pick an example). Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ACS routine trace.
And remember, that I cannot set up a testcase, because I don't know what parameters the application passes to SMS. Finally it appeared that the clue was in the set of volsers, that I had never forseen. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Darth Keller Sent: Thursday, September 12, 2013 22:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine trace. Sorry, long day - I forgot you said this was a dynamic allocation, which is what made me thing about going back to NaviQuest in the 1st place. my bad - ddk / But that's the beauty of NaviQuest - you can set up your test case, test it against your 'live' code changing values until your results match what you're seeing. Then you can run that test case against new code to see what it does with the data. As to not knowing what is being presented to the routines, you can add variables to your WRITE statement to tell you exactly what SMS sees. In the case I was working on yesterday, my test dataset was falling out of the code a long way from where I thought it was supposed to I couldn't see why. So I updated to WRITE statement where it was falling out of the code and added a dozen different variables to the WRITE - specifically I wanted to see the variable I was testing for in the earlier segment. I was testing for the RACF defaults security is supposed to set up when they define a new user ID - my displays showed me that for this ID that had not happened. There was actually nothing wrong with the code - it was in how the ID was set up - I've been doing this a lot of years and haven't found an instance yet that I couldn't debug using WRITE statements and the right combinations of WRITE Variables. HTH's. ddk -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ACS routine trace.
No I can't. I worked together with the supplier and they told me which parameters were passed to my SC routine what it did (did wrong). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of efinnell15 Sent: Thursday, September 12, 2013 22:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine trace. Can you turn on verbose logging for the specific APP during the event in question? Maybe something irregular would solve the mystery. I would guess something like a temp creation and a rename. In a message dated 09/12/13 14:46:28 Central Daylight Time, kees.verno...@klm.com writes: I can only debug this problem in a live envirionment, hence the 'tracing' needed for the live ACS routines. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 Printer components manual GA24-3073-3
Ah yes the 1403: I remember at Florida Power we had a deck of cards that could be Printed to play Anchors Away My Boys. And as someone mentioned, not all control tape channels had punches, so a skip channel character at the beginning of a line either accidentally or on purpose, could empty a full box or green bar paper. Then there were those crazy FORTRAN engineering students working late at night. I would help the operators at USF run payroll sometimes so I could get on machine quicker. And then once I wrote a FORTRAN program punched on 5081 cards that Printed a birthday cake with candles and the name of a girl. My first graphics program mixed in with all those thermo calculations. Don Higgins d...@higgins.net www.don-higgins.net -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Wait all CPU's enabled at least once
I asked out of curiosity. I wanted to read how it worked. I wondered if it is really fast It is not only not really fast, it is very slow and (as is pretty obvious) gets worse as the number of CPUs increases. z/OS has to be very careful about the frequency with which it needs to do this. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL problem (not really), but sort of.
OP here. I guess I shouldn' t post while ticked off at someone. Apologies. The real problem is that I simply was not able to explain to the programmer __in terms that made sense to a COBOL programmer__ what was happening. His concept of READ ... INTO was that the READ was reading _directly_ INTO the receiving area. I have now learned, from this discussion, that the way that a COBOL programmer would say it is that the READ ... INTO is simply a shortcut way of saying READ FILE followed by a MOVE FD TO 01 statement. And that is why it works sometimes and S0C4-4's other times. I would guess that if the programmer made the ODO variable be the name of the variable in the FD which does contain the correct value, that it would work as he wants every time. I don't know why he put the ODO variable into a WORKING STORAGE variable. I am, and think like, an HLASM programmer. So my explanations sometimes are in the correct dialect when I talk to COBOL-only people. Again, many thanks to all. I'll try to explain to him when I get back from vacation on Monday. On Thu, Sep 12, 2013 at 7:20 PM, Clark Morris cfmpub...@ns.sympatico.cawrote: On 11 Sep 2013 10:21:17 -0700, in bit.listserv.ibm-main you wrote: I can try that. The programmer says that he intents to define the passed in area in the calling program at the front of his WORKING-STORAGE so that the area is larger. I.e. it is _planning_ on a buffer overflow and _hoping_ that it doesn't affect the calling program. I don't have authority to disallow this. And we don't do any kind of peer review because we just don't have the people left. In the sub-routine change the READ ... INTO to a READ followed by a MOVE of the record just read and some value if AT END is reached. Clark Morris On Wed, Sep 11, 2013 at 12:09 PM, Thomas Berg thomas.b...@swedbank.se wrote: I would say: the READ .. INTO .. statement doesn't look at the numerical value in the length field, it only looks at the max possible length as defined. And acts accordingly. Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Wednesday, September 11, 2013 7:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: COBOL problem (not really), but sort of. A programmer came by today with a problem. He is sometimes getting a S0C4-4 abend in a COBOL program. This is a subroutine. One of the parameters passed in is a data area, which can be of various lengths. It is defined with an OCCURS DEPENDING ON with a data element within the area. I.e. the first 05 level is PIC S9(5) COMP. The subroutine does a READ of a data set into this area. This is where the abend occurs. The reason is because the OCCURS DEPENDING ON maximum size is significantly larger than what the caller is passing it. And the READ to the 01 is trying to pad the entire possible 01 level with blanks. The problem is how do I describe this to a COBOL programmer who just doesn't get it. He expects COBOL to _not_ pad the non existent occurrences with blanks. And, if fact, to not even reference this area wherein they would have resided, had they existed. I'm just get deer in headlights looks. I'm not using the correct words, somehow. -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL problem (not really), but sort of.
John McKown wrote: OP here. I guess I shouldn' t post while ticked off at someone. Apologies. Not me, I would just be 'p*ssed off!' ;-) The real problem is that I simply was not able to explain to the programmer __in terms that made sense to a COBOL programmer__ what was happening. His concept of READ ... INTO was that the READ was reading _directly_ INTO the receiving area. That is incorrect. Have him read the COBOL Language Ref. First COBOL, reads in the data, do its checks to see if READ is completed successfully and then only MOVE the data to the receiving area according to the relevant MOVE and RECORD rules. For what I know: If input area is longer than receiving area, you will get abends or your input is truncated. Simply. If input is shorter than receiving, then you get either garbage at the end or it is padded up to the end. AFAIK, COBOL has reserved areas for input, working area and also the final receiving area. Depending on your declaration those areas may be pre-filled in with blanks, zeroes or whatever you place in. Just get that in your programmer's empty brain. There should be ample space for that. ;-) I have now learned, from this discussion, that the way that a COBOL programmer would say it is that the READ ... INTO is simply a shortcut way of saying READ FILE followed by a MOVE FD TO 01 statement. Correct. And please reread Peter Farley's snippet. This could help you. And that is why it works sometimes and S0C4-4's other times. Because you would overwrite something. So your programmer really needs to think like a COBOL programmer. You want to use COBOL, use the COBOL's rules. Same for Assembler or other languages. I would guess that if the programmer made the ODO variable be the name of the variable in the FD which does contain the correct value, that it would work as he wants every time. I don't know why he put the ODO variable into a WORKING STORAGE variable. If he does not tell you, simply stop help him or put a COBOL Language Ref book under his nose (and eyes!). I am, and think like, an HLASM programmer. So my explanations sometimes are in the correct dialect when I talk to COBOL-only people. Again, many thanks to all. I'll try to explain to him when I get back from vacation on Monday. Good luck! ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Teletypewriter Model 33
l...@garlic.com (Anne Lynn Wheeler) writes: ... which saw little uptake until sysplex ... except for IMS hot-standby. The lack of uptake contributed to her not staying long ... however also there were the re-occuring battles with the communication group trying to force her into using SNA for loosely-coupled operation. There would be periodic termporary truces where they said she could use anything she wanted within the datacenter, but the communication group owned everything that crossed the datacenter walls ... but they would then resume their efforts to try and force her to use SNA. actually IMS hot-standby had a different problem with SNA. While IMS hot-standby could be back up operational in very short time ... in a configuration with 30k-60k terminals (sessions), it could take VTAM 2-3hrs to get all the sessions re-established (VTAM session establishment was real resource hog even on the largest processor configuration available from IBM). I was working with a baby-bell to turn out some work they had done for a 37x5 emulator, as a product. They had done a NCP emulator on Series/1 that had significantly more function and better performance that real 37x5. A separate feature was it also supported non-IBM, non-SNA systems old posts discussing implementation http://www.garlic.com/~lynn/99.html#67 http://www.garlic.com/~lynn/99.html#70 Among other things, it told the host VTAM that all resources were cross-domain ... owned by some other VTAM ... when in fact they were owned by the distributed and redundant network infrastructure. RU traffic was also carried over real network. What interested IMS hot-standby was being able to create shadow sessions on the IMS hot-standby (in addition to the standard session on the active IMS system) ... so everything was immediately ready to go on the hot-standby. My objective was to ship initially on Series/1 but very quickly upgrade it to a (801/risc) RIOS chip implementation. The communcation group was well-known for all sort of FUD and corporate dirty tricks ... so with some help ... I got agreement from the largest 37x5 customer to completely fund the whole effort (the customer claimed being able to move to the new type1 product supported by IBM ... they would recoup total cost in less than a year). The communication group even tried a lot of FUD on my comparison numbers with the 3725 (see reference URLs), however the numbers came straight out of the communication group's 3725 configurator AID on the HONE system (some of the communication group responsible for much of the FUD didn't even know about their HONE configurator AIDs) ... misc. past posts mentioning HONE http://www.garlic.com/~lynn/subtopic.html#hone I was so confident that I even gave a detailed presentation at a fall SNA Architecture Review Board meeting. How the communication group finally was able to block the product can only be described as truth is greater than fiction. We also crossed the communication group in their battle against client/server and distributed computing when we came up with 3-tier networking architecture and were out pitching it to corporate executives. This is part of one such presentation which also contrasts 16mbit token-ring with 10mbit enet (which brought down a lot more of thier FUD on our heads) http://www.garlic.com/~lynn/2002q.html#40 other past posts mentioning 3tier http://www.garlic.com/~lynn/submnetwork.html#3tier -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
In ngf43910qavrl8b2ci7vs2m3uto3isj...@4ax.com, on 09/12/2013 at 07:29 PM, Clark Morris cfmpub...@ns.sympatico.ca said: the person who decided that local SNA 327X devices could only be accessed though VTAM They used to be accessed by TCAM as well. If your complaint is that the CONSOLE address space can't access them directly, but only as SNA consoles, that would require that the entire cluster be used for nothing but consoles, or that the CONSOLE address space was bloated with MSNF code. requiring shops to have 2 BiSync 327x controllers for console availability There is no support for bisynch consoles. At least code to read PDSE's should be available to NIP and maybe SYS1.NUCLEUS. Another case where IBM developers failed to learn from earlier IBM projects; TSS/360 had page oriented PDS[1] support way back when. [1] Actually, the entire volume containing a VPAM library was page formatted. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Sysplex newbie
Hi folks, We have a single z10, and would like to split its main partition into production and developer partitions. Capacity should be ok. We're looking at all the stuff we need to worry about sharing, like GRS, spool, RACF, RMM, HSM, catalogs, virtual tape, etc etc. But underneath it all, we probably need to set up a sysplex. Keep in mind that we've never set up a sysplex before or done any real sharing beyond shared DASD, so there will be dumb questions. I think a basic sysplex will be enough, that way we won't need a coupling facility. We will need a way for them to talk to each other (and probably with one or two sandbox lpars), so I'm looking into CTCs. The question I haven't found an answer to is how to use CTCs without an escon or ficon switch; we have spare channels and I want to do this on the cheap if I can. I'm still reading about it, but any insight would be appreciated. Thanks! -- -- Jim Blalock z/OS Support Manager CCIT, Clemson University (864) 656-3680 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex newbie
Have you reviewed the REDBOOKS on setting up a SYSPLEX? Have they been helpful? http://www.redbooks.ibm.com/abstracts/sg242079.html http://www.redbooks.ibm.com/abstracts/sg246485.html http://www.redbooks.ibm.com/abstracts/sg247817.html http://www.redbooks.ibm.com/abstracts/sg245235.html http://www.redbooks.ibm.com/abstracts/sg246818.html http://www.redbooks.ibm.com/abstracts/sg244356.html http://www.redbooks.ibm.com/redbooks/pdfs/sg246485.pdf Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Blalock Sent: Friday, September 13, 2013 7:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Sysplex newbie Hi folks, We have a single z10, and would like to split its main partition into production and developer partitions. Capacity should be ok. We're looking at all the stuff we need to worry about sharing, like GRS, spool, RACF, RMM, HSM, catalogs, virtual tape, etc etc. But underneath it all, we probably need to set up a sysplex. Keep in mind that we've never set up a sysplex before or done any real sharing beyond shared DASD, so there will be dumb questions. I think a basic sysplex will be enough, that way we won't need a coupling facility. We will need a way for them to talk to each other (and probably with one or two sandbox lpars), so I'm looking into CTCs. The question I haven't found an answer to is how to use CTCs without an escon or ficon switch; we have spare channels and I want to do this on the cheap if I can. I'm still reading about it, but any insight would be appreciated. Thanks! -- -- Jim Blalock z/OS Support Manager CCIT, Clemson University (864) 656-3680 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
I have not read every post in this thread. Has anyone else pointed out that this rather serious compatibility issue is not even mentioned until page 177 of the Migration Guide, where it rates a single short sentence fragment? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Conley Sent: Thursday, September 12, 2013 8:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 On 9/12/2013 8:12 AM, John Gilmore wrote: Tom Conley wroter: begin extract All due respect, the cost to IBM's customer base for converting all COBOL executable libraries to PDSE will be measured in millions, if not billions, of US dollars. /end extract [With] all due respect again, this is empty rhetoric. The last Decennial Census, of 2010, yielded a US population aged 5-17 of 53,980,105. Let us now assume, conservatively, that the members of this group spent an arithmetic mean of US$1.00 per week on junk food in 2010. The 'alarming' result? This group spent US$2,806,965,460 on junk food in 2010! 'Almost' 3 billion dollars wasted! Etc., etc. The context-free large-numbers gambit is an old one, but it persuades only the already persuaded. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN So there's no cost whatsoever to IBM's customer base for converting COBOL executable libraries from PDS to PDSE? My mistake. Here are some context-free, large-numbers gambit empty rhetoric numbers. Let's assume 1000 COBOL licenses in the world, with 100 executable datasets per license (IMNSHO, ridiculously conservative estimates). So that's 100,000 executable datasets. I'll set, again, a conservative estimate of $1,000 to convert the PDS to PDSE. Here is how I break that down. Planning - 1 hour. Allocating and copying - 1 hour. Change control paperwork - 2 hours. Implementation - 2 hours. Post-implementation followup - 2 hours. That's 8 hours at a fully-burdened rate of $125/hr. I haven't even figured in the cost of DASD. That's $100M US just to convert this small scenario I've laid out here. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
Thanks all. Yeah, little problem finding the docs on the Web -- that was not the issue. I just like the organization provided by the Softcopy Reader/Softcopy Librarian combo. Shelves and so forth. Meaningful titles for the mysteriously-named manual files. Ability to download all of the manuals for a given product with a single click. Keeping track of what's newer than what you already have. Etc. Yes, it supports PDF -- although less wonderfully than it supports BookManager. (Of course -- it calls PDFs Extended Shelves. Extended as in less functionality!) I guess I must be the only person in the world using these two programs. Strange. I originally got them off of the old z/OS CD and then DVD manual sets, I think. Perhaps when z/OS 2.1 goes GA the end of the month they will provide a documentation bundle that will include COBOL 5.1. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, September 12, 2013 1:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for COBOL V5R1 Softcopy Librarian docs That is correct. And I also understand that IBM wants us to use INFOCENTER. I have not determine (cause I have not researched it) how to install that on my PC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
I have to say I agree. If PDSEs are fundamental to the OS, then internal OS code should support them. If they're not fundamental, then COBOL should not be requiring them. I'm not a sysprog either, so I don't fully appreciate the sharing issues, but for gosh sakes, after 26 years of customer complaints IBM should have gotten all of the issues under control. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris Sent: Thursday, September 12, 2013 6:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 While I have been away from systems programming for over a decade, I am appalled to see that a PDSE still cannot contain SYS1.LINKLIB, SYS1.LPALIB and SYS1.NUCLEUS. Whoever came up with the idea that a major access method should be done by a started task should be consigned to the same hell as the person who decided that local SNA 327X devices could only be accessed though VTAM thus requiring shops to have 2 BiSync 327x controllers for console availability. Would anyone care if NIP took a cylinder, 2 cylinders or even 100 cylinders. If started task is a good idea for PDSE, it should be equally good for VSAM. At least code to read PDSE's should be available to NIP and maybe SYS1.NUCLEUS. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex newbie
OK, Objectives: Simple, low cost (no new equipment if I can help it), low overhead, isolate production from development. We do not need the things that parallel sysplex would give us; anyway, a parallel sysplex on a single box doesn't make sense to me. We do want: .. GRS that works in a way that makes sense: cross-system ENQ, convert RESERVEs .. Shared HSM, RMM, catalogs, virtual tape. Probably NJE instead of shared spool. .. Give the developers a place to work so they don't need to log on to prod except to upgrade or fix things .. Developer tools won't run on production Isolation can be accomplished with some vary-offline commands in COMMND00, that allows us to vary prod volumes online to dev if we have to. And I know about opinions on ibm-main, I've been here before :-) On 9/13/2013 11:28 AM, Norman.Hollander wrote: Before reading books on Sysplex mechanics, and it certainly is less challenging with a basic Sysplex, You should ask yourself what objectives you are trying to accomplish. The first objective should be Availability. For complete High Availability and Continuous Availability, you would actually need a Coupling Facility for a Parallel Sysplex. A Parallel Sysplex has a bit more complexity in the Capacity Planning areas and the logistics of Recovery. The mechanics are really not difficult: there is pre-positioning Your current environment, defining the Sysplex, and then implementing it. Are you planning to divide the DASD farm? Is everything to be shared? Is it OK to have Development access Production data? There is a some considerations to think about; so be careful moving forward. All of the Redbooks are an excellent start to understand what you'll need. Be sure to ask question here. Many of us will have definite opinions for you. zNorman -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, September 13, 2013 8:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex newbie Have you reviewed the REDBOOKS on setting up a SYSPLEX? Have they been helpful? http://www.redbooks.ibm.com/abstracts/sg242079.html http://www.redbooks.ibm.com/abstracts/sg246485.html http://www.redbooks.ibm.com/abstracts/sg247817.html http://www.redbooks.ibm.com/abstracts/sg245235.html http://www.redbooks.ibm.com/abstracts/sg246818.html http://www.redbooks.ibm.com/abstracts/sg244356.html http://www.redbooks.ibm.com/redbooks/pdfs/sg246485.pdf Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Blalock Sent: Friday, September 13, 2013 7:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Sysplex newbie Hi folks, We have a single z10, and would like to split its main partition into production and developer partitions. Capacity should be ok. We're looking at all the stuff we need to worry about sharing, like GRS, spool, RACF, RMM, HSM, catalogs, virtual tape, etc etc. But underneath it all, we probably need to set up a sysplex. Keep in mind that we've never set up a sysplex before or done any real sharing beyond shared DASD, so there will be dumb questions. I think a basic sysplex will be enough, that way we won't need a coupling facility. We will need a way for them to talk to each other (and probably with one or two sandbox lpars), so I'm looking into CTCs. The question I haven't found an answer to is how to use CTCs without an escon or ficon switch; we have spare channels and I want to do this on the cheap if I can. I'm still reading about it, but any insight would be appreciated. Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex newbie
Before reading books on Sysplex mechanics, and it certainly is less challenging with a basic Sysplex, You should ask yourself what objectives you are trying to accomplish. The first objective should be Availability. For complete High Availability and Continuous Availability, you would actually need a Coupling Facility for a Parallel Sysplex. A Parallel Sysplex has a bit more complexity in the Capacity Planning areas and the logistics of Recovery. The mechanics are really not difficult: there is pre-positioning Your current environment, defining the Sysplex, and then implementing it. Are you planning to divide the DASD farm? Is everything to be shared? Is it OK to have Development access Production data? There is a some considerations to think about; so be careful moving forward. All of the Redbooks are an excellent start to understand what you'll need. Be sure to ask question here. Many of us will have definite opinions for you. zNorman -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, September 13, 2013 8:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex newbie Have you reviewed the REDBOOKS on setting up a SYSPLEX? Have they been helpful? http://www.redbooks.ibm.com/abstracts/sg242079.html http://www.redbooks.ibm.com/abstracts/sg246485.html http://www.redbooks.ibm.com/abstracts/sg247817.html http://www.redbooks.ibm.com/abstracts/sg245235.html http://www.redbooks.ibm.com/abstracts/sg246818.html http://www.redbooks.ibm.com/abstracts/sg244356.html http://www.redbooks.ibm.com/redbooks/pdfs/sg246485.pdf Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Blalock Sent: Friday, September 13, 2013 7:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Sysplex newbie Hi folks, We have a single z10, and would like to split its main partition into production and developer partitions. Capacity should be ok. We're looking at all the stuff we need to worry about sharing, like GRS, spool, RACF, RMM, HSM, catalogs, virtual tape, etc etc. But underneath it all, we probably need to set up a sysplex. Keep in mind that we've never set up a sysplex before or done any real sharing beyond shared DASD, so there will be dumb questions. I think a basic sysplex will be enough, that way we won't need a coupling facility. We will need a way for them to talk to each other (and probably with one or two sandbox lpars), so I'm looking into CTCs. The question I haven't found an answer to is how to use CTCs without an escon or ficon switch; we have spare channels and I want to do this on the cheap if I can. I'm still reading about it, but any insight would be appreciated. Thanks! -- -- Jim Blalock z/OS Support Manager CCIT, Clemson University (864) 656-3680 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex newbie
Hi, I have to ask - why a sysplex when two separate LPARs that don't share anything may be simpler? It shouldn't cost any more to have separate LPARs if you're running VWLC, especially since you sound like you're running the same products in both LPARs. Sysplexes are great if you need them, but a pain if you don't. Just a thought. thanks Peter On Fri, 13 Sep 2013 10:24:39 -0400, Jim Blalock ca...@clemson.edu wrote: Hi folks, We have a single z10, and would like to split its main partition into production and developer partitions. Capacity should be ok. We're looking at all the stuff we need to worry about sharing, like GRS, spool, RACF, RMM, HSM, catalogs, virtual tape, etc etc. But underneath it all, we probably need to set up a sysplex. Keep in mind that we've never set up a sysplex before or done any real sharing beyond shared DASD, so there will be dumb questions. I think a basic sysplex will be enough, that way we won't need a coupling facility. We will need a way for them to talk to each other (and probably with one or two sandbox lpars), so I'm looking into CTCs. The question I haven't found an answer to is how to use CTCs without an escon or ficon switch; we have spare channels and I want to do this on the cheap if I can. I'm still reading about it, but any insight would be appreciated. Thanks! -- -- Jim Blalock z/OS Support Manager CCIT, Clemson University (864) 656-3680 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Timothy: Well you did mention it. So I will ask the question to you. What is the cost benefit to do the conversion? So far there seems to be a debug feature (which I don't believe anyone says that it is must have feature). So, other than this so call magical debug feature (which apparently only available to COBOL why should we convert?) IBM has been silent about the downsides as well, what about those (please don't say because as management doesn't like because they want a business case and so far I have not heard of a business case). I am advising my clients not to convert unless I see a business case. Ed On Sep 13, 2013, at 1:12 AM, Timothy Sipples wrote: Peter Farley astutely points out: It seems to me that the first reason for the PDSE requirement was their choice to use the Java backend code generator Precisely. OK, let's summarize: 1. There is always a migration effort to upgrade anything, anywhere. It will cost millions or billions of dollars for the iPhone community to upgrade from iOS 6 to iOS 7 starting next week, yet it will be done. And for most people most of the time it'll be a smooth, low cost, value- adding experience because a lot of technical people did a lot of work. 2. Enterprise COBOL 5.1 has a PDSE prerequisite for important technical reasons which Peter Farley has helpfully explained. (Thanks, Peter.) 3. You may have a migration effort to get to PDSE. If so, there will be some cost/effort. I don't remember characterizing the size of that cost/effort except that it's far from the biggest in history. (Y2K? z/Architecture? VS COBOL II? Sysplex?) I do remember recommending an assessment of that cost/effort via a trial (for example). 4. The migration effort must be assessed along with the benefits -- and wow there are many of the latter. What's the continuing cost to run XX% less efficient code than now available? John Gilmore opines: I have made no secret of my view that the management of too many mainframe shops is compulsively risk-averse, suspiciously unanimous in its rejection of innovation, in a word, reactionary. These attitudes are destroying the mainframe I hope that's not going on here, this time. The existence of a cost/ effort is not a sufficient justification for inertia and inaction -- agreed, John. I humbly suggest we now, constructively, focus on what's involved in moving to PDSE (if you haven't already), techniques for reducing the costs/risks/effort to move, and develop advice (and/or point to existing advice) on how to get the job done as quickly and efficiently as possible. We've got a prerequisite, yes. We've also got a fantastic new compiler, hurray! And if there's something IBM could or should do better to make PDSE better, yes, please let IBM know (the official ways). But don't wait for IBM unless that's the only business-justified choice available. Who's delivering friendly, responsive customer service? Who's delivering relevant, valuable innovation? Are you? Or is somebody else? *Somebody* will satisfy user and business demands. How about this community? How about mainframes *and the talented people who operate them*? Let's roll up our collective sleeves, figure this out, and get the job done, OK? Because the folks upgrading 10,000 blade servers from Windows Server 2003 to Windows Server 2012 are working, and they don't even have coexistence/fallback available (to pick an example). -- -- Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
9/30/2014 is way too far in the future for our management to worry about. On Sep 13, 2013 11:14 AM, Bob Shannon bshan...@rocketsoftware.com wrote: Of course, we r stuck on 1.12 for the foreseeable future due to the ever decreasing budget we get. 1.12 goes off support 9/30/2014 Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Of course, we r stuck on 1.12 for the foreseeable future due to the ever decreasing budget we get. 1.12 goes off support 9/30/2014 Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IXC434I
We are installing a Zec12 and trying to IPL out test systems. We do not have the STP configured yet, but we are just trying to ipl the sysplex. We are getting the message IXC434I: IXC434I SYSTEM SYSC HAS TIMING DEFINITIONS THAT ARE NOT CONSISTENT WITH THE OTHER ACTIVE SYSTEMS IN SYSPLEX SCCTEST - EFFECTIVE CLOCK VALUES ARE NOT CONSISTENT. SYSTEM: SYSC IS USING LOCAL SYSTEM: SYSC IS USING EDCITS How does it even know about EDCITS? Why can't we ipl using the local time? E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties by an authorized state official. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex newbie
We've been doing this for years, with a few shared disks (including SYSRES (but not SYS ZFS)). With care and no COBOL 5.1 you don't need the plex. Four LPARS total on a z9-l03. z/OS sandbox, ISV sandbox, Development, Production. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Bishop Sent: Friday, September 13, 2013 8:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex newbie Hi, I have to ask - why a sysplex when two separate LPARs that don't share anything may be simpler? It shouldn't cost any more to have separate LPARs if you're running VWLC, especially since you sound like you're running the same products in both LPARs. Sysplexes are great if you need them, but a pain if you don't. Just a thought. thanks Peter On Fri, 13 Sep 2013 10:24:39 -0400, Jim Blalock ca...@clemson.edu wrote: Hi folks, We have a single z10, and would like to split its main partition into production and developer partitions. Capacity should be ok. We're looking at all the stuff we need to worry about sharing, like GRS, spool, RACF, RMM, HSM, catalogs, virtual tape, etc etc. But underneath it all, we probably need to set up a sysplex. Keep in mind that we've never set up a sysplex before or done any real sharing beyond shared DASD, so there will be dumb questions. I think a basic sysplex will be enough, that way we won't need a coupling facility. We will need a way for them to talk to each other (and probably with one or two sandbox lpars), so I'm looking into CTCs. The question I haven't found an answer to is how to use CTCs without an escon or ficon switch; we have spare channels and I want to do this on the cheap if I can. I'm still reading about it, but any insight would be appreciated. Thanks! -- -- Jim Blalock z/OS Support Manager CCIT, Clemson University (864) 656-3680 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IXC434I
So are you still using the ETR and not STP? System programmer response: Look for and correct any problems with the ETR clock, signalling paths, or couple data set. If the system was removed because it could not support the logical partition number of another system, look for and correct the missing service that will allow the system to support the attributes of the other systems in the sysplex. If the problem persists, search problem reporting data bases for a fix for the problem. If no fix exists, contact the IBMR Support Center. Provide the stand-alone dump. What is EDCITS for your environment? Is it another LPAR? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lopez, Sharon Sent: Friday, September 13, 2013 9:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IXC434I We are installing a Zec12 and trying to IPL out test systems. We do not have the STP configured yet, but we are just trying to ipl the sysplex. We are getting the message IXC434I: IXC434I SYSTEM SYSC HAS TIMING DEFINITIONS THAT ARE NOT CONSISTENT WITH THE OTHER ACTIVE SYSTEMS IN SYSPLEX SCCTEST - EFFECTIVE CLOCK VALUES ARE NOT CONSISTENT. SYSTEM: SYSC IS USING LOCAL SYSTEM: SYSC IS USING EDCITS How does it even know about EDCITS? Why can't we ipl using the local time? E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties by an authorized state official. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 Printer components manual GA24-3073-3
I searched a little for 1403 line printer art but didn't find anything but the music. There was Alfred E. Newman, Lone Ranger, Apollo, Snoopy Marilyn Monroe and some composite of Raquel Welch on a stool with long flowing tresses to make it PG-13. In a message dated 09/13/13 05:49:09 Central Daylight Time, d...@higgins.net writes: And then once I wrote a FORTRAN program punched on 5081 cards that Printed a birthday cake with candles and the name of a girl. My first graphics program mixed in with all those thermo calculations. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex newbie
We have also been doing point to point CTCs for a long time. We started with ESCON and CTC/CNC pairs but now use FICON connections so type FC vs CTC/CNC but it all works well enough (although we too are a very basic environment). Once it's working we've had no issue across processor upgrades. Good luck, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex newbie
Jim - I think CTCs are required when you don't have a CF. We have CFs so this isn't an issue for us. We have used Escon in the past for CTCs. One consideration is that the zEC12 and zBC12 don't support Escon so if you plan to upgrade processors it would be best to commit to using Ficon instead of Escon. Sorry, but we have no experience doing that. Carl retired maybe five years ago. He had a serious heart attack in about 2004 so that may have hastened his retirement. He and Susan have a camper and travel extensively. Unfortunately I haven't seen him for at least five years. We are on opposite coasts so that makes it hard. SHARE has become very small. No one has a travel budget anymore. It's still a good conference, but it's a shadow of what it once was. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Blalock Sent: Friday, September 13, 2013 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex newbie OK, Objectives: Simple, low cost (no new equipment if I can help it), low overhead, isolate production from development. We do not need the things that parallel sysplex would give us; anyway, a parallel sysplex on a single box doesn't make sense to me. We do want: .. GRS that works in a way that makes sense: cross-system ENQ, convert RESERVEs .. Shared HSM, RMM, catalogs, virtual tape. Probably NJE instead of shared spool. .. Give the developers a place to work so they don't need to log on to prod except to upgrade or fix things .. Developer tools won't run on production Isolation can be accomplished with some vary-offline commands in COMMND00, that allows us to vary prod volumes online to dev if we have to. And I know about opinions on ibm-main, I've been here before :-) On 9/13/2013 11:28 AM, Norman.Hollander wrote: Before reading books on Sysplex mechanics, and it certainly is less challenging with a basic Sysplex, You should ask yourself what objectives you are trying to accomplish. The first objective should be Availability. For complete High Availability and Continuous Availability, you would actually need a Coupling Facility for a Parallel Sysplex. A Parallel Sysplex has a bit more complexity in the Capacity Planning areas and the logistics of Recovery. The mechanics are really not difficult: there is pre-positioning Your current environment, defining the Sysplex, and then implementing it. Are you planning to divide the DASD farm? Is everything to be shared? Is it OK to have Development access Production data? There is a some considerations to think about; so be careful moving forward. All of the Redbooks are an excellent start to understand what you'll need. Be sure to ask question here. Many of us will have definite opinions for you. zNorman -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, September 13, 2013 8:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex newbie Have you reviewed the REDBOOKS on setting up a SYSPLEX? Have they been helpful? http://www.redbooks.ibm.com/abstracts/sg242079.html http://www.redbooks.ibm.com/abstracts/sg246485.html http://www.redbooks.ibm.com/abstracts/sg247817.html http://www.redbooks.ibm.com/abstracts/sg245235.html http://www.redbooks.ibm.com/abstracts/sg246818.html http://www.redbooks.ibm.com/abstracts/sg244356.html http://www.redbooks.ibm.com/redbooks/pdfs/sg246485.pdf Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Blalock Sent: Friday, September 13, 2013 7:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Sysplex newbie Hi folks, We have a single z10, and would like to split its main partition into production and developer partitions. Capacity should be ok. We're looking at all the stuff we need to worry about sharing, like GRS, spool, RACF, RMM, HSM, catalogs, virtual tape, etc etc. But underneath it all, we probably need to set up a sysplex. Keep in mind that we've never set up a sysplex before or done any real sharing beyond shared DASD, so there will be dumb questions. I think a basic sysplex will be enough, that way we won't need a coupling facility. We will need a way for them to talk to each other (and probably with one or two sandbox lpars), so I'm looking into CTCs. The question I haven't found an answer to is how to use CTCs without an escon or ficon switch; we have spare channels and I want to do this on the cheap if I can. I'm still reading about it, but any insight would be appreciated. Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local consoles could not be SNA devices at IPL time was Re: PDS/E, Shared Dasd, and COBOL V5
In 9sc6395775c3rd4dp7icvtu31c4kp0l...@4ax.com, on 09/13/2013 at 12:51 PM, Clark Morris cfmpub...@ns.sympatico.ca said: My complaint, poorly stated is that locally attached 327x devices had to be NON-SNA in order to be used as consoles. Given that there was only a single address for a local SNA cluster, what alternative do you suggest to having an access method deal with them? Making the CONSOLE address space an SSCP would seem to be too expensive. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
I still use and really like Softcopy Librarian. I have stated my opinion of the phase-out of Bookmanager format here before. My opinion of Infocenter is not fit for a public forum:) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, September 13, 2013 8:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for COBOL V5R1 Softcopy Librarian docs Thanks all. Yeah, little problem finding the docs on the Web -- that was not the issue. I just like the organization provided by the Softcopy Reader/Softcopy Librarian combo. Shelves and so forth. Meaningful titles for the mysteriously-named manual files. Ability to download all of the manuals for a given product with a single click. Keeping track of what's newer than what you already have. Etc. Yes, it supports PDF -- although less wonderfully than it supports BookManager. (Of course -- it calls PDFs Extended Shelves. Extended as in less functionality!) I guess I must be the only person in the world using these two programs. Strange. I originally got them off of the old z/OS CD and then DVD manual sets, I think. Perhaps when z/OS 2.1 goes GA the end of the month they will provide a documentation bundle that will include COBOL 5.1. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, September 12, 2013 1:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for COBOL V5R1 Softcopy Librarian docs That is correct. And I also understand that IBM wants us to use INFOCENTER. I have not determine (cause I have not researched it) how to install that on my PC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
Okay! Dave, can you find any Enterprise COBOL 5.1 shelf for Softcopy Librarian? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, September 13, 2013 2:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for COBOL V5R1 Softcopy Librarian docs I still use and really like Softcopy Librarian. I have stated my opinion of the phase-out of Bookmanager format here before. My opinion of Infocenter is not fit for a public forum:) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On Fri, 13 Sep 2013 11:44:56 -0400, Charles Mills wrote: I have to say I agree. If PDSEs are fundamental to the OS, then internal OS code should support them. It does. But not early in the IPL process. In fact, there are important system components that are designed to use facilities that are available only in program objects, not in load modules. Those system components cannot reside in a PDS. If they're not fundamental, then COBOL should not be requiring them. That is an excuse for you to be hesitant to use PDSE for your applications. Not a very good one, IMO. Do you have a business case that requires that PDSE support be available earlier in the IPL process? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris Sent: Thursday, September 12, 2013 6:29 PM While I have been away from systems programming for over a decade, I am appalled to see that a PDSE still cannot contain SYS1.LINKLIB, SYS1.LPALIB and SYS1.NUCLEUS. Do you have a need for it, or is that just some religious doctrine? Would anyone care if NIP took a cylinder, 2 cylinders or even 100 cylinders. Do you mean the IPL text? I would care if the IPL text was 100 cylinders. That would be nearly 5 MB of code, and I would expect that it would need to have PTFs applied to it far too often. Changing the IPL text is somewhat more complicated than changing elements in LINKLIB, LPALIB and NUCLEUS. In particular, SMP/E is not designed to replace the IPL text. You can't look at your target zone in SMP/E and determine that NIP is at the correct level. Indeed, it is not easy to determine that the IPL text is correct. If, OTOH, you are talking about the NIP modules that reside in SYS1.NUCLEUS, I guess you would still be appalled that SYS1,NUCLEUS still would not be able to be a PDSE. But why do you care? Do you have code that needs to be in the nucleus? z/OS is a big and complicated operating system. Like most operating systems today, it is implemented in several layers. NIP has the most basic support needed to load the nucleus. If started task is a good idea for PDSE, it should be equally good for VSAM. Started tasks are required for many important system functions. It is not clear to me that the use of PDSE is one of them. You can't do much with VSAM or most other data sets until the CATALOG address space is active. Other started tasks are required for you to access SPOOL. Or issue an ENQ. Or allocate a data set for your address space. z/OS is not fully active and ready to process applications until after many started tasks are active. At least code to read PDSE's should be available to NIP and maybe SYS1.NUCLEUS. Why? Do you have a need for it? What is your business case? There are a lot of important system functions that are not available in the nucleus. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex newbie
Two suggestions: 1) the setting up a sysplex series of manuals 2) the merging systems into a sysplex manuals. Sorry, don't have the manual numbers handy. Suggestions: 1) create 2 (2 image) sysplexes (i?). one for test/dev, the other for production. 2) GRS, XCF, etc. can be handled via CTC adapters. Just need some cables. 3) *DO NOT* share anything between test/production sysplexes. Data can be transferred via NJE or TCPIP or HIPERSOCKETS. ( a couple of temporary shared volumes can be created/destroyed for extra large needs). snip Objectives: Simple, low cost (no new equipment if I can help it), low overhead, isolate production from development. We do not need the things that parallel sysplex would give us; anyway, a parallel sysplex on a single box doesn't make sense to me. /snip Bear in mind, that the whole point of a sysplex is to share everything . Some of the items below are hard to do in a sysplex sharing dev/prod images. snip We do want: .. GRS that works in a way that makes sense: cross-system ENQ, convert RESERVEs .. Shared HSM, RMM, catalogs, virtual tape. Probably NJE instead of shared spool. .. Give the developers a place to work so they don't need to log on to prod except to upgrade or fix things .. Developer tools won't run on production Isolation can be accomplished with some vary-offline commands in COMMND00, that allows us to vary prod volumes online to dev if we have to. /snip HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
There is a case to be made for making PDSE support available earlier, even very early, and even if it is initially rudimentary (like the quondam very-early-in-the-initialization-process support for reading only unblocked card images from a PDS member). That case is that as things now stand both PDS support---long in the tooth and radically unsatisfactory in many ways---and PDSE support must go forward together forever. Getting rid of PDSs finally and definitively would be highly desirable, but there is no likelihood of any such IBM action in the proximate future. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
No :), but I won't be looking anytime soon. Given the recent revelations about that version of COBOL and that actually, we are still on IBM Enterprise COBOL for z/OS and OS/390 3.1.0, with a moribund mainframe :( COBOL 5.1 is not even on my list of would be nice to do some day. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, September 13, 2013 12:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for COBOL V5R1 Softcopy Librarian docs Okay! Dave, can you find any Enterprise COBOL 5.1 shelf for Softcopy Librarian? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, September 13, 2013 2:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for COBOL V5R1 Softcopy Librarian docs I still use and really like Softcopy Librarian. I have stated my opinion of the phase-out of Bookmanager format here before. My opinion of Infocenter is not fit for a public forum:) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
On 13 September 2013 15:14, Charles Mills charl...@mcn.org wrote: Okay! Dave, can you find any Enterprise COBOL 5.1 shelf for Softcopy Librarian? I did a little poking around, since it wasn't obvious where Softcopy Librarian was getting its info. You set up an Internet source such as http://publib.boulder.ibm.com (I can't remember if SR comes with this built in, or if I got it from somewhere else, but I think the former.) So when you click on it, SL does an HTML GET for /epubs/df/ebrscrt.des on that site. This file contains a barely structured list of filenames and comments, and *that* is where that Sep 2012 string on the z/OS V1R13 and Software Products Collection PDF/BookMgr comes from. Evidently no one changed the comment, even though the file dates are 13 Sept 2013. So the file for this Collection is /epubs/df/zosv1r13.des, and that, despite the same .des filetype, contains a much more structured - though not XML - list of .bks, .xks, .boo and .pdf files, and some other metadata. You can see these in a browser, but unfortunately the directories containing the files (/epubs/book, /epubs/pdf, and /epubs/bkshelf) are not listable. Now looking at the page http://www-01.ibm.com/support/docview.wss?uid=swg27036733 that was mentioned for COBOL, the PDF files are on the very same publib.boulder.ibm.com server as the SL files. So all it would take would be for someone at IBM pubs (if there's anyone left), to edit the file zosv1r13.des and insert six PDF filenames for COBOL. Or they could do it right and actually create a .xks bookshelf file as well; even Softcopy Reader can do that. As for whether there's any way to fake this by putting your own descriptor files somewhere, well perhaps, if you have a local web server that can serve the /epubs/df directory locally, and redirect all others to the IBM site. Or perhaps you could use the proxy support in SL to redirect selectively. But then you'd still need to know the filenames, and by the time you've done that you might as well do it all (heh) manually. Friday Fun. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
Being a lazy shop, we use PDSEs so that we don't need to compress. All application libraries, source and executable are PDSE format. I yet to have a problem. We are a two system, basic sysplex. We also are plain vanilla. Don't even add sugar!grin/ Of course, we r stuck on 1.12 for the foreseeable future due to the ever decreasing budget we get. So COBOL 5.1 is a no go for us. We are still 3.4.1, but may upgrade due to the recent price equalization announced by IBM. Which has caused much weeping, and wailing, and gnashing of teeth. z price increases just push us closer to getting off of it. I guess that is good riddance to some. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 13 Sep 2013 14:04:56 -0700, in bit.listserv.ibm-main you wrote: There is a case to be made for making PDSE support available earlier, even very early, and even if it is initially rudimentary (like the quondam very-early-in-the-initialization-process support for reading only unblocked card images from a PDS member). IF (caps intentional) the z series AND z/OS are to have a long term future, the z series must support the fastest fiber protocol (see Lynn Wheeler's posts on the subject) and FBA (support that SHORT SIGHTED BEAN COUNTERS vetoed according to Lynn). A GDG facility would need to be added to ESDS processing. PDSE would have to function for ALL library data sets. Non-FBA data architectures would have FBA equivalents and all data architectures would have to be supported at IPL time. Clark Morris That case is that as things now stand both PDS support---long in the tooth and radically unsatisfactory in many ways---and PDSE support must go forward together forever. Getting rid of PDSs finally and definitively would be highly desirable, but there is no likelihood of any such IBM action in the proximate future. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On 9/13/2013 5:47 PM, Clark Morris wrote: IF (caps intentional) the z series AND z/OS are to have a long term future, the z series must support the fastest fiber protocol (see Lynn Wheeler's posts on the subject) and FBA (support that SHORT SIGHTED BEAN COUNTERS vetoed according to Lynn). APAR Identifier .. OA41040 Last Changed 13/09/12 NEW FUNCTION APAR Symptom .. NF FUNCTION Status ... CLOSED UR1 Severity ... 3 Date Closed . 13/09/12 Component .. 5752SC1C3 Duplicate of Reported Release . 780 Fixed Release 999 Component Name IOS Special Notice ATTENTION Current Target Date .. Flags SCP ...NEW FUNCTION Platform Status Detail: APARCLOSURE - APAR is being closed. PE PTF List: PTF List: Release 78H : PTF not available yet Release 780 : PTF not available yet Release 790 : PTF not available yet Parent APAR: Child APAR list: ERROR DESCRIPTION: New Function APAR LOCAL FIX: PROBLEM SUMMARY: * USERS AFFECTED: Users at HBB7780 and above * * PROBLEM DESCRIPTION: New function in support of z/OS FBA * * Services* * RECOMMENDATION: * New function to support z/OS FBA Services. (D/T2107) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
Charles, I have taken a look at several XKS files and have determined that they are nothing more than XML, encoded in UTF-16 Big-Endian format. If you have an appropriate editor, you should be able to create your own. Here is the structure -- ?xml version=1.0 encoding=UTF-1.6 standalone=no? !DOCTYPE XKS PUBLIC -//IBM//BookManager XKS 0.1//EN http://publib.boulder.ibm.com/epubs/df/dtd; XKS SHELFHEADER NAME=filename TITLE/TITLE AUTHOR/AUTHOR UPDATE DATETIME=ccyy-mm-ddThh:mm:ss/UPDATE /SHELFHEADER DOCUMENT DOCID=publication number INSTANCE DOCOBJTYPE=application/pdf NAME=filename VALIDATE=NO TITLE/TITLE UPDATE DATETIME=ccyy-mm-ddThh:mm:ss/UPDATE /INSTANCE /DOCUMENT /XKS The specification for NAME in the SHELFHEADER section should be replaced by the 8-character filename of the XKS file, omitting the filename extension and retaining the double quotes, while the settings of the TITLE, AUTHOR, and UPDATE sections are self-explanatory. I do NOT have any information in respect to length limitations for the TITLE and AUTHOR settings. The DOCUMENT section should be repeated for each document to be included in the bookshelf. The specification for DOCID in the DOCUMENT section should be replaced by the IBM publication number, in the format --nn, retaining the double quotes, NAME should be replaced by the 8-character filename of the PDF file, omitting the filename extension and retaining the double quotes, while the settings of the TITLE and UPDATE sections are self-explanatory. Again, I do NOT have any information in respect to length limitations for the TITLE settings. John P. Baker -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, September 13, 2013 3:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for COBOL V5R1 Softcopy Librarian docs Okay! Dave, can you find any Enterprise COBOL 5.1 shelf for Softcopy Librarian? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, September 13, 2013 2:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for COBOL V5R1 Softcopy Librarian docs I still use and really like Softcopy Librarian. I have stated my opinion of the phase-out of Bookmanager format here before. My opinion of Infocenter is not fit for a public forum:) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On Fri, 13 Sep 2013 18:03:03 -0700, Ed Jaffe wrote: ... PROBLEM SUMMARY: * USERS AFFECTED: Users at HBB7780 and above * * PROBLEM DESCRIPTION: New function in support of z/OS FBA * * Services* * RECOMMENDATION: * New function to support z/OS FBA Services. (D/T2107) Well spotted Ed. Good to see the component is IOS - maybe we'll all (eventually) get some benefit out of it, not just DB2 and/or the JVM. What do you reckon; PDS/E as FBA g,d,r Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On Fri, 13 Sep 2013 18:03:03 -0700, Ed Jaffe wrote:. APAR Identifier .. OA41040 Last Changed 13/09/12 Ambiguous date. https://xkcd.com/1179/ Symptom .. NF FUNCTION Status ... CLOSED UR1 What's UR1? I suppose I should RTFM. Component Name IOS Special Notice ATTENTION iPhone? I'm astonished. (Assuming broad-based support.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
In addition to OA41040, there are at least three (3) related APARs -- OA41558 DEVSERV OA42887 SRM OA42912 [Not available] John P. Baker -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex newbie
On Fri, 13 Sep 2013 20:10:05 +, Staller, Allan wrote: FICON CTC's are currently supported. IIRC PTF's are available for zOS 1.12 and up.. You may be thinking of the FICON support for (non-XCF) GRS ring. FICON CTC for base sysplex has been supported forever - and is a no-brainer IMHO. Absolutely no sense in going (non-XCF) GRS ring if installing new these days. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IXC434I
We are installing a Zec12 and trying to IPL our test systems. We do not have the STP configured yet, but we are just trying to ipl the sysplex. We are getting the message IXC434I: IXC434I SYSTEM SYSC HAS TIMING DEFINITIONS THAT ARE NOT CONSISTENT WITH THE OTHER ACTIVE SYSTEMS IN SYSPLEX SCCTEST - EFFECTIVE CLOCK VALUES ARE NOT CONSISTENT. SYSTEM: SYSC IS USING LOCAL SYSTEM: SYSC IS USING EDCITS How does it even know about EDCITS? Why can't we ipl using the local time? XCF has detected that the sysplex couple dataset has an old entry in the SMST for SYSC running in STP-only CTN EDCITS. Are you saying CLOCKxx specified ETRMODE NO, STPMODE NO? Do you specify SIMETRID? What do you specify for PLEXCFG in IEASYSxx? I am guessing that you specified SIMETRID as you talk about ipling the sysplex. In that case you should reply I to IXC420D to intialize the sysplex. If you did not specify SIMETRID then it seems you have specified PLEXCFG=MULTISYSTEM or ANY. You need to specify PLEXCFG=XCFLOCAL. George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On 9/13/2013 8:43 PM, John P. Baker wrote: In addition to OA41040, there are at least three (3) related APARs -- OA41558 DEVSERV OA42887 SRM OA42912 [Not available] APAR Identifier .. OA42912 https://www-304.ibm.com/ibmlink/sis/viewAparDoc.wss?context=aparAndUsagesearchWords=oa42912documentIds=OA42912lc=encc=US Last Changed 13/09/12 RMF SUPPORT FOR IOS APAR OA41040 https://www-304.ibm.com/ibmlink/sis/viewAparDoc.wss?context=aparAndUsagesearchWords=oa42912documentIds=OA41040lc=encc=US -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
At 21:48 -0500 on 09/13/2013, Paul Gilmartin wrote about Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V: x-charset UTF-8On Fri, 13 Sep 2013 18:03:03 -0700, Ed Jaffe wrote:. APAR Identifier .. OA41040 Last Changed 13/09/12 Ambiguous date. d/m/y (European Date Format) - ie: September 13, 2012. https://xkcd.com/1179/ Symptom .. NF FUNCTION Status ... CLOSED UR1 What's UR1? I suppose I should RTFM. Component Name IOS Special Notice ATTENTION iPhone? I/O Support. I'm astonished. (Assuming broad-based support.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN /x-charset -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On 9/13/2013 9:55 PM, Robert A. Rosenberg wrote: At 21:48 -0500 on 09/13/2013, Paul Gilmartin wrote about Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V: x-charset UTF-8On Fri, 13 Sep 2013 18:03:03 -0700, Ed Jaffe wrote:. APAR Identifier .. OA41040 Last Changed 13/09/12 Ambiguous date. d/m/y (European Date Format) - ie: September 13, 2012. LOL. I guess you're trying to prove Gil's point. :) Of course, anyone who's ever used IBMLink to lookup/access APARs/PTFs knows its dates are of the form yy/mm/dd. The last update was yesterday... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
