Re: Scary Sysprogs and educating those 'kids'....
David Crayford wrote: begin extract Of course, the data center behemoths like google, facebook, amazon et all choose to buy the cheapest bare metal commodity components with redundancy done by the software. At that scale it's the only model that makes economic sense. /end extract It is a model that makes economic sense in some circumstances particularly when the costs of [uncommon] failures are borne by others. It is not the only such model or even the best one in all circumstances. For, say, google one of the merits of providing notionally free services is that its SLA with its users is a very informal, relaxed one. Occasional disasters---They have occurred---are not disabling. I use google services, particularly google scholar, heavily; and I find the implicit bargain it has struck with its users for these services more than satisfactory. Its model and that bargain would not, however, satisfy me in other situations. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Hardware failures (was Re: Scary Sysprogs ...)
Back in the z890 days, we had a CPU fail. Of course, the hardware automatically recovered and we only knew about it due to a logrec record being written and a message on the HMC. We also had one of our OSAs fail. The second OSA did an ARP takeover (proper term?) and we suffered _no_ user interruption. The LAN people _refused_ to believe that the OSA could fail that way without disrupting all the IP sessions of the users on that OSA. Apparently when a multi-NIC PC has a NIC fail, all the IP sessions on that NIC die immediately (well, they time out). On Wed, Jan 8, 2014 at 12:52 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Scott Ford wrote: Like Joel, I haven't seen a hardware failure in the Z/OS world since the 70s. Lucky you. I wrote on IBM-MAIN in May/June 2013 about Channel Errors which caused SMF damage amongst other problems. These channel errors were caused by bad optic cables and some directors/routers. Then last year, during a hardware upgrade, those projects were delayed because an IBM hardware component blew and a part has to be flown in from somewhere... Hardware failures can happens in these days. 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 -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? 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: Hardware failures (was Re: Scary Sysprogs ...)
Anecdotage is, I suppose, innocuous; but it would be helpful to make some distinctions, in particular one between hardware failures and system failures. Hardware failures that are recovered from are moderately frequent, as everyone who has had occasion to look at SYS1.LOGREC outputs presumably knows. The merit of z/OS and its predecessors is that most such failures are recovered from without system loss. The system continues to be available and to do useful work. The hardware is indeed very reliable, but the machinery for detecting and recovering from hardware [and some software] errors makes an equally important contribution to system availability. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Scary Sysprogs
Common sense isn't common Mark Twain snip As always an excellent point. I think critical thinking and common sense is missing sometimes. Maybe my 63 yrs is showing /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Scary Sysprogs
It's pretty creativity-stifling to work in a company where the threat of being fired looms. If one works for a firm that has annual RIFs just as a matter of practice and one is constantly in fear of setting a foot wrong lest one get on that list, then one is not going to do anything more than the bare minimum. No one wants to work a single extra minute in that kind of environment. Absent such a fear, one is more willing to take risks, be innovative. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Scary Sysprogs
I agree. If you've never failed, you haven't tried hard enough to grow yourself. On 01/08/14 09:05, Govind Chettiar wrote: It's pretty creativity-stifling to work in a company where the threat of being fired looms. If one works for a firm that has annual RIFs just as a matter of practice and one is constantly in fear of setting a foot wrong lest one get on that list, then one is not going to do anything more than the bare minimum. No one wants to work a single extra minute in that kind of environment. Absent such a fear, one is more willing to take risks, be innovative. -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Darren seems to be alive but....
In 9db59a6e-9a50-4e6c-be95-9b9e3244b...@comcast.net, on 01/07/2014 at 11:59 AM, Ed Gould edgould1...@comcast.net said: Darren seems to be alive but it isn't clear who is in charge. The issue isn't who is in charge, but what resources he has. Send your list questions to ibm-main-requ...@listserv.ua.edu and they should get through to the list owner even if Darren decides to hand off the work to someone else. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO FULL SCREEN MODE UNDER ISPF
In 7280b0f7-a217-4d37-aea2-f1e46be53...@optonline.net, on 01/07/2014 at 11:48 AM, Micheal Butz michealb...@optonline.net said: I need to have a TGET To have a full screen TPUT to display What happens if you don't have a TGET before the TPUT FULLSCR? Did you issue a STFDMODE? Did you use TPG to issue a READ PARTITION QUERY? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Hardware failures (was Re: Scary Sysprogs ...)
In caajsdjjarmx2jqj0awzwf1gnptnx_5eysazwro83e2ewsc5...@mail.gmail.com, on 01/08/2014 at 07:16 AM, John McKown john.archie.mck...@gmail.com said: The LAN people _refused_ to believe that the OSA could fail that way without disrupting all the IP sessions of the users on that OSA. That's typical, alas. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Hardware failures (was Re: Scary Sysprogs ...)
On 08/01/2014, at 9:16 PM, John McKown john.archie.mck...@gmail.com wrote: The LAN people _refused_ to believe that the OSA could fail that way without disrupting all the IP sessions of the users on that OSA. Apparently when a multi-NIC PC has a NIC fail, all the IP sessions on that NIC die immediately (well, they time out). Doesn't NIC teaming solve that problem on distributed? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Scary Sysprogs
Yes sir, agreed Scott ford www.identityforge.com from my IPAD On Jan 8, 2014, at 8:34 AM, Staller, Allan allan.stal...@kbmg.com wrote: Common sense isn't common Mark Twain snip As always an excellent point. I think critical thinking and common sense is missing sometimes. Maybe my 63 yrs is showing /snip -- 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: Hardware failures (was Re: Scary Sysprogs ...)
Software recovery of hardware errors? It is quite an opportunity area for IBM to re-publicize, especially for these new kids on the block. I recently had an incredibly amazing discussion with someone who I respect highly, at Oracle (formerly SUN Micro), a very knowledgeable veteran system architect, who was so proud that Solaris had implemented hardware processor storage page-frame recovery in software. You know, take a 'parity' or 'checking-block code' failure (multiple bit errors, etc), and then take the frame offline, and if the frame was unchanged and backing a pageable page, then you invalidate the page, and a fresh copy, 'the slot' on DASD, gets loaded in. Great stuff. Congratulations, Solaris! Yes, but this was implemented at IBM so darned early, in the 1970s. I documented it (and other things) in an IBM Internal report about 'S370 Machine Checks in MVS', circa 1974 and then plagiarized myself putting it into the very first 'MVS Diagnostic Techniques' manual (a manual, not a Redbook or sales flyer), circa 1976. Yes, old news at IBM. If old mainframe veterans are not so aware of this stuff, then can we expect 'the kids' to know about it? Old, old news at IBM, but there is a fresh audience. And they NEED to hear it. We NEED to tell them! Don't we? What do you think? Dan -Original Message- From: John Gilmore jwgli...@gmail.com Sent: Jan 8, 2014 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Hardware failures (was Re: Scary Sysprogs ...) Anecdotage is, I suppose, innocuous; but it would be helpful to make some distinctions, in particular one between hardware failures and system failures. Hardware failures that are recovered from are moderately frequent, as everyone who has had occasion to look at SYS1.LOGREC outputs presumably knows. The merit of z/OS and its predecessors is that most such failures are recovered from without system loss. The system continues to be available and to do useful work. The hardware is indeed very reliable, but the machinery for detecting and recovering from hardware [and some software] errors makes an equally important contribution to system availability. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Thank you, Dan Dan Skwire home phone 941-378-2383 cell phone 941-400-7632 office phone 941-227-6612 primary email: dskw...@mindspring.com secondary email: dskw...@gmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Darren seems to be alive but....
Who is in charge when there is an issue (like mine - being unceremoniously unsubscribed). BTW my original question to the list owner was NOT to Darren .. it was to whoever is in charge. So if it went to Darren then I would have hoped he would have some sort of sorting mechanism (ie important messages to list-owner and other messages from IBM-MAIN). Ed On Jan 8, 2014, at 12:59 AM, Ron Hawkins wrote: Ed, You're original question to the list, and I quote verbatim: Is the owner of IBM-MAIN alive or dead? Darren's first sentence in his response: Yes, Ed, I'm still alive. What part of your original question was not answered? Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Tuesday, January 07, 2014 10:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Darren seems to be alive but All: Darren seems to be alive but it isn't clear who is in charge. So no real answer to the original question is not answered. Thanks for whoever suggested that Darren be contacted. Ed - - 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: Darren seems to be alive but....
On Jan 8, 2014, at 8:02 AM, Shmuel Metz (Seymour J.) wrote: In 9db59a6e-9a50-4e6c-be95-9b9e3244b...@comcast.net, on 01/07/2014 at 11:59 AM, Ed Gould edgould1...@comcast.net said: Darren seems to be alive but it isn't clear who is in charge. The issue isn't who is in charge, but what resources he has. Send your list questions to ibm-main-requ...@listserv.ua.edu and they should get through to the list owner even if Darren decides to hand off the work to someone else. Seymour: I DID SEND THE MESSAGE to the list owner (I thought Darren had retired). That is why I am surprised that Darren didn't get the message as apparently he still owns the list but then that leaves the issue up in the air if Darren doesn't get the the messages to the LISTOWNER who does? Ed -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@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: Hardware failures (was Re: Scary Sysprogs ...)
re: http://www.garlic.com/~lynn/2014.html#23 Scary Sysprogs and educating those 'kids' http://www.garlic.com/~lynn/2014.html#24 Scary Sysprogs and educating those 'kids' after transferring to San Jose Research ... I was allowed to wandering around other locations in the area. One of the places was the disk engineering and development labs. At the time, they had a fare number of IBM mainframes (they would get one of the earliest engineering mainframe processors ... usually #3 or #4 for starting disk testings ... aka needing to test engineering disks ... but also needing to test engineering mainframes with latest disks). At the time the machine rooms were running all the mainframes 7x24 around the clock, stand-alone testing schedules. At one time, they had tried to use MVS to have operating system environment and being able to do multiple concurrent testing ... however in that environment, MVS had 15min MTBF. I offered to rewrite the I/O supervisor to make it bullet proof and never fail ... enabling on-demand, anytime, concurrent testing ... significantly improving disk development productivity. After that I would get sucked into diagnosing lots of development activity ... because frequently anytime there was any kind of problem ... they would accuse the software ... and I would get a call ... and have to figure out what the hardware problem was. old postsing about getting to play disk engineer in bldgs 1415 http://www.garlic.com/~lynn/subtopic.html#disk I did a write up of what was necessary to support the environment and happened to make reference to the MVS 15min MTBF ... which brought down the wrath of the MVS RAS group on my head ... they would have gotten me fired if they could figure out how (I had tried to work with them to improve MVS RAS ... but instead they turned it into an adversary situation). A couple years later ... when 3380s starting to ship ... MVS system was hanging/failing (requiring re-IPL) in the FE 3380 error regression tests (typical errors expected to be found in customer installations) ... and in the majority of the cases, there was not even an indication of what was responsible for the failure (of course I had to be handling them all along ... since nearly all development was being done under systems I provided). old email from the period discussing MVS failures with FE 3380 error regression test: http://www.garlic.com/~lynn/2007.html#email801015 3380s had been announced 11June1980 http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380.html -- 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
Sysplex File System Sharing with Mountpoints Containing Symlinks
I'm testing the sharing of a zFS file system between sysplex'd
z/OS 2.1 and z/OS 1.13 systems. The file system is to be mounted
at a mountpoint that contains a symlink containing $VERSION in its
definition. That is, the mountpoint is '/usr/local' but '/usr' is a
symlink defined as '$VERSION/usr'.
On the z/OS 2.1 system, this mountpoint resolves to
'/Z21/usr/local'. On the z/OS 1.13 system, it resolves to
'/Z1D/usr/local'.
When the z/OS 2.1 system is IPL'd first, the file system
successfully mounts at '/Z21/usr/local'. When the z/OS
1.13 system is IPL'd second, the mount is refused with message:
BPXF237I FILE SYSTEM USER.TOOLS WAS ALREADY MOUNTED ON PATHNAME
/Z21/usr/local.
How does one make the USERS.TOOLS file system available to the
z/OS 1.13 at /usr/local (which resolves to /Z1D/usr/local)?
Configuration:
BPXPRMxx - SYSPLEX(YES)
IOEPRMxx - sysplex=filesys and sysplex_filesys_sharemode=NORWSHARE
Mount command:
MOUNTFILESYSTEM('USER.TOOLS')
TYPE(ZFS)
MODE(read) UNMOUNT
MOUNTPOINT('/usr/local')
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Scary Sysprogs
Hi, Ron, The only thing I wish we would teach newbies in any field of mainframe is Do Nothing should always be in the list of options. I wish we could teach (some of) management that, as well. Cheers,,,Steve Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov From: Ron Hawkins ronjhawk...@sbcglobal.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/07/2014 05:24 AM Subject:Re: Scary Sysprogs Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU All, My history with z/OS is more about performance and tuning, rather than hardcore sysprogging. Tuning is almost always about doing it a new way, and I only wish there were more newbies in this field with no preconceived ideas about how it has always worked. Back when I was not Mr Congeniality a stand up argument with a Sysprog about how to resolve a performance problem was almost a monthly occasion at any site. The only thing I wish we would teach newbies in any field of mainframe is Do Nothing should always be in the list of options. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari Sent: Tuesday, January 07, 2014 1:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Scary Sysprogs Nathan (and maybe any other youngster) I think if you have some problem, you will get every support from this newsgroup list , and if you need, personally from me also. Glad to see young people here. On 06.01.2014 19:44, Nathan J Pfister wrote: Harry has a good point. I am a 26 year old in the mainframe world, and came into an internship with the US DoD while in my Junior Year of college. I have seen, from the younger generation view that he pointed out, a fair amount of the dismissive and condescending attitudes in some of the seniors that I have worked with. That being said, there are also quite a few seniors that I have had the fortune of working with that have had quite the opposite affect on me personally, and they are the reason that I have, for a bit more than 5 years now stuck with a career working with z/OS. Maybe I am among the outliers in the research study alluded to, but I feel that all fields have a fair amount of people in both positions: those willing to share and listen, and those that are still trying to live the glory days of old being very quick to dismiss any new ideas...so I'm not sure that that is unique to the demographics of the z/OS Systems Programmer groups. That said, maybe I was just fortunate that I found my internship and first post-college job within the Federal Government in which it is nearly impossible to get fired, thus making change and new ideas/people not as much of a threat as in private industry. Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services From: Harry Wahl harry_w...@hotmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/06/2014 01:34 PM Subject:Scary Sysprogs; was: Is the oner of IBM-Main still with us? Sent by:IBM Mainframe Discussion List IBM- m...@listserv.ua.edu Interesting segue this thread has taken... I recently attended an IBM meeting which addressed why young people are eschewing an IBM z/OS mainframe career in favor of other platforms, including other IBM platforms. This seems to be a very serious concern at IBM and possibly the greatest threat to the future of z/OS. The speaker was a woman from IBM who had been tasked by IBM management to study this. She presented selected conclusions from her assignment. Some results were what one would expect, many results were unexpected or at least not typically considered in the context of z/OS's continued viability. One of the top reasons graduating students from the best universities will not accept a position working on z/OS is how they feel they are (or will be) treated by z/OS old-timers, particularly systems programmers. This conclusion is supported by other data indicating that students who co-op'ed or interned in z/OS positions are far more likely to reject z/OS as a career as opposed to those graduates who have no experience with the z/OS environment (technically and socially). The prevailing conjecture for this phenomena is the relatively advanced age of z/OS people. There seems to be a phase in one's life and career where there is a natural desire to mentor young people. It is a time when young people are not your competition (you have accepted that you are no longer one of them) and you are aware of the knowledge and insights your work experiences have imbued you with and wish to express and share them with someone who can both appreciate and benefit from them. This phase eventually passes...obviously. The average age of z/OS people is far beyond the average age of other
Re: Sysplex File System Sharing with Mountpoints Containing Symlinks
Is filesystem USER.TOOLS part of the z/OS maintained filesystem? Sounds like
in BPXPRMxx you have VERSION set to Z1D on one system, and Z21 on another. If
this filesystem is NOT part of z/OS maintained filesystems, then you can
1) Create a new directory entry in your SYSPLEX ROOT filesystem called
something like /shared/tools
2) In your versioned filesystems, remve the directory /usr/local, and replace
it with a symbolic link like ln -s /shared/tools /usr/local
Then both systems will resolve the directory to the same location. With
shared file systems in z/OS unix, a physical filesystem can only be mounted
once, period.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cal McCracken
Sent: Wednesday, January 08, 2014 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Sysplex File System Sharing with Mountpoints Containing Symlinks
I'm testing the sharing of a zFS file system between sysplex'd z/OS 2.1 and
z/OS 1.13 systems. The file system is to be mounted at a mountpoint that
contains a symlink containing $VERSION in its definition. That is, the
mountpoint is '/usr/local' but '/usr' is a symlink defined as '$VERSION/usr'.
On the z/OS 2.1 system, this mountpoint resolves to '/Z21/usr/local'. On the
z/OS 1.13 system, it resolves to '/Z1D/usr/local'.
When the z/OS 2.1 system is IPL'd first, the file system successfully mounts at
'/Z21/usr/local'. When the z/OS
1.13 system is IPL'd second, the mount is refused with message:
BPXF237I FILE SYSTEM USER.TOOLS WAS ALREADY MOUNTED ON PATHNAME /Z21/usr/local.
How does one make the USERS.TOOLS file system available to the z/OS 1.13 at
/usr/local (which resolves to /Z1D/usr/local)?
Configuration:
BPXPRMxx - SYSPLEX(YES)
IOEPRMxx - sysplex=filesys and sysplex_filesys_sharemode=NORWSHARE
Mount command:
MOUNTFILESYSTEM('USER.TOOLS')
TYPE(ZFS)
MODE(read) UNMOUNT
MOUNTPOINT('/usr/local')
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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: Scary Sysprogs
Amen, Steve, or at least discuss options with knowledgable techies. Scott ford www.identityforge.com from my IPAD On Jan 8, 2014, at 10:04 AM, Steve Conway steve_con...@ao.uscourts.gov wrote: Hi, Ron, The only thing I wish we would teach newbies in any field of mainframe is Do Nothing should always be in the list of options. I wish we could teach (some of) management that, as well. Cheers,,,Steve Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov From: Ron Hawkins ronjhawk...@sbcglobal.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/07/2014 05:24 AM Subject:Re: Scary Sysprogs Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU All, My history with z/OS is more about performance and tuning, rather than hardcore sysprogging. Tuning is almost always about doing it a new way, and I only wish there were more newbies in this field with no preconceived ideas about how it has always worked. Back when I was not Mr Congeniality a stand up argument with a Sysprog about how to resolve a performance problem was almost a monthly occasion at any site. The only thing I wish we would teach newbies in any field of mainframe is Do Nothing should always be in the list of options. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari Sent: Tuesday, January 07, 2014 1:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Scary Sysprogs Nathan (and maybe any other youngster) I think if you have some problem, you will get every support from this newsgroup list , and if you need, personally from me also. Glad to see young people here. On 06.01.2014 19:44, Nathan J Pfister wrote: Harry has a good point. I am a 26 year old in the mainframe world, and came into an internship with the US DoD while in my Junior Year of college. I have seen, from the younger generation view that he pointed out, a fair amount of the dismissive and condescending attitudes in some of the seniors that I have worked with. That being said, there are also quite a few seniors that I have had the fortune of working with that have had quite the opposite affect on me personally, and they are the reason that I have, for a bit more than 5 years now stuck with a career working with z/OS. Maybe I am among the outliers in the research study alluded to, but I feel that all fields have a fair amount of people in both positions: those willing to share and listen, and those that are still trying to live the glory days of old being very quick to dismiss any new ideas...so I'm not sure that that is unique to the demographics of the z/OS Systems Programmer groups. That said, maybe I was just fortunate that I found my internship and first post-college job within the Federal Government in which it is nearly impossible to get fired, thus making change and new ideas/people not as much of a threat as in private industry. Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services From: Harry Wahl harry_w...@hotmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/06/2014 01:34 PM Subject:Scary Sysprogs; was: Is the oner of IBM-Main still with us? Sent by:IBM Mainframe Discussion List IBM- m...@listserv.ua.edu Interesting segue this thread has taken... I recently attended an IBM meeting which addressed why young people are eschewing an IBM z/OS mainframe career in favor of other platforms, including other IBM platforms. This seems to be a very serious concern at IBM and possibly the greatest threat to the future of z/OS. The speaker was a woman from IBM who had been tasked by IBM management to study this. She presented selected conclusions from her assignment. Some results were what one would expect, many results were unexpected or at least not typically considered in the context of z/OS's continued viability. One of the top reasons graduating students from the best universities will not accept a position working on z/OS is how they feel they are (or will be) treated by z/OS old-timers, particularly systems programmers. This conclusion is supported by other data indicating that students who co-op'ed or interned in z/OS positions are far more likely to reject z/OS as a career as opposed to those graduates who have no experience with the z/OS environment (technically and socially). The prevailing conjecture for this phenomena is the relatively advanced age of z/OS people. There seems to be a phase in one's life and career where there is a natural desire to mentor young people. It is a time when young people are not your competition (you have accepted that you are no longer one of them) and you are aware of the knowledge and insights your work experiences have imbued you with and wish to express and
Re: Scary Sysprogs
Gerhard, Boy, you put into words my thoughts of many years and installations and two ISVs. Thank you Scott ford www.identityforge.com from my IPAD On Jan 8, 2014, at 10:30 AM, Gerhard Postpischil gerha...@charter.net wrote: On 1/8/2014 9:05 AM, Govind Chettiar wrote: It's pretty creativity-stifling to work in a company where the threat of being fired looms. If one works for a firm that has annual RIFs just as a matter of practice and one is constantly in fear of setting a foot wrong lest one get on that list, then one is not going to do anything more than the bare minimum. No one wants to work a single extra minute in that kind of environment. Absent such a fear, one is more willing to take risks, be innovative. I worked for an ISV that had a very relaxed environment, and if you finished your work on time, could experiment. They were victims of their own success, getting bought out by a larger company. Their policies required an annual review, and the lowest scoring individual in each group was fired. One year that was the maintainer of their top selling product. But even without RIFs, some environments can be stifling. The staff in some government installations seems to fall into two categories - those who are capable and learn how to avoid pitfalls of rules, and those with marginal skills. As a case in point, I did some contract work at one agency that required all jobs using tapes to contain JCL comments listing, by data set name, all volumes to be mounted, in sequence, with precise formatting requirements. They had a command that would show the volumes for a data set, but the user still had to edit each job almost every run. I suspect that they had this process as long as they had TSO; after a while I got sick and tired of this, and wrote an EDIT macro that did the necessary work. Sometimes a fresh look is helpful. Gerhard Postpischil Bradford, Vermont -- 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: Scary Sysprogs
On Wed, 8 Jan 2014 10:30:35 -0500, Gerhard Postpischil wrote: B... As a case in point, I did some contract work at one agency that required all jobs using tapes to contain JCL comments listing, by data set name, all volumes to be mounted, in sequence, with precise formatting requirements. And no one thought to ask, Why? Sometimes such practices are a legacy of systems converted from other OSes of other vendors that have less sophisticated data management facilities. ... They had a command that would show the volumes for a data set, but the user still had to edit each job almost every run. Isn't that what the CATALOG is for? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex File System Sharing with Mountpoints Containing Symlinks
Thanks for your response, David. USER.TOOLS is not part of the z/OS-maintained file system. It's something we maintain internally. I do have my VERSION values set as you noted. Replacing sub-directory 'local' with a symlink looks like it will work for us. Thank you! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex File System Sharing with Mountpoints Containing Symlinks
Don’t know if you have LPARs designated at TEST, DEV and PROD, but another
variation is to incorporate the use of system symbols. You could have a
/shared/TECH/tools /shared/DEV/tools, and /shared/prod/tools, and instead of
the ln -s /shared/tools /usr/local, you could use ln -s
'$SYSSYMA/shared/ENV./tools' /usr/tools assuming you have a system symbol
defined like ENV=TECH, or ENV=DEV , or ENV=PROD
Then your mount statements would be
MOUNTFILESYSTEM('USER.ENV..TOOLS')
TYPE(ZFS)
MODE(read) UNMOUNT
MOUNTPOINT('/shared/ENV./tools')
This would allow you to have a version of your TOOLS filesystem by environment.
A USER.TECH.TOOLS, USER.DEV.TOOLS, and USER.PROD.TOOLS so that you are not
affecting all environments at once with a change to USER.TOOLS.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cal McCracken
Sent: Wednesday, January 08, 2014 10:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sysplex File System Sharing with Mountpoints Containing Symlinks
Thanks for your response, David.
USER.TOOLS is not part of the z/OS-maintained file system. It's something we
maintain internally.
I do have my VERSION values set as you noted.
Replacing sub-directory 'local' with a symlink looks like it will work for us.
Thank you!
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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: Hardware failures (was Re: Scary Sysprogs ...)
john.archie.mck...@gmail.com (John McKown) writes: Back in the z890 days, we had a CPU fail. Of course, the hardware automatically recovered and we only knew about it due to a logrec record being written and a message on the HMC. We also had one of our OSAs fail. The second OSA did an ARP takeover (proper term?) and we suffered _no_ user interruption. The LAN people _refused_ to believe that the OSA could fail that way without disrupting all the IP sessions of the users on that OSA. Apparently when a multi-NIC PC has a NIC fail, all the IP sessions on that NIC die immediately (well, they time out). re: http://www.garlic.com/~lynn/2014.html#23 Scary Sysprogs and educating those 'kids' http://www.garlic.com/~lynn/2014.html#24 Scary Sysprogs and educating those 'kids' http://www.garlic.com/~lynn/2014.html#27 Hardware failures (was Re: Scary Sysprogs ...) we did IP-address take-over (ARP cache times out and remaps ip-address to a different MAC address) in HA/CMP http://www.garlic.com/~lynn/subtopic.html#hacmp however at the time, most vendors used bsd reno/tahoe 4.3 software for their tcp/ip stack ... and there was a bug in the 4.3 code (and therefor in nearly every machine out there). the bug was in the ip layer ... it saved the previous response from call to ARP cache ... and if the next IP operation was for the same ip-address, it used the saved value (and bypassed calling arp cache handler). ARP cache protocol requires that the saved ip-address/mac-address mapping in the ARP cache times-out and a new ARP operation has to be done to discover the corresponding MAC address (for that ip-address). However, the saved mac address had no such time-out. In a strongly oriented client/server environment when the client primarily does majority of its tcp/ip to the same server (ip-address) ... it could go for long periods of time w/o changing ip-addresses. As a result a server doing ip-address takeover to a different LAN/MAC address wouldn't be noticed by such clients. We had to come up with all sorts of hacks to smear ip-address traffic across the environment ... trying to force clients to reset their ip-address to mac-address mapping. There is separate gimmick which involves MAC-address spoofing ... i.e. in theory every MAC-addresses are unique created at manufacturing time ... however some number of adapters have been given the ability to soft reset their MAC-address (so if one adapter fails ... another adapter can spoof the failed adapter). -- 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: Hardware failures (was Re: Scary Sysprogs ...)
If you read my original remarks more closely, you would see I did not say I had seen no IBM mainframe hardware failures since the 70's, but that I had not seen any UNDETECTED hardware failures. If the hardware reported no hardware problems, you could pretty well rule that out as a cause of application failure - it had to be a software issue. As others have already remarked, many detected mainframe hardware failures in recent decades resulted in no outages or minimal disruption because of redundancy in the hardware and z/OS recovery. But I have also seen a few classic cases where the hardware built-in diagnostics had much difficulty directing proper repairs because the root cause was something that wasn't expected to break (bad I/O cage in z9 rather than bad cards, intermittent errors from loose bolt connecting large power bus strips that didn't show up until 6 months after a water-cooled processor upgrade). The only hardware issues that occurred with any regularity were issues with tape drives and line printers and these tended to be either media problems or obvious mechanical issues. Several single-drive failures per year were also common in our RAID-5 DASD subsystems, but these were always non disruptive to the data and to z/OS. Joel C. Ewing On 01/08/2014 07:16 AM, John McKown wrote: Back in the z890 days, we had a CPU fail. Of course, the hardware automatically recovered and we only knew about it due to a logrec record being written and a message on the HMC. We also had one of our OSAs fail. The second OSA did an ARP takeover (proper term?) and we suffered _no_ user interruption. The LAN people _refused_ to believe that the OSA could fail that way without disrupting all the IP sessions of the users on that OSA. Apparently when a multi-NIC PC has a NIC fail, all the IP sessions on that NIC die immediately (well, they time out). On Wed, Jan 8, 2014 at 12:52 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Scott Ford wrote: Like Joel, I haven't seen a hardware failure in the Z/OS world since the 70s. Lucky you. I wrote on IBM-MAIN in May/June 2013 about Channel Errors which caused SMF damage amongst other problems. These channel errors were caused by bad optic cables and some directors/routers. Then last year, during a hardware upgrade, those projects were delayed because an IBM hardware component blew and a part has to be flown in from somewhere... Hardware failures can happens in these days. Groete / Greetings Elardus Engelbrecht -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex File System Sharing with Mountpoints Containing Symlinks
Good stuff! We don't have a TEST/DEV/PROD environment, however our 3 LPAR environment is always running n through n-2 versions of z/OS to facilitate product testing and problem re-creation for our developers. We alternate frequently among various versions and service refreshes of Java during testing and your suggestion of using system symbols could be very handy. Thanks again. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Hardware failures (was Re: Scary Sysprogs ...)
W dniu 2014-01-08 17:23, Joel C. Ewing pisze: If you read my original remarks more closely, you would see I did not say I had seen no IBM mainframe hardware failures since the 70's, but that I had not seen any UNDETECTED hardware failures. If the hardware reported no hardware problems, you could pretty well rule that out as a cause of application failure - it had to be a software issue. OK, I have seen undetected HW failures on mainframe. Example: IBM RAMAC RVA. Disk module was in ? status. Something between OK and NOTOK. Machine reported no bad disks, but the disk was not OK any longer and not in use. Another example: ESCON port. OK, I detected it because CU attached did not work, but root cause wasn't reported. Another one, quite recent (it's microcode issue actually): LPAR cannot be IPLed after z/OS shutdown and Reset Clear. Circumvention: don't use Reset Clear or re-activate LPAR. I believe I can dig in my memory deeper... -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.555.904 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter
Hi, I am getting the following return code when try to add CSVLLIX1 with the moaddr parameter of CSVDYNEX The AMODE of the program is correct = 31 As The high order bit of the address is one With the dsname parameter I get a RC of 0 R15 = 8 , R0 = 827 Below is my code * Add LLA exit CSVLLIX1 in case module is LLA MA * LOAD EP=CSVLLIX1 ST R0,LLA_EXIT L R9,PSAAOLD-PSA(,R0) ZZ USING ASCB,R9 ICM R8,B'',ZZ.ASCBJBNI BZSTARTTSK MVC JOB_NAME,0(R8) B PRIME_JOB STARTTSK DS0H ICM R8,B'',ZZ.ASCBJBNS MVC JOB_NAME,0(R8) PRIME_JOB DS 0H LAR8,JOB_NAME * L R10,LLA_EXIT CSVDYNEX REQUEST=ADD, EXITNAME=CSVLLIX1, STATE=ACTIVE, MODNAME=CSVLLIX1, MODADDR=(R10), JOBNAME=(R8), POS=FIRST, RETCODE=RETCODE, RSNCODE=RSNCODE,MF=(E,DYN_PARM) Program defination Name Prompt Alias-of Size TTR ACAM RM . CSVLLIX1 006000480B01 31 ANY R15 = 08 R0 = 0827 CSVDYNEXRSNBADAMODE Meaning: Program error. For an ADD, MODIFY, or REPLACE request: one of the following occurred: ° An exit routine with AMODE=31 is being added to an exit that requires that its exit routines have AMODE=24. ° An exit routine with AMODE=24 is being added to an exit that requires that its exit routines have AMODE=31. Action: Make sure the AMODE attributes of the exit routine to be added conform to the exit definition. 2.5.3 Exit Routine Environment CSVLLIX1 receives control in the following environment: Enabled for interrupts. In supervisor state and in primary ASC mode with the primary ASID equal to the home ASID. In AMODE 31 and RMODE ANY. Under a content supervisor's SVRB within the user's address space. With no locks or ENQs held. Under any task that might issue a LINK, LOAD, XCTL, or ATTACH macro. Subtopics: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
I have always felt that the parent-goes-away-leaving-the-child-running scenario was the *ix substitution for what we can do with XCTL in z/OS systems. But (as usual) that might just be my wrong-headed view of the situation. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm Sent: Wednesday, January 08, 2014 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Spawned Address Space Control in tcsh shell Is there a specific reason (other than it being goofy) that the child could just become the parent? Some sort of percolation upward? Rob Schramm Rob Schramm Senior Systems Consultant Imperium Group On Tue, Dec 31, 2013 at 2:18 PM, Tony Harminc t...@harminc.net wrote: On 31 December 2013 13:23, Paul Gilmartin paulgboul...@aim.com wrote: Most (?) of the complaints about (non-)shared areas stem from the non-propagation of DDNAMEs through fork(). Ain't gonna get better (NVFL, anyway). Because of ENQ conflicts between parent and child. Extend the ENQ scope to job rather than address space? NVFL, again. I could imagine: o A scheme where an allocation could be transferred from parent to child, freeing the ENQ in parent. o A server-client model in which the actual I/O is performed by the parent that performs the allocation, and the data passed to the child via sockets or POSIX pipes. Sort of like NFS, but it needs to be better than NFS. The likely problem is that - unlike the MVS subtasking model - in UNIX the parent process can go away leaving the child running. Would you leave the parent running just to handle the I/O work, or clean it up and transfer the ENQs and/or allocations to the child at that point, or just say Don't Do That, or...? Tony H. -- 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: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter
From the CSVDYNEX doc : MODADDR specifies a fullword (or a register containing the address of a fullword) that contains the address of the exit routine to be added. I suggest you code MODADDR=LLA_EXIT in your CSVDYNEX macro specification. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of MichealButz Sent: 08 January 2014 16:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter Hi, I am getting the following return code when try to add CSVLLIX1 with the moaddr parameter of CSVDYNEX The AMODE of the program is correct = 31 As The high order bit of the address is one With the dsname parameter I get a RC of 0 R15 = 8 , R0 = 827 Below is my code * Add LLA exit CSVLLIX1 in case module is LLA MA * LOAD EP=CSVLLIX1 ST R0,LLA_EXIT L R9,PSAAOLD-PSA(,R0) ZZ USING ASCB,R9 ICM R8,B'',ZZ.ASCBJBNI BZSTARTTSK MVC JOB_NAME,0(R8) B PRIME_JOB STARTTSK DS0H ICM R8,B'',ZZ.ASCBJBNS MVC JOB_NAME,0(R8) PRIME_JOB DS 0H LAR8,JOB_NAME * L R10,LLA_EXIT CSVDYNEX REQUEST=ADD, EXITNAME=CSVLLIX1, STATE=ACTIVE, MODNAME=CSVLLIX1, MODADDR=(R10), JOBNAME=(R8), POS=FIRST, RETCODE=RETCODE, RSNCODE=RSNCODE,MF=(E,DYN_PARM) Program defination Name Prompt Alias-of Size TTR ACAM RM . CSVLLIX1 006000480B01 31 ANY R15 = 08 R0 = 0827 CSVDYNEXRSNBADAMODE Meaning: Program error. For an ADD, MODIFY, or REPLACE request: one of the following occurred: ° An exit routine with AMODE=31 is being added to an exit that requires that its exit routines have AMODE=24. ° An exit routine with AMODE=24 is being added to an exit that requires that its exit routines have AMODE=31. Action: Make sure the AMODE attributes of the exit routine to be added conform to the exit definition. 2.5.3 Exit Routine Environment CSVLLIX1 receives control in the following environment: . Enabled for interrupts. . In supervisor state and in primary ASC mode with the primary ASID equal to the home ASID. . In AMODE 31 and RMODE ANY. . Under a content supervisor's SVRB within the user's address space. . With no locks or ENQs held. . Under any task that might issue a LINK, LOAD, XCTL, or ATTACH macro. Subtopics: -- 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: Spawned Address Space Control in tcsh shell
On 8 January 2014 11:47, Farley, Peter x23353 peter.far...@broadridge.com wrote: I have always felt that the parent-goes-away-leaving-the-child-running scenario was the *ix substitution for what we can do with XCTL in z/OS systems. But (as usual) that might just be my wrong-headed view of the situation. I'm not so sure. While the implementors of z/OS UNIX have done a remarkable job of fusing MVS and UNIX behaviour, there are limits. I think of UNIX exec() as the closest thing to MVS XCTL. But UNIX processes are different; the parent can do the UNIX classic fork() followed by exec() done by the new child, or the similar spawn(), in each case leaving a parent and a child. Each can do their own thing (which could include further exec()s) for as long as they like, and then either can terminate independent of the other. While there may well be signals and default behaviours to worry about, the result can be that the child runs while the parent is gone. There is nothing like this in the case of MVS TCBs. If the parent ends, the child abends. Under some circumstances the abend can be caught, but life cannot continue without the parent. TonyH. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On Wed, 8 Jan 2014 11:47:58 -0500, Farley, Peter x23353 wrote: I have always felt that the parent-goes-away-leaving-the-child-running scenario was the *ix substitution for what we can do with XCTL in z/OS systems. Ummm... Not quite. *IX supports the scenario: a) Parent runs for a while, then fork()s child. b) Parent and child run concurrently and cooperatively for a while. c) Parent-goes-away-leaving-the-child-running. XCTL fails to support (b) because the parent goes away instantly. ATTACH fails to support (c) because the child can't outlive the parent. (But why not? Silly design. Perhaps none of the OS/360 designers were orphans, so the concept never occurred to them.) In *IX, if the parent goes away, the grandparent adopts the child. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
One possibility is to use POSIX threading instead of ATTACH. POSIX threads all run in the same address space. And are actually implemented via TCBs. But there is no parent/child relationship between a thread and a separate thread which a given thread creates. The only special thread is the initial thread (called the IPT ). When it dies, then all the POSIX threads die. This is because that thread actually does all the ATTACHes. It is similar to how PL/I did it's multitasking. On Wed, Jan 8, 2014 at 12:20 PM, Paul Gilmartin paulgboul...@aim.comwrote: On Wed, 8 Jan 2014 11:47:58 -0500, Farley, Peter x23353 wrote: I have always felt that the parent-goes-away-leaving-the-child-running scenario was the *ix substitution for what we can do with XCTL in z/OS systems. Ummm... Not quite. *IX supports the scenario: a) Parent runs for a while, then fork()s child. b) Parent and child run concurrently and cooperatively for a while. c) Parent-goes-away-leaving-the-child-running. XCTL fails to support (b) because the parent goes away instantly. ATTACH fails to support (c) because the child can't outlive the parent. (But why not? Silly design. Perhaps none of the OS/360 designers were orphans, so the concept never occurred to them.) In *IX, if the parent goes away, the grandparent adopts the child. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? 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: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter
Okay thank you Sent from my iPhone On Jan 8, 2014, at 12:08 PM, Rob Scott rsc...@rocketsoftware.com wrote: From the CSVDYNEX doc : MODADDR specifies a fullword (or a register containing the address of a fullword) that contains the address of the exit routine to be added. I suggest you code MODADDR=LLA_EXIT in your CSVDYNEX macro specification. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of MichealButz Sent: 08 January 2014 16:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter Hi, I am getting the following return code when try to add CSVLLIX1 with the moaddr parameter of CSVDYNEX The AMODE of the program is correct = 31 As The high order bit of the address is one With the dsname parameter I get a RC of 0 R15 = 8 , R0 = 827 Below is my code * Add LLA exit CSVLLIX1 in case module is LLA MA * LOAD EP=CSVLLIX1 ST R0,LLA_EXIT L R9,PSAAOLD-PSA(,R0) ZZ USING ASCB,R9 ICM R8,B'',ZZ.ASCBJBNI BZSTARTTSK MVC JOB_NAME,0(R8) B PRIME_JOB STARTTSK DS0H ICM R8,B'',ZZ.ASCBJBNS MVC JOB_NAME,0(R8) PRIME_JOB DS 0H LAR8,JOB_NAME * L R10,LLA_EXIT CSVDYNEX REQUEST=ADD, EXITNAME=CSVLLIX1, STATE=ACTIVE, MODNAME=CSVLLIX1, MODADDR=(R10), JOBNAME=(R8), POS=FIRST, RETCODE=RETCODE, RSNCODE=RSNCODE,MF=(E,DYN_PARM) Program defination Name Prompt Alias-of Size TTR ACAM RM . CSVLLIX1 006000480B01 31 ANY R15 = 08 R0 = 0827 CSVDYNEXRSNBADAMODE Meaning: Program error. For an ADD, MODIFY, or REPLACE request: one of the following occurred: ° An exit routine with AMODE=31 is being added to an exit that requires that its exit routines have AMODE=24. ° An exit routine with AMODE=24 is being added to an exit that requires that its exit routines have AMODE=31. Action: Make sure the AMODE attributes of the exit routine to be added conform to the exit definition. 2.5.3 Exit Routine Environment CSVLLIX1 receives control in the following environment: . Enabled for interrupts. . In supervisor state and in primary ASC mode with the primary ASID equal to the home ASID. . In AMODE 31 and RMODE ANY. . Under a content supervisor's SVRB within the user's address space. . With no locks or ENQs held. . Under any task that might issue a LINK, LOAD, XCTL, or ATTACH macro. Subtopics: -- 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: Innovating an old IMS 3270-based application
On 1/7/14 3:05 AM, Elardus Engelbrecht wrote: Timothy Sipples wrote: 1A. Users want Web-based access, OK. May I assume that means (or could soon mean) mobile as well (iPads, Android devices, and so on)? Can you do SSL connection on those toys? [1] ALL of the iOS and Android devices that I _personally_ use fully support SSL. (Also, both my iPhone and iPad have built-in VPN clients which support IPsec VPN connections that are fully interoperable with my employer's network.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter
I'd be interested if this fixes the problem. I looked up the CSVDYNEX RC 8 and RSN 827 and it says a AMODE=31 exit routine is being added to an exit that requires its routines to be AMODE=24. Cliff McNeill Date: Wed, 8 Jan 2014 17:08:08 + From: rsc...@rocketsoftware.com Subject: Re: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter To: IBM-MAIN@LISTSERV.UA.EDU From the CSVDYNEX doc : MODADDR specifies a fullword (or a register containing the address of a fullword) that contains the address of the exit routine to be added. I suggest you code MODADDR=LLA_EXIT in your CSVDYNEX macro specification. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of MichealButz Sent: 08 January 2014 16:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter Hi, I am getting the following return code when try to add CSVLLIX1 with the moaddr parameter of CSVDYNEX The AMODE of the program is correct = 31 As The high order bit of the address is one With the dsname parameter I get a RC of 0 R15 = 8 , R0 = 827 Below is my code * Add LLA exit CSVLLIX1 in case module is LLA MA * LOAD EP=CSVLLIX1 ST R0,LLA_EXIT L R9,PSAAOLD-PSA(,R0) ZZ USING ASCB,R9 ICM R8,B'',ZZ.ASCBJBNI BZ STARTTSK MVC JOB_NAME,0(R8) B PRIME_JOB STARTTSK DS 0H ICM R8,B'',ZZ.ASCBJBNS MVC JOB_NAME,0(R8) PRIME_JOB DS 0H LA R8,JOB_NAME * L R10,LLA_EXIT CSVDYNEX REQUEST=ADD, EXITNAME=CSVLLIX1, STATE=ACTIVE, MODNAME=CSVLLIX1, MODADDR=(R10), JOBNAME=(R8), POS=FIRST, RETCODE=RETCODE, RSNCODE=RSNCODE,MF=(E,DYN_PARM) Program defination Name Prompt Alias-of Size TTR AC AM RM . CSVLLIX1 0060 00480B 01 31 ANY R15 = 08 R0 = 0827 CSVDYNEXRSNBADAMODE Meaning: Program error. For an ADD, MODIFY, or REPLACE request: one of the following occurred: ° An exit routine with AMODE=31 is being added to an exit that requires that its exit routines have AMODE=24. ° An exit routine with AMODE=24 is being added to an exit that requires that its exit routines have AMODE=31. Action: Make sure the AMODE attributes of the exit routine to be added conform to the exit definition. 2.5.3 Exit Routine Environment CSVLLIX1 receives control in the following environment: . Enabled for interrupts. . In supervisor state and in primary ASC mode with the primary ASID equal to the home ASID. . In AMODE 31 and RMODE ANY. . Under a content supervisor's SVRB within the user's address space. . With no locks or ENQs held. . Under any task that might issue a LINK, LOAD, XCTL, or ATTACH macro. Subtopics: -- 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: Hardware failures (was Re: Scary Sysprogs ...)
IIRC the 360/50's didn't have parity checking CPU buss. Long story short CE told me in early 80's CE overtime dropped 50% with intro of 370' and another 50% when 303x's were withdrawn. In a message dated 1/8/2014 10:31:01 A.M. Central Standard Time, r.skoru...@bremultibank.com.pl writes: I believe I can dig in my memory deeper... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS 2.1 toleration PTFs
Hello, We recently installed z/OS 2.1 system and now in process of making it sysplex member of currently running SYSPLEX. We have multiple version of z/OS running in this sysplex. But, when I am trying to IPL z/OS 2.1 having sysplex defination, I am getting below error. *IEA002I APAR OA36207 is not installed on TST01. SYSTEM TST02 is being Partitioned .* *IXC220W XCF is unable to continue . Wait State 082 REASON code 000.* This error clearly indicate to install z/OS 2.1 toleration PTFs on low level z/OS system, So that all z/OS with different version can be part of same sysplex. I am following below link for getting PTF number for APAR OA36207 . http://www-01.ibm.com/support/docview.wss?uid=isg1OA36207 But I am not able to find any more document, which can help me getting list of all required toleration PTFs for low level z/OS system to make it work with z/OS 2.1 in this sysplex. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 toleration PTFs
I think you need to run a FIXCAT report with a current HOLD DATA information. It seems you need to go to the migration guides and apply all co-existence maintenance for z/OS and any 3rd party vendor. FIXCAT (fix category) information to Enhanced HOLDDATA and the REPORT MISSINGFIX function introduced in z/OS V1R10 SMP/E. For example SET BDY(GLOBAL). REPORT MISSINGFIX ZONES(ZOSR12T) FIXCAT(IBM.Coexistence.z/OS.V2R1). See this url for additional information on installing fixes http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp?topic=%2Fcom.ibm.zos.v2 r1.e0zm100%2Fcoxptfs.htm Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, January 08, 2014 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 toleration PTFs Hello, We recently installed z/OS 2.1 system and now in process of making it sysplex member of currently running SYSPLEX. We have multiple version of z/OS running in this sysplex. But, when I am trying to IPL z/OS 2.1 having sysplex defination, I am getting below error. *IEA002I APAR OA36207 is not installed on TST01. SYSTEM TST02 is being Partitioned .* *IXC220W XCF is unable to continue . Wait State 082 REASON code 000.* This error clearly indicate to install z/OS 2.1 toleration PTFs on low level z/OS system, So that all z/OS with different version can be part of same sysplex. I am following below link for getting PTF number for APAR OA36207 . http://www-01.ibm.com/support/docview.wss?uid=isg1OA36207 But I am not able to find any more document, which can help me getting list of all required toleration PTFs for low level z/OS system to make it work with z/OS 2.1 in this sysplex. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter
Cliff The original MODADDR keyword pointed to the load point of the module and not the required address of the load point (ie one level of dereferencing out). As the first four bytes of the module were probably some sort of branch around the eye catch instruction and was not greater than x'7Fxx' - for example x'47F0', CSVDYNEX thought that the caller had passed a 24bit address instead of the required 31bit. On 8 Jan 2014, at 18:38, Clifford McNeill sy...@hotmail.com wrote: I'd be interested if this fixes the problem. I looked up the CSVDYNEX RC 8 and RSN 827 and it says a AMODE=31 exit routine is being added to an exit that requires its routines to be AMODE=24. Cliff McNeill Date: Wed, 8 Jan 2014 17:08:08 + From: rsc...@rocketsoftware.com Subject: Re: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter To: IBM-MAIN@LISTSERV.UA.EDU From the CSVDYNEX doc : MODADDR specifies a fullword (or a register containing the address of a fullword) that contains the address of the exit routine to be added. I suggest you code MODADDR=LLA_EXIT in your CSVDYNEX macro specification. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of MichealButz Sent: 08 January 2014 16:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter Hi, I am getting the following return code when try to add CSVLLIX1 with the moaddr parameter of CSVDYNEX The AMODE of the program is correct = 31 As The high order bit of the address is one With the dsname parameter I get a RC of 0 R15 = 8 , R0 = 827 Below is my code * Add LLA exit CSVLLIX1 in case module is LLA MA * LOAD EP=CSVLLIX1 ST R0,LLA_EXIT L R9,PSAAOLD-PSA(,R0) ZZ USING ASCB,R9 ICM R8,B'',ZZ.ASCBJBNI BZ STARTTSK MVC JOB_NAME,0(R8) B PRIME_JOB STARTTSK DS 0H ICM R8,B'',ZZ.ASCBJBNS MVC JOB_NAME,0(R8) PRIME_JOB DS 0H LA R8,JOB_NAME * L R10,LLA_EXIT CSVDYNEX REQUEST=ADD, EXITNAME=CSVLLIX1, STATE=ACTIVE, MODNAME=CSVLLIX1, MODADDR=(R10), JOBNAME=(R8), POS=FIRST, RETCODE=RETCODE, RSNCODE=RSNCODE,MF=(E,DYN_PARM) Program defination Name Prompt Alias-of Size TTR AC AM RM . CSVLLIX1 0060 00480B 01 31 ANY R15 = 08 R0 = 0827 CSVDYNEXRSNBADAMODE Meaning: Program error. For an ADD, MODIFY, or REPLACE request: one of the following occurred: ° An exit routine with AMODE=31 is being added to an exit that requires that its exit routines have AMODE=24. ° An exit routine with AMODE=24 is being added to an exit that requires that its exit routines have AMODE=31. Action: Make sure the AMODE attributes of the exit routine to be added conform to the exit definition. 2.5.3 Exit Routine Environment CSVLLIX1 receives control in the following environment: . Enabled for interrupts. . In supervisor state and in primary ASC mode with the primary ASID equal to the home ASID. . In AMODE 31 and RMODE ANY. . Under a content supervisor's SVRB within the user's address space. . With no locks or ENQs held. . Under any task that might issue a LINK, LOAD, XCTL, or ATTACH macro. Subtopics: -- 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: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter
Rob, Thanks. I see my confusion. The error also is for AMODE 24 when AMODE 31 is needed in additon to AMODE 31 when AMODE 24 is needed. Cliff McNeill Date: Wed, 8 Jan 2014 19:35:09 + From: rsc...@rocketsoftware.com Subject: Re: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter To: IBM-MAIN@LISTSERV.UA.EDU Cliff The original MODADDR keyword pointed to the load point of the module and not the required address of the load point (ie one level of dereferencing out). As the first four bytes of the module were probably some sort of branch around the eye catch instruction and was not greater than x'7Fxx' - for example x'47F0', CSVDYNEX thought that the caller had passed a 24bit address instead of the required 31bit. On 8 Jan 2014, at 18:38, Clifford McNeill sy...@hotmail.com wrote: I'd be interested if this fixes the problem. I looked up the CSVDYNEX RC 8 and RSN 827 and it says a AMODE=31 exit routine is being added to an exit that requires its routines to be AMODE=24. Cliff McNeill Date: Wed, 8 Jan 2014 17:08:08 + From: rsc...@rocketsoftware.com Subject: Re: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter To: IBM-MAIN@LISTSERV.UA.EDU From the CSVDYNEX doc : MODADDR specifies a fullword (or a register containing the address of a fullword) that contains the address of the exit routine to be added. I suggest you code MODADDR=LLA_EXIT in your CSVDYNEX macro specification. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of MichealButz Sent: 08 January 2014 16:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter Hi, I am getting the following return code when try to add CSVLLIX1 with the moaddr parameter of CSVDYNEX The AMODE of the program is correct = 31 As The high order bit of the address is one With the dsname parameter I get a RC of 0 R15 = 8 , R0 = 827 Below is my code * Add LLA exit CSVLLIX1 in case module is LLA MA * LOAD EP=CSVLLIX1 ST R0,LLA_EXIT L R9,PSAAOLD-PSA(,R0) ZZ USING ASCB,R9 ICM R8,B'',ZZ.ASCBJBNI BZ STARTTSK MVC JOB_NAME,0(R8) B PRIME_JOB STARTTSK DS 0H ICM R8,B'',ZZ.ASCBJBNS MVC JOB_NAME,0(R8) PRIME_JOB DS 0H LA R8,JOB_NAME * L R10,LLA_EXIT CSVDYNEX REQUEST=ADD, EXITNAME=CSVLLIX1, STATE=ACTIVE, MODNAME=CSVLLIX1, MODADDR=(R10), JOBNAME=(R8), POS=FIRST, RETCODE=RETCODE, RSNCODE=RSNCODE,MF=(E,DYN_PARM) Program defination Name Prompt Alias-of Size TTR AC AM RM . CSVLLIX1 0060 00480B 01 31 ANY R15 = 08 R0 = 0827 CSVDYNEXRSNBADAMODE Meaning: Program error. For an ADD, MODIFY, or REPLACE request: one of the following occurred: ° An exit routine with AMODE=31 is being added to an exit that requires that its exit routines have AMODE=24. ° An exit routine with AMODE=24 is being added to an exit that requires that its exit routines have AMODE=31. Action: Make sure the AMODE attributes of the exit routine to be added conform to the exit definition. 2.5.3 Exit Routine Environment CSVLLIX1 receives control in the following environment: . Enabled for interrupts. . In supervisor state and in primary ASC mode with the primary ASID equal to the home ASID. . In AMODE 31 and RMODE ANY. . Under a content supervisor's SVRB within the user's address space. . With no locks or ENQs held. . Under any task that might issue a LINK, LOAD, XCTL, or ATTACH macro. Subtopics: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error Adding CSVLLIX1 using CSVDYNEX with modaddr paramter
On Wed, 8 Jan 2014 11:45:58 -0500, MichealButz michealb...@optonline.net wrote: I am getting the following return code when try to add CSVLLIX1 with the moaddr parameter of CSVDYNEX The AMODE of the program is correct = 31 As The high order bit of the address is one With the dsname parameter I get a RC of 0 R15 = 8 , R0 = 827 Below is my code * Add LLA exit CSVLLIX1 in case module is LLA MA * LOAD EP=CSVLLIX1 ST R0,LLA_EXIT If I understand the processing for this exit, the exit routine must be in common storage (e.g., LPA or CSA) if you specify MODADDR on the CSVDYNEX ADD macro. So unless your LOAD is satisfied from LPA I doubt that this will work properly. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPL Issue
While John's suggestion will work, there is a cost to those releases that do not need the IEAVTRML update of unnecessary processing on every task and address space termination (normal and abnormal) of setting up and calling the admittedly tiny target routine. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Hardware failures (was Re: Scary Sysprogs ...)
efinnel...@aol.com (Ed Finnell) writes: IIRC the 360/50's didn't have parity checking CPU buss. Long story short CE told me in early 80's CE overtime dropped 50% with intro of 370' and another 50% when 303x's were withdrawn. re: http://www.garlic.com/~lynn/2014.html#23 Scary Sysprogs and educating those 'kids' http://www.garlic.com/~lynn/2014.html#24 Scary Sysprogs and educating those 'kids' http://www.garlic.com/~lynn/2014.html#27 Hardware failures (was Re: Scary Sysprogs ...) http://www.garlic.com/~lynn/2014.html#29 Hardware failures (was Re: Scary Sysprogs ...) 303x's were mostly 370s. they took the integrated channel microcode from the 370/158 and created the 303x channel director (158 microcode engine with just the integrated channel microcode and w/o the 370 microcode). a 3031 was a 370/158 engine with the 370 microcode (and w/o the integrated channel microcde) and a 2nd (channel director) 370/158 engine with the integrated channel microcode (and w/o the 370 microcode). a 3032 was a 370/168 reconfigured to work with channel director a 3033 started out being 370/168 logic mapped to 20% faster chips ... some other optimization eventually got it up to about 50% faster than 168. CE had machine diagnostic service process that required being able to scope. The 3081 had chips packaged inside TCM (thermal conduction module) and couldn't be scoped. To support CE service process, the TCMs had a bunch of probes connected to a service processor. CEs then had (bootstrap) diiagnostic service process that could diagnose/scope a failing service processor ... and then use a working service processor to diagnose the rest of the machine. TCM http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV2137.html and http://en.wikipedia.org/wiki/Thermal_Conduction_Module#Mainframes_and_supercomputers other comments about 3033 3081 ... being part of the qd effort to get machines back into the product pipeline after the failure of the Future System effort: http://www.jfsowa.com/computer/memo125.htm the 3090 started out with 4331 running a highly modified version of release 6 vm370/cms as the service processor (with all the menu screens done in cms ios3270). This was upgraded to a pair of 4361s (with probes into TCMs for diagnosing problems). reference to 3092 (service controller) needing a pair of 3370 fixed-block architecture disks i.e. the system disks for the vm/4361s (aka even for a pure MVS installation ... where MVS never had any 3370/FBA support) http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3090.html more ... although following says 3090 in 1984 ... but 3090 wasn't announced until feb 1985 (see above): http://en.wikipedia.org/wiki/Thermal_Conduction_Module#Mainframes_and_supercomputers old email mentioning 3092 http://www.garlic.com/~lynn/2010e.html#email861031 http://www.garlic.com/~lynn/2010e.html#email861223 -- 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: LOGSTREAM data set RM.METADATA
Fred, In addition to the doc link reference to the RRS manual that was already provided; please note that the specific logstream that you referenced (the RRS 'RM.METAdata' logstream) is OPTIONAL and is ONLY used by RRS at the direction of an external RM (Resource Manager) and really only needs to be defined IF you are running an RM that uses it (their set up / installation materials should! point this out explicitly). If you are just starting out then the other OPTIONAL logstream is the 'Archive' one - which is intended for use the by the installation itself to track completed transactions. IF you decide NOT to create either one of these OPTIONAL logstreams - please be aware that when you start RRS you will get a message indicating there is an OPTIONAL logstream was NOT found (that is expected in this case but we just need to make sure of that). Good Luck, Bill IBM z/OS RRS Development and Service -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
LLA/VLF -- NAMED LNKLST?
My memory is hazy on this. Been digging through various manuals for z/OS 1.13. [Haven't had to do real sysprog stuff since z/OS 1.4...] I seem to recall something about Named LNKLST. But I can't find anything on it in the current manuals (I have some number of PDFs on my hard drive for z/OS 1.13). I have also been looking at ABCs of z/OS Systems Programming VOL2 (SG24-6982). Or have I completely confused a couple of concepts? What I am trying to do is improve performance of certain systems, and I thought there was a way to have LLA w/VLF do this but my brain keeps rebelling - Perhaps my problem is my brain has hard associated LLA with Linklist Look Aside as opposed to Library Look Aside? But I thought you do not want to take your user LOADLIBs and put them into the LNKLST. And it seems to me if you don't do that, you can't get a performance boost from LLA/VLF. What is bringing this up are things I have found in looking at CICS/TS 5.1 and COBOL 5.1. Since COBOL 5.1 is going to require PDSE and certain ISV products we have are documented as not doing so well with PDSE over PDS... It seems to me that we would want to use the LLA/VLF native route. IFF it is actually going to provide a performance boost over no management of LOADLIB concatenations. So what are the pros and cons of this (other than in a PLEX, especially, we have to do LLA Refresh...)? Regards, Steve Thompson The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Scary Sysprogs
Mark, Yep that's why they put erasers on pencils, people make mistakes, if they are self-aware the learn from them Scott ford www.identityforge.com from my IPAD On Jan 8, 2014, at 9:08 AM, Mark Jacobs mark.jac...@custserv.com wrote: I agree. If you've never failed, you haven't tried hard enough to grow yourself. On 01/08/14 09:05, Govind Chettiar wrote: It's pretty creativity-stifling to work in a company where the threat of being fired looms. If one works for a firm that has annual RIFs just as a matter of practice and one is constantly in fear of setting a foot wrong lest one get on that list, then one is not going to do anything more than the bare minimum. No one wants to work a single extra minute in that kind of environment. Absent such a fear, one is more willing to take risks, be innovative. -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- 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: Scary Sysprogs
On 1/8/2014 10:41 AM, Paul Gilmartin wrote: And no one thought to ask, Why? Apparently not. The hardware and support staff is two states away, and the local management doesn't seem to get involved in minor details. Isn't that what the CATALOG is for? I didn't want to write a monograph. Their tape data sets comprise up to 100 volumes, although I suspect that with the advent of cartridges that will have shrunk somewhat. They had IBM maintained mods to support that, but I had no access to them. Obviously they didn't provide JCL support, JFCB extensions, or catalog mods. But I shouldn't be too hard on them; I also worked on a contract supporting a large NYC insurance company where a non-setup job would get four to eight hour turnaround, tapes had to be specified on JCL comments cards, and turnaround for a simple tape job was one to two days. By comparison a service bureau I worked at provided while-you-wait turnaround (5-10 minutes) for small jobs, and short jobs with a tape or disk mount finished almost as fast (360/65, later a 165). One of my local changes was a rewrite of the JES2 job scheduling code to consider priority before job class. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMP/E GIM69217I
Here we go again. We're getting: RECEIVE LIST FROMNTS ... . GIM69217ITHE LEVEL OF PROGRAM GIMJVCLT (36.17) IS NOT COMPATIBLE WITH THE LEVEL OF THE SMP/E CALLING PROGRAM GIMSMP (36.38). Our sysprog has opened an issue with IBM. We have no Java involvement in our payload program. It's my understanding that Java is used only to calculate the SHA-1 checksum during RECEIVE FROMNETWORK if crypto hardware is unavailable (it isn't). Verification of that checksum is mentioned in the Commands manual under FROMNETWORK, not under FROMNTS. We have DDDEF for SMPJHOME, not for SMPCPATH. I don't find GIMJVCLT under the SMPJHOME hierarchy (but I'm not very good at opening jars). What's happening? SYSMSGS says: SMPCPATH SMPCPATH NODDF SMPJHOME SMPJHOME PATH'/usr/lpp/java/J6.0.1/' (my SMPNTS is a symlink. I notice that SYSMSGS identifies the PATHHFS as the filesystem containing the symlink, not the filesystem containing the SMPNTS directory. I wonder it's optimal not to resolve the path?) Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E GIM69217I
Gil, The message states Ensure the correct service level of the SMP/E Java programs are accessible to the calling program. The SMPCPATH DD statement can be used to specify the directory where the SMP/E Java classes reside. For example: //SMPCPATH DD PATH='/usr/lpp/smp/classes/' Have you tried adding the C PATH to the job? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, January 08, 2014 5:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMP/E GIM69217I Here we go again. We're getting: RECEIVE LIST FROMNTS ... . GIM69217ITHE LEVEL OF PROGRAM GIMJVCLT (36.17) IS NOT COMPATIBLE WITH THE LEVEL OF THE SMP/E CALLING PROGRAM GIMSMP (36.38). Our sysprog has opened an issue with IBM. We have no Java involvement in our payload program. It's my understanding that Java is used only to calculate the SHA-1 checksum during RECEIVE FROMNETWORK if crypto hardware is unavailable (it isn't). Verification of that checksum is mentioned in the Commands manual under FROMNETWORK, not under FROMNTS. We have DDDEF for SMPJHOME, not for SMPCPATH. I don't find GIMJVCLT under the SMPJHOME hierarchy (but I'm not very good at opening jars). What's happening? SYSMSGS says: SMPCPATH SMPCPATH NODDF SMPJHOME SMPJHOME PATH'/usr/lpp/java/J6.0.1/' (my SMPNTS is a symlink. I notice that SYSMSGS identifies the PATHHFS as the filesystem containing the symlink, not the filesystem containing the SMPNTS directory. I wonder it's optimal not to resolve the path?) Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Scary Sysprogs
I remember, from the early 1980's, a quote along the lines of: If a SYSPROG hasn't p*ssed off at least one person a day, they aren't doing their job! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Mark Jacobs mark.jac...@custserv.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Wed, 8 Jan 2014 09:08:02 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Scary Sysprogs I agree. If you've never failed, you haven't tried hard enough to grow yourself. On 01/08/14 09:05, Govind Chettiar wrote: It's pretty creativity-stifling to work in a company where the threat of being fired looms. If one works for a firm that has annual RIFs just as a matter of practice and one is constantly in fear of setting a foot wrong lest one get on that list, then one is not going to do anything more than the bare minimum. No one wants to work a single extra minute in that kind of environment. Absent such a fear, one is more willing to take risks, be innovative. -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- 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: Scary Sysprogs
Ted, Yes sir I remember that...so true Scott ford www.identityforge.com from my IPAD On Jan 8, 2014, at 10:35 PM, Ted MacNEIL eamacn...@yahoo.ca wrote: I remember, from the early 1980's, a quote along the lines of: If a SYSPROG hasn't p*ssed off at least one person a day, they aren't doing their job! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Mark Jacobs mark.jac...@custserv.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Wed, 8 Jan 2014 09:08:02 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Scary Sysprogs I agree. If you've never failed, you haven't tried hard enough to grow yourself. On 01/08/14 09:05, Govind Chettiar wrote: It's pretty creativity-stifling to work in a company where the threat of being fired looms. If one works for a firm that has annual RIFs just as a matter of practice and one is constantly in fear of setting a foot wrong lest one get on that list, then one is not going to do anything more than the bare minimum. No one wants to work a single extra minute in that kind of environment. Absent such a fear, one is more willing to take risks, be innovative. -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- 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: Spawned Address Space Control in tcsh shell
On Wed, 8 Jan 2014 12:28:13 -0600, John McKown wrote: One possibility is to use POSIX threading instead of ATTACH. POSIX threads all run in the same address space. And are actually implemented via TCBs. But there is no parent/child relationship between a thread and a separate thread which a given thread creates. The only special thread is the initial thread (called the IPT ). When it dies, then all the POSIX threads die. This is because that thread actually does all the ATTACHes. It is similar to how PL/I did it's multitasking. It's interesting that you refer to PL/I in the past tense. But that may be a matter more of your personal history than of PL/I's. And, each thread could do its own I/O securely. Almost. There's still the problem of DDNAME contention. Damn! it would be so nice if ATTACH handled alternate DDNAME assignment rather than leaving it to the various utilities. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On Jan 8, 2014, at 10:22 PM, Paul Gilmartin wrote: On SNIP-- And, each thread could do its own I/O securely. Almost. There's still the problem of DDNAME contention. Damn! it would be so nice if ATTACH handled alternate DDNAME assignment rather than leaving it to the various utilities. Paul: Its not so much attach its that the utilities expect a certain format of a list and you would break a lot of code if you were to change it this late in the game. Most (if not all) of the utilities are cast in stone. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E GIM69217I
This happens to me all the time. After applying maintenance to SMP/E you've updated the SMPCPATH dataset which has now got out of synch with the rest of SMPE. Quickest resolution is to steplib to the SYS1.MIGLIB that also got updated by the same APPLY. Alan Field Technical Engineer Principal BCBS Minnesota Phone: 651.662.3546 Mobile: 651.428.8826 From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 01/08/2014 18:57 Subject:SMP/E GIM69217I Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Here we go again. We're getting: RECEIVE LIST FROMNTS ... . GIM69217ITHE LEVEL OF PROGRAM GIMJVCLT (36.17) IS NOT COMPATIBLE WITH THE LEVEL OF THE SMP/E CALLING PROGRAM GIMSMP (36.38). Our sysprog has opened an issue with IBM. We have no Java involvement in our payload program. It's my understanding that Java is used only to calculate the SHA-1 checksum during RECEIVE FROMNETWORK if crypto hardware is unavailable (it isn't). Verification of that checksum is mentioned in the Commands manual under FROMNETWORK, not under FROMNTS. We have DDDEF for SMPJHOME, not for SMPCPATH. I don't find GIMJVCLT under the SMPJHOME hierarchy (but I'm not very good at opening jars). What's happening? SYSMSGS says: SMPCPATH SMPCPATH NODDF SMPJHOME SMPJHOME PATH'/usr/lpp/java/J6.0.1/' (my SMPNTS is a symlink. I notice that SYSMSGS identifies the PATHHFS as the filesystem containing the symlink, not the filesystem containing the SMPNTS directory. I wonder it's optimal not to resolve the path?) Thanks, 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: Spawned Address Space Control in tcsh shell
On 1/8/14, 10:20 AM, Paul Gilmartin wrote: On Wed, 8 Jan 2014 11:47:58 -0500, Farley, Peter x23353 wrote: I have always felt that the parent-goes-away-leaving-the-child-running scenario was the *ix substitution for what we can do with XCTL in z/OS systems. Ummm... Not quite. *IX supports the scenario: a) Parent runs for a while, then fork()s child. b) Parent and child run concurrently and cooperatively for a while. c) Parent-goes-away-leaving-the-child-running. XCTL fails to support (b) because the parent goes away instantly. ATTACH fails to support (c) because the child can't outlive the parent. (But why not? Silly design. Perhaps none of the OS/360 designers were orphans, so the concept never occurred to them.) In *IX, if the parent goes away, the grandparent adopts the child. I believe init (pid 1) becomes the parent. It is not uncommon for a process to fork a child process and then the child to fork a grandchild after which the middle process exits leaving the grandchild under the care of init. This relieves the original process from dealing with wait or SIGCHLD at some later time. This was especially common when BSD and SYSVR4 Unix behaved differently in this area. Regards, Henry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 toleration PTFs
Hello, I tried following link suggest in previous email . http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp?topic=%2Fcom.ibm.zos.v2r1.e0zm100%2Fcoxptfs.htm I run missing FIXCAT(IBM.Coexistence.z/OS.V2R1) report Job on z/OS 1.11 and z/OS 1.13, which are part of my current sysplex and z/Os 2.1 system will be adding as new sysplex member in this current sysplex. But, I have few queries 1) Do we really need these Coexistence PTF mentioned in the fixcat report (z/OS 1.11 and z/OS 1.13) to be part of sysplex member with z/OS 2.1 or only below PTF will work for this issue. http://www-01.ibm.com/support/docview.wss?uid=isg1OA36207 Release 770 : UA68603 available 13/04/17 (F304 ) Release 780 : UA68604 available 13/04/17 (F304 ) Release 750 : UA68601 available 13/04/17 (F304 ) Release 760 : UA68602 available 13/04/17 (F304 ) 2) Also when I tried downloading PTF mentioned in (z/OS 1.11 and z/OS 1.13) FIXCAT report from shop zseries, I am failed to order z/OS 1.1 PTF with below Error Order Rejected. *Manufacturing status* Customer BITMAP is being used for this order Not all Ordered PTF(s) were found Please suggest. On Thu, Jan 9, 2014 at 12:34 AM, Lizette Koehler stars...@mindspring.comwrote: I think you need to run a FIXCAT report with a current HOLD DATA information. It seems you need to go to the migration guides and apply all co-existence maintenance for z/OS and any 3rd party vendor. FIXCAT (fix category) information to Enhanced HOLDDATA and the REPORT MISSINGFIX function introduced in z/OS V1R10 SMP/E. For example SET BDY(GLOBAL). REPORT MISSINGFIX ZONES(ZOSR12T) FIXCAT(IBM.Coexistence.z/OS.V2R1). See this url for additional information on installing fixes http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp?topic=%2Fcom.ibm.zos.v2 r1.e0zm100%2Fcoxptfs.htm Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, January 08, 2014 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 toleration PTFs Hello, We recently installed z/OS 2.1 system and now in process of making it sysplex member of currently running SYSPLEX. We have multiple version of z/OS running in this sysplex. But, when I am trying to IPL z/OS 2.1 having sysplex defination, I am getting below error. *IEA002I APAR OA36207 is not installed on TST01. SYSTEM TST02 is being Partitioned .* *IXC220W XCF is unable to continue . Wait State 082 REASON code 000.* This error clearly indicate to install z/OS 2.1 toleration PTFs on low level z/OS system, So that all z/OS with different version can be part of same sysplex. I am following below link for getting PTF number for APAR OA36207 . http://www-01.ibm.com/support/docview.wss?uid=isg1OA36207 But I am not able to find any more document, which can help me getting list of all required toleration PTFs for low level z/OS system to make it work with z/OS 2.1 in this sysplex. -- 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
