Re: the Queen of Coding - Adm. Grace Hoper
I always thought it was a relay. -teD Original Message From: Ed Finnell Sent: Monday, January 25, 2016 01:17 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: the Queen of Coding - Adm. Grace Hoper Chicken fried moth between the vacuum tubes. In a message dated 1/24/2016 11:43:56 P.M. Central Standard Time, charl...@mcn.org writes: Nope. -- 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: the Queen of Coding - Adm. Grace Hoper
Chicken fried moth between the vacuum tubes. In a message dated 1/24/2016 11:43:56 P.M. Central Standard Time, charl...@mcn.org writes: Nope. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: the Queen of Coding - Adm. Grace Hoper
Lizette Koehler wrote: Yes ESPN website Video is for Women in Computing in 1940s and specifically the Queen of Coding Adm. Grace Hoper. http://espn.go.com/video/clip?id=12205119 Very sweet albeit distant gaze backwards through the glass darkly. -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: the Queen of Coding - Adm. Grace Hoper
Nope. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert A. Rosenberg Sent: Sunday, January 24, 2016 8:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: the Queen of Coding - Adm. Grace Hoper At 17:53 -0700 on 01/24/2016, Lizette Koehler wrote about the Queen of Coding - Adm. Grace Hoper: >Yes ESPN website Video is for Women in Computing in 1940¹s and >specifically the Queen of Coding Adm. Grace Hoper. > >http://espn.go.com/video/clip?id=12205119 > > > >16 1Ž2 minutes. Very interesting history of computers. Did they mention that she was the origin of the term "Computer Bug" as well as describing the first one (ie: The actual insect found in the computer)? MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: the Queen of Coding - Adm. Grace Hoper
At 21:01 -0600 on 01/24/2016, Joel C. Ewing wrote about Re: the Queen of Coding - Adm. Grace Hoper: I can't remember the exact way she worded it, but the other memorable bit of wisdom was that she had successfully managed to accomplish so much, despite government and military proclivity for red tape and inertia, by learning that when something new needed to be done it was much more effective (especially as a women in a male environment) to just do it and apologize later for her "oversight" of not getting prior permission, rather than make a vain attempt to ask for permission in advance. IOW: It is better to ask for forgiveness than permission. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: the Queen of Coding - Adm. Grace Hoper
At 17:53 -0700 on 01/24/2016, Lizette Koehler wrote about the Queen of Coding - Adm. Grace Hoper: Yes ESPN website Video is for Women in Computing in 1940¹s and specifically the Queen of Coding Adm. Grace Hoper. http://espn.go.com/video/clip?id=12205119 16 12 minutes. Very interesting history of computers. Did they mention that she was the origin of the term "Computer Bug" as well as describing the first one (ie: The actual insect found in the computer)? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: the Queen of Coding - Adm. Grace Hoper
On 01/24/2016 06:53 PM, Lizette Koehler wrote: > > > Yes – ESPN website – Video is for Women in Computing in 1940’s and > specifically > the Queen of Coding – Adm. Grace Hoper. > > http://espn.go.com/video/clip?id=12205119 > > > > 16 ½ minutes. Very interesting history of computers. > > > > Lizette Koehler > > statistics: A precise and logical method for stating a half-truth inaccurately > > While a grad student at Purdue in 1971, I saw Admiral Hopper speak at ACM'71 (in Chicago, I think). I believe ACM'71 was the occasion of the first annual ACM Grace Hopper Award (to Donald E. Knuth). I can't remember whether she was a keynote speaker or just spoke at the presentation of the award, but neither of the two things about her talk that made the most lasting impression made it into the recent video: One was that she was noted in those days for carrying with her "nanoseconds" and at least one "microsecond" to illustrate the length of wire an electrical impulse could traverse in that amount of time. She had several nanoseconds with her (just under 1 ft in length) and handed out a few to the audience, to illustrate that although the common perception was that electrical signals were instantaneous that physical size became a significant impediment as processor clock speeds approached nanosecond values. I can't remember the exact way she worded it, but the other memorable bit of wisdom was that she had successfully managed to accomplish so much, despite government and military proclivity for red tape and inertia, by learning that when something new needed to be done it was much more effective (especially as a women in a male environment) to just do it and apologize later for her "oversight" of not getting prior permission, rather than make a vain attempt to ask for permission in advance. -- 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
the Queen of Coding - Adm. Grace Hoper
Yes ESPN website Video is for Women in Computing in 1940s and specifically the Queen of Coding Adm. Grace Hoper. http://espn.go.com/video/clip?id=12205119 16 ½ minutes. Very interesting history of computers. Lizette Koehler statistics: A precise and logical method for stating a half-truth inaccurately -- 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.2 3270 OMVS ssh masks passwords!
Mark Post wrote: Probably the same way the Linux 3270 console driver does it. It knows enough to set the attribute byte for the field to be non-display. Attended an IBM official SNA course in Phoenix in April, 1998 with a retired-and-back-to-consult IBM'er. He pointed out, "When you enter a password on a 3270 terminal, the only one who can't see it is you." Of course, nowadays the terminal is probably X3270 over an SSH tunnel. -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Man Versus System
Guys, Great articles, I learned BAL on a BPS360/20... Brings back a lot of memories.. Scott On Friday, January 22, 2016, Ed Finnell < 000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: > Not nearly as unhappy as the Ops Mgr that found out they had replied "u" > all 1000 times. > > > In a message dated 1/22/2016 3:51:48 P.M. Central Standard Time, > li...@akphs.com writes: > > MVS and TPF were quite unhappy about it. > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: > INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.2 3270 OMVS ssh masks passwords!
>>> On 1/23/2016 at 01:54 PM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > Data point: Under 3270 OMVS, the "su" command properly masks the password. > I wonder how it does that? Probably the same way the Linux 3270 console driver does it. It knows enough to set the attribute byte for the field to be non-display. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ShopZ
Thanks Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Sunday, January 24, 2016 12:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ShopZ A quick search internet search came up with this. See if it can help from the IBM web site User guide, tutorials, etc. http://www-304.ibm.com/software/shopzseries/ShopzSeries_public.wss Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Steve Beaver > Sent: Sunday, January 24, 2016 1:56 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: ShopZ > > Is anyone aware of a document that teaches/describes the how to use > ShopZ that I can give to someone that has Never done SHopZ. > > Steve > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ShopZ
A quick search internet search came up with this. See if it can help from the IBM web site User guide, tutorials, etc. http://www-304.ibm.com/software/shopzseries/ShopzSeries_public.wss Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Steve Beaver > Sent: Sunday, January 24, 2016 1:56 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: ShopZ > > Is anyone aware of a document that teaches/describes the how to use ShopZ that > I can give to someone that has Never done SHopZ. > > Steve > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ShopZ
Is anyone aware of a document that teaches/describes the how to use ShopZ that I can give to someone that has Never done SHopZ. Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MVS operator command issue
ITchalk, Yes sir On Sunday, January 24, 2016, Scott Ford wrote: > Rob, > > Great ! Ty sir > > Scott > > On Sunday, January 24, 2016, Rob Schramm > wrote: > >> Or write an auth routine to flip the non cancel bit off. >> >> Change the code and add the Stop command as the proper way to shut it >> down. Example on planetmvs >> >> On Sun, Jan 24, 2016, 3:38 PM Rob Schramm wrote: >> >> > Restrict access to cancel the task and use automation to do the >> commands. >> > >> > On Sun, Jan 24, 2016, 3:36 PM Itschak Mugzach >> wrote: >> > >> >> I think the intent was to protect from cancel by mistake. I believe >> that >> >> cancel is the way they stop the stc as well. This is why i proposed to >> >> have >> >> a special record read from storage to stop the stc. >> >> >> >> Best, >> >> ITschak >> >> >> >> ITschak Mugzach >> >> Z/OS, ISV Products and Application Security & Risk Assessments >> >> Professional >> >> >> >> On Sun, Jan 24, 2016 at 10:32 PM, Rob Schramm >> >> wrote: >> >> >> >> > Marking it non cancellable will prevent the normal cancel. But will >> not >> >> > stop the force arm. >> >> > >> >> > On Sun, Jan 24, 2016, 3:26 PM Andy Wood >> wrote: >> >> > >> >> > > On Sun, 24 Jan 2016 11:55:16 -0800, Charles Mills < >> charl...@mcn.org> >> >> > > wrote: >> >> > > >> >> > > >It can be done but it is not easy. You don't actually need the >> front >> >> end >> >> > > (I think -- more familiar with C than COBOL). But it is not >> >> "supported." >> >> > > S122's are "unrecoverable." >> >> > > > >> >> > > >> >> > > I have no idea about either C or Cobol, but you can "intercept" x22 >> >> > abends >> >> > > using TERM=YES on ESTAE - the ESTAE routine gets control but is not >> >> > allowed >> >> > > to retry. >> >> > > >> >> > > Since SP231 is being used, the code is presumably running >> authorised >> >> and >> >> > > could thus also make use of RESMGR to handle task and also address >> >> space >> >> > > termination. >> >> > > >> >> > > >> -- >> >> > > For IBM-MAIN subscribe / signoff / archive access instructions, >> >> > > send email to lists...@listserv.ua.edu with the message: INFO >> >> IBM-MAIN >> >> > > >> >> > -- >> >> > >> >> > Rob Schramm >> >> > The Art of Mainframe, Inc >> >> > >> >> > >> -- >> >> > 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 >> >> >> > -- >> > >> > Rob Schramm >> > The Art of Mainframe, Inc >> > >> -- >> >> Rob Schramm >> The Art of Mainframe, Inc >> >> -- >> 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: Lineage of TPF
000248cce9f3-dmarc-requ...@listserv.ua.edu (Ed Finnell) writes: > As Lynn mentioned there were hardware mods for ACP/TPF to the 3081, 3083 > and 3090's. They were given new numbers 9081,9083 and of course 9190? I guess > shorter path lengths and such but couldn't find any details after a short > search. besides the 3830 disk controller RPQ ... the 3083 was 3081 with one of the processors removed (at the time, acp/tpf didn't have tightly-coupled multiprocessor support) that still wasn't competitive ... so there was 3083 with specialized channel microcode operation tailored to ACP/TPF operation. I'm not familiar something similar for 3090. as mentioned 3081 technology wasn't competitive with clones: http://www.jfsowa.com/computer/memo125.htm initial 3081D per processor throughput was suppose to be faster than 3033 ... but many benchmarks have it about 20% slower. 3081K doubled the cache and per processor was suppose to improve to 50% faster than 3033 ... but many benchmarks were same as 3033. IBM 2-way multiprocessor technology from the period slowed the processor clock down by 10% to handle cross-cache activity. Going from 3081K to 3083K increased processor clock by nearly 15% (no multiprocessor clock slow-down) ... 3083 mostly done because all ACP/TPF customers might migrate to clone makers (since ACP/TPF didn't have multiprocessor support). Faster clock and tweaks for 3083jx got it up to 16% faster than 3081K (or supposedly almost 80% faster than 3033). 9083 had different I/O microcode load to bias for the typical higher channel i/o loads by ACP/TPF. It is possible that they may have done something similar for 3090, but I don't recollect any details. -- 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: MVS operator command issue
Rob, Great ! Ty sir Scott On Sunday, January 24, 2016, Rob Schramm wrote: > Or write an auth routine to flip the non cancel bit off. > > Change the code and add the Stop command as the proper way to shut it > down. Example on planetmvs > > On Sun, Jan 24, 2016, 3:38 PM Rob Schramm > wrote: > > > Restrict access to cancel the task and use automation to do the > commands. > > > > On Sun, Jan 24, 2016, 3:36 PM Itschak Mugzach > wrote: > > > >> I think the intent was to protect from cancel by mistake. I believe that > >> cancel is the way they stop the stc as well. This is why i proposed to > >> have > >> a special record read from storage to stop the stc. > >> > >> Best, > >> ITschak > >> > >> ITschak Mugzach > >> Z/OS, ISV Products and Application Security & Risk Assessments > >> Professional > >> > >> On Sun, Jan 24, 2016 at 10:32 PM, Rob Schramm > > >> wrote: > >> > >> > Marking it non cancellable will prevent the normal cancel. But will > not > >> > stop the force arm. > >> > > >> > On Sun, Jan 24, 2016, 3:26 PM Andy Wood > wrote: > >> > > >> > > On Sun, 24 Jan 2016 11:55:16 -0800, Charles Mills > > >> > > wrote: > >> > > > >> > > >It can be done but it is not easy. You don't actually need the > front > >> end > >> > > (I think -- more familiar with C than COBOL). But it is not > >> "supported." > >> > > S122's are "unrecoverable." > >> > > > > >> > > > >> > > I have no idea about either C or Cobol, but you can "intercept" x22 > >> > abends > >> > > using TERM=YES on ESTAE - the ESTAE routine gets control but is not > >> > allowed > >> > > to retry. > >> > > > >> > > Since SP231 is being used, the code is presumably running authorised > >> and > >> > > could thus also make use of RESMGR to handle task and also address > >> space > >> > > termination. > >> > > > >> > > > -- > >> > > For IBM-MAIN subscribe / signoff / archive access instructions, > >> > > send email to lists...@listserv.ua.edu with the > message: INFO > >> IBM-MAIN > >> > > > >> > -- > >> > > >> > Rob Schramm > >> > The Art of Mainframe, Inc > >> > > >> > -- > >> > 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 > >> > > -- > > > > Rob Schramm > > The Art of Mainframe, Inc > > > -- > > Rob Schramm > The Art of Mainframe, Inc > > -- > 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: MVS operator command issue
It is my understanding that the main program is Cobol... ITschak ITschak Mugzach Z/OS, ISV Products and Application Security & Risk Assessments Professional On Sun, Jan 24, 2016 at 10:42 PM, Rob Schramm wrote: > Or write an auth routine to flip the non cancel bit off. > > Change the code and add the Stop command as the proper way to shut it > down. Example on planetmvs > > On Sun, Jan 24, 2016, 3:38 PM Rob Schramm wrote: > > > Restrict access to cancel the task and use automation to do the > commands. > > > > On Sun, Jan 24, 2016, 3:36 PM Itschak Mugzach > wrote: > > > >> I think the intent was to protect from cancel by mistake. I believe that > >> cancel is the way they stop the stc as well. This is why i proposed to > >> have > >> a special record read from storage to stop the stc. > >> > >> Best, > >> ITschak > >> > >> ITschak Mugzach > >> Z/OS, ISV Products and Application Security & Risk Assessments > >> Professional > >> > >> On Sun, Jan 24, 2016 at 10:32 PM, Rob Schramm > >> wrote: > >> > >> > Marking it non cancellable will prevent the normal cancel. But will > not > >> > stop the force arm. > >> > > >> > On Sun, Jan 24, 2016, 3:26 PM Andy Wood > wrote: > >> > > >> > > On Sun, 24 Jan 2016 11:55:16 -0800, Charles Mills > > >> > > wrote: > >> > > > >> > > >It can be done but it is not easy. You don't actually need the > front > >> end > >> > > (I think -- more familiar with C than COBOL). But it is not > >> "supported." > >> > > S122's are "unrecoverable." > >> > > > > >> > > > >> > > I have no idea about either C or Cobol, but you can "intercept" x22 > >> > abends > >> > > using TERM=YES on ESTAE - the ESTAE routine gets control but is not > >> > allowed > >> > > to retry. > >> > > > >> > > Since SP231 is being used, the code is presumably running authorised > >> and > >> > > could thus also make use of RESMGR to handle task and also address > >> space > >> > > termination. > >> > > > >> > > > -- > >> > > For IBM-MAIN subscribe / signoff / archive access instructions, > >> > > send email to lists...@listserv.ua.edu with the message: INFO > >> IBM-MAIN > >> > > > >> > -- > >> > > >> > Rob Schramm > >> > The Art of Mainframe, Inc > >> > > >> > -- > >> > 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 > >> > > -- > > > > Rob Schramm > > The Art of Mainframe, Inc > > > -- > > Rob Schramm > The Art of Mainframe, Inc > > -- > 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: MVS operator command issue
Or write an auth routine to flip the non cancel bit off. Change the code and add the Stop command as the proper way to shut it down. Example on planetmvs On Sun, Jan 24, 2016, 3:38 PM Rob Schramm wrote: > Restrict access to cancel the task and use automation to do the commands. > > On Sun, Jan 24, 2016, 3:36 PM Itschak Mugzach wrote: > >> I think the intent was to protect from cancel by mistake. I believe that >> cancel is the way they stop the stc as well. This is why i proposed to >> have >> a special record read from storage to stop the stc. >> >> Best, >> ITschak >> >> ITschak Mugzach >> Z/OS, ISV Products and Application Security & Risk Assessments >> Professional >> >> On Sun, Jan 24, 2016 at 10:32 PM, Rob Schramm >> wrote: >> >> > Marking it non cancellable will prevent the normal cancel. But will not >> > stop the force arm. >> > >> > On Sun, Jan 24, 2016, 3:26 PM Andy Wood wrote: >> > >> > > On Sun, 24 Jan 2016 11:55:16 -0800, Charles Mills >> > > wrote: >> > > >> > > >It can be done but it is not easy. You don't actually need the front >> end >> > > (I think -- more familiar with C than COBOL). But it is not >> "supported." >> > > S122's are "unrecoverable." >> > > > >> > > >> > > I have no idea about either C or Cobol, but you can "intercept" x22 >> > abends >> > > using TERM=YES on ESTAE - the ESTAE routine gets control but is not >> > allowed >> > > to retry. >> > > >> > > Since SP231 is being used, the code is presumably running authorised >> and >> > > could thus also make use of RESMGR to handle task and also address >> space >> > > termination. >> > > >> > > -- >> > > For IBM-MAIN subscribe / signoff / archive access instructions, >> > > send email to lists...@listserv.ua.edu with the message: INFO >> IBM-MAIN >> > > >> > -- >> > >> > Rob Schramm >> > The Art of Mainframe, Inc >> > >> > -- >> > 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 >> > -- > > Rob Schramm > The Art of Mainframe, Inc > -- Rob Schramm The Art of Mainframe, Inc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MVS operator command issue
ITschak yes and I don't want to loose the secondary index, I thought if I intercepted the S222 then I could save the secondary index to disk and then come down normally, I am not sure this is why I posted the question.. Scott On Sunday, January 24, 2016, Itschak Mugzach wrote: > I think the intent was to protect from cancel by mistake. I believe that > cancel is the way they stop the stc as well. This is why i proposed to have > a special record read from storage to stop the stc. > > Best, > ITschak > > ITschak Mugzach > Z/OS, ISV Products and Application Security & Risk Assessments Professional > > On Sun, Jan 24, 2016 at 10:32 PM, Rob Schramm > wrote: > > > Marking it non cancellable will prevent the normal cancel. But will not > > stop the force arm. > > > > On Sun, Jan 24, 2016, 3:26 PM Andy Wood > wrote: > > > > > On Sun, 24 Jan 2016 11:55:16 -0800, Charles Mills > > > > wrote: > > > > > > >It can be done but it is not easy. You don't actually need the front > end > > > (I think -- more familiar with C than COBOL). But it is not > "supported." > > > S122's are "unrecoverable." > > > > > > > > > > I have no idea about either C or Cobol, but you can "intercept" x22 > > abends > > > using TERM=YES on ESTAE - the ESTAE routine gets control but is not > > allowed > > > to retry. > > > > > > Since SP231 is being used, the code is presumably running authorised > and > > > could thus also make use of RESMGR to handle task and also address > space > > > termination. > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the > message: INFO IBM-MAIN > > > > > -- > > > > Rob Schramm > > The Art of Mainframe, Inc > > > > -- > > 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: MVS operator command issue
Restrict access to cancel the task and use automation to do the commands. On Sun, Jan 24, 2016, 3:36 PM Itschak Mugzach wrote: > I think the intent was to protect from cancel by mistake. I believe that > cancel is the way they stop the stc as well. This is why i proposed to have > a special record read from storage to stop the stc. > > Best, > ITschak > > ITschak Mugzach > Z/OS, ISV Products and Application Security & Risk Assessments Professional > > On Sun, Jan 24, 2016 at 10:32 PM, Rob Schramm > wrote: > > > Marking it non cancellable will prevent the normal cancel. But will not > > stop the force arm. > > > > On Sun, Jan 24, 2016, 3:26 PM Andy Wood wrote: > > > > > On Sun, 24 Jan 2016 11:55:16 -0800, Charles Mills > > > wrote: > > > > > > >It can be done but it is not easy. You don't actually need the front > end > > > (I think -- more familiar with C than COBOL). But it is not > "supported." > > > S122's are "unrecoverable." > > > > > > > > > > I have no idea about either C or Cobol, but you can "intercept" x22 > > abends > > > using TERM=YES on ESTAE - the ESTAE routine gets control but is not > > allowed > > > to retry. > > > > > > Since SP231 is being used, the code is presumably running authorised > and > > > could thus also make use of RESMGR to handle task and also address > space > > > termination. > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > > > > Rob Schramm > > The Art of Mainframe, Inc > > > > -- > > 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 > -- Rob Schramm The Art of Mainframe, Inc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MVS operator command issue
I think the intent was to protect from cancel by mistake. I believe that cancel is the way they stop the stc as well. This is why i proposed to have a special record read from storage to stop the stc. Best, ITschak ITschak Mugzach Z/OS, ISV Products and Application Security & Risk Assessments Professional On Sun, Jan 24, 2016 at 10:32 PM, Rob Schramm wrote: > Marking it non cancellable will prevent the normal cancel. But will not > stop the force arm. > > On Sun, Jan 24, 2016, 3:26 PM Andy Wood wrote: > > > On Sun, 24 Jan 2016 11:55:16 -0800, Charles Mills > > wrote: > > > > >It can be done but it is not easy. You don't actually need the front end > > (I think -- more familiar with C than COBOL). But it is not "supported." > > S122's are "unrecoverable." > > > > > > > I have no idea about either C or Cobol, but you can "intercept" x22 > abends > > using TERM=YES on ESTAE - the ESTAE routine gets control but is not > allowed > > to retry. > > > > Since SP231 is being used, the code is presumably running authorised and > > could thus also make use of RESMGR to handle task and also address space > > termination. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > > Rob Schramm > The Art of Mainframe, Inc > > -- > 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: MVS operator command issue
Marking it non cancellable will prevent the normal cancel. But will not stop the force arm. On Sun, Jan 24, 2016, 3:26 PM Andy Wood wrote: > On Sun, 24 Jan 2016 11:55:16 -0800, Charles Mills > wrote: > > >It can be done but it is not easy. You don't actually need the front end > (I think -- more familiar with C than COBOL). But it is not "supported." > S122's are "unrecoverable." > > > > I have no idea about either C or Cobol, but you can "intercept" x22 abends > using TERM=YES on ESTAE - the ESTAE routine gets control but is not allowed > to retry. > > Since SP231 is being used, the code is presumably running authorised and > could thus also make use of RESMGR to handle task and also address space > termination. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm The Art of Mainframe, Inc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MVS operator command issue
On Sun, 24 Jan 2016 11:55:16 -0800, Charles Mills wrote: >It can be done but it is not easy. You don't actually need the front end (I >think -- more familiar with C than COBOL). But it is not "supported." S122's >are "unrecoverable." > I have no idea about either C or Cobol, but you can "intercept" x22 abends using TERM=YES on ESTAE - the ESTAE routine gets control but is not allowed to retry. Since SP231 is being used, the code is presumably running authorised and could thus also make use of RESMGR to handle task and also address space termination. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lineage of TPF
As Lynn mentioned there were hardware mods for ACP/TPF to the 3081, 3083 and 3090's. They were given new numbers 9081,9083 and of course 9190? I guess shorter path lengths and such but couldn't find any details after a short search. https://en.wikipedia.org/wiki/List_of_IBM_products In a message dated 1/24/2016 12:36:42 P.M. Central Standard Time, li...@akphs.com writes: Um. No? Yes? Maybe? Are you saying that it has a different lineage when run under z/VM? Then "No". That certain operational characteristics will vary? Sure. But seriously-what's your point? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MVS operator command issue
It can be done but it is not easy. You don't actually need the front end (I think -- more familiar with C than COBOL). But it is not "supported." S122's are "unrecoverable." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Sunday, January 24, 2016 11:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: MVS operator command issue All: I have a scenario i would like to explain ... 1. Cobol STC , uses assembler module to read records that are placed in SP 231. The data is persistent. This data is read into a secondary index for dup checking. My issue is if someone issues a 'C stcname' the the customer can loose data. My questions is if I code something like this: Assembler -- CEEPIPI with a ESTAE ...Assembler calls the cobol routines Can I intercept the S222 abend and save data ..? Regards, Scott -- 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: MVS operator command issue
Not Sure if this will work, but try adding the main program to PPT (schedxx in parmlib) with NOCANCEL attribute. I wonder what will make the stc shutdown, may be a record read from SP231 (stop run, may be)? Best, ITschak ITschak Mugzach Z/OS, ISV Products and Application Security & Risk Assessments Professional On Sun, Jan 24, 2016 at 9:07 PM, Scott Ford wrote: > All: > > I have a scenario i would like to explain ... > > 1. Cobol STC , uses assembler module to read records that are placed in SP > 231. The data is persistent. > This data is read into a secondary index for dup checking. > > My issue is if someone issues a 'C stcname' the the customer can loose > data. My questions is if I code something like this: > > Assembler -- CEEPIPI with a ESTAE > ...Assembler calls the cobol routines > > Can I intercept the S222 abend and save data ..? > > Regards, > Scott > > -- > 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
MVS operator command issue
All: I have a scenario i would like to explain ... 1. Cobol STC , uses assembler module to read records that are placed in SP 231. The data is persistent. This data is read into a secondary index for dup checking. My issue is if someone issues a 'C stcname' the the customer can loose data. My questions is if I code something like this: Assembler -- CEEPIPI with a ESTAE ...Assembler calls the cobol routines Can I intercept the S222 abend and save data ..? Regards, Scott -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lineage of TPF
Gregg wrote: >ACP/TPF/zTPF on silicon/in LPar is one thing, as a guest on VM (test) is >something other. No? Um. No? Yes? Maybe? Are you saying that it has a different lineage when run under z/VM? Then "No". That certain operational characteristics will vary? Sure. But seriously-what's your point? .phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
