z/OS MF environment - effort estimation.
Hi All, Good day. I needed expert advise on how do we calculate the numbers (effort estimation ) provided that we have the infrastructure that we support. Assuming that I have the below: 1) # of LPARs. 2) # of ISV products. 3) Automation on z/os on all LPARs. 4) Storage 5)MIPS 6) # of CICS regions 7) # of DB2 subsystems 8) MQ regions 9) # of WAS 10) # of IMS subsystems etc. I understand that different shops have different strategy in calculating the same. However I needed valuable inputs on how to start estimating. Is there any industry standard or best practice available. How are shops deducing #'s given the infrastructure that is available. I really appreciate all your inputs in this regard. Please let me know for any further information required from my end. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS MF environment - effort estimation.
Anil Kumar wrote: >Good day. I needed expert advise on how do we calculate the numbers (effort >estimation ) What numbers / effort? Costs? Man-hours? CPU estimate? Licenses? Infrastructure? etc.? > ... provided that we have the infrastructure that we support. Are these things in place: Power (Main and UPS), Room space, Physical security? >... Assuming that I have the below: >1) # of LPARs. >2) # of ISV products. >3) Automation on z/os on all LPARs. >4) Storage >5)MIPS >6) # of CICS regions >7) # of DB2 subsystems >8) MQ regions >9) # of WAS >10) # of IMS subsystems More things to add... 11) Network infrastructure including remote connection. 12) Security product(s) 13) PPRC and what else too for your storage... 14) You forgot about DRP. This will certainly double (sort off) your 'effort'. 15) Workstations to access above things ... 16) XCF, Sysplex Timers 17) Add more toys and tools including having a 'Sandbox' LPAR for SMP/E and testing out products. >I understand that different shops have different strategy in calculating the >same. However I needed valuable inputs on how to start estimating. Ask first, how much staff do you have and how much are you willing to pay or pulling in contractors. How many clients / users do you have for each of those listed systems? >Is there any industry standard or best practice available. Yes, there is only ONE standard, it is named 'No Standard'. You will have to figure out yourself what is the best for you. Perhaps there are IBM-MAIN members who can help you or supply you a product which can do those estimates... >I really appreciate all your inputs in this regard. Please let me know for any >further information required from my end. Ask your vendors. They know their products and can give you a ball-park figure of everything. Good luck. 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
AW: Re: RSM Freemained Frames - When do they apply?
> RSM will free frames if available frames are in short supply. > If you obtain a smaller amount, get it backed, and then release it, you > may be more likely to observe the frames being retained. I've changed the program to allocate 8KiB areas instead of 10MiB, and RSM decides to keep the frames upon the storage release. IPCS RSMDATA REALFRAME lists the freemained frames. Although this feature is pretty much useless for the programmer, it's nice to have seen it in action once. Thanks again, Jim. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Track address space which is non reusable
I track ASID usage with the free MXI from Rocket. I track it because some product leave the ASID's in a 'not-reusable' state. I execute it in a batch job and create a running total of how many are available and how many are not-reusable. I've been burned a couple of times when there were no more left and no new address spaces would start. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake Anderson Sent: Monday, December 18, 2017 1:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Track address space which is non reusable 'Why? Just like Lizette asked, you should also give reason why you want that info.' For setting up a health checker. Sorry' i should have told earlier. On 18-Dec-2017 11:03 AM, "Elardus Engelbrecht" < elardus.engelbre...@sita.co.za> wrote: Jake Anderson wrote: >>Is there any rexx exec or a program which can tell me the number of Address space which are nonreusable ASID ? >>zOS 2.2 Why? Just like Lizette asked, you should also give reason why you want that info. Roger Lowe wrote: >If I remember correctly, there should be a Health Check called "IEA_ASIDS" which should give you the info that you are after ... Yup, you are correct. If you have such ASIDs, you will see IEAVEH012I and IEAVEH001I. Also, Mark Zelden has a REXX program 'ASIDLIST". Check his website, you should be able to use Mr. G. O. Ogle's fancy search thing ( :-D ) to search for it. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN - CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System intends this e-mail message, and any attachments, to be used only by the person(s) or entity to which it is addressed. This message may contain confidential and/or legally privileged information. If the reader is not the intended recipient of this message or an employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are prohibited from printing, copying, storing, disseminating or distributing this communication. If you received this communication in error, please delete it from your computer and notify the sender by reply e-mail. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol upgrade 6.2 linklist
On Mon, Dec 18, 2017 at 12:20 AM, Peter Hunkeler wrote: > > If an auditor "pressed", then (if not also insisting on LNKAUTH=APFTAB), > that auditor most likely was wrong. > > > IMHO, those auditors were wrong. Full stop. Auditors should investigate, > document, and suggest. Auditors should never be allowed to force something. > I'm no longer allowed around auditors. I have two problems. The first is that I tell them the absolute truth, as best as I know it. The second is that I tell them to shove off if they start pestering me to "get this done now, I demand you drop everything to do this for me." > > > -- > Peter Hunkeler > > -- I have a theory that it's impossible to prove anything, but I can't prove it. 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: LRS VPS Printer Replacment
I am curious as to why you want to replace VPS with another product, at least one which you would have to pay for anyway. I know that Mckinney has a competing product which is probably cheaper than VPS, but LRS support has always been great (when they get paid on time) and it may not be worth the effort to replace it. Especially if a lot of customized code has to be written. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of zos reader Sent: Thursday, December 14, 2017 4:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: LRS VPS Printer Replacment Hi, We are planning to replace LRS VPS Printers to other Vendor product, I am not aware of other vendor products in Market. Can you all share your thoughts please. Thanks.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ShopZ 24/7? Maybe not so much....
The "new tools" are neither as reliable, available or functional as those they are replacing -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Sunday, December 17, 2017 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ShopZ 24/7? Maybe not so much On 12/17/2017 9:59 AM, Pinnacle wrote: > Thought ShopZ was supposed to be available 24/7, but it appears to be > taking the weekend off. Been trying to get 3 PTF's for over an hour > now. Not like anybody would apply maintenance on a weekend or anything > > Regards, > Tom Conley > 4 hours and counting -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Track address space which is non reusable
Hmmm. Already a health check for ASIDs isn’t there? IEA_ASIDS.Lists normal and replacement IDs. Even tells you How many have become non-reusable since the IPL On Mon, Dec 18, 2017 at 7:31 AM Brown, Duncan wrote: > I track ASID usage with the free MXI from Rocket. > > I track it because some product leave the ASID's in a 'not-reusable' > state. I execute it in a batch job and create a running total of how many > are available and how many are not-reusable. > > I've been burned a couple of times when there were no more left and no new > address spaces would start. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jake Anderson > Sent: Monday, December 18, 2017 1:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Track address space which is non reusable > > 'Why? Just like Lizette asked, you should also give reason why you want > that info.' > > For setting up a health checker. Sorry' i should have told earlier. > > > > > On 18-Dec-2017 11:03 AM, "Elardus Engelbrecht" < > elardus.engelbre...@sita.co.za> wrote: > > Jake Anderson wrote: > > >>Is there any rexx exec or a program which can tell me the number of > Address space which are nonreusable ASID ? > >>zOS 2.2 > > Why? Just like Lizette asked, you should also give reason why you want > that info. > > > Roger Lowe wrote: > > >If I remember correctly, there should be a Health Check called "IEA_ASIDS" > which should give you the info that you are after ... > > Yup, you are correct. If you have such ASIDs, you will see IEAVEH012I and > IEAVEH001I. > > Also, Mark Zelden has a REXX program 'ASIDLIST". Check his website, you > should be able to use Mr. G. O. Ogle's fancy search thing ( :-D ) to search > for it. > > 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > - > CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System > intends this e-mail message, and any attachments, to be used only by the > person(s) or entity to which it is addressed. This message may contain > confidential and/or legally privileged information. If the reader is not > the intended recipient of this message or an employee or agent responsible > for delivering the message to the intended recipient, you are hereby > notified that you are prohibited from printing, copying, storing, > disseminating or distributing this communication. If you received this > communication in error, please delete it from your computer and notify the > sender by reply e-mail. > > > -- > 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: CMS style XMITMSG for Unix and other platforms
Hi Rick, I may not get to try your XMITMSG tool for a while due to other commitments, but the VM facility I miss the most is the SMSG / WAKEUP SMSG facility that permits "server" VM's to run and respond to remote requests from "users". In a prior lifetime my coworkers and I used that facility to implement a nicely featured SCLM for an ISV. I realize that a git server is the modern incarnation of that concept and git is certainly a much more sophisticated SCLM tool, but it would be interesting anyway to have something resembling SMSG / WAKEUP SMSG available in z/OS. XMITMSG would be very helpful in a "disconnected server" setup for sure. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rick Troth Sent: Sunday, December 17, 2017 8:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CMS style XMITMSG for Unix and other platforms EXTERNAL: This email originated from outside of Broadridge. Do not click any links or open any attachments unless you trust the sender and know the content is safe. Aaaand ... it seems to be good enough for download: 'git clone' and then 'make tests'. Works. https://github.com/trothr/xmitmsgx You can also find it on Casita.Net: http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.0.17.tar.gz I'd like to hear back from someone trying it on USS. Should work fine with batch or TSO too when using flat filenames. Realy I'd like to hear back from *anyone* (using it on, e.g., AIX or Linux or whatever). -- R; <>< On 12/11/17 09:34, Rick Troth wrote: > friends -- > > VM/CMS has a wonderful utility driven by 'XMITMSG' (the command) and by > APPLMSG (the macro). If you're a VMer, you know about it. If you're a > VSE or MVS person, maybe not. It's good stuff. For (at least) the second > time, I started putting together an XMITMSG work-alike for Unix (POSIX, > including Linux). Anyone else interested in this? If so, please let me > know. > > There are language libraries and message handlers in Unix land. I have > yet to find one that works like XMITMSG and the APPLMSG macro with token > replacement, enumerated messages, clear codes in the handling. Maybe > there is such, in which case my little "xmitmsgx" project might reduce > to simple interoperability glue code. If so, great! > > I WAS SHOCKED several years ago to learn that there is no equivalent > function in z/OS. It's an incredibly elegant way to handle localization > (national languages, regional dialects). This project should work on MVS > too; it's simple code. > > If you have time and inclination to try this thing (and offer feedback > ... or code), please holler. Thanks! -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ShopZ 24/7? Maybe not so much....
On 12/17/2017 12:52 PM, Tom Conley wrote: On 12/17/2017 9:59 AM, Pinnacle wrote: Thought ShopZ was supposed to be available 24/7, but it appears to be taking the weekend off. Been trying to get 3 PTF's for over an hour now. Not like anybody would apply maintenance on a weekend or anything Regards, Tom Conley 4 hours and counting Finally completed at 316 minutes, or 5 hours and 16 minutes for those of you at home. Can't wait until I need maint to fix a Sev 1 and run into this. What a joke. I can run Windows update anytime I want, why the hell can't I do that for z/OS? We'll bring this up at SHARE yet again, and IBM will assure us they're working on it, they'll point to their 99.99 uptime, and then nothing will change. Lather, rinse, repeat. WAKE UP IBM, THIS IS COMPLETELY UNACCEPTABLE FOR SERVICE DELIVERY!!! Why am I so pissed? We've been working with IBM for AT LEAST five years concerning 24/7 availability for both Service Delivery and IBMLink. Yet we continue to have these extended outages. No wonder people want off the mainframe. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CMS style XMITMSG for Unix and other platforms
On Mon, Dec 18, 2017 at 10:26 AM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Hi Rick, > > I may not get to try your XMITMSG tool for a while due to other > commitments, but the VM facility I miss the most is the SMSG / WAKEUP SMSG > facility that permits "server" VM's to run and respond to remote requests > from "users". In a prior lifetime my coworkers and I used that facility to > implement a nicely featured SCLM for an ISV. > > I realize that a git server is the modern incarnation of that concept and > git is certainly a much more sophisticated SCLM tool, but it would be > interesting anyway to have something resembling SMSG / WAKEUP SMSG > available in z/OS. > I would guess that most software which does that would use the QEDIT macro ( https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa300/qedit.htm) and the associated MODIFY operator command. Of course, this is not really a "general purpose" interface for program to program (IPC) communication. That's a good job for TCPIP or, in some ways even better, UNIX message queues (IPC within a single OS). > > XMITMSG would be very helpful in a "disconnected server" setup for sure. > > Peter > -- I have a theory that it's impossible to prove anything, but I can't prove it. 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: ShopZ 24/7? Maybe not so much....
What he said! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Monday, December 18, 2017 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ShopZ 24/7? Maybe not so much On 12/17/2017 12:52 PM, Tom Conley wrote: > On 12/17/2017 9:59 AM, Pinnacle wrote: >> Thought ShopZ was supposed to be available 24/7, but it appears to be >> taking the weekend off. Been trying to get 3 PTF's for over an hour >> now. Not like anybody would apply maintenance on a weekend or >> anything >> >> Regards, >> Tom Conley >> > > 4 hours and counting > Finally completed at 316 minutes, or 5 hours and 16 minutes for those of you at home. Can't wait until I need maint to fix a Sev 1 and run into this. What a joke. I can run Windows update anytime I want, why the hell can't I do that for z/OS? We'll bring this up at SHARE yet again, and IBM will assure us they're working on it, they'll point to their 99.99 uptime, and then nothing will change. Lather, rinse, repeat. WAKE UP IBM, THIS IS COMPLETELY UNACCEPTABLE FOR SERVICE DELIVERY!!! Why am I so pissed? We've been working with IBM for AT LEAST five years concerning 24/7 availability for both Service Delivery and IBMLink. Yet we continue to have these extended outages. No wonder people want off the mainframe. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CMS style XMITMSG for Unix and other platforms
peter.far...@broadridge.com (Farley, Peter x23353) writes: > I may not get to try your XMITMSG tool for a while due to other > commitments, but the VM facility I miss the most is the SMSG / WAKEUP > SMSG facility that permits "server" VM's to run and respond to remote > requests from "users". In a prior lifetime my coworkers and I used > that facility to implement a nicely featured SCLM for an ISV. > > I realize that a git server is the modern incarnation of that concept > and git is certainly a much more sophisticated SCLM tool, but it would > be interesting anyway to have something resembling SMSG / WAKEUP SMSG > available in z/OS. > > XMITMSG would be very helpful in a "disconnected server" setup for sure. triva: SPM ... special message was a superset of SMSG & IUCV combined. It was original done for CP/67 by the IBM Pisa Scientific Center ... and ported to vm370 in POK. I included it in my internal CSC/VM system distribution for internal datacenters and supported by internal VNET (even included in the original version shipped to customers). Reference in this old post http://www.garlic.com/~lynn/2006w.html#8 and email http://www.garlic.com/~lynn/2006w.html#email750430 more detailed description http://www.garlic.com/~lynn/2006w.html16 I had also done autolog facility ... originally for doing automated benchmarks http://www.garlic.com/~lynn/submain.html#benchmark but was included in my internal CSC/VM distribution and quickly picked up for starting "service virtual machines" ... which could use SPM for doing things like early "automated operator" implementations. It was used by the author of REXX in his multi-user (client/server) space wars implementation ... client supported 3270 display and client/server communication was via SPM. Since VNET internal network supported SPM ... space war players could be on the same machine or anyplace on the internal network. One of the problems was bot players fairly early appeared which were beating all the human players (because they could make moves much faster). Server was then modified that increased energy user non-linearly as interval between moves dropped below some (human) threashold. part of old (client) MFF PLI http://www.garlic.com/~lynn/2005u.html#4 -- 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: ShopZ 24/7? Maybe not so much....
On 12/18/2017 8:30 AM, Tom Conley wrote: We'll bring this up at SHARE yet again, and IBM will assure us they're working on it, they'll point to their 99.99 uptime, and then nothing will change. Funny how the downtime (.001%? Really? No! That counts only "unexpected" outages...) always seems to occur on the weekends when sysprogs need it most... :-\ -- Phoenix Software International Edward E. Jaffe 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: ShopZ 24/7? Maybe not so much....
Tom, FWIW, I agree with everything you are saying with regards to availability. But, from your comments, and from others seem to imply, that it also sounds like you are picking/choosing what PTF's to download? Why not order/download everything available on a weekly basis? Even if you don’t plan to apply it, at least the chances are much better you'll have the PTF you need at in that critical moment. Not preaching, just curious why folks just don’t download/receive everything on a scheduled basis. _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Monday, December 18, 2017 11:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ShopZ 24/7? Maybe not so much **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** On 12/17/2017 12:52 PM, Tom Conley wrote: > On 12/17/2017 9:59 AM, Pinnacle wrote: >> Thought ShopZ was supposed to be available 24/7, but it appears to be >> taking the weekend off. Been trying to get 3 PTF's for over an hour >> now. Not like anybody would apply maintenance on a weekend or >> anything >> >> Regards, >> Tom Conley >> > > 4 hours and counting > Finally completed at 316 minutes, or 5 hours and 16 minutes for those of you at home. Can't wait until I need maint to fix a Sev 1 and run into this. What a joke. I can run Windows update anytime I want, why the hell can't I do that for z/OS? We'll bring this up at SHARE yet again, and IBM will assure us they're working on it, they'll point to their 99.99 uptime, and then nothing will change. Lather, rinse, repeat. WAKE UP IBM, THIS IS COMPLETELY UNACCEPTABLE FOR SERVICE DELIVERY!!! Why am I so pissed? We've been working with IBM for AT LEAST five years concerning 24/7 availability for both Service Delivery and IBMLink. Yet we continue to have these extended outages. No wonder people want off the mainframe. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CMS style XMITMSG for Unix and other platforms
Back in the Paleolithic era IBM ported VMPC to MVS for use by TCP/IP. The Pascal stack has been dead for lo these many years. Is it conceivable that the VMCF port is still present in z/OS V2? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Monday, December 18, 2017 11:26 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: CMS style XMITMSG for Unix and other platforms Hi Rick, I may not get to try your XMITMSG tool for a while due to other commitments, but the VM facility I miss the most is the SMSG / WAKEUP SMSG facility that permits "server" VM's to run and respond to remote requests from "users". In a prior lifetime my coworkers and I used that facility to implement a nicely featured SCLM for an ISV. I realize that a git server is the modern incarnation of that concept and git is certainly a much more sophisticated SCLM tool, but it would be interesting anyway to have something resembling SMSG / WAKEUP SMSG available in z/OS. XMITMSG would be very helpful in a "disconnected server" setup for sure. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rick Troth Sent: Sunday, December 17, 2017 8:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CMS style XMITMSG for Unix and other platforms EXTERNAL: This email originated from outside of Broadridge. Do not click any links or open any attachments unless you trust the sender and know the content is safe. Aaaand ... it seems to be good enough for download: 'git clone' and then 'make tests'. Works. https://secure-web.cisco.com/1569EauQyiUBk0UI-kLr73Tuu_q0uGgwUC6o6G54m_hi6OGCs-qYYVSjKoSYKQD3QMn0V9vZwOa15GRKHwA2fN40NR5koQvP4FdEKHWoseYx0nPtvqhpiR0L8aE3PXDqQbY5FdCi5PbaxahZj6M0Li6U_CYMp41DxVmn6uoGC3SPca3uHccgCC-0NtjE3c7z_Lf2H-zkTXTnQSupTuHh-qigFpGQjwNzZ1sjyeAZh0iqsDvwqv_YVQ14wI_GWMf_pC6c9nQkldJQ9vFcEzcHKvVxDH0nvB1ZiS8MWVUv-19t9u2TA1vZXHkS8PYNwQkPMIIC8p03BvI5LR2JoskT4jT3U-7WtZI-m0AGAlBRiupDN4zUWLuTTZRAESLyQ-dLRQ5M9NDoluzk5ib5Ip8N-HJEOj4wSaS6hjT7D4ihrgL2-YmvPw0IF5TqUOltrc3k-/https%3A%2F%2Fgithub.com%2Ftrothr%2Fxmitmsgx You can also find it on Casita.Net: http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.0.17.tar.gz I'd like to hear back from someone trying it on USS. Should work fine with batch or TSO too when using flat filenames. Realy I'd like to hear back from *anyone* (using it on, e.g., AIX or Linux or whatever). -- R; <>< On 12/11/17 09:34, Rick Troth wrote: > friends -- > > VM/CMS has a wonderful utility driven by 'XMITMSG' (the command) and by > APPLMSG (the macro). If you're a VMer, you know about it. If you're a > VSE or MVS person, maybe not. It's good stuff. For (at least) the second > time, I started putting together an XMITMSG work-alike for Unix (POSIX, > including Linux). Anyone else interested in this? If so, please let me > know. > > There are language libraries and message handlers in Unix land. I have > yet to find one that works like XMITMSG and the APPLMSG macro with token > replacement, enumerated messages, clear codes in the handling. Maybe > there is such, in which case my little "xmitmsgx" project might reduce > to simple interoperability glue code. If so, great! > > I WAS SHOCKED several years ago to learn that there is no equivalent > function in z/OS. It's an incredibly elegant way to handle localization > (national languages, regional dialects). This project should work on MVS > too; it's simple code. > > If you have time and inclination to try this thing (and offer feedback > ... or code), please holler. Thanks! -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: ShopZ 24/7? Maybe not so much....
On 12/18/2017 12:29 PM, Ed Jaffe wrote: On 12/18/2017 8:30 AM, Tom Conley wrote: We'll bring this up at SHARE yet again, and IBM will assure us they're working on it, they'll point to their 99.99 uptime, and then nothing will change. Funny how the downtime (.001%? Really? No! That counts only "unexpected" outages...) always seems to occur on the weekends when sysprogs need it most... :-\ "Me and Eddie tiltin' at the Windmills" (sung to the tune of "Me and Julio Down by the Schoolyard"). Don't get me started on the outages always being Saturday night-Sunday morning. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bad History (was: "make" question)
Keep in mind that originally POSIX and UNIX were different. IBM even documented the discrepancies between the two. AFAIK IEEE POSIX has been swallowed by the successor to X/OPEN and you now only need a single certification, but that wasn't the case at the time of the original MVSOE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Saturday, December 16, 2017 11:11 AM To: IBM-MAIN@listserv.ua.edu Subject: Bad History (was: "make" question) On Sat, 16 Dec 2017 16:58:15 +0800, David Crayford wrote: > >... I would pick gmake 9/10 because it's pervasive and more >portable. If you work with open source software on z/OS gmake is a must >have. > I imagine: RFE: We want UNIX. IBM: Be more specific. Both: (After much deliberation) Single UNIX specification. And so it went. There's no formal specification of GNU Linux. Sigh. -- gil -- 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: Cobol upgrade 6.2 linklist
"He jests at scars that never felt a wound." But it's not my dog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Saturday, December 16, 2017 1:26 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Cobol upgrade 6.2 linklist Some folks have probably been burned by the abuse of user libraries in the LINKLIST and so preach fire and brimstone against it. To others it is just "business as usual" because they have not experienced such abuse or its consequences. I am one of them. As I said, YMMV. Each company is a mini-culture unto itself, and our beliefs and fears are ruled by culture and experience. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, December 15, 2017 7:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol upgrade 6.2 linklist I dunno... when we migrated from VSE to z/OS in 2010 I was almost burned as a heretic for suggesting that user application libraries be placed in the linklist... From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Friday, December 15, 2017 2:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol upgrade 6.2 linklist Re: #3, that is not necessarily true. Depends heavily on the shop-standard STEPLIB rules (use or don't use production "user library" in STEPLIB's). As long as the "normal" rule is NOT to use production "user library" in STEPLIB's and you choose to use the "two library" approach to migration, putting the PDSE ahead of the PDS in the LINKLIST makes sense and does what you need it to do. As usual, I think it is a case of YMMV depending on your shop's historical STEPLIB rules. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, December 15, 2017 1:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol upgrade 6.2 linklist I am surprised no one yet as asked, is the OP referring to 1) The COBOL compiler library, 2) the COBOL runtime library, or 3) user libraries with COBOL programs. 1) Don't see any real need for this. 2) Probably already done, as the COBOL runtime library is CEE.SCEERUN 3) I've been told that "user libraries" like this should never be in the linklist. From: IBM Mainframe Discussion List on behalf of Jake Anderson Sent: Friday, December 15, 2017 5:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Cobol upgrade 6.2 linklist Hi A general question Do you still cobol load module in linklist post upgrade to 6.2 ? Regards Jake -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: Cobol upgrade 6.2 linklist
It used to be that you couldn't have PDSE in LNKLSTxx, but could add a PDSE with an automatic SETPROG command. I don't know whether that restriction still exists. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Carmen Vitullo Sent: Friday, December 15, 2017 1:15 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Cobol upgrade 6.2 linklist Hum , I know COBOL object modules 5+ need to be PDS/E, but I've never knew about the linklist restrictions with PDS/E , so what about IBM libraries in the linklist from my serverpac build? alway had in CPAC.PARMLIB and migrated forward. SYS1.SHASLNKE SYS1.SIEALNKE SYS1.SIEAMIGEetc am I taking unnecessary chances? Carmen Vitullo - Original Message - From: "Lizette Koehler" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, December 15, 2017 11:47:57 AM Subject: Re: Cobol upgrade 6.2 linklist As you will find out. Any Cobol program compiled from the Cobol Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD. If you have your application batch load library in the LINKLST then you will need to move it into the place where you start other PDS/E Dataset in the Linklst. The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do not have the SMSPDSx ASID available at the time the LINKLST is done. You have to build it after the SMSPDSx STC is up Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jake Anderson > Sent: Friday, December 15, 2017 5:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Cobol upgrade 6.2 linklist > > Hi > > A general question > > Do you still cobol load module in linklist post upgrade to 6.2 ? > > Regards > Jake > -- 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: ShopZ 24/7? Maybe not so much....
We run a nightly batch job to receive all PTF's from IBM one for each CSI. That way as long as the Friday job ran we should have ANY PTF for that product if we need to apply something during the Maint window. We also include the hold data in that same job so as to catch as many PE's as we can. -- Jerry Whitteridge IBM Global Services Delivery Manager e-Mail: jerry.whitteri...@ibm.com Cell: 602 527 4871 < Note New Phone Number IBM Mainframe Discussion List wrote on 12/18/2017 10:39:24 AM: > From: "Jousma, David" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 12/18/2017 10:40 AM > Subject: Re: ShopZ 24/7? Maybe not so much > Sent by: IBM Mainframe Discussion List > > Tom, > > FWIW, I agree with everything you are saying with regards to > availability. But, from your comments, and from others seem to > imply, that it also sounds like you are picking/choosing what PTF's > to download? Why not order/download everything available on a > weekly basis? Even if you don’t plan to apply it, at least the > chances are much better you'll have the PTF you need at in that > critical moment. > > Not preaching, just curious why folks just don’t download/receive > everything on a scheduled basis. > > _ > Dave Jousma > Manager Mainframe Engineering, Assistant Vice President > david.jou...@53.com > 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H > p 616.653.8429 > f 616.653.2717 > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Tom Conley > Sent: Monday, December 18, 2017 11:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ShopZ 24/7? Maybe not so much > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > On 12/17/2017 12:52 PM, Tom Conley wrote: > > On 12/17/2017 9:59 AM, Pinnacle wrote: > >> Thought ShopZ was supposed to be available 24/7, but it appears to be > >> taking the weekend off. Been trying to get 3 PTF's for over an hour > >> now. Not like anybody would apply maintenance on a weekend or > >> anything > >> > >> Regards, > >> Tom Conley > >> > > > > 4 hours and counting > > > > Finally completed at 316 minutes, or 5 hours and 16 minutes for > those of you at home. Can't wait until I need maint to fix a Sev 1 > and run into this. What a joke. I can run Windows update anytime I > want, why the hell can't I do that for z/OS? We'll bring this up at > SHARE yet again, and IBM will assure us they're working on it, > they'll point to their > 99.99 uptime, and then nothing will change. Lather, rinse, repeat. > > WAKE UP IBM, THIS IS COMPLETELY UNACCEPTABLE FOR SERVICE DELIVERY!!! > > Why am I so pissed? We've been working with IBM for AT LEAST five > years concerning 24/7 availability for both Service Delivery and > IBMLink. Yet we continue to have these extended outages. No wonder > people want off the mainframe. > > Regards, > Tom Conley > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > This e-mail transmission contains information that is confidential > and may be privileged. It is intended only for the addressee(s) > named above. If you receive this e-mail in error, please do not > read, copy or disseminate it in any manner. If you are not the > intended recipient, any disclosure, copying, distribution or use of > the contents of this information is prohibited. Please reply to the > message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer > system. Your assistance in correcting this error is appreciated. > > > -- > 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: ShopZ 24/7? Maybe not so much....
On 12/18/2017 9:39 AM, Jousma, David wrote: ... from your comments, and from others seem to imply, that it also sounds like you are picking/choosing what PTF's to download? Why not order/download everything available on a weekly basis? Rather than downloading ALL, we choose to download only that which is recommended by IBM. What's wrong with that? SET BOUNDARY (GLOBAL) . RECEIVE ORDER( ORDERSERVER(ORDSRVR) CONTENT(RECOMMENDED) CLIENT(SMPCLNT) WAIT(NOLIMIT) /* As long as it takes */ ) DELETEPKG . -- Phoenix Software International Edward E. Jaffe 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: Cobol upgrade 6.2 linklist
The issue with PDSE in the linklist is related to any PDSE that is in the IPL linklist gets an tag to (I think it is ) XCFAS so that if you whish to do dynamic maintenance to a product you can take the existing library out of the linklist, but can't rename etc. You would then need to use a new Library name to put the product back into linklist. If you are not in the habit of doing dynamic maintenance the PDSE in the IPL linklist isn't an issue, and if you can use different names it's also not an issue. -- Jerry Whitteridge IBM Global Services Delivery Manager e-Mail: jerry.whitteri...@ibm.com Cell: 602 527 4871 < Note New Phone Number IBM Mainframe Discussion List wrote on 12/18/2017 11:17:01 AM: > From: Seymour J Metz > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 12/18/2017 11:17 AM > Subject: Re: Cobol upgrade 6.2 linklist > Sent by: IBM Mainframe Discussion List > > It used to be that you couldn't have PDSE in LNKLSTxx, but could add > a PDSE with an automatic SETPROG command. I don't know whether that > restriction still exists. > > -- > Shmuel (Seymour J.) Metz > https://urldefense.proofpoint.com/v2/url? > u=http-3A__mason.gmu.edu_-7Esmetz3&d=DwIFAw&c=jf_iaSHvJObTbx- > siA1ZOg&r=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E&m=C2kzwWYqC2ybVmHsfpyw64D6PNfA6yu1lS3vcYix7Vo&s=VBOFuf9SLwZLzw4062UipuCiuQswXhRkKon3Cw5np64&e= > > > From: IBM Mainframe Discussion List on > behalf of Carmen Vitullo > Sent: Friday, December 15, 2017 1:15 PM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: Cobol upgrade 6.2 linklist > > Hum , I know COBOL object modules 5+ need to be PDS/E, but I've > never knew about the linklist restrictions with PDS/E , so what > about IBM libraries in the linklist from my serverpac build? > alway had in CPAC.PARMLIB and migrated forward. > > > SYS1.SHASLNKE > > > > SYS1.SIEALNKE > > > SYS1.SIEAMIGEetc > am I taking unnecessary chances? > > > > Carmen Vitullo > > - Original Message - > > From: "Lizette Koehler" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Friday, December 15, 2017 11:47:57 AM > Subject: Re: Cobol upgrade 6.2 linklist > > As you will find out. Any Cobol program compiled from the Cobol > Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD. > > If you have your application batch load library in the LINKLST then > you will need to move it into the place where you start other PDS/E > Dataset in the Linklst. > > The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do > not have the SMSPDSx ASID available at the time the LINKLST is done. > You have to build it after the SMSPDSx STC is up > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Jake Anderson > > Sent: Friday, December 15, 2017 5:51 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Cobol upgrade 6.2 linklist > > > > Hi > > > > A general question > > > > Do you still cobol load module in linklist post upgrade to 6.2 ? > > > > Regards > > Jake > > > > -- > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol upgrade 6.2 linklist
I see your points, for me, it's never been in a habit of upgrading any target lib's that are linklisted, did that once with some older XX products (PDS) that didn't act well after trying dynamically refreshing LLA and the linklist, so I've built my linklist lib's from my target libs, and IPL most times. Carmen Vitullo - Original Message - From: "Jerry Whitteridge" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, December 18, 2017 12:21:55 PM Subject: Re: Cobol upgrade 6.2 linklist The issue with PDSE in the linklist is related to any PDSE that is in the IPL linklist gets an tag to (I think it is ) XCFAS so that if you whish to do dynamic maintenance to a product you can take the existing library out of the linklist, but can't rename etc. You would then need to use a new Library name to put the product back into linklist. If you are not in the habit of doing dynamic maintenance the PDSE in the IPL linklist isn't an issue, and if you can use different names it's also not an issue. -- Jerry Whitteridge IBM Global Services Delivery Manager e-Mail: jerry.whitteri...@ibm.com Cell: 602 527 4871 < Note New Phone Number IBM Mainframe Discussion List wrote on 12/18/2017 11:17:01 AM: > From: Seymour J Metz > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 12/18/2017 11:17 AM > Subject: Re: Cobol upgrade 6.2 linklist > Sent by: IBM Mainframe Discussion List > > It used to be that you couldn't have PDSE in LNKLSTxx, but could add > a PDSE with an automatic SETPROG command. I don't know whether that > restriction still exists. > > -- > Shmuel (Seymour J.) Metz > https://urldefense.proofpoint.com/v2/url? > u=http-3A__mason.gmu.edu_-7Esmetz3&d=DwIFAw&c=jf_iaSHvJObTbx- > siA1ZOg&r=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E&m=C2kzwWYqC2ybVmHsfpyw64D6PNfA6yu1lS3vcYix7Vo&s=VBOFuf9SLwZLzw4062UipuCiuQswXhRkKon3Cw5np64&e= > > > From: IBM Mainframe Discussion List on > behalf of Carmen Vitullo > Sent: Friday, December 15, 2017 1:15 PM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: Cobol upgrade 6.2 linklist > > Hum , I know COBOL object modules 5+ need to be PDS/E, but I've > never knew about the linklist restrictions with PDS/E , so what > about IBM libraries in the linklist from my serverpac build? > alway had in CPAC.PARMLIB and migrated forward. > > > SYS1.SHASLNKE > > > > SYS1.SIEALNKE > > > SYS1.SIEAMIGEetc > am I taking unnecessary chances? > > > > Carmen Vitullo > > - Original Message - > > From: "Lizette Koehler" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Friday, December 15, 2017 11:47:57 AM > Subject: Re: Cobol upgrade 6.2 linklist > > As you will find out. Any Cobol program compiled from the Cobol > Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD. > > If you have your application batch load library in the LINKLST then > you will need to move it into the place where you start other PDS/E > Dataset in the Linklst. > > The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do > not have the SMSPDSx ASID available at the time the LINKLST is done. > You have to build it after the SMSPDSx STC is up > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Jake Anderson > > Sent: Friday, December 15, 2017 5:51 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Cobol upgrade 6.2 linklist > > > > Hi > > > > A general question > > > > Do you still cobol load module in linklist post upgrade to 6.2 ? > > > > Regards > > Jake > > > > -- > 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 > -- 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: "make" question
Tabs were a bloody nuisance long before 3270 displays came along; in fact, they may have been worse on hardcopy terminals than on 3270s. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of John McKown Sent: Thursday, December 14, 2017 2:08 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: "make" question On Thu, Dec 14, 2017 at 12:56 PM, Jack J. Woehr wrote: > On 12/14/2017 7:25 AM, Gord Tomlin wrote: > >> All the make tools share an annoying reliance on tab characters. > > > This is somehow more pernicious than punch-card-column dependencies in > traditional IBM tools? :) IMO, the use of tabs as a "data character" is only annoying to people stuck on a 3270 display. I have _no_ problems with them when I'm using ssh to get a UNIX shell. Boiled down, I will agree that using UNIX tools in a TSO (3270) environment is annoying. Equally annoying, to me, is the column dependencies when I editing an HLASM or COBOL program from the UNIX shell. And don't get me going on the "vi" that IBM distributes. > -- > Jack J. Woehr # Science is more than a body of knowledge. It's a way of > http://secure-web.cisco.com/1ybTM2fIPP6WIfaVgbAVnswUzPnLdlv3Q8suGEuvNuIcWmlO1FeCilZ_8AhBDR-gmcGDcWhBJEMVBPDjtPo47Ec46mMyk-AOKheGSj1zNZIOcc1PcpkdPbisMbUUwXdyxchTPLkS9938zz2xTA-atthJaQg8nrixGqy71j40crWiVHjKaJvcMhcM9azcZhOXm_krOIUa8sblenqgCAnmtqbNSt3SM6rhLSb33bqcKbth50bY0xFf6E4s7hYftAcX6Jn6IIYuYLjj2sxSYKJ4Lid-vuodLYc4D758luythtRxrb0-N0X5-cas0_7vXj6XnN4ZzfOH5RrAwzTh8V-zKkU5HwMD6yW_7sAusgAdvov4FtuFtqpTgxabUa3aMKgLc/http%3A%2F%2Fwww.well.com%2F%7Ejax > # thinking, a way of skeptically interrogating the > universe > www.softwoehr.com # with a fine understanding of human fallibility. - > Carl Sagan > -- I have a theory that it's impossible to prove anything, but I can't prove it. 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
Re: ShopZ 24/7? Maybe not so much....
This is not to excuse bad behavior, but for years IBM has recommended pulling all available fixes on a regular schedule, e.g. daily. This to guard against this kind of situation: needing a particular fix in a big hurry when the delivery mechanism is not working for whatever reason. (Do as they say, not as I do.) We have discussed ServiceLink availability with IBM at several SHARE meetings. Our point was that since (probably the vast majority of) customers perform maintenance activities on weekends, that's the worst time for ServiceLink maintenance. We got considerable sympathy from the folks we met with, but they admitted that they don't control the schedule and could only recommend. Meanwhile the IBM maintenance schedule seems not to have changed. Sigh. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, December 18, 2017 9:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: ShopZ 24/7? Maybe not so much On 12/18/2017 8:30 AM, Tom Conley wrote: > We'll bring this up at SHARE yet again, and IBM will assure us they're > working on it, they'll point to their 99.99 uptime, and then nothing > will change. Funny how the downtime (.001%? Really? No! That counts only "unexpected" outages...) always seems to occur on the weekends when sysprogs need it most... :-\ -- Phoenix Software International Edward E. Jaffe 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: ShopZ 24/7? Maybe not so much....
On 12/18/2017 1:19 PM, Ed Jaffe wrote: On 12/18/2017 9:39 AM, Jousma, David wrote: ... from your comments, and from others seem to imply, that it also sounds like you are picking/choosing what PTF's to download? Why not order/download everything available on a weekly basis? Rather than downloading ALL, we choose to download only that which is recommended by IBM. What's wrong with that? SET BOUNDARY (GLOBAL) . RECEIVE ORDER( ORDERSERVER(ORDSRVR) CONTENT(RECOMMENDED) CLIENT(SMPCLNT) WAIT(NOLIMIT) /* As long as it takes */ ) DELETEPKG . In my case, I was trying to get AST fixes hot off the press, with a requisite 24-hour delay to make sure all the SOURCEIDs attached. Yeah, that's right, the PTF is made available before all its SOURCEIDs have been attached (I can't make this "stuff" up). I do an ALL about once a month, I may start doing it weekly. But Murphy applies here. The fix you need in a time of crisis will not be RECEIVEd, and ShopZ will be unavailable to download it. I've also seen ShopZ outages reported here at all times of the day or night, so periodically downloading ALL is not the answer. IBM investing in a support structure that is available 24/7 is the answer. And it's been the answer for years now. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ShopZ 24/7? Maybe not so much....
What he said! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Monday, December 18, 2017 12:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ShopZ 24/7? Maybe not so much On 12/18/2017 1:19 PM, Ed Jaffe wrote: > On 12/18/2017 9:39 AM, Jousma, David wrote: >> ... from your comments, and from others seem to imply, that it also >> sounds like you are picking/choosing what PTF's to download? Why >> not order/download everything available on a weekly basis? > > Rather than downloading ALL, we choose to download only that which is > recommended by IBM. What's wrong with that? > >SET BOUNDARY (GLOBAL) . >RECEIVE ORDER( > ORDERSERVER(ORDSRVR) > CONTENT(RECOMMENDED) > CLIENT(SMPCLNT) > WAIT(NOLIMIT) /* As long as it takes */ >) DELETEPKG . > In my case, I was trying to get AST fixes hot off the press, with a requisite 24-hour delay to make sure all the SOURCEIDs attached. Yeah, that's right, the PTF is made available before all its SOURCEIDs have been attached (I can't make this "stuff" up). I do an ALL about once a month, I may start doing it weekly. But Murphy applies here. The fix you need in a time of crisis will not be RECEIVEd, and ShopZ will be unavailable to download it. I've also seen ShopZ outages reported here at all times of the day or night, so periodically downloading ALL is not the answer. IBM investing in a support structure that is available 24/7 is the answer. And it's been the answer for years now. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ES/9000 Console Cable
Quick question: On the small ES/9000s (9221-150), how exactly does the console cable connect to the processor? Parallel port from the PC (apparently S/390 and 9370 are like this)? -- Will -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CMS style XMITMSG for Unix and other platforms
Interesting question. I do see a VMCF STC on our V2.1 system. Where would one look to find docs on how to use it? Comm Server docs? Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, December 18, 2017 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CMS style XMITMSG for Unix and other platforms Back in the Paleolithic era IBM ported VMPC to MVS for use by TCP/IP. The Pascal stack has been dead for lo these many years. Is it conceivable that the VMCF port is still present in z/OS V2? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Monday, December 18, 2017 11:26 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: CMS style XMITMSG for Unix and other platforms Hi Rick, I may not get to try your XMITMSG tool for a while due to other commitments, but the VM facility I miss the most is the SMSG / WAKEUP SMSG facility that permits "server" VM's to run and respond to remote requests from "users". In a prior lifetime my coworkers and I used that facility to implement a nicely featured SCLM for an ISV. I realize that a git server is the modern incarnation of that concept and git is certainly a much more sophisticated SCLM tool, but it would be interesting anyway to have something resembling SMSG / WAKEUP SMSG available in z/OS. XMITMSG would be very helpful in a "disconnected server" setup for sure. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rick Troth Sent: Sunday, December 17, 2017 8:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CMS style XMITMSG for Unix and other platforms Aaaand ... it seems to be good enough for download: 'git clone' and then 'make tests'. Works. https://secure-web.cisco.com/1569EauQyiUBk0UI-kLr73Tuu_q0uGgwUC6o6G54m_hi6OGCs-qYYVSjKoSYKQD3QMn0V9vZwOa15GRKHwA2fN40NR5koQvP4FdEKHWoseYx0nPtvqhpiR0L8aE3PXDqQbY5FdCi5PbaxahZj6M0Li6U_CYMp41DxVmn6uoGC3SPca3uHccgCC-0NtjE3c7z_Lf2H-zkTXTnQSupTuHh-qigFpGQjwNzZ1sjyeAZh0iqsDvwqv_YVQ14wI_GWMf_pC6c9nQkldJQ9vFcEzcHKvVxDH0nvB1ZiS8MWVUv-19t9u2TA1vZXHkS8PYNwQkPMIIC8p03BvI5LR2JoskT4jT3U-7WtZI-m0AGAlBRiupDN4zUWLuTTZRAESLyQ-dLRQ5M9NDoluzk5ib5Ip8N-HJEOj4wSaS6hjT7D4ihrgL2-YmvPw0IF5TqUOltrc3k-/https%3A%2F%2Fgithub.com%2Ftrothr%2Fxmitmsgx You can also find it on Casita.Net: http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.0.17.tar.gz I'd like to hear back from someone trying it on USS. Should work fine with batch or TSO too when using flat filenames. Realy I'd like to hear back from *anyone* (using it on, e.g., AIX or Linux or whatever). -- R; <>< On 12/11/17 09:34, Rick Troth wrote: > friends -- > > VM/CMS has a wonderful utility driven by 'XMITMSG' (the command) and > by APPLMSG (the macro). If you're a VMer, you know about it. If you're > a VSE or MVS person, maybe not. It's good stuff. For (at least) the > second time, I started putting together an XMITMSG work-alike for Unix > (POSIX, including Linux). Anyone else interested in this? If so, > please let me know. > > There are language libraries and message handlers in Unix land. I have > yet to find one that works like XMITMSG and the APPLMSG macro with > token replacement, enumerated messages, clear codes in the handling. > Maybe there is such, in which case my little "xmitmsgx" project might > reduce to simple interoperability glue code. If so, great! > > I WAS SHOCKED several years ago to learn that there is no equivalent > function in z/OS. It's an incredibly elegant way to handle > localization (national languages, regional dialects). This project > should work on MVS too; it's simple code. > > If you have time and inclination to try this thing (and offer feedback > ... or code), please holler. Thanks! -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ES/9000 Console Cable
HMC ? if you are talking master console, or system consoles, I believe it was a token ring network http://www-01.ibm.com/support/docview.wss?uid=isg2ba4122bfe6d689198525666e005d3c9f&aid=1 this may help Carmen Vitullo - Original Message - From: "William Donzelli" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, December 18, 2017 1:04:24 PM Subject: ES/9000 Console Cable Quick question: On the small ES/9000s (9221-150), how exactly does the console cable connect to the processor? Parallel port from the PC (apparently S/390 and 9370 are like this)? -- Will -- 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: ShopZ 24/7? Maybe not so much....
Nothing wrong with that. But why? Invariably, you'll need that one PTF that isn’t there _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, December 18, 2017 1:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ShopZ 24/7? Maybe not so much **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** On 12/18/2017 9:39 AM, Jousma, David wrote: > ... from your comments, and from others seem to imply, that it also sounds > like you are picking/choosing what PTF's to download? Why not > order/download everything available on a weekly basis? Rather than downloading ALL, we choose to download only that which is recommended by IBM. What's wrong with that? SET BOUNDARY (GLOBAL) . RECEIVE ORDER( ORDERSERVER(ORDSRVR) CONTENT(RECOMMENDED) CLIENT(SMPCLNT) WAIT(NOLIMIT) /* As long as it takes */ ) DELETEPKG . -- Phoenix Software International Edward E. Jaffe 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 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CMS style XMITMSG for Unix and other platforms
My guess would be CS, but ICBW. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Monday, December 18, 2017 2:19 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: CMS style XMITMSG for Unix and other platforms Interesting question. I do see a VMCF STC on our V2.1 system. Where would one look to find docs on how to use it? Comm Server docs? Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, December 18, 2017 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CMS style XMITMSG for Unix and other platforms Back in the Paleolithic era IBM ported VMPC to MVS for use by TCP/IP. The Pascal stack has been dead for lo these many years. Is it conceivable that the VMCF port is still present in z/OS V2? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Monday, December 18, 2017 11:26 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: CMS style XMITMSG for Unix and other platforms Hi Rick, I may not get to try your XMITMSG tool for a while due to other commitments, but the VM facility I miss the most is the SMSG / WAKEUP SMSG facility that permits "server" VM's to run and respond to remote requests from "users". In a prior lifetime my coworkers and I used that facility to implement a nicely featured SCLM for an ISV. I realize that a git server is the modern incarnation of that concept and git is certainly a much more sophisticated SCLM tool, but it would be interesting anyway to have something resembling SMSG / WAKEUP SMSG available in z/OS. XMITMSG would be very helpful in a "disconnected server" setup for sure. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rick Troth Sent: Sunday, December 17, 2017 8:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CMS style XMITMSG for Unix and other platforms Aaaand ... it seems to be good enough for download: 'git clone' and then 'make tests'. Works. https://secure-web.cisco.com/1569EauQyiUBk0UI-kLr73Tuu_q0uGgwUC6o6G54m_hi6OGCs-qYYVSjKoSYKQD3QMn0V9vZwOa15GRKHwA2fN40NR5koQvP4FdEKHWoseYx0nPtvqhpiR0L8aE3PXDqQbY5FdCi5PbaxahZj6M0Li6U_CYMp41DxVmn6uoGC3SPca3uHccgCC-0NtjE3c7z_Lf2H-zkTXTnQSupTuHh-qigFpGQjwNzZ1sjyeAZh0iqsDvwqv_YVQ14wI_GWMf_pC6c9nQkldJQ9vFcEzcHKvVxDH0nvB1ZiS8MWVUv-19t9u2TA1vZXHkS8PYNwQkPMIIC8p03BvI5LR2JoskT4jT3U-7WtZI-m0AGAlBRiupDN4zUWLuTTZRAESLyQ-dLRQ5M9NDoluzk5ib5Ip8N-HJEOj4wSaS6hjT7D4ihrgL2-YmvPw0IF5TqUOltrc3k-/https%3A%2F%2Fgithub.com%2Ftrothr%2Fxmitmsgx You can also find it on Casita.Net: http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.0.17.tar.gz I'd like to hear back from someone trying it on USS. Should work fine with batch or TSO too when using flat filenames. Realy I'd like to hear back from *anyone* (using it on, e.g., AIX or Linux or whatever). -- R; <>< On 12/11/17 09:34, Rick Troth wrote: > friends -- > > VM/CMS has a wonderful utility driven by 'XMITMSG' (the command) and > by APPLMSG (the macro). If you're a VMer, you know about it. If you're > a VSE or MVS person, maybe not. It's good stuff. For (at least) the > second time, I started putting together an XMITMSG work-alike for Unix > (POSIX, including Linux). Anyone else interested in this? If so, > please let me know. > > There are language libraries and message handlers in Unix land. I have > yet to find one that works like XMITMSG and the APPLMSG macro with > token replacement, enumerated messages, clear codes in the handling. > Maybe there is such, in which case my little "xmitmsgx" project might > reduce to simple interoperability glue code. If so, great! > > I WAS SHOCKED several years ago to learn that there is no equivalent > function in z/OS. It's an incredibly elegant way to handle > localization (national languages, regional dialects). This project > should work on MVS too; it's simple code. > > If you have time and inclination to try this thing (and offer feedback > ... or code), please holler. Thanks! -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CMS style XMITMSG for Unix and other platforms
sme...@gmu.edu (Seymour J Metz) writes: > Back in the Paleolithic era IBM ported VMPC to MVS for use by > TCP/IP. The Pascal stack has been dead for lo these many years. Is it > conceivable that the VMCF port is still present in z/OS V2? I've periodically commented about how how the communication group was going to be responsible for the demise of the disk division ... communication group had corporate strategic responsibility ("stranglehold") for everything crossed datacenter walls and was fiercely fighting off distributed computing and client/server (trying to preserve their dumb terminal paradigm). some past posts http://www.garlic.com/~lynn/subnetwork.html#terminal Part of this was doing its best to prevent shipping TCP/IP. Eventually it shipped but only got 44kbytes/sec transfer using whole 3090 cpu. I did the enhancements for rfc1044 and in some throughput tests at Cray research, got mbyte/sec channel speed throughput between 4341 and Cray using only modest amount of 4341 processor (possibly 500 times improvement in cpu used per bytes moved) ... some past posts http://www.garlic.com/~lynn/subnetwork.html#1044 sometime later, it was ported to MVS by emulating VM370 function on MVS. However later, the communication group hired subcontractor to add TCP/IP support to VTAM. His initial implementation had TCP/IP performing much faster than LU6.2. He was told that everybody "knows" that a "correct" TCP/IP implementation is much slower than LU6.2 and they would only be paying for a "correct" implementation. recent post in thread http://www.garlic.com/~lynn/2017k.html#37 CMS style XMITMSG for Unix and other platforms recent post about communication group http://www.garlic.com/~lynn/2017k.html#34 Bad History -- 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: ES/9000 Console Cable
I do not think they called them HMCs back during the ES/9000 era (at least for the little ones), just "Processor Console". -- Will On Mon, Dec 18, 2017 at 2:20 PM, Carmen Vitullo wrote: > HMC ? > if you are talking master console, or system consoles, I believe it was a > token ring network > > > http://www-01.ibm.com/support/docview.wss?uid=isg2ba4122bfe6d689198525666e005d3c9f&aid=1 > > > this may help > > > > Carmen Vitullo > > - Original Message - > > From: "William Donzelli" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Monday, December 18, 2017 1:04:24 PM > Subject: ES/9000 Console Cable > > Quick question: > > On the small ES/9000s (9221-150), how exactly does the console cable > connect to the processor? Parallel port from the PC (apparently S/390 > and 9370 are like this)? > > -- > Will > > -- > 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: CMS style XMITMSG for Unix and other platforms
On Mon, Dec 18, 2017 at 1:25 PM, Seymour J Metz wrote: > My guess would be CS, but ICBW. > You're right. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halz002/ip_vmcf_tnf_config.htm > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Farley, Peter x23353 > Sent: Monday, December 18, 2017 2:19 PM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: CMS style XMITMSG for Unix and other platforms > > Interesting question. I do see a VMCF STC on our V2.1 system. Where > would one look to find docs on how to use it? Comm Server docs? > > Peter > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Seymour J Metz > Sent: Monday, December 18, 2017 12:42 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CMS style XMITMSG for Unix and other platforms > > Back in the Paleolithic era IBM ported VMPC to MVS for use by TCP/IP. The > Pascal stack has been dead for lo these many years. Is it conceivable that > the VMCF port is still present in z/OS V2? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Farley, Peter x23353 > Sent: Monday, December 18, 2017 11:26 AM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: CMS style XMITMSG for Unix and other platforms > > Hi Rick, > > I may not get to try your XMITMSG tool for a while due to other > commitments, but the VM facility I miss the most is the SMSG / WAKEUP SMSG > facility that permits "server" VM's to run and respond to remote requests > from "users". In a prior lifetime my coworkers and I used that facility to > implement a nicely featured SCLM for an ISV. > > I realize that a git server is the modern incarnation of that concept and > git is certainly a much more sophisticated SCLM tool, but it would be > interesting anyway to have something resembling SMSG / WAKEUP SMSG > available in z/OS. > > XMITMSG would be very helpful in a "disconnected server" setup for sure. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Rick Troth > Sent: Sunday, December 17, 2017 8:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CMS style XMITMSG for Unix and other platforms > > Aaaand ... it seems to be good enough for download: 'git clone' and then > 'make tests'. Works. > > https://secure-web.cisco.com/1569EauQyiUBk0UI-kLr73Tuu_ > q0uGgwUC6o6G54m_hi6OGCs-qYYVSjKoSYKQD3QMn0V9vZwOa15GRK > HwA2fN40NR5koQvP4FdEKHWoseYx0nPtvqhpiR0L8aE3PXDqQbY5FdCi5PbaxahZj6M0Li6U_ > CYMp41DxVmn6uoGC3SPca3uHccgCC-0NtjE3c7z_Lf2H-zkTXTnQSupTuHh- > qigFpGQjwNzZ1sjyeAZh0iqsDvwqv_YVQ14wI_GWMf_pC6c9nQkldJQ9vFcEzcHKvVxDH0nvB > 1ZiS8MWVUv-19t9u2TA1vZXHkS8PYNwQkPMIIC8p03BvI5LR2JoskT4jT3U-7WtZI- > m0AGAlBRiupDN4zUWLuTTZRAESLyQ-dLRQ5M9NDoluzk5ib5Ip8N- > HJEOj4wSaS6hjT7D4ihrgL2-YmvPw0IF5TqUOltrc3k-/https%3A% > 2F%2Fgithub.com%2Ftrothr%2Fxmitmsgx > > > You can also find it on Casita.Net: > > http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.0.17.tar.gz > > > I'd like to hear back from someone trying it on USS. Should work fine with > batch or TSO too when using flat filenames. > Realy I'd like to hear back from *anyone* (using it on, e.g., AIX or Linux > or whatever). > > -- R; <>< > > > On 12/11/17 09:34, Rick Troth wrote: > > friends -- > > > > VM/CMS has a wonderful utility driven by 'XMITMSG' (the command) and > > by APPLMSG (the macro). If you're a VMer, you know about it. If you're > > a VSE or MVS person, maybe not. It's good stuff. For (at least) the > > second time, I started putting together an XMITMSG work-alike for Unix > > (POSIX, including Linux). Anyone else interested in this? If so, > > please let me know. > > > > There are language libraries and message handlers in Unix land. I have > > yet to find one that works like XMITMSG and the APPLMSG macro with > > token replacement, enumerated messages, clear codes in the handling. > > Maybe there is such, in which case my little "xmitmsgx" project might > > reduce to simple interoperability glue code. If so, great! > > > > I WAS SHOCKED several years ago to learn that there is no equivalent > > function in z/OS. It's an incredibly elegant way to handle > > localization (national languages, regional dialects). This project > > should work on MVS too; it's simple code. > > > > If you have time and inclination to try this thing (and offer feedback > > ... or code), please holler. Thanks! > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. I
Re: ES/9000 Console Cable
correct, we never did, but checking the fine manual I found Hardware Management Console .. 2-4 Carmen Vitullo - Original Message - From: "William Donzelli" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, December 18, 2017 1:27:37 PM Subject: Re: ES/9000 Console Cable I do not think they called them HMCs back during the ES/9000 era (at least for the little ones), just "Processor Console". -- Will On Mon, Dec 18, 2017 at 2:20 PM, Carmen Vitullo wrote: > HMC ? > if you are talking master console, or system consoles, I believe it was a > token ring network > > > http://www-01.ibm.com/support/docview.wss?uid=isg2ba4122bfe6d689198525666e005d3c9f&aid=1 > > > > this may help > > > > Carmen Vitullo > > - Original Message - > > From: "William Donzelli" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Monday, December 18, 2017 1:04:24 PM > Subject: ES/9000 Console Cable > > Quick question: > > On the small ES/9000s (9221-150), how exactly does the console cable > connect to the processor? Parallel port from the PC (apparently S/390 > and 9370 are like this)? > > -- > Will > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ShopZ 24/7? Maybe not so much....
On 12/18/2017 11:20 AM, Jousma, David wrote: Nothing wrong with that. But why? Invariably, you'll need that one PTF that isn’t there Haven't had that happen, but if it ever does I will remember this conversation... -- Phoenix Software International Edward E. Jaffe 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: ShopZ 24/7? Maybe not so much....
On 2017-12-18, at 11:20:33, Ed Jaffe wrote: > > Rather than downloading ALL, we choose to download only that which is > recommended by IBM. What's wrong with that? > > SET BOUNDARY (GLOBAL) . > RECEIVE ORDER( > ORDERSERVER(ORDSRVR) > CONTENT(RECOMMENDED) > CLIENT(SMPCLNT) > WAIT(NOLIMIT) /* As long as it takes */ > ) DELETEPKG . > Unless ORDER guarantees it, I'd be more comfortable with APPLY CHECK to assure that all requisites have been RECEIVEd. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ES/9000 Console Cable
The ES/9000s predate this manual by ten or so years, so I thick quite a lot changed in that time. -- Will On Mon, Dec 18, 2017 at 2:37 PM, Carmen Vitullo wrote: > correct, we never did, but checking the fine manual I found > > > Hardware Management Console .. 2-4 > > > > Carmen Vitullo > > - Original Message - > > From: "William Donzelli" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Monday, December 18, 2017 1:27:37 PM > Subject: Re: ES/9000 Console Cable > > I do not think they called them HMCs back during the ES/9000 era (at > least for the little ones), just "Processor Console". > > -- > Will > > On Mon, Dec 18, 2017 at 2:20 PM, Carmen Vitullo wrote: >> HMC ? >> if you are talking master console, or system consoles, I believe it was a >> token ring network >> >> >> http://www-01.ibm.com/support/docview.wss?uid=isg2ba4122bfe6d689198525666e005d3c9f&aid=1 >> >> >> this may help >> >> >> >> Carmen Vitullo >> >> - Original Message - >> >> From: "William Donzelli" >> To: IBM-MAIN@LISTSERV.UA.EDU >> Sent: Monday, December 18, 2017 1:04:24 PM >> Subject: ES/9000 Console Cable >> >> Quick question: >> >> On the small ES/9000s (9221-150), how exactly does the console cable >> connect to the processor? Parallel port from the PC (apparently S/390 >> and 9370 are like this)? >> >> -- >> Will >> >> -- >> 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 > > > -- > 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: Cobol upgrade 6.2 linklist
To clarify my post about putting a consolidated application library in LINKLIST. Audit did not 'force' us, they 'pressed' us. Difference is that Audit exhortations can be resisted if you don't mind going on the defensive all the way up the flagpole. In our case, this production library contained modules for all major applications. Update access to this library was managed by production control people, a segment of the Operations group. Audit felt that this was better control than allowing production jobs to STEPLIB to anything in the house. Concern in this case was not for mischief performed by AC=1 programs but by devious logic in unauthorized programs. Banks have to so darn careful. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, December 18, 2017 9:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Cobol upgrade 6.2 linklist "He jests at scars that never felt a wound." But it's not my dog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Saturday, December 16, 2017 1:26 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Cobol upgrade 6.2 linklist Some folks have probably been burned by the abuse of user libraries in the LINKLIST and so preach fire and brimstone against it. To others it is just "business as usual" because they have not experienced such abuse or its consequences. I am one of them. As I said, YMMV. Each company is a mini-culture unto itself, and our beliefs and fears are ruled by culture and experience. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, December 15, 2017 7:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol upgrade 6.2 linklist I dunno... when we migrated from VSE to z/OS in 2010 I was almost burned as a heretic for suggesting that user application libraries be placed in the linklist... From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Friday, December 15, 2017 2:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol upgrade 6.2 linklist Re: #3, that is not necessarily true. Depends heavily on the shop-standard STEPLIB rules (use or don't use production "user library" in STEPLIB's). As long as the "normal" rule is NOT to use production "user library" in STEPLIB's and you choose to use the "two library" approach to migration, putting the PDSE ahead of the PDS in the LINKLIST makes sense and does what you need it to do. As usual, I think it is a case of YMMV depending on your shop's historical STEPLIB rules. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, December 15, 2017 1:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol upgrade 6.2 linklist I am surprised no one yet as asked, is the OP referring to 1) The COBOL compiler library, 2) the COBOL runtime library, or 3) user libraries with COBOL programs. 1) Don't see any real need for this. 2) Probably already done, as the COBOL runtime library is CEE.SCEERUN 3) I've been told that "user libraries" like this should never be in the linklist. From: IBM Mainframe Discussion List on behalf of Jake Anderson Sent: Friday, December 15, 2017 5:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Cobol upgrade 6.2 linklist Hi A general question Do you still cobol load module in linklist post upgrade to 6.2 ? Regards Jake -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol upgrade 6.2 linklist
Like Skip, we are a financial institution with serious client responsibilities, and we also use a separate-from-development production control group as the only authorized updaters of the main application libraries. AFAIK no auditor has ever complained about our controls or our procedures. We also use several layers of approvals and reviews for all application code, which provides additional levers and control points to help protect against both accidental and intentional application shenanigans. Shmuel is right to chide me for sounding like I was implying that nothing *could* happen. I did not intend to say or imply that, as I am old and experienced enough to know Murphy all too well in all his various incarnations. I was simply stating that there has not (yet) been any serious incident with our setup and controls as they are. Our ingrained culture of caring seriously and continuously about clients helps keep a person and an organization on their toes. I'm not sure if we use the LNKLST APF feature that Peter Relson mentioned, but I would imagine we do, as I am darn sure that nothing I can do lets me run any authorized code anywhere on z/OS. Our PARMLIB datasets are protected, so I cannot look to see if we use it or not. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Monday, December 18, 2017 4:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol upgrade 6.2 linklist To clarify my post about putting a consolidated application library in LINKLIST. Audit did not 'force' us, they 'pressed' us. Difference is that Audit exhortations can be resisted if you don't mind going on the defensive all the way up the flagpole. In our case, this production library contained modules for all major applications. Update access to this library was managed by production control people, a segment of the Operations group. Audit felt that this was better control than allowing production jobs to STEPLIB to anything in the house. Concern in this case was not for mischief performed by AC=1 programs but by devious logic in unauthorized programs. Banks have to so darn careful. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, December 18, 2017 9:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Cobol upgrade 6.2 linklist "He jests at scars that never felt a wound." But it's not my dog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Saturday, December 16, 2017 1:26 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Cobol upgrade 6.2 linklist Some folks have probably been burned by the abuse of user libraries in the LINKLIST and so preach fire and brimstone against it. To others it is just "business as usual" because they have not experienced such abuse or its consequences. I am one of them. As I said, YMMV. Each company is a mini-culture unto itself, and our beliefs and fears are ruled by culture and experience. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, December 15, 2017 7:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol upgrade 6.2 linklist I dunno... when we migrated from VSE to z/OS in 2010 I was almost burned as a heretic for suggesting that user application libraries be placed in the linklist... From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Friday, December 15, 2017 2:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol upgrade 6.2 linklist Re: #3, that is not necessarily true. Depends heavily on the shop-standard STEPLIB rules (use or don't use production "user library" in STEPLIB's). As long as the "normal" rule is NOT to use production "user library" in STEPLIB's and you choose to use the "two library" approach to migration, putting the PDSE ahead of the PDS in the LINKLIST makes sense and does what you need it to do. As usual, I think it is a case of YMMV depending on your shop's historical STEPLIB rules. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, December 15, 2017 1:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol upgrade 6.2 linklist I am surprised no one yet as asked, is the OP referring to 1) The COBOL compiler library, 2) the COBOL runtime library, or 3) user libraries with COBOL programs. 1) Don't see any real need for this. 2) Probably already done, as the COBOL runtime library i
Re: ShopZ 24/7? Maybe not so much....
The only problem with downloading selectively is that a Recommended PTF may PRE(REQ) one that did not make that list. You won't know until APPLY time. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, December 18, 2017 10:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: ShopZ 24/7? Maybe not so much On 12/18/2017 9:39 AM, Jousma, David wrote: > ... from your comments, and from others seem to imply, that it also sounds > like you are picking/choosing what PTF's to download? Why not > order/download everything available on a weekly basis? Rather than downloading ALL, we choose to download only that which is recommended by IBM. What's wrong with that? SET BOUNDARY (GLOBAL) . RECEIVE ORDER( ORDERSERVER(ORDSRVR) CONTENT(RECOMMENDED) CLIENT(SMPCLNT) WAIT(NOLIMIT) /* As long as it takes */ ) DELETEPKG . -- Phoenix Software International Edward E. Jaffe 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: "make" question
I cobbled up CMS Make (like three times, two being lost to former employers) and intentionally made "leading white space" count for "leading tab character". Seems to work, but I always only ever use a subset of full 'make' capability (on any platform). Anyway, it's not difficult to have your makefiles fix themselves, converting leading 8 blanks to a tab automagically. Some of the makefiles in and around CMS Make do exactly that: if they land on (for example) Linux, they get run through 'sed' to convert leading 8 blanks to a single tab. The idea is that "makefile" (or "Makefile" if you must) depends on some other "makefile.in", which is the master. On any platform, if "makefile.in" is newer, the recipe is triggered, and maybe is just ... sed 's#^#\t#' < makefile.in > makefile ... or something to that effect. (Might have to embed a real tab if your 'sed' is not smart enough.) Then you can edit your master rules files on 3270 without funky presentation and painful data entry incantations. Makefile with dependencies is messy but not unheard of. -- R; <>< On 12/18/17 13:42, Seymour J Metz wrote: Tabs were a bloody nuisance long before 3270 displays came along; in fact, they may have been worse on hardcopy terminals than on 3270s. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of John McKown Sent: Thursday, December 14, 2017 2:08 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: "make" question On Thu, Dec 14, 2017 at 12:56 PM, Jack J. Woehr wrote: On 12/14/2017 7:25 AM, Gord Tomlin wrote: All the make tools share an annoying reliance on tab characters. This is somehow more pernicious than punch-card-column dependencies in traditional IBM tools? :) IMO, the use of tabs as a "data character" is only annoying to people stuck on a 3270 display. I have _no_ problems with them when I'm using ssh to get a UNIX shell. Boiled down, I will agree that using UNIX tools in a TSO (3270) environment is annoying. Equally annoying, to me, is the column dependencies when I editing an HLASM or COBOL program from the UNIX shell. And don't get me going on the "vi" that IBM distributes. -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of http://secure-web.cisco.com/1ybTM2fIPP6WIfaVgbAVnswUzPnLdlv3Q8suGEuvNuIcWmlO1FeCilZ_8AhBDR-gmcGDcWhBJEMVBPDjtPo47Ec46mMyk-AOKheGSj1zNZIOcc1PcpkdPbisMbUUwXdyxchTPLkS9938zz2xTA-atthJaQg8nrixGqy71j40crWiVHjKaJvcMhcM9azcZhOXm_krOIUa8sblenqgCAnmtqbNSt3SM6rhLSb33bqcKbth50bY0xFf6E4s7hYftAcX6Jn6IIYuYLjj2sxSYKJ4Lid-vuodLYc4D758luythtRxrb0-N0X5-cas0_7vXj6XnN4ZzfOH5RrAwzTh8V-zKkU5HwMD6yW_7sAusgAdvov4FtuFtqpTgxabUa3aMKgLc/http%3A%2F%2Fwww.well.com%2F%7Ejax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --ClefOS 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: "make" question
On Mon, 18 Dec 2017 19:47:26 -0500, Rick Troth wrote: > >Anyway, it's not difficult to have your makefiles fix themselves, >converting leading 8 blanks to a tab automagically. Some of the >makefiles in and around CMS Make do exactly that: if they land on (for >example) Linux, they get run through 'sed' to convert leading 8 blanks >to a single tab. > Doesn't this break a macro definition or a dependency rule that happens to start with 8 blanks? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ShopZ 24/7? Maybe not so much....
[Default] On 18 Dec 2017 10:40:41 -0800, in bit.listserv.ibm-main jesse1.robin...@sce.com (Jesse 1 Robinson) wrote: >This is not to excuse bad behavior, but for years IBM has recommended pulling >all available fixes on a regular schedule, e.g. daily. This to guard against >this kind of situation: needing a particular fix in a big hurry when the >delivery mechanism is not working for whatever reason. (Do as they say, not as >I do.) > >We have discussed ServiceLink availability with IBM at several SHARE meetings. >Our point was that since (probably the vast majority of) customers perform >maintenance activities on weekends, that's the worst time for ServiceLink >maintenance. We got considerable sympathy from the folks we met with, but they >admitted that they don't control the schedule and could only recommend. >Meanwhile the IBM maintenance schedule seems not to have changed. Sigh. > Who does control the schedule and why can;t customers contact THAT department? Could the shareholders among us make a stink by asking for a proxy vote on the issue (I would be willing to sign it with my small number of shares) and if anyone lives close to the next annual meeting (I'm in Nova Scotia) maybe he or she could raise the question there. Clark Morris >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >626-543-6132 Office ?=== NEW >robin...@sce.com > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Ed Jaffe >Sent: Monday, December 18, 2017 9:31 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: ShopZ 24/7? Maybe not so much > >On 12/18/2017 8:30 AM, Tom Conley wrote: >> We'll bring this up at SHARE yet again, and IBM will assure us they're >> working on it, they'll point to their 99.99 uptime, and then nothing >> will change. > >Funny how the downtime (.001%? Really? No! That counts only "unexpected" >outages...) always seems to occur on the weekends when sysprogs need it >most... :-\ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Are levels of control one reason for cloud movement was Re: Cobol upgrade 6.2 linklist
[Default] On 18 Dec 2017 14:11:34 -0800, in bit.listserv.ibm-main peter.far...@broadridge.com (Farley, Peter x23353) wrote: >Like Skip, we are a financial institution with serious client >responsibilities, and we also use a separate-from-development production >control group as the only authorized updaters of the main application >libraries. AFAIK no auditor has ever complained about our controls or our >procedures. > >We also use several layers of approvals and reviews for all application code, >which provides additional levers and control points to help protect against >both accidental and intentional application shenanigans. Do those levels of control encourage people to move applications to other platforms or the cloud? Clark Morris > >Shmuel is right to chide me for sounding like I was implying that nothing >*could* happen. I did not intend to say or imply that, as I am old and >experienced enough to know Murphy all too well in all his various >incarnations. I was simply stating that there has not (yet) been any serious >incident with our setup and controls as they are. Our ingrained culture of >caring seriously and continuously about clients helps keep a person and an >organization on their toes. > >I'm not sure if we use the LNKLST APF feature that Peter Relson mentioned, but >I would imagine we do, as I am darn sure that nothing I can do lets me run any >authorized code anywhere on z/OS. Our PARMLIB datasets are protected, so I >cannot look to see if we use it or not. > >Peter > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Jesse 1 Robinson >Sent: Monday, December 18, 2017 4:02 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Cobol upgrade 6.2 linklist > >To clarify my post about putting a consolidated application library in >LINKLIST. Audit did not 'force' us, they 'pressed' us. Difference is that >Audit exhortations can be resisted if you don't mind going on the defensive >all the way up the flagpole. In our case, this production library contained >modules for all major applications. Update access to this library was managed >by production control people, a segment of the Operations group. Audit felt >that this was better control than allowing production jobs to STEPLIB to >anything in the house. Concern in this case was not for mischief performed by >AC=1 programs but by devious logic in unauthorized programs. Banks have to so >darn careful. ;-) > >. >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >626-543-6132 Office ?=== NEW >robin...@sce.com > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Seymour J Metz >Sent: Monday, December 18, 2017 9:54 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: Cobol upgrade 6.2 linklist > >"He jests at scars that never felt a wound." > >But it's not my dog. > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List on behalf of >Farley, Peter x23353 >Sent: Saturday, December 16, 2017 1:26 AM >To: IBM-MAIN@listserv.ua.edu >Subject: Re: Cobol upgrade 6.2 linklist > >Some folks have probably been burned by the abuse of user libraries in the >LINKLIST and so preach fire and brimstone against it. > >To others it is just "business as usual" because they have not experienced >such abuse or its consequences. I am one of them. > >As I said, YMMV. Each company is a mini-culture unto itself, and our beliefs >and fears are ruled by culture and experience. > >Peter > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Frank Swarbrick >Sent: Friday, December 15, 2017 7:16 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Cobol upgrade 6.2 linklist > >I dunno... when we migrated from VSE to z/OS in 2010 I was almost burned as a >heretic for suggesting that user application libraries be placed in the >linklist... > >From: IBM Mainframe Discussion List on behalf of >Farley, Peter x23353 >Sent: Friday, December 15, 2017 2:00 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Cobol upgrade 6.2 linklist > >Re: #3, that is not necessarily true. Depends heavily on the shop-standard >STEPLIB rules (use or don't use production "user library" in STEPLIB's). As >long as the "normal" rule is NOT to use production "user library" in STEPLIB's >and you choose to use the "two library" approach to migration, putting the >PDSE ahead of the PDS in the LINKLIST makes sense and does what you need it to >do. > >As usual, I think it is a case of YMMV depending on your shop's historical >STEPLIB rules. > >Peter > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Frank Swarbrick >Sent:
Re: Cobol upgrade 6.2 linklist
We steer away from dynamic linklist update as well. When Omegamon could do it decades ago, I chided IBM for lagging behind. Nowadays I have a different perspective: not how to move forward, but how to move back in case of unexpected trouble. So we invariably create a new library and IPL with it. In case of (possible but unlikely) chaos, we IPL back the old library. Whatever the original problem was, it could hardly be worse than getting stuck in a hot mess purgatory with no clear exit. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Monday, December 18, 2017 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Cobol upgrade 6.2 linklist I see your points, for me, it's never been in a habit of upgrading any target lib's that are linklisted, did that once with some older XX products (PDS) that didn't act well after trying dynamically refreshing LLA and the linklist, so I've built my linklist lib's from my target libs, and IPL most times. Carmen Vitullo - Original Message - From: "Jerry Whitteridge" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, December 18, 2017 12:21:55 PM Subject: Re: Cobol upgrade 6.2 linklist The issue with PDSE in the linklist is related to any PDSE that is in the IPL linklist gets an tag to (I think it is ) XCFAS so that if you whish to do dynamic maintenance to a product you can take the existing library out of the linklist, but can't rename etc. You would then need to use a new Library name to put the product back into linklist. If you are not in the habit of doing dynamic maintenance the PDSE in the IPL linklist isn't an issue, and if you can use different names it's also not an issue. -- Jerry Whitteridge IBM Global Services Delivery Manager e-Mail: jerry.whitteri...@ibm.com Cell: 602 527 4871 < Note New Phone Number IBM Mainframe Discussion List wrote on 12/18/2017 11:17:01 AM: > From: Seymour J Metz > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 12/18/2017 11:17 AM > Subject: Re: Cobol upgrade 6.2 linklist Sent by: IBM Mainframe > Discussion List > > It used to be that you couldn't have PDSE in LNKLSTxx, but could add a > PDSE with an automatic SETPROG command. I don't know whether that > restriction still exists. > > -- > Shmuel (Seymour J.) Metz > https://urldefense.proofpoint.com/v2/url? > u=http-3A__mason.gmu.edu_-7Esmetz3&d=DwIFAw&c=jf_iaSHvJObTbx- > siA1ZOg&r=0avyVTgpzBFlo1QAgHxCtqKtRE6Ldl_1M9tI2p7Kc8E&m=C2kzwWYqC2ybVmHsfpyw64D6PNfA6yu1lS3vcYix7Vo&s=VBOFuf9SLwZLzw4062UipuCiuQswXhRkKon3Cw5np64&e= > > > From: IBM Mainframe Discussion List on > behalf of Carmen Vitullo > Sent: Friday, December 15, 2017 1:15 PM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: Cobol upgrade 6.2 linklist > > Hum , I know COBOL object modules 5+ need to be PDS/E, but I've never > knew about the linklist restrictions with PDS/E , so what about IBM > libraries in the linklist from my serverpac build? > alway had in CPAC.PARMLIB and migrated forward. > > > SYS1.SHASLNKE > > > > SYS1.SIEALNKE > > > SYS1.SIEAMIGEetc > am I taking unnecessary chances? > > > > Carmen Vitullo > > - Original Message - > > From: "Lizette Koehler" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Friday, December 15, 2017 11:47:57 AM > Subject: Re: Cobol upgrade 6.2 linklist > > As you will find out. Any Cobol program compiled from the Cobol > Compiler from 5.0 up will REQUIRE PDSE for the Load lib - Object LOAD. > > If you have your application batch load library in the LINKLST then > you will need to move it into the place where you start other PDS/E > Dataset in the Linklst. > > The LINKLST PROGxx need to be only PDS datasets. PDS/E datasets do not > have the SMSPDSx ASID available at the time the LINKLST is done. > You have to build it after the SMSPDSx STC is up > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Jake Anderson > > Sent: Friday, December 15, 2017 5:51 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Cobol upgrade 6.2 linklist > > > > Hi > > > > A general question > > > > Do you still cobol load module in linklist post upgrade to 6.2 ? > > > > Regards > > Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "make" question
On 12/18/17 20:44, Paul Gilmartin wrote: On Mon, 18 Dec 2017 19:47:26 -0500, Rick Troth wrote: Anyway, it's not difficult to have your makefiles fix themselves, converting leading 8 blanks to a tab automagically. Some of the makefiles in and around CMS Make do exactly that: if they land on (for example) Linux, they get run through 'sed' to convert leading 8 blanks to a single tab. Doesn't this break a macro definition or a dependency rule that happens to start with 8 blanks? I did say limited scope. So I suppose it /could/, but IMLX I've never seen a macro nor rule that starts with 8 blanks. There must have been some reason Feldman chose instead of &lwsp. But the story I recall fondly is that after creating 'make' and turning it loose and then getting a good night's sleep, he fretted, "why did I give it such a stupid requirement?". (heavily paraphrased; "stupid" wording mine) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- R; <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN