Re: Old hardware

d10j...@us.ibm.com (Jim Mulder) writes: > It may depend on which types of risks are being considered. For > example, would you consider it risky to run a stable but unsupported > version of Windows on a machine which is connected to the internet, > since no new security fixes are being provided

Re: Mainframe operating systems?

VP/CSS And you missed one of the OS/360 versions: PCP - only one partition plus spool Lloyd On 4/15/2017 5:27 PM, Phil Smith wrote: Today's random wondering: how many operating systems can folks remember having run on S/360 and descendants? I can think of: OS/360 (including MFT, MVT, MVS,

CAVMEN Meeting May 18, 2017 - FIRST NOTICE

Hello, The second quarter meeting of the Chicago Area VM (and Linux) Enthusiasts will be held on Thursday, May 18, 2017. As we have lost our sponsor, attendees will be on their own for refreshments and lunch. Sorry. Meeting Location: This quarter's meeting will once again be held at the AON

Re: Old hardware

> On Apr 19, 2017, at 9:59 AM, Pommier, Rex wrote: > > Probably quite well. Folks who make this kind of decisions are typically > completely clueless as to what they're doing, unfortunately. Rexx: I worked at one place that was UFB. Their idea of DR was when they got

ICSF -CKDS Question

I have several keys defined in the CKDS. I have been able to rename the keys using program CSFKGUP and refresh the keys using program CSFEUTIL. I would like to make a copy of a key and rename it and store it in the CKDS. EX. Keya.test copy and make Keyb.test. Both keys are now

Re: ISPF edit macro

On Wed, 19 Apr 2017 22:08:01 +0200, R.S. wrote: >No, I don't. Actually I don't know how to do it properly. >My rexx code (taken from RTFM): > >'ISREDIT MACRO (NESTMAC)' >'ISREDIT (DATA1) = DATAID' >'ISREDIT (CURMEM) = MEMBER' >Address ispexec 'LMOPEN DATAID('data1') OPTION(INPUT)' >member = ' '

Re: ISPF edit macro

I have some code that does this. I'll post it later when I get to the office. (It's 6 AM here)... On Thu, Apr 20, 2017 at 5:35 AM, R.S. wrote: > I have an edit macro for issuing another macro against all member is a > given library. > It works OK, but in

Re: ISPF edit macro

No, I don't. Actually I don't know how to do it properly. My rexx code (taken from RTFM): 'ISREDIT MACRO (NESTMAC)' 'ISREDIT (DATA1) = DATAID' 'ISREDIT (CURMEM) = MEMBER' Address ispexec 'LMOPEN DATAID('data1') OPTION(INPUT)' member = ' ' lmrc = 0 Do While lmrc = 0 Address ispexec 'LMMLIST

Re: ISPF edit macro

Check Mark Zelden's web site for EDMACALL. I believe it does what you want. Mike Myers Mentor Services Corporation On 04/19/2017 03:35 PM, R.S. wrote: I have an edit macro for issuing another macro against all member is a given library. It works OK, but in "attended" mode - every change has to

Re: Old hardware

Jim Mulder wrote: % > It may depend on which types of risks are being considered. For example, >would you consider it risky to run a stable but unsupported version of >Windows on a machine which is connected to the internet, since no new >security fixes are being provided for that version?

Re: ISPF edit macro

In the macro that issues the save issue "ISREDIT AUTOSAVE ON" See ISPF Edit and EDIT Macros for full syntax Dennis Roach, CISSP, PMP AIG IAM Platform Administration | Identity & Access Management 2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019 Phone:

Re: ISPF edit macro

do you perform an ISREDIT SAVE ISREDIT END ? Carmen - Original Message - From: "R.S." To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, April 19, 2017 2:35:30 PM Subject: ISPF edit macro I have an edit macro for issuing another macro against all

ISPF edit macro

I have an edit macro for issuing another macro against all member is a given library. It works OK, but in "attended" mode - every change has to be confirmed by issuing PF3 (or PF12 if you don't want changes in a given member). I'm looking for something more automated - a macro, which issues

Re: SYS1.BRODCAST

I see you have gotten many answers on this. If you use USER LOG Datasets (as specified in IKJTSOxx, or use PARMLIB command in ISPF) then the NOTIFY goes to the USER LOG dataset. Then only SEND messages go to SYS1.BRODCAST and retrieved with LISTBC command. If you do not user USER LOG

Re: SYS1.BRODCAST

I haven't looked anything up and it may have changed since the dark ages. However, BRODCAST (and presumably the "user" equivalents) is updated by the SEND command. I don't think you want UACC of UPDATE because then any old user would be able to update it and possibly destroy its format in

Re: SYS1.BRODCAST

It's all about user broadcast. It that's in use, all user-directed messages go there instead of SYS1.BRODCAST. Hence UACC(UPDATE) is not appropriate. Our SYS1.BRODCAST contains only 'broadcast' messages that all users see at logon or in response to LISTBC; nothing personal. We actually run with

Re: SYS1.BRODCAST

What if people code their jobs with the NOTIFY parameter? Doesn't that update SYS1.BRODCAST? If so, then it wouldn't be able to update it. Or does that authority come from somewhere else? -- For IBM-MAIN subscribe / signoff

Re: COBOL integrated pre-processor, API in general

On Wed, Apr 19, 2017 at 12:52 PM, Frank Swarbrick < frank.swarbr...@outlook.com> wrote: > I give permission for anyone to use that COBOL input-exit however they > like. > I did ask my manager's, manager's manager (!!) if it was OK to post > non-business related COBOL code I developed at work to

Re: SYS1.BRODCAST

It depends on whether or not you are using user broadcast datasets. If user broadcast datasets are in use, this is not a reasonable level of access. IF user broadcast datasets are not in use, this is a perfectly reasonable level of accsss. Check the TSO manuals for details on user brodcast

Re: SYS1.BRODCAST

Actually it is READ. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icha700/sdslc.htm On Wed, Apr 19, 2017 at 8:54 PM gsg < 0053fe88ed35-dmarc-requ...@listserv.ua.edu> wrote: > Does SYS1.BRODCAST need to have UACC of UPDATE? If so, is it actually > stated

SYS1.BRODCAST

Does SYS1.BRODCAST need to have UACC of UPDATE? If so, is it actually stated somewhere? Been trying to find information on this. TIA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: COBOL integrated pre-processor, API in general

I give permission for anyone to use that COBOL input-exit however they like. I did ask my manager's, manager's manager (!!) if it was OK to post non-business related COBOL code I developed at work to github and the like and he said it was fine. Did not go as far as discussing a LICENSE to use,

Re: Old hardware

It may depend on which types of risks are being considered. For example, would you consider it risky to run a stable but unsupported version of Windows on a machine which is connected to the internet, since no new security fixes are being provided for that version? Jim Mulder z/OS

Re: Old hardware

kees.verno...@klm.com (Vernooij, Kees - KLM , ITOPT1) writes: > It sounds like when I started my job, with SVS on 370/158-168 > machines. When during IBM courses the teacher asked what we systems we > were using and I said we also had 2 360/65's running, everybody turned > to see where I came

Re: Old hardware

[Default] On 19 Apr 2017 07:19:57 -0700, in bit.listserv.ibm-main kees.verno...@klm.com (Vernooij, Kees - KLM , ITOPT1) wrote: > > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of David Crayford >> Sent: 19 April, 2017 15:51

Re: Old hardware

You make a very good point that if everything is stable and hasn't been changed in years then there seems to be little risk. But when at outlier occurs you're in trouble! On 19/04/2017 11:08 PM, Blaicher, Christopher Y. wrote: Back when S banks were getting into NOW accounts, what we know as

Re: Old hardware

Back when S banks were getting into NOW accounts, what we know as checking accounts, I was hired to be the manager of systems programming. They were running unsupported versions of the operating system, CICS, BTAM and everything else. They had a 99.9% up-time and every one slept well, all

Re: Old hardware

Probably quite well. Folks who make this kind of decisions are typically completely clueless as to what they're doing, unfortunately. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Wednesday, April 19, 2017

Re: RACF TEMPDSN improvement with the zOS 1.13

>You have gotten excellent replies from Robert and Dan. You can sure use these >resources as proof of that change. Also see http://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__April_2012.pdf Happy reading! Groete / Greetings Elardus Engelbrecht

Re: Old hardware

How do your management sleep at night with an unsupported software? On 19/04/2017 8:58 PM, John McKown wrote: That is interesting to know. But, unless the situation changes (IMO "for the better"), then we are stuck on our current configuration FOREVER. Upper management utterly hates, despises,

Re: Old hardware

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of David Crayford > Sent: 19 April, 2017 15:51 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Old hardware > > On 19/04/2017 1:58 PM, Timothy Sipples wrote: > > We have a customer in

Re: RACF TEMPDSN improvement with the zOS 1.13

Rogério Camargo wrote: >Thanks for your reply. You're most welcome. >... but again, I could not identified any piece of information about the >TEMPDSN improvements came with the zOS V1R13. You have gotten excellent replies from Robert and Dan. You can sure use these resources as proof of

Re: Old hardware

Timothy Sipples wrote: >We have a customer in my general part of the world that is, as I write >this, moving from an IBM mainframe they installed in early 1999 (with ~1998 >software releases) to a shiny new IBM z System machine. They have "only" >about 19 years (and counting) of new features and

Re: Old hardware

On 19/04/2017 1:58 PM, Timothy Sipples wrote: We have a customer in my general part of the world that is, as I write this, moving from an IBM mainframe they installed in early 1999 (with ~1998 software releases) to a shiny new IBM z System machine. They have "only" about 19 years (and counting)

Re: RACF TEMPDSN improvement with the zOS 1.13

Dan, I really appreciate that you're right such doc shows that and implies the 1.13 had that change. Tks a lot!! From: IBM Mainframe Discussion List on behalf of Dan Little Sent: Wednesday, April 19,

Re: RACF TEMPDSN improvement with the zOS 1.13

Bob, Thanks so much I noticed now such difference. Have a great day! From: IBM Mainframe Discussion List on behalf of Robert S. Hansel (RSH) Sent: Wednesday, April 19, 2017 6:56 AM To:

Re: Old hardware

That is interesting to know. But, unless the situation changes (IMO "for the better"), then we are stuck on our current configuration FOREVER. Upper management utterly hates, despises, abhors, and denigrates the existence of z/OS. They truly seem to be "all Windows, all the time!". I firmly

Re: RACF TEMPDSN improvement with the zOS 1.13

It's not really described as an improvement anywhere for z/OS 1.13 but the documentation at https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icha700/tempdsn.htm does reference sharing disk with V1.12 or earlier which kind of implies that V1.13 had the change. Dan

Re: RACF TEMPDSN improvement with the zOS 1.13

Hey Elardus, good morning! Thanks for your reply. And yes, I've being searched these manuals (zOS 1.13 Migration Guide and also I tried the "z/Architecture Principles of Operation " but again, I could not identified any piece of information about the TEMPDSN improvements came with the zOS

Re: RACF TEMPDSN improvement with the zOS 1.13

HI Roger, Beginning with z/OS 1.13, the activation of TEMPDSN no longer interferes with currently running processes, and it is safe to activate TEMPDSN without waiting for an IPL. If you compare the description of TEMPDSN in the 1.12 version of the RACF Security Administrator's Guide with its

Re: Paging subsystems in the era of big&^% memory

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mike Schwab > Sent: 18 April, 2017 17:52 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Paging subsystems in the era of big&^% memory > > For every byte of real memory, you need 1