Re: Red Alert Test Email

2023-05-24 Thread Beverly Caldwell
Yes I got one.

On Wed, May 24, 2023, 5:07 PM Mark Jacobs <
0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> Did anyone else get one today? There's nothing new on the actual red alert
> landing page.
>
> Mark Jacobs
>
> Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted
> email.
>
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: [EXTERNAL] Re: zOSMF

2023-05-24 Thread Beverly Caldwell
If zosmf is the answer what the hell was the question?

On Wed, May 24, 2023, 12:16 PM Colin Paice  wrote:

> For one IBM PP, they had a zosmf process for customising. It made the
> trivial bits easier, and ignored the hard bits eg  setting up SMS and RACF
> definitions. Once configured I could not see how to change the
> configuration. For setting up second instance you had to start from the
> beginning.
>
> If z/osmf is the answer perhaps the configuration could have
> novice/intermediate/ expert. For novice it should hide standard defaults
> and show what you MUST configure. For expert it shows all options. Help
> displays novice
> / Intermediate / expert levels as well
> Colin
>
> On Wed, May 24, 2023, 18:52 Shaffer, Terri <
> 017d5f778222-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Completely agree with the overhead and complicatedness!
> >
> > You know what's sad, is when I started in mainframes 39 years ago, The
> old
> > IBM SE sat with me gave me the basics, etc and said go for it on a test
> > system. And you learned actually what each process did.  I have seen even
> > today system programmers that are clueless, all they were told was follow
> > steps 1 thru 10, and if it fails in step x, they have no clue what to do.
> > This is the problem with z/OSMF and especially the new software instance
> > install BS, its trying to make it idiot proof, but everyones SMS,
> volumes,
> > catalogs, etc are all different and it doesn't work, or not easily.
> >
> > Us old timers, are the only ones that really understand z/OS, could build
> > a system from scratch, understand NIP, NET, JES2 and how everything works
> > together.  I have worked at 7 different companies in my 39 years and
> > maintenance was pretty much always done the same way.  Build the jobs
> once,
> > change Volsers, zones, etc and submit.
> >
> > No GUI clicky BS, processor intensive, certificate ridden process, that's
> > removed from the actual LPAR.  And when z/OSMF doesn't work, then deer in
> > headlights start to occur!
> >
> > Ms Terri E Shaffer
> > Senior Systems Engineer,
> > z/OS Support:
> > ACIWorldwide - Telecommuter
> > H(412-766-2697) C(412-519-2592)
> > terri.shaf...@aciworldwide.com
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Pommier, Rex
> > Sent: Tuesday, March 7, 2023 10:53 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [EXTERNAL] Re: zOSMF
> >
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know
> the
> > content is safe.
> >
> >
> > Hi Rob and Terri,
> >
> > I'll weigh in here from the opposite end of the spectrum.  From my POV,
> > z/OSMF is nothing but overhead for us.  We have a very small system.  2
> > LPARs, no sysplex, nothing difficult about it.  We build a new OS on one
> of
> > them and clone it to the other and we're done.  All z/OSMF is going to do
> > for us is add complexity to a simple system.  And I agree with Terri and
> > Barbara that the next gen of sysprog won't have a clue where to go
> looking
> > when z/OSMF breaks.
> >
> > Rex
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Rob Schramm
> > Sent: Monday, March 6, 2023 9:18 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] Re: zOSMF
> >
> > See you are missing the point.
> >
> > If you have 117 lpars, of course you going to work on making the process
> > actually work.  Because every minute you save in that process is worth 2
> > hours. The point is is that for each institution that's done that
> there's a
> > bunch that haven't or they've got some jammed together process that
> breaks
> > every single time that somebody new touches it.  And it's not
> standardized
> > then it's not maintained and it's poorly documented and it's... you
> know...
> > ad infinitum ad nauseam.  So for you ... I agree it's probably more of a
> > pain in the neck.  And there will probably be some sort of compromise
> > eventually.  But for all the people that have these other processes, I
> > think the standardization that is going to come from this will ultimately
> > make this a lot easier. And the dealing with the myriad of ISP software
> and
> > IBM non server pack software or stuff that could be on the server pack
> but
> > doesn't actually belong there... This should help immeasurably so once
> > again I will disagree with your disagreement.
> >
> > Rob
> >
> > On Mon, Mar 6, 2023, 20:12 Shaffer, Terri <
> > 017d5f778222-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > When I worked at Chase bank, We had 117 LPARS and maintenance/clone
> > > was a
> > > 30 minute task. So adding z/OSMF was never even brought up as a
> > > consideration.
> > >
> > > So while I understand the direction IBM is headed, its adding LOTS of
> > > layers to something that sound not be hard.   Running thru screens vs
> > > submitting a canned job, is hours vs minutes.
> > >
> > > As much as I love my job and starting with MVS 1.3.8 to now z/OS 2.5
> 

Re: Are Banks Breaking Up With Mainframes? | Forbes

2023-05-20 Thread Beverly Caldwell
Sounds like the 'Mainframe is Obsolete' gang is back.
More wishful thinking.

On Sat, May 20, 2023, 10:58 AM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Opinions are wrong more often.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Saturday, May 20, 2023, 11:03 AM, Mike Schwab 
> wrote:
>
> >Tracking the years 2022 – 2029
> Once you get the data, please publish a report.  Forecasts are often
> widely wrong.
>
> On Sat, May 20, 2023 at 9:27 AM Bill Johnson
> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Bull.
> https://www.flynetviewer.com/blog/20220922/global-mainframe-market-projected-grow-318-billion-2029
> >
> >
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Saturday, May 20, 2023, 4:03 AM, Jack Zukt  wrote:
> >
> > Whatever the agenda of the writer, it still is something that is
> happening,
> > mostly, I think, because of IBM's SW pricing strategy.
> > Regards
> > Jack
> >
> > On Fri, May 19, 2023, 20:14 Mark Regan  wrote:
> >
> > >
> > >
> https://www.forbes.com/sites/forbesfinancecouncil/2023/03/31/are-banks-breaking-up-with-mainframes/?sh=acb458b6bccc
> > > <
> > >
> https://www.forbes.com/sites/forbesfinancecouncil/2023/03/31/are-banks-breaking-up-with-mainframes/?sh=acb458b6bccc_id=54716d118b
> >
> > > _id=54716d118b
> > >
> > >
> > >
> > > Regards,
> > >
> > > Mark Regan, K8MTR General, EN80tg
> > > CTO1 USNR-Retired (1969-1991),
> > >
> > > RUENAAA/CNO WASHINGTON DC//OP-009QCP
> > >
> > > Nationwide Insurance, Retired, 1986-2017
> > > z/OS Network Systems Programmer (z NetView, z/OS Communications Server)
> > > Email:marktre...@gmail.com 
> > > LinkedIn:  https://www.linkedin.com/in/mark-t-regan
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > 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
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> 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: ABEND S0C1 start TUBES

2023-04-15 Thread Beverly Caldwell
We'll, if that tubes thingy is vital to the production system then the DR
test failed didn't it?. That's why we do these things.

On Sat, Apr 15, 2023, 6:25 PM Mark Jacobs <
0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> WAG. Is the DR processor the same model as where they run their production?
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
>
>
> --- Original Message ---
> On Saturday, April 15th, 2023 at 6:15 PM, Paul Gorlinsky <
> p...@atsmigrations.com> wrote:
>
>
> > Customer is attempting a DR test... all new keys for the CPU ...
> UNICOM/MACRO 4 TUBES ABENDS with S0C1 when starting ... Vendor wasn't
> available ... any one else experience this?
> >
> > --
> > 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: How long for an experiened z/OS sysprog to come up to speed on a new environment?

2023-02-19 Thread Beverly Caldwell
Oh dear.

On Sun, Feb 19, 2023, 5:03 PM Grant Taylor <
023065957af1-dmarc-requ...@listserv.ua.edu> wrote:

> On 2/19/23 4:27 PM, Beverly Caldwell wrote:
> > But yes it has never been a problem for me. Sometimes takes a little
> > deviousness to make the transfer work.
> >
> > These people think they are so smart but there is usually a way round
> > their little schemes.
>
> I feel like this flies in the face of security policies that some
> organizations put in place.  What's more is that trying to circumvent
> the stated policy is often sufficient violation to become an HR ~>
> employment problem.
>
> You should never have to try, or even attempt, to get around something.
>
> You should have blessing and an approved method to bring something in.
>
> If someone violates this precept to bring something in, how do you know
> that they won't also violate this precept to take something out?
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
> 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: How long for an experiened z/OS sysprog to come up to speed on a new environment?

2023-02-19 Thread Beverly Caldwell
I would answer your questions if knew who you were and why you were asking!
But yes it has never been a problem for me. Sometimes takes a little
deviousness to make the transfer work.
These people think they are so smart but there is usually a way round their
little schemes.

On Sun, Feb 19, 2023, 3:52 PM Jeremy Nicoll 
wrote:

> On Sun, 19 Feb 2023, at 22:33, Rob Schramm wrote:
>
> > Ps Most of the rest can be figured out.. tools/JCL can be downloaded
>
> Do all sites actually let you bring in your own tools, sample JCL etc?
> How
> about - say - assembler source?  It seems to me that some places might
> view that as a security risk.  And how, if you develop any new
> samples/tools
> at one site do you get them out afterwards?
>
>
> Never mind moving to a new site, how much less productive does anyone think
> they would be if one day they suddenly had no access to their own datasets
> (and let's say those of colleagues, as well)?
>
> I know that when I last worked I hardly ever wrote any JCL etc from
> scratch.  I
> looked for my own prior examples.  If I had none, I browsed my immediate
> colleagues' PDSes.
>
> --
> Jeremy Nicoll - my opinions are my own.
>
> --
> 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: How long for an experiened z/OS sysprog to come up to speed on a new environment?

2023-02-16 Thread Beverly Caldwell
One day is usually sufficient. Provided local management doesn't get in the
way and has everything ready for the incoming person.

On Thu, Feb 16, 2023, 5:37 PM Laurence Chiu  wrote:

> This is probably a how long is a piece of string question but I said I
> would ask management anyway.
>
> Environment
>
> z/OS (of course)
> Z13's and Z15's
> Two sites with DWDM connectivity.
> DS8K SANs and TS77XX VTS
> Parallel Sysplex
>
> DWDM between the sites, Metro Mirror, HyperSwap, VTS grid.
>
> We are running into resource constraints in delivering an
> aggressive development plan which includes'
> - a new Sysplex for an independent business unit
> - moving data off an existing VTS grid and creating a whole new one
> which will require having an existing VTS having its data lost
> - Repopulating the VTS across the DWDM using COPYCAT
> - installing new VTS
> - possibly new DS8K and later one a new Z15
>
> Assuming we could find suitably qualified z/OS and storage sysprogs, given
> decent documentation etc. how long would somebody like that take to be
> productive and ease the workload?
>
> As a secondary  question, are there companies who specialise in z/OS
> sysprog services as body shops? And I don't mean the usual suspects :-)
>
> Thanks
>
> --
> 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/IS Sysprog Positions Available

2021-06-16 Thread Beverly Caldwell
Greetinsowareyoutodayopeyoudoingreat. HCL for god's sake is that the best
you can do? They're always urgent with that outfit aren't they? Looks like
they can't even spell z/OS.

On Wed, Jun 16, 2021, 11:38 AM Allan Staller <
0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:

> Classification: Confidential
> We have an urgent need for 3 Sr. z/OS Systems Programmer
>
> Skills:   z/OS,   JES2,   JES3,   OPS/MVS,   ACF2,   Tivoli WS,  IBM
> SA,  Netview
> Location: Dallas or Houston,  (preferred),  Remote
>
> Perm, Contract to hire
>
> I am not a recruiter, however, I am one of the interfaces to that
> organization.
> Please send your info to meat at the email address below and it will be
> forwarded.
> All information will be kept confidential.
>
> Allan Staller
> HCL AMERICA INC - Lead Technical Specialist
> Email- allan.stal...@hcl.com
>
>
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator
> or HCL or its affiliates. Views or opinions, if any, presented in this
> email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification, distribution and / or
> publication of this message without the prior written consent of authorized
> representative of HCL is strictly prohibited. If you have received this
> email in error please delete it and notify the sender immediately. Before
> opening any email and/or attachments, please check them for viruses and
> other defects.
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Tracking called (non-main) programs using SMF records

2019-11-14 Thread Beverly Caldwell
Write your own CSV exit to knock out an SMF record for these called
programs. I have done this several times and only once missed anything
because some smartie pants from CA was doing his own program loads.

On Thu, Nov 14, 2019 at 3:59 AM Massimo Biancucci  wrote:

> Hi,
>
> as other colleagues already said, no standard SMF way.
>
> At my customers sites, they use TADz (it seems Ptracker gives more
> information like the chain between caller and called) and for some of them
> a product we developed to correlate CICS-Transactions with LINKed/CALLed
> programs (written to SMF records).
>
> About cleanup, if applicable, keep attention to static linked programs who
> seem to be called by nobody.
>
> Best regards.
> Max
>
> Il giorno mer 13 nov 2019 alle ore 17:07 Steff Gladstone <
> steff.gladst...@gmail.com> ha scritto:
>
> > We would like to clean up our load libraries by deleting unused programs.
> >
> > Is there any way to use SMF data to track real-time usage of programs
> which
> > are not main programs but are called by other programs?
> >
> > We were under the impression  that only executions of main programs
> (PGM=)
> >  were recorded with SMF.  Scanning program sources for called programs is
> > unsatisfactory for us since the call could be dynamic (name of program
> > contained in a variable) or conditional on a particular set of
> > circumstances that never occurs in practice.
> >
> > Thanks in advance!
> >
> > Steff Gladstone
> >
> > --
> > 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: Seeking doc on TSOENTER and TSOLEAVE macros

2019-10-15 Thread Beverly Caldwell
You have the source code for these macros I assume. Can you not read them
and document them yourself? I seem to remember them from some time ago but
it looks as though I threw them out at some point.

On Tue, Oct 15, 2019 at 9:48 AM Lionel B Dyck  wrote:

> TSOENTER/TSOLEAVE were found in CBT Files 300, 119, and 136.  Perhaps
> others but I haven't looked further.
>
> Thanks
>
>
> Lionel B. Dyck <
> Website: http://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Paul Gilmartin
> Sent: Tuesday, October 15, 2019 11:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Seeking doc on TSOENTER and TSOLEAVE macros
>
> On Tue, 15 Oct 2019 11:17:56 -0500, Tom Marchant wrote:
>
> >On Tue, 15 Oct 2019 10:31:12 -0500, Lionel B Dyck wrote:
> >
> >>I found these macros used in several TSO commands on the CBTTape but
> >>there is no documentation on them that I can find.  Can anyone point
> >>me to any doc?
> >
> >I don't find them in any IBM macro library, nor do find a MAC of either
> >name in our z/OS system. What CBT tape file(s) did you find them in?
> >
> Do those commands assemble successfully?  Who are the author(s)?
>
> -- 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
>

--
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.4

2019-02-20 Thread Beverly Caldwell
Why does anybody care what they call it. It's only going to be the same old
thing we have been dealing with for the last how many years now?. A tweak
here, a twiddle there.

On Tue, Feb 19, 2019 at 12:43 AM Vernooij, Kees (ITOP NM) - KLM <
kees.verno...@klm.com> wrote:

> Is it named V2.4 or V3.1 or ...?
> The few references I saw about the z/OS version after 2.3 was named "the
> z/OS version after 2.3".
>
> Kees.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Allan Staller
> > Sent: 18 February, 2019 19:18
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: z/OS 2.4
> >
> > Has anybody seen the z/OS V2R4 preview announcement go by?
> >
> > If so, can you provide a link or Announcement number?
> >
> > TIA,
> >
> > ::DISCLAIMER::
> > 
> > 
> > 
> > --
> > The contents of this e-mail and any attachment(s) are confidential and
> > intended for the named recipient(s) only. E-mail transmission is not
> > guaranteed to be secure or error-free as information could be
> > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
> > may contain viruses in transmission. The e mail and its contents (with
> > or without referred errors) shall therefore not attach any liability on
> > the originator or HCL or its affiliates. Views or opinions, if any,
> > presented in this email are solely those of the author and may not
> > necessarily reflect the views or opinions of HCL or its affiliates. Any
> > form of reproduction, dissemination, copying, disclosure, modification,
> > distribution and / or publication of this message without the prior
> > written consent of authorized representative of HCL is strictly
> > prohibited. If you have received this email in error please delete it
> > and notify the sender immediately. Before opening any email and/or
> > attachments, please check them for viruses and other defects.
> > 
> > 
> > 
> > --
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO STEPLIB Allocation

2018-10-29 Thread Beverly Caldwell
Well thank y'all. I guess that's about what I expected.

On Sun, Oct 28, 2018 at 1:53 PM Binyamin Dissen 
wrote:

> On Sun, 28 Oct 2018 08:12:49 -0700 Beverly Caldwell  >
> wrote:
>
> :>Does anyone know, by any chance, if there is any (legitimate) way to rid
> :>oneself of an unwanted STEPLIB allocation to one's TSO session ?
> Ordinarily
> :>I would set up a new logon procedure but that's not an option on this
> gig.
> :>Probably better not download any code either.
>
> How does the "unwanted" steplib bother you?
>
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
>
> --
> 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


TSO STEPLIB Allocation

2018-10-28 Thread Beverly Caldwell
Does anyone know, by any chance, if there is any (legitimate) way to rid
oneself of an unwanted STEPLIB allocation to one's TSO session ? Ordinarily
I would set up a new logon procedure but that's not an option on this gig.
Probably better not download any code either.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO RENAME broke?

2018-09-25 Thread Beverly Caldwell
The only time I use any of those commands is when something is broke in the
logon procedure. The last time I had to do that it was OK. I even managed
to remember the old edit commands!

On Tue, Sep 25, 2018 at 12:27 PM Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Anyone use TSO rename anymore?  Just tried it.  Don't get any errors, but
> it doesn't do it either.  Tried in batch, and get a RC8 but no messages.
> Tried in ispf option 6, READY prompt, nothing different.
>
> Can't say I've used it in years, so maybe its been retired?  We are at
> V2.3 FYI.
>
>
>
>
> _
> Dave Jousma
> Mainframe Engineering, Assistant Vice President
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
> p 616.653.8429
> f 616.653.2717
>
> This e-mail transmission contains information that is confidential and may
> be privileged.
> It is intended only for the addressee(s) named above. If you receive this
> e-mail in error,
> please do not read, copy or disseminate it in any manner.  If you are not
> the intended
> recipient, any disclosure, copying, distribution or use of the contents of
> this information
> is prohibited. Please reply to the message immediately by informing the
> sender that the
> message was misdirected. After replying, please erase it from your
> computer system. Your
> assistance in correcting this error is appreciated.
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Report volumes with IPLText

2018-09-07 Thread Beverly Caldwell
Don't tell me. Your systems are so reliable you've forgotten where your IPL
volumes are.!

On Fri, Sep 7, 2018 at 10:36 AM Dyck, Lionel B. (RavenTek) <
01d7f21a6167-dmarc-requ...@listserv.ua.edu> wrote:

> Is there a utility that will display all mounted volumes that have IPL
> Text installed?
>
> --
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer - RavenTek Solution Partners
>
>
>
> --
> 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: Question on SMF Records and ALTER GDG Base

2018-08-27 Thread Beverly Caldwell
Off hand I would try a 66. Have you looked in the SMF book?

On Sun, Aug 26, 2018 at 6:23 PM Lizette Koehler 
wrote:

> So, I have a request about who changed a GDG limit.
>
> Is there an SMF record that would list that type of change?
>
> I know the command will be ALTER gdg-base LIMIT(xx)
>
> What type of SMF Record would I look at?
>
> Thanks
>
>
> 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
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Jes2 Initiator number

2018-08-07 Thread Beverly Caldwell
Just wondering why that would be of interest. If it is anywhere it will be
in the type 30 i would think. There is an indicator that the init is wlm
managed.

On Tue, Aug 7, 2018 at 12:34 PM, Tony Cieri  wrote:

> Is the JES2 initiator number that runs a job recorded in any SMF records??
>
> The only "audit" trail that I can find is the $HASP373 message when a job
> is started.
>
> I would appreciate any pointers that anyone can provide.
> Thanks
> Tony
>
> --
> 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: Need help with ISPF Dialogue Manager and VGET

2018-08-01 Thread Beverly Caldwell
Well, you are almost there, Paul. You seem to have the hang of this. What
do you need, someone to write it for you?

On Mon, Jul 30, 2018 at 1:45 PM, esst...@juno.com  wrote:

> Hello,
> .
> I need some clarification on using the ISPF VGET Service in an Assembler
> Program, the examples I've found were not much help.
> .
> .
> I have a CLIST which issues a VPUT for three Fields
> Name, City,  STATE. These variable are placed on the SHARED POOL.
> The CLIST then invokes an Assembler Program which should issue a VGET
> for the three variables and write them to a VSAM dataset.
> .
> In the examples I found I never see the Variables for the VGET defined
> in the program.
> .
> I suspect I need to first issue a VDEFINE, with a Name List, Variable
> list, Format List and Length List  prior to issuing the VGET.
> .
> THE VGET SERVICE only identifies a name-list like
> NAME-LIST EQU *
>   DC  A(3)
>   DC  A(0)
>   DC  CL8'NAME '
>   DC  CL8'CITY '
>   DC  CL8'STATE'
> .
> Do I need to issue a VDEFINE first  for the Variables specified in the
> VGET. Would someone please clarify 
> .
> .
> Paul
> .
> .
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Looking for IMS Sysprog

2018-06-30 Thread Beverly Caldwell
Yes, very interesting. Unfortunately people with names like yours are
little more than  time wasters with your urgent non existing requirements
for your direct non existing clients, kindly revert etc etc.

On Fri, Jun 29, 2018 at 7:40 AM, Salah Balboul  wrote:

> Morning list,
>
> Looking for an IMS Sysprog in Jacksonville, FL. Contract to hire.
>
> Email me if interested.
>
> Thanks
>
> --
> 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: JCL ERROR Anybody ?

2018-06-11 Thread Beverly Caldwell
I see. Never even considered that. This came from IBM via the DB2 order. Of
course that doesn't mean they actually tested it!

On Mon, Jun 11, 2018 at 4:49 PM, Sri h Kolusu  wrote:

> > OK so far. Step 12 > allocates the entire pds to a ddname to service link
> edit INCLUDE  statements.and immediately after that in the JCL alllocates
> &(member)
> > to use as SYSIN to the linkage editor. This allocation fails with a
> dataset  not found.jcl error All dispositions except the first and even
> includig the
> > last (failing) one are OLD, PASS.
>
> Beverly,
>
> If you are referring the same temp dataset with 2 different DDnames in the
> same step, then you probably need VOL=REF
>
> something like this
>
> //STEP0100 EXEC PGM=SORT
> //SORTOUT  DD DSN=&,DISP=(,PASS),SPACE=(CYL,(1,1),RLSE)
> ...
> //STEP0200 EXEC PGM=ABCD
> //INA  DD DSN=&,DISP=(OLD,PASS),VOL=REF=*.STEP0100.SORTOUT
> //INB  DD DSN=&,DISP=(OLD,PASS),VOL=REF=*.STEP0100.SORTOUT
>
>
> Kolusu
>
>
>
>
>
> --
> 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


JCL ERROR Anybody ?

2018-06-11 Thread Beverly Caldwell
This is the second time this has happened to me in as many months:

A job in the DB2 install process:

Job has 12 steps, the, first 11 are HLASM steps compilingl the various bits
and pieces needed by DB2. Step 1 defines a temporary pds with
DISP=(NEW,PASS) gives it some DCB info even a DSORG=PO. Name is
&(member name) . Steps 2 - 11 output the compiled code into this
temporary pds. using &(member name) DISP=OLD,PASS.  OK so far. Step 12
allocates the entire pds to a ddname to service link edit INCLUDE
statements.and immediately after that in the JCL alllocates &(member)
to use as SYSIN to the linkage editor. This allocation fails with a dataset
not found.jcl error All dispositions except the first and even includig the
last (failing) one are OLD, PASS.

Anybody have any idea what's going on here ? I'm hoping someone will pop up
with a "Oh you can't do that" and tell me why. Either that or it's some
ancient quirk of JCL.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: ISPF programming with assembler

2018-06-11 Thread Beverly Caldwell
Well, it's a variable which you will have to define like any other variable
in your program. Once you do that it can be accessed  and read. I don't
recall its actual name. Check the table display service section in the
developers guide.

On Fri, Jun 8, 2018 at 7:35 AM, Immo  wrote:

> Hi,
>
>
>
> I'd like to retrieve the unique row-id for an entry in an ISPF table from
> an
> assembler program (not the crp!). Unfortunately I didn't find out how to
> get
> hold of the value on my own and so far I haven't found a usable example.
>
>
>
> Any hint or pointer to a working example in assembler language would be
> great!
>
>
>
> Thanks in advance,
>
>
>
> Michael
>
>
>
>
> --
> 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: Unicode Q

2018-03-13 Thread Beverly Caldwell
Thank you all. I never even thought of left and right !

On Tue, Mar 13, 2018 at 12:48 PM, Seymour J Metz <sme...@gmu.edu> wrote:

> I would guess that L and R refer to the default direction for bitext.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf
> of Beverly Caldwell <star2015...@gmail.com>
> Sent: Tuesday, March 13, 2018 3:38 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Unicode Q
>
> If I do a DISPLAY UNI,ALL I see a list titled  conversion and the
> entries are followed by a -E -R or -L in one case -ER.
>
> Anyone know what that means ?
>
> --
> 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


Unicode Q

2018-03-13 Thread Beverly Caldwell
If I do a DISPLAY UNI,ALL I see a list titled  conversion and the
entries are followed by a -E -R or -L in one case -ER.

Anyone know what that means ?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: catalog doubt

2018-01-06 Thread Beverly Caldwell
OK OK OK Take a joke can you? Or is that not allowed on this board?  I was
being somewhat facetious. I was referring to IBM's tendency to surround
everything they do with some sort of mystical complexity.

On Fri, Jan 5, 2018 at 8:47 PM, Ron hawkins <ronjhawk...@sbcglobal.net>
wrote:

> Kirk,
>
> Auribus teneo lupum.
>
> Sharing SMS managed outside of SMS is on the cardinal sins of SMS.
>
> It is more than just aid to allocation, but also an enabler of function.
> If your LPAR doesn't read the NVR, then your open is dead in the water,
> right?
>
> Ron
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Beverly Caldwell
> Sent: Friday, January 5, 2018 1:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] catalog doubt
>
> What is a catalog?. It's a list of files and where they can be found. What
> is SMS management? It's basically an aid to allocation. Simple right? NO
> We're IBM and nothing is allowed to be that simple.
>
> On Tue, Jan 2, 2018 at 11:13 AM, Kirk Wolf <k...@dovetail.com> wrote:
>
> > On Mon, Jan 1, 2018 at 1:08 PM, Beverly Caldwell
> > <star2015...@gmail.com>
> > wrote:
> >
> > > ..
> > > Now if you really like banging your head against a brick wall, try
> > dealing
> > > with datasets which are SMS managed on one LPAR but are not
> > > cataloged to the LPAR you are on. If you want to access those you
> > > really will have fun and you'll be wondering why on earth you got
> > > into this mainframe cr/\p in the first place.
> > >
> > > You are exactly right, Beverly!   I had to deal with this recently and
> it
> > was a major PITA.   Its like IBM never considered all of the real-world
> use
> > cases.
> >
> > Kirk Wolf
> > Dovetailed Technologies
> > http://dovetail.com
> >
> > >
> > >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> 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: catalog doubt

2018-01-05 Thread Beverly Caldwell
What is a catalog?. It's a list of files and where they can be found. What
is SMS management? It's basically an aid to allocation. Simple right? NO
We're IBM and nothing is allowed to be that simple.

On Tue, Jan 2, 2018 at 11:13 AM, Kirk Wolf <k...@dovetail.com> wrote:

> On Mon, Jan 1, 2018 at 1:08 PM, Beverly Caldwell <star2015...@gmail.com>
> wrote:
>
> > ..
> > Now if you really like banging your head against a brick wall, try
> dealing
> > with datasets which are SMS managed on one LPAR but are not cataloged to
> > the LPAR you are on. If you want to access those you really will have fun
> > and you'll be wondering why on earth you got into this mainframe cr/\p in
> > the first place.
> >
> > You are exactly right, Beverly!   I had to deal with this recently and it
> was a major PITA.   Its like IBM never considered all of the real-world use
> cases.
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> >
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: catalog doubt

2018-01-01 Thread Beverly Caldwell
Well, for someone who is new to the mainframe you certainly chose a deep
pool to jump into. Messing with catalogs is always fun. There's a great
vendor product available which will allow you to do almost anything with
foreign catalogs, I can't just remember its name but I'm sure someone else
will help you out.

Now if you really like banging your head against a brick wall, try dealing
with datasets which are SMS managed on one LPAR but are not cataloged to
the LPAR you are on. If you want to access those you really will have fun
and you'll be wondering why on earth you got into this mainframe cr/\p in
the first place.

On Fri, Dec 29, 2017 at 7:13 PM, johnnydeep san 
wrote:

> Hi all,
>
> i have XYZ dataset's (vsam and non-vsam) files on SYSA under usercatlog
> "SYSA.ADCDCAT.TEST" . I would like to use all XYZ datasets on SYSB.
>
> I ran import connect job on SYSB after sharing the same volume's where XYZ
> are resides.But i could not fetch the datasets on new system directly , it
> shows "NO data set names found" . I can fetch it only by giving volume
> serial along with datasetname on 3.4 . Did i'm miss any anything ?. I have
> create alias user01 for SYSA.ADCDCAT.TEST on sysa. should i create the same
> alias again on sysB as well? .  please guide me ,i'm new to mainframe
> environment .
>
>
> Note: I'm uisng RDZ  not real mainframe box .
>
> --
> 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: IEFACTRT and flowerbox with excp consolidation

2017-11-28 Thread Beverly Caldwell
Can't you just modify the one you have to make it do what you want ?

On Mon, Nov 27, 2017 at 1:02 PM, Peter Vander Woude  wrote:

> Does anyone have an IEFACTRT exit, that produces a flower box AND
> processes all the smf30 extension records for when DDCONS is set to NO, so
> we just get one total for all the EXCP's done to each DDNAME?  I've tried
> the ones on the CBT tape, and none of them seem to do that.
>
> Thank,
> Peter
>
> --
> 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: OS/390 2.5

2017-11-27 Thread Beverly Caldwell
Why would you even waste your time with these idiots, Mark ? They have
screwed themselves into the ground.

You can bet your boots the same team of management clowns who brought this
situation about are still in control. So I would pitch them a complete
upgrade to the latest software and hardware, cost it all out and tell them
this is what you will have to pay to get yourselves out of this hole.

Any technical fix is only going to be temporary and will only prolong the
situation, doing nothing to solve the basic problem.

You could maybe find a more polite way of putting it.

On Mon, Nov 27, 2017 at 8:44 AM, John McKown 
wrote:

> On Mon, Nov 27, 2017 at 8:05 AM, PINION, RICHARD W. <
> rpin...@firsttennessee.com> wrote:
>
> > So you are saying I can't IPL OS/360 on our z13 :)
> >
>
> ​Not without an "RPQ". I remember back in the 1980s when Braniff Airways
> (now defunct) was running OS/MVT on a 3033. It only ran because IBM wrote
> special patches to allow it. These patches were only available via an "RPQ"
> (Request for Price Quotation?).
>
> Given that all the current IBMZ machines are basically "millicoded", I can
> imagine that it is _theoretically_ ​possible to have an a number of MCL
> variants which could implement almost any level of architecture. Of course,
> if marketing tried this, I would guess that they would be subject to a
> "dark ops" strike from the hardware engineers.
>
>
> --
> I have a theory that it's impossible to prove anything, but I can't prove
> it.
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: SUBVERSION for Mainframe code

2017-10-09 Thread Beverly Caldwell
I use a source code control tool called RACF. It actually comes with z/OS.
Pretty effective too.

On Mon, Oct 9, 2017 at 10:02 AM, Jack J. Woehr  wrote:

> On 10/9/2017 8:44 AM, Peter wrote:
>
>> Has anyone used Subversion as their source control tool for mainframe
>> code?
>> I'm assuming that you can't install SVN on the mainframe but I was
>> wondering if there was another way to use it and check out the code to the
>> mainframe ?
>>
>
>
> SVN can run under USS.
>
>
> --
> 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
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Here's a horrifying thought for all you management types....

2017-10-05 Thread Beverly Caldwell
>From an IBM red book, the one which describes Walmart’s adventures with
CICS in a cloud.

>From the section which describes the activities of the CICS and z/OS
systems programmers:


“The traditional role of systems programmers over time became focused on
system
administration functions. But, to extend the capabilities of CICS, the
old-school, multi-role
technician must reemerge and embrace the latest technologies”


Well some of us never actually went away.


But wait, there’s more. It gets worse. Further on in the same article
there’s talk of:

“Selecting HLASM and COBOL as service development languages.”

Programming, Jim? *Assembler* language programming? I don’t think we need
any of *that* here.


What I would like to know is where were all the managers while all this
programming was going on. Does Walmart have the most enlightened managers
in the mainframe world or did they just not have a clue what was going on.
I suspect the latter, it’s unlikely Walmart’s managers are any different
from anyone else’s.


A very interesting red book with lots of detailed information although I
kept seeing the word 'service'. Not a word one would normally associate
with Walmart.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: "Breach" (fka Would encryption have prevented known major breaches?)

2017-09-18 Thread Beverly Caldwell
"Would encryption have prevented known major breaches?" Actually, no, I
think it would have made the effects worse. If Equifax had encrypted their
data, right now those clowns would be slapping each other on the back and
telling themselves, nothing to worry about, no need to report this to
anyone, eh boys? So the effects would have not been apparent for however
long it took the people who got the data to decrypt it.

On Fri, Sep 15, 2017 at 7:05 AM, Peter Relson  wrote:

> 
> In my view, your definition is not what most people mean with the word
> "breach."
> 
>
> And in my view my definition is exactly what is meant by breach. A breach
> is unintended entrance. And that is exactly what the dictionary reference
> says.
>
> The consequences of that unintended entrance are not relevant to whether
> or not there was a breach.
>
> 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
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Question about question

2017-09-18 Thread Beverly Caldwell
Ask these boys, Peter. They seem to have an answer for everything.

On Mon, Sep 18, 2017 at 9:30 AM, Peter Ten Eyck <
peter.tene...@americannational.com> wrote:

> Where is the best place to post a question about REXX and SDSF coding and
> usage? I have some code that I have written and it’s not working
> "correctly".
>
> --
> 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: Would encryption have prevented known major breaches?

2017-09-18 Thread Beverly Caldwell
I encrypt my SSN by making up a new one every time some ahole asks for it.

On Sun, Sep 17, 2017 at 5:38 PM, Phil Smith  wrote:

> Jack J. Woehr wrote:
> >Okay, I have the answer to the Equifax question.
> >I obtained the answer by the simple act of freezing my records on all
> three services:
> >Experian and Transunion: Had to jump through many verification hoops,
> answer trick questions.
> >Equifax: One simple basic info screen and I'm the owner of my account
> freeze.
> >Reveals everything we need to know about the breach, don't you think?
>
> Ouch. True, but you missed Innovis-the fourth, soon (I expect) to be one
> of the Big Three.
>
> A kinder interpretation is that EFX decided that they'd pissed people off
> enough already, and should make it easy to freeze-they also stopped
> charging for it even in states like mine where they're allowed to do so.
> Innovis also doesn't charge, but I expect that's because they're relatively
> small, can't afford to irritate people. Not saying that EFX deserves this
> interpretation, just sayin' that it's possible.
>
> ...phsiii
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Looking for mainframe shops Lexington/Cincinnati

2017-08-31 Thread Beverly Caldwell
You missed nothing with the exodus of the toyota mainframe. A bunch of
geriatric IMS systems running probanly 5 transactions an hour..

If you are looking for interesting work with interesting people to do it
with I would keep the IBM mainframe firmly in the rear-view mirror.

On Thu, Aug 31, 2017 at 7:57 AM, Bill Bishop (TMNA) 
wrote:

> Joel;
>
> Lexington is going to be very tough.
>
> The only zOS shops in the area are the State of Kentucky in Frankfort,
> Toyota in Georgetown, Ashland Oil and Lexmark, both in Lexington itself.
>
> I have also heard that there is an old system at University of Kentucky
> Medical Center.
>
> Toyota is supported out of Plano, Texas now.  Lexmark is all outsourced to
> IBM.
>
> There are several sites in Louisville.  Besides those mentioned already,
> there is Kentucky Farm Bureau and Yum Brands that I know of.  There may be
> more.
>
> Pickings are slim in Lexington.  That is why I took the move from
> Georgetown to Plano.  I was not ready to retire yet.
>
> Thanks
>
> Bill Bishop
> Consultant, Mainframe Engineer
> Mainframe and Scheduling | Infrastructure Technology Services
> Toyota Motor North America
>  bill.bis...@toyota.com
> Office:  (469) 292-5149
> Cell:  (502) 316-4386
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joel M Ivey
> Sent: Wednesday, August 30, 2017 10:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Looking for mainframe shops Lexington/Cincinnati
>
> Thank you to all.  Several good leads for me.  I appreciate it.   I'm
> looking hard at the Fort Knox opp, but also hoping to find something there
> in the Lexington area.
>
> --
> 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: Remote position

2017-07-26 Thread Beverly Caldwell
Oh the indians will just love you for posting this online. your inbox will
soon be full of urgent nonexistent requirements for their direct
nonexistent clients. just revert with lowest possible rate and visa status
and you're off!

On Tue, Jul 25, 2017 at 5:12 PM, Mvs Guy  wrote:

> Hello Group,
>
> Apologize for being anonymous.
>
> I am looking for a remote zOS or zVM sysprog position anywhere in US. To
> summarize about me, I have almost 20 years of zOS/z/VM experience including
> but not limited to Assembler programming, User exits, Sysplex, Storage,
> Perf tuning(SAS/MXG), zLinux etc.
>
> Please note I am looking for fully remote only positions after initial
> on-site on-boarding.And I don't want to work for IBM consulting.
>
>  If you happen to know a position please email me at: zosn...@gmail.com
>
> Thank you.
>
> --
> 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: Friday question: ISPF Statistics Manipulation

2017-07-07 Thread Beverly Caldwell
Evidence of what Barb ? Don't hang anyone on this evidence. Anyone with
update access to the pds can update this field..
I do it all the time to source code libraries to set the version level in
the uid field.

I can't think how you would do it. The ds name in the RACF call will not
contain a member name just the pds name as it is the directory which is
being updated.

Maybe an ISPF exit ?

On Fri, Jul 7, 2017 at 8:05 AM, Barbara Nitz  wrote:

> A colleague of mine just asked me if ISPF statistics in a data set,
> especially the USERID field, can be manipulated. We used ISPF 3.5 and we
> were both astonished that I was easily able to fake a userid as the one who
> last changed a member (testing in my own dataset, of course).
>
> This immediately raised the question for me if there is any RACF control
> that would prevent this type of manipulation, especially since the userids
> in those statistics are widely used as evidence. Does anyone know if there
> are such RACF controls? A quick search in the ISPF books didn't turn up any
> hint.
>
> Barbara
>
> --
> 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: After IT outage, British Airways union blames outsourced IT jobs in India for problem

2017-06-05 Thread Beverly Caldwell
http://www.theregister.co.uk/2017/06/02/british_airways_data_centre_configuration/

I read The Register's account of this. I particularly enjoyed seeing TCS
and the word "cockup" together in the same sentence. Perfect.

On Mon, May 29, 2017 at 8:30 AM, Phil Smith  wrote:

> http://timesofindia.indiatimes.com/business/india-
> business/after-it-outage-british-airways-union-blames-
> outsourced-it-jobs-in-india-for-problem/articleshow/58874334.cms
>
> Well, that's better than "we lost a power supply and we built our system
> with an obvious SPOF". Unless they're blaming the SPOF design on the
> Indians, of course (still fully possible). Not sure "We outsourced and had
> no grown-up oversight" is an excuse either.
>
> The best example of a successful outsourcing (who shall remain nameless)
> that I know of kept several senior staff to be the interface with the
> outsourcer. They keep 'em (mostly) honest. Next-best is, of course, moving
> existing staff to the outsourcer, but that "wears off" over time.
>
> Remind me again why outsourcing is such a great idea... (yeah, yeah, I
> know the reasoning, don't start).
>
> ...phsiii
>
> --
> 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