Re: TSO Setup on SSH

[venkat kulkarni]

Thanks to all. After receiving all reply from experts and from manual now
my understanding is,

I should use SSL 992 port and with self signed certificate to enable SSL on
tso. Please correct me , if I am going in wrong direction.

Also please help me to find difference in tn3270 and tn3270e and when
should we use tn3270e instead of tn3270.

Thanks for all help.

On Nov 22, 2016 22:54, "Kirk Wolf"  wrote:

> The scripting for x3270 is basically just automation control.   I don't
> really understand why there would be a performance issue or concern.
>
> http://x3270.bgp.nu/Unix/x3270-script.html
>
> Here's an example that I did that logs into TSO with a password/passticket
> supplied in an environment variable:
>
> #!/bin/bash
> # script to start x3270 and login to TSO with a MSG10 menu screen
> zosuser=$1
> zoshostandport=$2
> connecthostandport=$3
> connecthostandport=${connecthostandport:-$zoshostandport}
>
> x3270 -script -xrm 'x3270.connectFileName: none' -once $connecthostandport
> < Wait(30,InputField)
> Title($zosuser@$zoshostandport)
> String(tso)
> Enter
> Wait(30,InputField)
> String($zosuser)
> Enter
> Wait(30,InputField)
> String($X3270PW)
> Closescript(0)
> EOF
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> On Tue, Nov 22, 2016 at 10:10 AM, Martin Packer 
> wrote:
>
> > I use x3270 all the time. And I've made widespread use of custom key
> > sequences to make me more productive. So far so good.
> >
> > Kirk, you mentioned scripting. I've only had limited success with that.
> > One day I'll persist. :-)
> >
> > But the reason for leaping in is to ask whether - in anyone on the list's
> > experience - scripting performance is OK. I ask because this seems
> > analogous to the kind of protocol IND£FILE represents, which I always
> > found to be slow.
> >
> > Thoughts?
> >
> > Martin Packer,
> > zChampion, Principal Systems Investigator,
> > Worldwide Cloud & Systems Performance, IBM
> >
> > +44-7802-245-584
> >
> > email: martin_pac...@uk.ibm.com
> >
> > Twitter / Facebook IDs: MartinPacker
> >
> > Blog:
> > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> >
> > Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/
> or
> >
> > https://itunes.apple.com/gb/podcast/mainframe-performance-
> > topics/id1127943573?mt=2
> >
> >
> >
> > From:   Kirk Wolf 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date:   22/11/2016 15:27
> > Subject:Re: TSO Setup on SSH
> > Sent by:IBM Mainframe Discussion List 
> >
> >
> >
> > There are a bunch of pieces that I would have to externalize; maybe some
> > day.
> >
> > I don't really find x3270 all that objectionable.  Its fairly easy to
> > customize and the scripting works fine.
> > Granted, I don't use it that much; most of my z/OS work is from a shell.
> >
> > Kirk Wolf
> > Dovetailed Technologies
> > http://dovetail.com
> >
> > On Tue, Nov 22, 2016 at 9:08 AM, John McKown
> > 
> > wrote:
> >
> > > On Tue, Nov 22, 2016 at 9:01 AM, Kirk Wolf  wrote:
> > >
> > > > ​
> > > >
> > > >
> > > > We do something like this from our Linux workstations.  I wrote a
> > script
> > > > that makes an ssh connection (authenticating with a private key from
> a
> > > > password safe) and over this connection it runs a z/OS UNIX command
> to
> > > > return a RACF passticket for the userid.   Then it starts x3270 with
> a
> > > > automation script that connects through the ssh tunnel and
> > automatically
> > > > logs on to TSO using the passticket.
> > > >
> > >
> > > ​Oh, that is clever. Can you share this? Too bad x3270 is a PITA to use
> > > compared to most of the Windows 3270 emulators.​ I wish someone would
> > take
> > > the x3270 code and enhance it to use QT or GTK+ or even some other
> > > windowing framework.
> > >
> > >
> > >
> > > >
> > > > Kirk Wolf
> > > > http://dovetail.com
> > > >
> > > >
> > > --
> > > Heisenberg may have been here.
> > >
> > > Unicode: http://xkcd.com/1726/
> > >
> > > 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
> >
> >
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to 

Re: IZUSEC job

[גדי בן אבי]

SMP/E doesn't have an object type called JOB or JCL.
SRC didn't find anthing.
Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: Wednesday, November 23, 2016 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IZUSEC job

Gadi.
Ask smp. If there a job with this name, smp kow it.

Itschak

בתאריך 23 בנוב 2016 09:14,‏ "גדי בן אבי"  כתב:

> I looked in SIZUJCL.
> It's not there :-(
> Gadi
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Elardus Engelbrecht
> Sent: Wednesday, November 23, 2016 8:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IZUSEC job
>
> GADI wrote:
>
> >I am trying to configure z/OSMF for the first time.
>
> Good luck. This is a horrible, but managable task. Easier thatn
> OMEGAMON of course... ;-)
>
>
> >I can't find the IZUSEC job that created the security definitions for
> z/OSMF.
>
> IBM should have given you a copy of dataset IZU.SIZUJCL which contains
> that and other members. This is the same dataset where you find the
> jobs to create + populate zHFS datasets amongst other things.
>
> About security, there are a good handful of IZU*SEC jobs waiting for you.
>
>
> >z/OSMF was installed as part of z/OS using ServerPac. z/OS and z/OSMF
> >are v2.1
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או
> חברה קשורה שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות
> או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של
> החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר
> מסמך כאמור (לרבות מסמך
> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום
> טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
> Please note that in accordance with Malam and/or its subsidiaries 
> (hereinafter :
> "Malam") regulations and signatory rights, no offer, agreement,
> concession or representation is binding on the Malam, unless
> accompanied by a duly signed separate document (or a scanned version
> thereof), affixed with the Malam seal.
>
> --
> 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
לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

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

Re: IZUSEC job

[Itschak Mugzach]

Gadi.
Ask smp. If there a job with this name, smp kow it.

Itschak

בתאריך 23 בנוב 2016 09:14,‏ "גדי בן אבי"  כתב:

> I looked in SIZUJCL.
> It's not there :-(
> Gadi
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: Wednesday, November 23, 2016 8:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IZUSEC job
>
> GADI wrote:
>
> >I am trying to configure z/OSMF for the first time.
>
> Good luck. This is a horrible, but managable task. Easier thatn OMEGAMON
> of course... ;-)
>
>
> >I can't find the IZUSEC job that created the security definitions for
> z/OSMF.
>
> IBM should have given you a copy of dataset IZU.SIZUJCL which contains
> that and other members. This is the same dataset where you find the jobs to
> create + populate zHFS datasets amongst other things.
>
> About security, there are a good handful of IZU*SEC jobs waiting for you.
>
>
> >z/OSMF was installed as part of z/OS using ServerPac. z/OS and z/OSMF
> >are v2.1
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה
> קשורה שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג
> מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את
> לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך
> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום
> טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please
> note that in accordance with Malam and/or its subsidiaries (hereinafter :
> "Malam") regulations and signatory rights, no offer, agreement, concession
> or representation is binding on the Malam, unless accompanied by a duly
> signed separate document (or a scanned version thereof), affixed with the
> Malam seal.
>
> --
> 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: IZUSEC job

[גדי בן אבי]

I looked in SIZUJCL.
It's not there :-(
Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Wednesday, November 23, 2016 8:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IZUSEC job

GADI wrote:

>I am trying to configure z/OSMF for the first time.

Good luck. This is a horrible, but managable task. Easier thatn OMEGAMON of 
course... ;-)


>I can't find the IZUSEC job that created the security definitions for z/OSMF.

IBM should have given you a copy of dataset IZU.SIZUJCL which contains that and 
other members. This is the same dataset where you find the jobs to create + 
populate zHFS datasets amongst other things.

About security, there are a good handful of IZU*SEC jobs waiting for you.


>z/OSMF was installed as part of z/OS using ServerPac. z/OS and z/OSMF
>are v2.1

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

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

Re: HSM question

[Elardus Engelbrecht]

Tony Thigpen wrote:

>Once a week, HSM performs an AUTOBACKUP. Until about 3 months ago, if nobody 
>was at the shop, HSM would ask for an exiting tape, wait 10 minutes, and if no 
>tape was mounted, it would ask "Can tape be mounted?". If our remote operator 
>replied 'N', then HSM would us a scratch tape. About once ever month or so, we 
>would run a recycle job to combine all the tapes.

What remote operator? A person or automated task?


>Discussions with all the 3 others involved in the discussion 3 months ago came 
>back with "I did not change anything 3 months ago."

Really? Do you have any tape management system?


>So, I have come to the conclusion that somebody issued a command to HSM but 
>did not update the config file so it would be handled at the next IPL.

Hmmm, yes something *has* changed! 

What command(s) was issued? What are the results of that change(s)? Can you get 
RACF / SMF / SYSLOG records of that ?


Lizette gave you good questions. I will certainly listen to her! ;-)

Groete / Greetings
Elardus Engelbrecht

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

Re: IZUSEC job

[Elardus Engelbrecht]

GADI wrote:

>I am trying to configure z/OSMF for the first time.

Good luck. This is a horrible, but managable task. Easier thatn OMEGAMON of 
course... ;-)


>I can't find the IZUSEC job that created the security definitions for z/OSMF.

IBM should have given you a copy of dataset IZU.SIZUJCL which contains that and 
other members. This is the same dataset where you find the jobs to create + 
populate zHFS datasets amongst other things.

About security, there are a good handful of IZU*SEC jobs waiting for you.


>z/OSMF was installed as part of z/OS using ServerPac. z/OS and z/OSMF are v2.1

Groete / Greetings
Elardus Engelbrecht

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

Re: Mainframe systems programmer ID 'vaulting'

[Elardus Engelbrecht]

Tony Thigpen wrote:

>> 1) System programmers had two logons. One "normal" and one "higher". The 
>> "normal" userid still had some privileged access, but nothing like the 
>> "higher" userid which had basically unlimited access.
>> 2) Additional audit trails were created for the "higher" userid. Both that 
>> fact that they logged on and what they did.
>> 3) The systems programmers split their libraries and work processes so that 
>> they only used the "higher" userid when really necessary.

Good precautions to prevent unintended changes, but it is a PITA! Some of us 
have TWO ids. One as a backup in case your session is busy with something else 
and you're in a hurry or you want to test out changes.


Jeremy Nicoll wrote:

>in, so eg write access to SYS1.PARMLIB was only ever given to MVS team people 
>who would never have access to IMS or CICS stuff.  

Seperation of duties. It is a good thing. If you're finished with a task and 
you hand it over, it is over. For example, it was my work to play with 
SYS1.VTAMLST and friends. I handed that over and my accesses were taken away. 
Part of the job. Same with DB2 and CICS, I know how to start/stop and basic 
debugging, but I don't touch the internals. As a RACF person I can give myself 
access, but then I will get in serious trouble...


>I think there was an ACF2 production batch job which revoked the privilege on 
>all eligible userids, so if you were called in at 0730 and granted yourself 
>extra access, you'd lose it at 8am, when the normal working-hours procedures 
>for getting extra access applied instead.

Weird and messy! It is my not so humble opinion of course. Of course some of 
these accesses are temporary by nature, for example during an once-off problem 
solving.

We don't time [1] access based on date/time/type of work, simply for practical 
reasons. What, if you need access just when that timed RACF / ACF job is 
running?

It is much easier to lock an application to allow logons during x-y hours 
during a-b days. We do that seldom, however.

Groete / Greetings
Elardus Engelbrecht

[1] - RACF tools can assist you with that. Give PErmits at 03:00. Remove Group 
connection at 08:00 and so on... Modify logon date/time for groups based on 
weekend and holidays.

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

IZUSEC job

[גדי בן אבי]

Hi,
I am trying to configure z/OSMF for the first time.
I can’t find the IZUSEC job that created the security definitions for z/OSMF.
z/OSMF was installed as part of z/OS using ServerPac.
z/OS and z/OSMF are v2.1

Gadi

לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

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

List Entries without Alias in Master Catalog(excluding system/io/page datasets)

[Ravi Gaur]

Been thinking various way to explore/list the datasets which somehow (obviously 
security/racf in place however considering unexpected situation) how to list 
the entries from master catalog which do not have alias defined/relate to user 
catalog ...so basically directly connected in master catalog(obviously has 
to put a exclude condition to ignore system required datasets).
Throwing to bigger audience to get more options...so far I am looking at 
CSI/CRPLUS way of getting it done.

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

Re: HSM question

[Lizette Koehler]

So some basic questions
  1)  What version of z/OS?
  2)  If you do a F dfhsmtaskname,Q SETSYS   does it show the same info as the 
ARCCMDxx member?
  3)  What is the specific messages  you are seeing during autobackup?


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tony Thigpen
> Sent: Tuesday, November 22, 2016 4:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: HSM question
> 
> HSM is not my ballgame, but I am tasked with figuring out this puzzle, so bear
> with me. As for background, the shop attempts to run lights-out 24/7.
> 
> Once a week, HSM performs an AUTOBACKUP. Until about 3 months ago, if nobody
> was at the shop, HSM would ask for an exiting tape, wait 10 minutes, and if no
> tape was mounted, it would ask "Can tape be mounted?". If our remote operator
> replied 'N', then HSM would us a scratch tape. About once ever month or so, we
> would run a recycle job to combine all the tapes.
> 
> About 3 months ago, we had some internal discussions about 'fixing' this so
> that it would just use scratch tapes without asking for an existing tape. The
> next thing we knew, the weekly tapes would automatically use a scratch tape.
> This was good. I assumed that one of the other guys had changed something.
> 
> Then came the time change and the resulting IPL. Now everything is different.
> It seems to work the way it did prior to 3 months ago, except for one problem.
> When the operator replies that the tape can not be mounted, instead of HSM
> using a scratch tape, it now asks for another HSM tape. After about 4 hours of
> this last week, I got in my car and went down an mounted the tape. (I am the
> only one that lives in the same town as the processor.)
> 
> Discussions with all the 3 others involved in the discussion 3 months ago came
> back with "I did not change anything 3 months ago."
> 
> But, the other 2 guys that know HSM also say "We are busy. If you want it
> different, figure it out and change it."
> 
> Key items I see in the config file are:
> SETSYS
>PARTIALTAPE(
> BACKUP(MARKFULL) -
> MIGRATION(MARKFULL))
> SETSYS
>SELECTVOLUME(
>BACKUP(SCRATCH)
>MIGRATION(SCRATCH) -
>DUMP(SCRATCH))
> SETSYS
>RECYCLEPERCENT(33)
>MAXRECYCLETASKS(1)
> SETSYS
>TAPEUTILIZATION(
> UNITTYPE(3590-1) PERCENTFULL(97))
> SETSYS
>TAPESPANSIZE(100)
> 
> (And the output of HSEND QUERY SETSYS is the same.)
> 
> The last update date stamp on the config files was 15/12/22.
> 
> So, I have come to the conclusion that somebody issued a command to HSM but
> did not update the config file so it would be handled at the next IPL.
> 
> Looking for any input.
> 
> --
> Tony Thigpen

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

Re: Mainframe systems programmer ID 'vaulting'

[Edward Finnell]

Or has had their data center blown up-vault and all! Can you say 'single  
point of failure'?
 
 
In a message dated 11/22/2016 7:51:28 P.M. Central Standard Time,  
0041d919e708-dmarc-requ...@listserv.ua.edu writes:

Not just  from some manager who doesn't know Mainframes, but some manager 
that has  never had the responsibility of operating a real computer 
system for  production purposes, especially in an Enterprise size data  
center.



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

Re: Mainframe systems programmer ID 'vaulting'

[Thomas Kern]

Not just from some manager who doesn't know Mainframes, but some manager 
that has never had the responsibility of operating a real computer 
system for production purposes, especially in an Enterprise size data 
center.


/Tom kern


On 11/22/2016 13:43, william janulin wrote:

Sounds like the brainchild of this project came from some management type that 
has no clue about mainframes. Usually ideas like that come from those types.



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

HSM question

[Tony Thigpen]

HSM is not my ballgame, but I am tasked with figuring out this puzzle, 
so bear with me. As for background, the shop attempts to run lights-out 
24/7.


Once a week, HSM performs an AUTOBACKUP. Until about 3 months ago, if 
nobody was at the shop, HSM would ask for an exiting tape, wait 10 
minutes, and if no tape was mounted, it would ask "Can tape be 
mounted?". If our remote operator replied 'N', then HSM would us a 
scratch tape. About once ever month or so, we would run a recycle job to 
combine all the tapes.


About 3 months ago, we had some internal discussions about 'fixing' this 
so that it would just use scratch tapes without asking for an existing 
tape. The next thing we knew, the weekly tapes would automatically use a 
scratch tape. This was good. I assumed that one of the other guys had 
changed something.


Then came the time change and the resulting IPL. Now everything is 
different. It seems to work the way it did prior to 3 months ago, except 
for one problem. When the operator replies that the tape can not be 
mounted, instead of HSM using a scratch tape, it now asks for another 
HSM tape. After about 4 hours of this last week, I got in my car and 
went down an mounted the tape. (I am the only one that lives in the same 
town as the processor.)


Discussions with all the 3 others involved in the discussion 3 months 
ago came back with "I did not change anything 3 months ago."


But, the other 2 guys that know HSM also say "We are busy. If you want 
it different, figure it out and change it."


Key items I see in the config file are:
SETSYS
  PARTIALTAPE(
   BACKUP(MARKFULL) -
   MIGRATION(MARKFULL))
SETSYS
  SELECTVOLUME(
  BACKUP(SCRATCH)
  MIGRATION(SCRATCH) -
  DUMP(SCRATCH))
SETSYS
  RECYCLEPERCENT(33)
  MAXRECYCLETASKS(1)
SETSYS
  TAPEUTILIZATION(
   UNITTYPE(3590-1) PERCENTFULL(97))
SETSYS
  TAPESPANSIZE(100)

(And the output of HSEND QUERY SETSYS is the same.)

The last update date stamp on the config files was 15/12/22.

So, I have come to the conclusion that somebody issued a command to HSM 
but did not update the config file so it would be handled at the next IPL.


Looking for any input.

--
Tony Thigpen

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

Re: Mainframe systems programmer ID 'vaulting'

[Lester, Bob]

For a while, about 15 years ago, we had "firecall" IDs.  When you logged in, it 
prompted you for information that, in turn, updated RACF with Name, expiration, 
etc.  These IDs were kept in paper form, in the Data Center Manager's office.

Of course, you had to jump thru the flaming hoops of Change Management first!

BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, November 22, 2016 2:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe systems programmer ID 'vaulting' [ EXTERNAL ]

Isn't this a violation of PCI DSS? "10.1 Implement audit trails to link all 
access to system components to each individual user."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bigendian Smalls
Sent: Tuesday, November 22, 2016 7:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe systems programmer ID 'vaulting'

This is something I hadn’t heard much about, but a couple questions come to 
mind - for anyone who has thought about or implemented this:

1) If you have a pool of IDs, then are you losing granularity with which you 
might want to assign privelages?  Meaning you now have to have IDs that have 
exactly the same permissions - if they are user-agnostic (among some class of 
users obviously, like DEVs or SYSPROGs or whatever) - Seems like that is back 
to the old, “Create a new id.  What perms to give him? Dunno, just build it 
like Chad’s, they have the same job.”  Which has kind of gone out of style for 
obvious reasons (though still prevelant in practice).

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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


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

Re: Mainframe systems programmer ID 'vaulting'

[Charles Mills]

Isn't this a violation of PCI DSS? "10.1 Implement audit trails to link all 
access to system components to each individual user."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bigendian Smalls
Sent: Tuesday, November 22, 2016 7:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe systems programmer ID 'vaulting'

This is something I hadn’t heard much about, but a couple questions come to 
mind - for anyone who has thought about or implemented this:

1) If you have a pool of IDs, then are you losing granularity with which you 
might want to assign privelages?  Meaning you now have to have IDs that have 
exactly the same permissions - if they are user-agnostic (among some class of 
users obviously, like DEVs or SYSPROGs or whatever) - Seems like that is back 
to the old, “Create a new id.  What perms to give him? Dunno, just build it 
like Chad’s, they have the same job.”  Which has kind of gone out of style for 
obvious reasons (though still prevelant in practice).

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

Re: Mainframe systems programmer ID 'vaulting'

[Jeremy Nicoll]

On Tue, 22 Nov 2016, at 18:44, Tony Thigpen wrote:
> As usual, some pc based person only thinks of the way their world works.
> 
> I have been though multiple audits at multiple companies where they 
> accepted that:
> 1) System programmers had two logons. One "normal" and one "higher". The 
> "normal" userid still had some privileged access, but nothing like the 
> "higher" userid which had basically unlimited access.
> 2) Additional audit trails were created for the "higher" userid. Both 
> that fact that they logged on and what they did.
> 3) The systems programmers split their libraries and work processes so 
> that they only used the "higher" userid when really necessary.

The place I worked in, in the 1990s did this.  We were an ACF2 site.  
Each if us still
only used our own userid, which contained flags saying which sysprog
team we were
in, so eg write access to SYS1.PARMLIB was only ever given to MVS team
people who 
would never have access to IMS or CICS stuff.  The userids also all had
an on-call flag 
which could only be set outwith normal hours of work, and the
dataset/resource 
rules were all revised so that anyone with that flag set had higher
levels of access and
auditing.

It took a while for the non-MVS sysprogs to get used to never having
access to the MVS-
team-owned SYS1.PARMLIB etc, but it basically boiled down to them having
to tell us 
what scheduled changes they wanted made there, and of course it gave
them an 
incentive to revise PROCs etc so that their products read parms from
PDSs they controlled
(which we had no access to).  

In an on-call situation you logged in as your normal userid then
executed a TSO command
processor which altered the flag in your ACF2 logonid record & forced a
reload of it in your
address space.  So far as I remember the times of day that the command
would do this
were themselves enforced through some sort of ACF2 resource rule which
the command 
processor tested before either making the change or rejecting it.  I
can't remember, but 
I expect when executing this we were re-prompted for our normal
password.

I think there was an ACF2 production batch job which revoked the
privilege on all 
eligible userids, so if you were called in at 0730 and granted yourself
extra access, 
you'd lose it at 8am, when the normal working-hours procedures for
getting extra 
access applied instead.

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

Re: Mainframe systems programmer ID 'vaulting'

[Rugen, Len]

At a minimum, I think an IT auditor would require a method of joining who owns 
one of these id's when, so the mainframe logs (and any other system) can know 
the real "who" did something.  What about long running tasks?  Can I start a 
session that outlives my lease on the ID?  I bet my task lives on, but blame 
goes elsewhere  Thinking like a bad guy, start a task with 24 hours of low 
use, then do bad things.

Sounds like a job for an ELK stack :-)  Has anyone ever tried sending mainframe 
things like SMF to ELK (elasticsearch/logstash/kibana, that acronym may not be 
well known here :-)?

Len Rugen

Metrics and Automation – umdoitmetr...@missouri.edu


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of william janulin
Sent: Tuesday, November 22, 2016 12:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe systems programmer ID 'vaulting'

Sounds like the brainchild of this project came from some management type that 
has no clue about mainframes. Usually ideas like that come from those types.
 

On Tuesday, November 22, 2016 1:37 PM, Bigendian Smalls 
 wrote:
 

 This is something I hadn’t heard much about, but a couple questions come to 
mind - for anyone who has thought about or implemented this:

1) If you have a pool of IDs, then are you losing granularity with which you 
might want to assign privelages?  Meaning you now have to have IDs that have 
exactly the same permissions - if they are user-agnostic (among some class of 
users obviously, like DEVs or SYSPROGs or whatever) - Seems like that is back 
to the old, “Create a new id.  What perms to give him? Dunno, just build it 
like Chad’s, they have the same job.”  Which has kind of gone out of style for 
obvious reasons (though still prevelant in practice).

2) How does tracing back activity go?  If Gil & Charles decide to collude and 
do horrible things, I see this on SMF or whatever I’m using to monitor these 
guys, then I have to go back to another system of record to see who had those 
IDs during what time (hoping that all that data is up to date, accurate and 
available)  ?  

3)  Is this a band-aid, where having MF-RACF (or whichever ESM) passphrases / 2 
factor auth would seemingly be preferable, but for whatever reason people 
can’t/won’t do this?

4) I get the value for privileged IDs that say a production support dev or 
infrastructure team that’s 2nd level, or oncall might not need everyday, but 
might need in a “break glass” scenario; but day to day - would it make sense?  
Certainly if the alternative is the standard password character pool and it’s 
30 year old lack of entropy, then anything is an improvement - but given the 
headaches in doing a huge new process / tooling - I wonder if time wouldn’t be 
better spent updating the ESM settings + 2 factor?


Chad


> On Nov 22, 2016, at 10:52 AM, James Peddycord  wrote:
> 
> NTAC:3NS-20
> Our company is undergoing a project to 'protect privileged access' by using a 
> password vaulting product. We have been doing this for quite some time for 
> applications teams who require higher levels of access to production datasets 
> for problem resolution, installs, etc.
> The way it works is that a pool of logonids is created, along with an AD 
> group that allows the appropriate applications folks to be able to 'check 
> out' one of these pooled logonids for 24 hours via a web interface. The web 
> interface uses the users lan password plus their secure key passcode and 
> phrase to validate their identity.
> The project has now included Windows and Unix server admins, but instead of a 
> pooled logonid these users have separate logonids with admin access and they 
> 'check out' their own individual administrator logonid.
> Now the project has moved into the mainframe systems programmer space. So far 
> we have used the 'privileges' on the logonid records as defined by our 
> security product to limit this vaulting. Users with 'security' access must 
> check out logonids from the vault. Users with the non-cncl privilege are next.
> During project discussions it has been brought up that the systems 
> programmers, with their access to SYS1 datasets and operator commands, are 
> privileged users by nature, and that eventually they are going to want to 
> vault this access. We (the systems programmers) are strongly against this.
> It looks like at some point we will lose our battle and our access to the 
> mainframe will be vaulted, meaning my entire team will need to check a 
> logonid out of the password vault every morning before starting work. Our 
> main argument now is that we do not want these logonids to be generic, pooled 
> logonids, we want them to be basically the same as our own logonids so that 
> we can see who did what by using the mainframe's built in logging (SMF data, 
> ISPF stats, etc...).
> 
> My questions are, are other companies using password vaulting 

Re: TSO Setup on SSH

[Kirk Wolf]

The scripting for x3270 is basically just automation control.   I don't
really understand why there would be a performance issue or concern.

http://x3270.bgp.nu/Unix/x3270-script.html

Here's an example that I did that logs into TSO with a password/passticket
supplied in an environment variable:

#!/bin/bash
# script to start x3270 and login to TSO with a MSG10 menu screen
zosuser=$1
zoshostandport=$2
connecthostandport=$3
connecthostandport=${connecthostandport:-$zoshostandport}

x3270 -script -xrm 'x3270.connectFileName: none' -once $connecthostandport

wrote:

> I use x3270 all the time. And I've made widespread use of custom key
> sequences to make me more productive. So far so good.
>
> Kirk, you mentioned scripting. I've only had limited success with that.
> One day I'll persist. :-)
>
> But the reason for leaping in is to ask whether - in anyone on the list's
> experience - scripting performance is OK. I ask because this seems
> analogous to the kind of protocol IND£FILE represents, which I always
> found to be slow.
>
> Thoughts?
>
> Martin Packer,
> zChampion, Principal Systems Investigator,
> Worldwide Cloud & Systems Performance, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>
> Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or
>
> https://itunes.apple.com/gb/podcast/mainframe-performance-
> topics/id1127943573?mt=2
>
>
>
> From:   Kirk Wolf 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   22/11/2016 15:27
> Subject:Re: TSO Setup on SSH
> Sent by:IBM Mainframe Discussion List 
>
>
>
> There are a bunch of pieces that I would have to externalize; maybe some
> day.
>
> I don't really find x3270 all that objectionable.  Its fairly easy to
> customize and the scripting works fine.
> Granted, I don't use it that much; most of my z/OS work is from a shell.
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> On Tue, Nov 22, 2016 at 9:08 AM, John McKown
> 
> wrote:
>
> > On Tue, Nov 22, 2016 at 9:01 AM, Kirk Wolf  wrote:
> >
> > > ​
> > >
> > >
> > > We do something like this from our Linux workstations.  I wrote a
> script
> > > that makes an ssh connection (authenticating with a private key from a
> > > password safe) and over this connection it runs a z/OS UNIX command to
> > > return a RACF passticket for the userid.   Then it starts x3270 with a
> > > automation script that connects through the ssh tunnel and
> automatically
> > > logs on to TSO using the passticket.
> > >
> >
> > ​Oh, that is clever. Can you share this? Too bad x3270 is a PITA to use
> > compared to most of the Windows 3270 emulators.​ I wish someone would
> take
> > the x3270 code and enhance it to use QT or GTK+ or even some other
> > windowing framework.
> >
> >
> >
> > >
> > > Kirk Wolf
> > > http://dovetail.com
> > >
> > >
> > --
> > Heisenberg may have been here.
> >
> > Unicode: http://xkcd.com/1726/
> >
> > 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
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> --
> 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: Mainframe systems programmer ID 'vaulting'

[Jousma, David]

This is pretty close to how we operate too.   While we are not yet to the 
vaulting stage for the god ID's.  They are working hard to push everything we 
do in the PROD environment into a Change record.   Things that used to fall 
into "systems administration" gray area.

In the past, if we had to stand up an new CICS region destined to be PROD, we 
just did the work, tested it, and when ready, put in a change record officially 
"dubbing" it prod, and anything done to it thereafter required a change record. 
  Now they want to include the act of building the new instance a prod change.  
 And of course because it's a prod change, they want to banish the work to 
Sunday 2AM-5AM.   

There isn't a lot of logical thinking going on in some of these risk/audit 
area's.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Tuesday, November 22, 2016 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe systems programmer ID 'vaulting'

As usual, some pc based person only thinks of the way their world works.

I have been though multiple audits at multiple companies where they accepted 
that:
1) System programmers had two logons. One "normal" and one "higher". The 
"normal" userid still had some privileged access, but nothing like the "higher" 
userid which had basically unlimited access.
2) Additional audit trails were created for the "higher" userid. Both that fact 
that they logged on and what they did.
3) The systems programmers split their libraries and work processes so that 
they only used the "higher" userid when really necessary.

The fact was that we had to negotiate what was considered "daily" work and what 
was considered "special" work. This took a bit of time and was refined over 
time. A lot of the decisions revolved around READ-ONLY vs UPDATE rights on many 
of the libraries.

Also, the security rules were different depending on which LPAR or Guest we 
were logged on to. Our normal userid could do everything on the systems 
programmer test LPAR. On the Development LPAR, it could do most everything. Our 
real limits were on the production LPARs.

That being said, I think you are going to have to also go down the same road 
where you split your work processes and libraries into normal daily stuff and 
"special" stuff. It will take you a while to get into the mindset, but in the 
end you will find that it worth it. It will take a lot of negotiating, but it

Since the first place where I was forced into this arrangement, I have 
implemented it at other locations. Yes, the systems programmers thought it was 
terrible at first, but once they got used to it, they realized that it 
sometimes saved their bacon. (Think "SHUTDOWN" under VM!) They had to learn to 
think: Which hat am I wearing right now? A limited systems programmer hat or 
the mainframe "god" hat.

If you get your workloads split correctly, you may not need to use a vaulted 
userid as often.

Tony Thigpen

James Peddycord wrote on 11/22/2016 11:52 AM:
> NTAC:3NS-20
> Our company is undergoing a project to 'protect privileged access' by using a 
> password vaulting product. We have been doing this for quite some time for 
> applications teams who require higher levels of access to production datasets 
> for problem resolution, installs, etc.
> The way it works is that a pool of logonids is created, along with an AD 
> group that allows the appropriate applications folks to be able to 'check 
> out' one of these pooled logonids for 24 hours via a web interface. The web 
> interface uses the users lan password plus their secure key passcode and 
> phrase to validate their identity.
> The project has now included Windows and Unix server admins, but instead of a 
> pooled logonid these users have separate logonids with admin access and they 
> 'check out' their own individual administrator logonid.
> Now the project has moved into the mainframe systems programmer space. So far 
> we have used the 'privileges' on the logonid records as defined by our 
> security product to limit this vaulting. Users with 'security' access must 
> check out logonids from the vault. Users with the non-cncl privilege are next.
> During project discussions it has been brought up that the systems 
> programmers, with their access to SYS1 datasets and operator commands, are 
> privileged users by nature, and that eventually they are going to want to 
> vault this access. We (the systems programmers) are strongly against this.
> It looks like at some point we will lose our battle and our access to the 
> mainframe will be vaulted, meaning my entire team will need to check a 
> logonid out of the password vault every morning before starting work. Our 
> main 

Re: REXX determine library that is executed from

[John McKown]

On Tue, Nov 22, 2016 at 2:47 PM, Robert Prins  wrote:

> On 2016-11-22 18:31, Donald Likens wrote:
>
>> I failed to mention that when using EXEC 'rexx.library'. (where
>> 'rexx.library' contains member TEMPNAME.)
>>
>> I am thinking about looking at the output of LISTA but not sure it is
>> worth
>> the effort. If anyone else has a need for this capability I may be able to
>> work something out and post it.
>>
>
> What doesn't work with the REXX from Frank Clarke that I posted?
>
> Robert
> --
> Robert AH Prins
> robert(a)prino(d)org
> No programming (yet) @ http://prino.neocities.org/
>
>
​Just to be my normal weird self, none of this will work in a REXX exec is
run by reading it / creating it dynamically in ​memory and passing the
in-memory EXEC to IRXEXEC.


-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

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

Re: REXX determine library that is executed from

[Robert Prins]

On 2016-11-22 18:31, Donald Likens wrote:

I failed to mention that when using EXEC 'rexx.library'. (where
'rexx.library' contains member TEMPNAME.)

I am thinking about looking at the output of LISTA but not sure it is worth
the effort. If anyone else has a need for this capability I may be able to
work something out and post it.


What doesn't work with the REXX from Frank Clarke that I posted?

Robert
--
Robert AH Prins
robert(a)prino(d)org
No programming (yet) @ http://prino.neocities.org/

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

Re: Mainframe systems programmer ID 'vaulting'

[Tony Thigpen]

As usual, some pc based person only thinks of the way their world works.

I have been though multiple audits at multiple companies where they 
accepted that:
1) System programmers had two logons. One "normal" and one "higher". The 
"normal" userid still had some privileged access, but nothing like the 
"higher" userid which had basically unlimited access.
2) Additional audit trails were created for the "higher" userid. Both 
that fact that they logged on and what they did.
3) The systems programmers split their libraries and work processes so 
that they only used the "higher" userid when really necessary.


The fact was that we had to negotiate what was considered "daily" work 
and what was considered "special" work. This took a bit of time and was 
refined over time. A lot of the decisions revolved around READ-ONLY vs 
UPDATE rights on many of the libraries.


Also, the security rules were different depending on which LPAR or Guest 
we were logged on to. Our normal userid could do everything on the 
systems programmer test LPAR. On the Development LPAR, it could do most 
everything. Our real limits were on the production LPARs.


That being said, I think you are going to have to also go down the same 
road where you split your work processes and libraries into normal daily 
stuff and "special" stuff. It will take you a while to get into the 
mindset, but in the end you will find that it worth it. It will take a 
lot of negotiating, but it


Since the first place where I was forced into this arrangement, I have 
implemented it at other locations. Yes, the systems programmers thought 
it was terrible at first, but once they got used to it, they realized 
that it sometimes saved their bacon. (Think "SHUTDOWN" under VM!) They 
had to learn to think: Which hat am I wearing right now? A limited 
systems programmer hat or the mainframe "god" hat.


If you get your workloads split correctly, you may not need to use a 
vaulted userid as often.


Tony Thigpen

James Peddycord wrote on 11/22/2016 11:52 AM:

NTAC:3NS-20
Our company is undergoing a project to 'protect privileged access' by using a 
password vaulting product. We have been doing this for quite some time for 
applications teams who require higher levels of access to production datasets 
for problem resolution, installs, etc.
The way it works is that a pool of logonids is created, along with an AD group 
that allows the appropriate applications folks to be able to 'check out' one of 
these pooled logonids for 24 hours via a web interface. The web interface uses 
the users lan password plus their secure key passcode and phrase to validate 
their identity.
The project has now included Windows and Unix server admins, but instead of a 
pooled logonid these users have separate logonids with admin access and they 
'check out' their own individual administrator logonid.
Now the project has moved into the mainframe systems programmer space. So far 
we have used the 'privileges' on the logonid records as defined by our security 
product to limit this vaulting. Users with 'security' access must check out 
logonids from the vault. Users with the non-cncl privilege are next.
During project discussions it has been brought up that the systems programmers, 
with their access to SYS1 datasets and operator commands, are privileged users 
by nature, and that eventually they are going to want to vault this access. We 
(the systems programmers) are strongly against this.
It looks like at some point we will lose our battle and our access to the 
mainframe will be vaulted, meaning my entire team will need to check a logonid 
out of the password vault every morning before starting work. Our main argument 
now is that we do not want these logonids to be generic, pooled logonids, we 
want them to be basically the same as our own logonids so that we can see who 
did what by using the mainframe's built in logging (SMF data, ISPF stats, 
etc...).

My questions are, are other companies using password vaulting or other 
multi-level authentication for mainframe systems programmer access?
What else could we use in our argument against using generic, pooled logonids?

Thanks in advance!

Jim

--
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: Mainframe systems programmer ID 'vaulting'

[william janulin]

Sounds like the brainchild of this project came from some management type that 
has no clue about mainframes. Usually ideas like that come from those types.
 

On Tuesday, November 22, 2016 1:37 PM, Bigendian Smalls 
 wrote:
 

 This is something I hadn’t heard much about, but a couple questions come to 
mind - for anyone who has thought about or implemented this:

1) If you have a pool of IDs, then are you losing granularity with which you 
might want to assign privelages?  Meaning you now have to have IDs that have 
exactly the same permissions - if they are user-agnostic (among some class of 
users obviously, like DEVs or SYSPROGs or whatever) - Seems like that is back 
to the old, “Create a new id.  What perms to give him? Dunno, just build it 
like Chad’s, they have the same job.”  Which has kind of gone out of style for 
obvious reasons (though still prevelant in practice).

2) How does tracing back activity go?  If Gil & Charles decide to collude and 
do horrible things, I see this on SMF or whatever I’m using to monitor these 
guys, then I have to go back to another system of record to see who had those 
IDs during what time (hoping that all that data is up to date, accurate and 
available)  ?  

3)  Is this a band-aid, where having MF-RACF (or whichever ESM) passphrases / 2 
factor auth would seemingly be preferable, but for whatever reason people 
can’t/won’t do this?

4) I get the value for privileged IDs that say a production support dev or 
infrastructure team that’s 2nd level, or oncall might not need everyday, but 
might need in a “break glass” scenario; but day to day - would it make sense?  
Certainly if the alternative is the standard password character pool and it’s 
30 year old lack of entropy, then anything is an improvement - but given the 
headaches in doing a huge new process / tooling - I wonder if time wouldn’t be 
better spent updating the ESM settings + 2 factor?


Chad


> On Nov 22, 2016, at 10:52 AM, James Peddycord  wrote:
> 
> NTAC:3NS-20
> Our company is undergoing a project to 'protect privileged access' by using a 
> password vaulting product. We have been doing this for quite some time for 
> applications teams who require higher levels of access to production datasets 
> for problem resolution, installs, etc.
> The way it works is that a pool of logonids is created, along with an AD 
> group that allows the appropriate applications folks to be able to 'check 
> out' one of these pooled logonids for 24 hours via a web interface. The web 
> interface uses the users lan password plus their secure key passcode and 
> phrase to validate their identity.
> The project has now included Windows and Unix server admins, but instead of a 
> pooled logonid these users have separate logonids with admin access and they 
> 'check out' their own individual administrator logonid.
> Now the project has moved into the mainframe systems programmer space. So far 
> we have used the 'privileges' on the logonid records as defined by our 
> security product to limit this vaulting. Users with 'security' access must 
> check out logonids from the vault. Users with the non-cncl privilege are next.
> During project discussions it has been brought up that the systems 
> programmers, with their access to SYS1 datasets and operator commands, are 
> privileged users by nature, and that eventually they are going to want to 
> vault this access. We (the systems programmers) are strongly against this.
> It looks like at some point we will lose our battle and our access to the 
> mainframe will be vaulted, meaning my entire team will need to check a 
> logonid out of the password vault every morning before starting work. Our 
> main argument now is that we do not want these logonids to be generic, pooled 
> logonids, we want them to be basically the same as our own logonids so that 
> we can see who did what by using the mainframe's built in logging (SMF data, 
> ISPF stats, etc...).
> 
> My questions are, are other companies using password vaulting or other 
> multi-level authentication for mainframe systems programmer access?
> What else could we use in our argument against using generic, pooled logonids?
> 
> Thanks in advance!
> 
> Jim
> 
> --
> 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: [EXTERNAL] Re: REXX determine library that is executed from

[Dyck, Lionel B. (TRA)]

Here is my contribution - it is a rexx exec that will check the STEPLIB (or 
provided ddname) for apf authorization.  It uses the console interface to get 
the apf list and then uses lista to find the dsnames in the allocation.  The 
challenge is that lista does not provide the volser so the assumption is that 
the dataset is on the cataloged volume for both steplib and apflist

/*   rexx procedure   *
 | Name:  CHKAPFSL|
 ||
 | Function:  Check the datasets in a STEPLIB concatenation   |
 |against the list of APF authorized libraries|
 ||
 | Syntax:%chkapfsl ddname|
 ||
 |   ddname defaults to STEPLIB   |
 ||
 | Usage Notes: Must have a DD that references the STEPLIB|
 |  Assumes the Dataset is cataloged  |
 ||
 | Author:Lionel B. Dyck  |
 ||
 | History:  (most recent on top) |
 |11/22/16 - Creation |
 ||
 * -- */
 arg dd
 
 parse value '' with null dsns
 if dd = null then dd = 'STEPLIB'
 
/* - *
 * Setup the CONSOLE command environment *
 * - */
"CONSPROF SOLDISP(no) SOLNUM(400) UNSOLDISP(yes)"
"CONSOLE ACTIVATE"
 
/* - *
 * Execute the provided z/OS Command *
 * - */
"CONSOLE SYSCMD(D PROG,APF)"
 
/* --- *
 * Retrieve the results of the z/OS Command.   *
 * *
 * Note that the default wait time is 30 seconds. That value   *
 * can be changed to any time frame that you need. Be aware that   *
 * it is a maximum wait time and that if the command ends before   *
 * that limit is reached then the results will be returned without *
 * waiting for the wait time to expire.*
 * --- */
rc = GETMSG('t.','sol',,,30)
 
/* - *
 * Close out the CONSOLE environment *
 * - */
"CONSOLE DEACTIVATE"
 
/* - *
 | Get APF list into usable stem |
 * - */
 do i = 1 to t.0
if word(t.i,1) = 'ENTRY' then leave
end
 do il = i+1 to t.0
parse value t.il with lib vol dsn
apf.dsn = vol
dsns = dsns dsn
end
 
/* - *
 | Now get the list of DSNAMEs in the ddname |
 * - */
 
 call outtrap 'trap.'
 "lista sta"
 call outtrap 'off'
 
 hit = 0
 cnt = 0
 tdd = null
 
 do i = 1 to trap.0
if tdd = dd then hit = 1
if hit = 1 then
   if tdd <> dd then leave
if left(trap.i,2) = "--" then iterate
if left(trap.i,1) <> " " then do
   dsn = word(trap.i,1)
   end
else do
 if left(trap.i,3) = "   " then do
 if tdd <> dd then iterate
 cnt = cnt + 1
 dsn.cnt = tdd dsn
 end
   else do
tdd = word(trap.i,1)
if tdd <> dd then iterate
cnt = cnt + 1
dsn.cnt = tdd dsn
end
   end
end
 
  do i = 1 to cnt
 stepdsn = word(dsn.i,2)
 if wordpos(stepdsn,dsns) = 0 then
say stepdsn 'is not APF authorized'
 end


--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer 
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Donald Likens
Sent: Tuesday, November 22, 2016 12:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: REXX determine library that is executed from

I failed to mention that when using EXEC 'rexx.library'. (where 'rexx.library' 
contains member TEMPNAME.)

I am thinking about looking at the output of LISTA but not sure it is worth the 
effort. If anyone else has a need for this capability I may be able to work 
something out and post it.

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

Re: Mainframe systems programmer ID 'vaulting'

[Bigendian Smalls]

This is something I hadn’t heard much about, but a couple questions come to 
mind - for anyone who has thought about or implemented this:

1) If you have a pool of IDs, then are you losing granularity with which you 
might want to assign privelages?  Meaning you now have to have IDs that have 
exactly the same permissions - if they are user-agnostic (among some class of 
users obviously, like DEVs or SYSPROGs or whatever) - Seems like that is back 
to the old, “Create a new id.  What perms to give him? Dunno, just build it 
like Chad’s, they have the same job.”  Which has kind of gone out of style for 
obvious reasons (though still prevelant in practice).

2) How does tracing back activity go?  If Gil & Charles decide to collude and 
do horrible things, I see this on SMF or whatever I’m using to monitor these 
guys, then I have to go back to another system of record to see who had those 
IDs during what time (hoping that all that data is up to date, accurate and 
available)  ?   

3)  Is this a band-aid, where having MF-RACF (or whichever ESM) passphrases / 2 
factor auth would seemingly be preferable, but for whatever reason people 
can’t/won’t do this?

4) I get the value for privileged IDs that say a production support dev or 
infrastructure team that’s 2nd level, or oncall might not need everyday, but 
might need in a “break glass” scenario; but day to day - would it make sense?   
Certainly if the alternative is the standard password character pool and it’s 
30 year old lack of entropy, then anything is an improvement - but given the 
headaches in doing a huge new process / tooling - I wonder if time wouldn’t be 
better spent updating the ESM settings + 2 factor?


Chad


> On Nov 22, 2016, at 10:52 AM, James Peddycord  wrote:
> 
> NTAC:3NS-20
> Our company is undergoing a project to 'protect privileged access' by using a 
> password vaulting product. We have been doing this for quite some time for 
> applications teams who require higher levels of access to production datasets 
> for problem resolution, installs, etc.
> The way it works is that a pool of logonids is created, along with an AD 
> group that allows the appropriate applications folks to be able to 'check 
> out' one of these pooled logonids for 24 hours via a web interface. The web 
> interface uses the users lan password plus their secure key passcode and 
> phrase to validate their identity.
> The project has now included Windows and Unix server admins, but instead of a 
> pooled logonid these users have separate logonids with admin access and they 
> 'check out' their own individual administrator logonid.
> Now the project has moved into the mainframe systems programmer space. So far 
> we have used the 'privileges' on the logonid records as defined by our 
> security product to limit this vaulting. Users with 'security' access must 
> check out logonids from the vault. Users with the non-cncl privilege are next.
> During project discussions it has been brought up that the systems 
> programmers, with their access to SYS1 datasets and operator commands, are 
> privileged users by nature, and that eventually they are going to want to 
> vault this access. We (the systems programmers) are strongly against this.
> It looks like at some point we will lose our battle and our access to the 
> mainframe will be vaulted, meaning my entire team will need to check a 
> logonid out of the password vault every morning before starting work. Our 
> main argument now is that we do not want these logonids to be generic, pooled 
> logonids, we want them to be basically the same as our own logonids so that 
> we can see who did what by using the mainframe's built in logging (SMF data, 
> ISPF stats, etc...).
> 
> My questions are, are other companies using password vaulting or other 
> multi-level authentication for mainframe systems programmer access?
> What else could we use in our argument against using generic, pooled logonids?
> 
> Thanks in advance!
> 
> Jim
> 
> --
> 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: REXX determine library that is executed from

[Donald Likens]

I failed to mention that when using EXEC 'rexx.library'. (where 'rexx.library' 
contains member TEMPNAME.)

I am thinking about looking at the output of LISTA but not sure it is worth the 
effort. If anyone else has a need for this capability I may be able to work 
something out and post it.

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

Re: Which STEPLIB concatenation is not authorized?

[Charles Mills]

You know what I am thinking of doing? Yes, it would be great to loop through 
all of the concatenations of STEPLIB and display the APF status of each. More 
time than I can justify at this moment. But what about the following? Wouldn't 
this solve the problem? A very simple program that would open a vanilla input 
DCB for SYSUT1, chain to the DEB and check the APF bit (DEBAPFIN?), and then 
issue a yay/nay WTO? A customer would have to copy the STEPLIB concatenations 
DD's one at a time into the SYSUT1 DD in a simple little jobstep, but that 
should be do-able. Advantage over a display command and IEHIBALL? If they 
copied it exactly as it was specified in STEPLIB then it would avoid all 
eyeball checks on the exact dataset name, multiple instances of a name on 
different VOLSERs, etc.

The source should be small enough to paste here, and I would do so if there is 
interest.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 22, 2016 6:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Which STEPLIB concatenation is not authorized?

On 11/22/2016 5:06 AM, Peter Relson wrote:
>
> What the system has, and could return (indeed does provide to the 
> CSVFETCH exit as of z/OS 2.2) is the UCB address and CCHH of the data 
> set. I don't claim to know exactly how, but you can get from that to the data 
> set name.
> An enhancement could be made to CSVQUERY/CSVINFO to provide that data.

I assume one would use the UCB address to get the volser, then process the VTOC 
using CVAFSEQ or similar to find which data set is located at that CCHH.

Hopefully, CVAFSEQ et al has no APF requirement. It would be an unfortunate 
catch-22 if only an authorized program could determine with certainty why it's 
not running authorized...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

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

Re: Which STEPLIB concatenation is not authorized?

[John McKown]

On Tue, Nov 22, 2016 at 11:35 AM, Charles Mills  wrote:

> > And those for whom this too complicated: don't touch a z/OS system until
> you have covered the dummies course.
>
> I'll tell the support staff to start telling that to the POCs. I'm sure the
> sales team will be pleased.
>

​INSTALLATION INSTRUCTIONS:

1) Hire someone who can read and is not a complete idiot.
...​



>
> Charles
>
>

-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

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

Re: Which STEPLIB concatenation is not authorized?

[Charles Mills]

> And those for whom this too complicated: don't touch a z/OS system until
you have covered the dummies course.

I'll tell the support staff to start telling that to the POCs. I'm sure the
sales team will be pleased.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Vernooij, Kees (ITOPT1) - KLM
Sent: Tuesday, November 22, 2016 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Which STEPLIB concatenation is not authorized?

Altogether, to me this all seems a tremendous overkill for a problem that
occurs a few time per year somewhere in the world.
How many system programmers does it take to switch a lightbulb? How many to
check a steplib concatenation on 047 abends? 

Take your libraries and check them against D PROG,APF and you know what
you're looking for. 
And those for whom this too complicated: don't touch a z/OS system until you
have covered the dummies course.

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

Re: Mainframe systems programmer ID 'vaulting'

[Steve]

Part 2 of the Story is that once all the bugs are fix/ironed out, ANYONE with a 
privileged USERID ID will have to LOGON Using CyberArk just to do their daily 
work.  This includes SECURITY, and SYSPROGS
 
 
Steve Beaver






This electronic mail (including any attachments) may contain information that 
is privileged, confidential, and/or otherwise protected from disclosure to 
anyone other than its intended recipient(s). Any dissemination or use of this 
electronic email or its contents (including any attachments) by persons other 
than the intended recipient(s) is strictly prohibited. If you have received 
this message in error, please notify us immediately by reply email so that we 
may correct our internal records. Please then delete the original message 
(including any attachments) in its entirety. Thank you


-Original Message-
From: "James Peddycord" 
Sent: Tuesday, November 22, 2016 11:52am
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Mainframe systems programmer ID 'vaulting'



NTAC:3NS-20
Our company is undergoing a project to 'protect privileged access' by using a 
password vaulting product. We have been doing this for quite some time for 
applications teams who require higher levels of access to production datasets 
for problem resolution, installs, etc.
The way it works is that a pool of logonids is created, along with an AD group 
that allows the appropriate applications folks to be able to 'check out' one of 
these pooled logonids for 24 hours via a web interface. The web interface uses 
the users lan password plus their secure key passcode and phrase to validate 
their identity.
The project has now included Windows and Unix server admins, but instead of a 
pooled logonid these users have separate logonids with admin access and they 
'check out' their own individual administrator logonid.
Now the project has moved into the mainframe systems programmer space. So far 
we have used the 'privileges' on the logonid records as defined by our security 
product to limit this vaulting. Users with 'security' access must check out 
logonids from the vault. Users with the non-cncl privilege are next.
During project discussions it has been brought up that the systems programmers, 
with their access to SYS1 datasets and operator commands, are privileged users 
by nature, and that eventually they are going to want to vault this access. We 
(the systems programmers) are strongly against this.
It looks like at some point we will lose our battle and our access to the 
mainframe will be vaulted, meaning my entire team will need to check a logonid 
out of the password vault every morning before starting work. Our main argument 
now is that we do not want these logonids to be generic, pooled logonids, we 
want them to be basically the same as our own logonids so that we can see who 
did what by using the mainframe's built in logging (SMF data, ISPF stats, 
etc...).

My questions are, are other companies using password vaulting or other 
multi-level authentication for mainframe systems programmer access?
What else could we use in our argument against using generic, pooled logonids?

Thanks in advance!

Jim

--
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: Mainframe systems programmer ID 'vaulting'

[Steve]

Jim - You just hit my ballpark
 
We have tried out CA and CyberArk.  We opted for CyberArk, however they have 
absolutely not idea what TN3270 is.  CyberArk has attempted, to write their own 
TN3270 using open Source and its a disaster.  There was a call today with 
CyberArk and they were told to get away from Open Source and/or the "Not 
written here" philosophy and give use a way to use Reflections inside CyberArk.
 
CyberArk cures the "'protect privileged access' but does not cure the Mainframe 
access we need.  We run zVM and Redhat Linux but until they fix the TN3270 
pushing them on Linux is useless.
 
We also user SmartCards with 6 digit pins.  Unless you have that, your are 
looking at MAJOR Dollars to get that in-place and implement for 2FA
 
 
Steve Beaver




This electronic mail (including any attachments) may contain information that 
is privileged, confidential, and/or otherwise protected from disclosure to 
anyone other than its intended recipient(s). Any dissemination or use of this 
electronic email or its contents (including any attachments) by persons other 
than the intended recipient(s) is strictly prohibited. If you have received 
this message in error, please notify us immediately by reply email so that we 
may correct our internal records. Please then delete the original message 
(including any attachments) in its entirety. Thank you


-Original Message-
From: "James Peddycord" 
Sent: Tuesday, November 22, 2016 11:52am
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Mainframe systems programmer ID 'vaulting'



NTAC:3NS-20
Our company is undergoing a project to 'protect privileged access' by using a 
password vaulting product. We have been doing this for quite some time for 
applications teams who require higher levels of access to production datasets 
for problem resolution, installs, etc.
The way it works is that a pool of logonids is created, along with an AD group 
that allows the appropriate applications folks to be able to 'check out' one of 
these pooled logonids for 24 hours via a web interface. The web interface uses 
the users lan password plus their secure key passcode and phrase to validate 
their identity.
The project has now included Windows and Unix server admins, but instead of a 
pooled logonid these users have separate logonids with admin access and they 
'check out' their own individual administrator logonid.
Now the project has moved into the mainframe systems programmer space. So far 
we have used the 'privileges' on the logonid records as defined by our security 
product to limit this vaulting. Users with 'security' access must check out 
logonids from the vault. Users with the non-cncl privilege are next.
During project discussions it has been brought up that the systems programmers, 
with their access to SYS1 datasets and operator commands, are privileged users 
by nature, and that eventually they are going to want to vault this access. We 
(the systems programmers) are strongly against this.
It looks like at some point we will lose our battle and our access to the 
mainframe will be vaulted, meaning my entire team will need to check a logonid 
out of the password vault every morning before starting work. Our main argument 
now is that we do not want these logonids to be generic, pooled logonids, we 
want them to be basically the same as our own logonids so that we can see who 
did what by using the mainframe's built in logging (SMF data, ISPF stats, 
etc...).

My questions are, are other companies using password vaulting or other 
multi-level authentication for mainframe systems programmer access?
What else could we use in our argument against using generic, pooled logonids?

Thanks in advance!

Jim

--
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: Which STEPLIB concatenation is not authorized?

[Ed Jaffe]

On 11/22/2016 5:06 AM, Peter Relson wrote:


What the system has, and could return (indeed does provide to the CSVFETCH
exit as of z/OS 2.2) is the UCB address and CCHH of the data set. I don't
claim to know exactly how, but you can get from that to the data set name.
An enhancement could be made to CSVQUERY/CSVINFO to provide that data.


I assume one would use the UCB address to get the volser, then process 
the VTOC using CVAFSEQ or similar to find which data set is located at 
that CCHH.


Hopefully, CVAFSEQ et al has no APF requirement. It would be an 
unfortunate catch-22 if only an authorized program could determine with 
certainty why it's not running authorized...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Mainframe systems programmer ID 'vaulting'

[James Peddycord]

NTAC:3NS-20
Our company is undergoing a project to 'protect privileged access' by using a 
password vaulting product. We have been doing this for quite some time for 
applications teams who require higher levels of access to production datasets 
for problem resolution, installs, etc.
The way it works is that a pool of logonids is created, along with an AD group 
that allows the appropriate applications folks to be able to 'check out' one of 
these pooled logonids for 24 hours via a web interface. The web interface uses 
the users lan password plus their secure key passcode and phrase to validate 
their identity.
The project has now included Windows and Unix server admins, but instead of a 
pooled logonid these users have separate logonids with admin access and they 
'check out' their own individual administrator logonid.
Now the project has moved into the mainframe systems programmer space. So far 
we have used the 'privileges' on the logonid records as defined by our security 
product to limit this vaulting. Users with 'security' access must check out 
logonids from the vault. Users with the non-cncl privilege are next.
During project discussions it has been brought up that the systems programmers, 
with their access to SYS1 datasets and operator commands, are privileged users 
by nature, and that eventually they are going to want to vault this access. We 
(the systems programmers) are strongly against this.
It looks like at some point we will lose our battle and our access to the 
mainframe will be vaulted, meaning my entire team will need to check a logonid 
out of the password vault every morning before starting work. Our main argument 
now is that we do not want these logonids to be generic, pooled logonids, we 
want them to be basically the same as our own logonids so that we can see who 
did what by using the mainframe's built in logging (SMF data, ISPF stats, 
etc...).

My questions are, are other companies using password vaulting or other 
multi-level authentication for mainframe systems programmer access?
What else could we use in our argument against using generic, pooled logonids?

Thanks in advance!

Jim

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

Re: Catalogs in a SYSPLEX

[van der Grijn, Bart (B)]

We run two sysplexes of about 12 LPARs each (NonProd vs Prod). Both plexes have 
a single mcat shared across the plex (but not between plexes). We've upgraded 
these from release to release over the last 10 years and never had to use a 
second master catalog. In fact, I just checked our NonProd mcat and it was 
created on 2007.005. 
We use a single SYSRES with its own catalog, which resides on the SYSRES. The 
SYSRES is swapped every month for a new one, which is how we introduce 
maintenance, or even upgrades. 

I've seen no down sides to a single mcat for our setup, but as others have 
noted, it will depend on the role of each system in the plex. For our setup all 
LPARs serve the same purpose, just for different application instances. 

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Tuesday, November 22, 2016 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Catalogs in a SYSPLEX

" Prior to this job I worked at a shop where we supported sysplexes from a 
single system to up to 10 LPARs in a single sysplex.  The master catalogs were 
not shared , I think I would put forth one big reason for not sharing the 
master catalog, would be system upgrades, when we went through the z/OS 
upgrades, there were times where SYS1. Level data sets location changed from 
one release to the next and the catalog needed to point to the new location for 
the new release.  We would upgrade one LPAR at a time in a sysplex, which was 
once a week, so it would be several weeks to complete a sysplex."

This is a non-starter. As far as I am concerned, everything that can be shared 
should be shared (Two of anything that do not agree worse than nothing). If you 
go with separate MCATS, you must spend a great deal of time ensuring they are 
in sync w/each other.

Sure, you need multiple MCATs during the upgrade cycle, but when all is done, 
there should be only one MCAT

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Monday, November 21, 2016 3:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Catalogs in a SYSPLEX

We currently have a 2 LPAR sysplex and the master catalog in not shared.  Prior 
to this job I worked at a shop where we supported sysplexes from a single 
system to up to 10 LPARs in a single sysplex.  The master catalogs were not 
shared , I think I would put forth one big reason for not sharing the master 
catalog, would be system upgrades, when we went through the z/OS upgrades, 
there were times where SYS1. Level data sets location changed from one release 
to the next and the catalog needed to point to the new location for the new 
release.  We would upgrade one LPAR at a time in a sysplex, which was once a 
week, so it would be several weeks to complete a sysplex.

I think there are a lot of questions you have to ask yourself about how you are 
going to handle the sysplex and what you are going to keep in the master 
catalog, besides SYS1.  Note: I believe System Symbols are your friend when 
setting up the catalog, for both data set names and VOLSER.


Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Travis
Sent: Monday, November 21, 2016 3:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Catalogs in a SYSPLEX

We are creating a SYSPLEX of two systems and there seems to be some debate 
about using a single shared master catalog or multiple master catalogs on each 
system. The IBM manuals recommend a single shared master catalog but our CE has 
been advocating multiple catalogs. What are the pros and cons of running each? 
We have two identical systems in the PLEX and for right now there is no plan to 
add more, however that could change at any time in the near future.


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

Re: TSO Setup on SSH

[Martin Packer]

I use x3270 all the time. And I've made widespread use of custom key 
sequences to make me more productive. So far so good.

Kirk, you mentioned scripting. I've only had limited success with that. 
One day I'll persist. :-)

But the reason for leaping in is to ask whether - in anyone on the list's 
experience - scripting performance is OK. I ask because this seems 
analogous to the kind of protocol IND£FILE represents, which I always 
found to be slow.

Thoughts?

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2



From:   Kirk Wolf 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   22/11/2016 15:27
Subject:Re: TSO Setup on SSH
Sent by:IBM Mainframe Discussion List 



There are a bunch of pieces that I would have to externalize; maybe some
day.

I don't really find x3270 all that objectionable.  Its fairly easy to
customize and the scripting works fine.
Granted, I don't use it that much; most of my z/OS work is from a shell.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, Nov 22, 2016 at 9:08 AM, John McKown 

wrote:

> On Tue, Nov 22, 2016 at 9:01 AM, Kirk Wolf  wrote:
>
> > ​
> >
> >
> > We do something like this from our Linux workstations.  I wrote a 
script
> > that makes an ssh connection (authenticating with a private key from a
> > password safe) and over this connection it runs a z/OS UNIX command to
> > return a RACF passticket for the userid.   Then it starts x3270 with a
> > automation script that connects through the ssh tunnel and 
automatically
> > logs on to TSO using the passticket.
> >
>
> ​Oh, that is clever. Can you share this? Too bad x3270 is a PITA to use
> compared to most of the Windows 3270 emulators.​ I wish someone would 
take
> the x3270 code and enhance it to use QT or GTK+ or even some other
> windowing framework.
>
>
>
> >
> > Kirk Wolf
> > http://dovetail.com
> >
> >
> --
> Heisenberg may have been here.
>
> Unicode: http://xkcd.com/1726/
>
> 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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: TSO Setup on SSH

[Kirk Wolf]

There are a bunch of pieces that I would have to externalize; maybe some
day.

I don't really find x3270 all that objectionable.  Its fairly easy to
customize and the scripting works fine.
Granted, I don't use it that much; most of my z/OS work is from a shell.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, Nov 22, 2016 at 9:08 AM, John McKown 
wrote:

> On Tue, Nov 22, 2016 at 9:01 AM, Kirk Wolf  wrote:
>
> > ​
> >
> >
> > We do something like this from our Linux workstations.  I wrote a script
> > that makes an ssh connection (authenticating with a private key from a
> > password safe) and over this connection it runs a z/OS UNIX command to
> > return a RACF passticket for the userid.   Then it starts x3270 with a
> > automation script that connects through the ssh tunnel and automatically
> > logs on to TSO using the passticket.
> >
>
> ​Oh, that is clever. Can you share this? Too bad x3270 is a PITA to use
> compared to most of the Windows 3270 emulators.​ I wish someone would take
> the x3270 code and enhance it to use QT or GTK+ or even some other
> windowing framework.
>
>
>
> >
> > Kirk Wolf
> > http://dovetail.com
> >
> >
> --
> Heisenberg may have been here.
>
> Unicode: http://xkcd.com/1726/
>
> 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: IBM FTPS connect

[Kurt Quackenbush]

On 11/18/2016 9:32 AM, Mark Pace wrote:

Great minds.   I created an Shopz order for an RSU yesterday.

Still having problems with Data connection.  Customer tried several changes
on their firewall without any luck.  They are now going to the vendor to
try to figure why it isn't working.


Good luck.  But again I have to suggest scrapping this effort to use 
FTPS altogether and just use HTTPS instead.  I think you previously said 
the customer does not have the appropriate SMP/E support?  PTF UO01693 
is 18 months old.  Is it really more difficult to apply the SMP/E PTF 
that provides HTTPS support than to struggle with firewalls?


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: TSO Setup on SSH

[John McKown]

On Tue, Nov 22, 2016 at 9:01 AM, Kirk Wolf  wrote:

> ​
>
>
> We do something like this from our Linux workstations.  I wrote a script
> that makes an ssh connection (authenticating with a private key from a
> password safe) and over this connection it runs a z/OS UNIX command to
> return a RACF passticket for the userid.   Then it starts x3270 with a
> automation script that connects through the ssh tunnel and automatically
> logs on to TSO using the passticket.
>

​Oh, that is clever. Can you share this? Too bad x3270 is a PITA to use
compared to most of the Windows 3270 emulators.​ I wish someone would take
the x3270 code and enhance it to use QT or GTK+ or even some other
windowing framework.



>
> Kirk Wolf
> http://dovetail.com
>
>
-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

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

Re: TSO Setup on SSH

[Kirk Wolf]

On Tue, Nov 22, 2016 at 12:03 AM, Jack J. Woehr  wrote:

>
> SSH and secure Telnet3270E essentially use the same security technology,
> that is, OpenSSL.
>

 z/OS OpenSSH does include some of the EVP crypto code from OpenSSL for
Ciphers and MACs, etc, but it doesn't use any "SSL" or "TLS" functionality.
  IBM's port also includes support for ICSF algorithms, which bypass the
OpenSSL Ciphers and MACs completely.   To say the it is the same security
technology as TN3270 is very misleading IMO.


>ssh -Llocalhost:12345:myzosbox:23 myid@myzosbox


>

> and after you have logged in via ssh a redirection is established from
> your local port 12345 to z/OS's port 23.
>
> After establishing the redirect, use PCOMM to connect to localhost:12345
> ... Thus, you will be going into the z/OS port 23 via the redirect via SSH
> port 22 on the z/OS box.
>

We do something like this from our Linux workstations.  I wrote a script
that makes an ssh connection (authenticating with a private key from a
password safe) and over this connection it runs a z/OS UNIX command to
return a RACF passticket for the userid.   Then it starts x3270 with a
automation script that connects through the ssh tunnel and automatically
logs on to TSO using the passticket.

Kirk Wolf
http://dovetail.com

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

Re: New SDSF Function for APF/PARM/PAG/ etc. (was Which STEPLIB concatenation is not authorized?)

[Richards, Robert B.]

Plus three new ones: AS, DYNX and PROC

The enhancements are available through functional PTFs, as listed in Table 4. 
Check the
software status before installing the PTFs to ensure that you have the latest 
maintenance.

Table 4 PTF information

The z/OS V1.13 PTFs are toleration only. The new enhancements are not available 
for
versions earlier than z/OS V2.1; however, these fixes allow the V1.13 to share 
the ISFPRMxx
with systems that have the new functions installed and active.

z/OS V2R2   z/OS V2R1z/OS V1.13
FMIDS   HQX77A0 HQX7790  HQX7780
Toleration and coexistence
UI90060 UI90059  UI90058
AS, DYNX, PROC, and
JC updates  UI41032 PTF UI41034,Not applicable
UI41033

Note: The PROC function is available for z/OS V2R2 only.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, November 22, 2016 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: New SDSF Function for APF/PARM/PAG/ etc. (was Which STEPLIB 
concatenation is not authorized?)

Just in case someone might be interested in this new function in SDSF at z/OS 
V2.1 and V2.2

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lizette Koehler
> Sent: Tuesday, November 22, 2016 7:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which STEPLIB concatenation is not authorized?
>
> Actually this can be in z/OS V2.1 with a PTF
>
> APAR Identifier .. PI60831  Last Changed  16/07/04
>   NEW FUNCTION
>
>
>   Symptom .. NF NEW FUNCTION  Status ... CLOSED  UR1
>   Severity ... 4  Date Closed . 16/06/13
>   Component .. 566548802  Duplicate of 
>   Reported Release . 790  Fixed Release  999
>   Component Name SDSF PLUGIN  Special Notice
>   Current Target Date ..16/06/30  Flags
>   SCP ...
>   Platform 
>
>   Status Detail: SHIPMENT - Packaged solution is available for
> shipment.
>
>   PE PTF List:
>
>   PTF List:
>   Release 7A0   : UI38655 available 16/06/29 (F606 )
>   Release 790   : UI38656 available 16/06/30 (F606 )
>
>   * PROBLEM DESCRIPTION: New function to implement the APF, LNK, *
>   *  LPA, PAG, PARM, and  SYS commands using *
>   *  the z/OSMF SDSF plug-in.
>
> Lizette
>
>
>

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

New SDSF Function for APF/PARM/PAG/ etc. (was Which STEPLIB concatenation is not authorized?)

[Lizette Koehler]

Just in case someone might be interested in this new function in SDSF at z/OS 
V2.1 and V2.2

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Tuesday, November 22, 2016 7:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which STEPLIB concatenation is not authorized?
> 
> Actually this can be in z/OS V2.1 with a PTF
> 
> APAR Identifier .. PI60831  Last Changed  16/07/04
>   NEW FUNCTION
> 
> 
>   Symptom .. NF NEW FUNCTION  Status ... CLOSED  UR1
>   Severity ... 4  Date Closed . 16/06/13
>   Component .. 566548802  Duplicate of 
>   Reported Release . 790  Fixed Release  999
>   Component Name SDSF PLUGIN  Special Notice
>   Current Target Date ..16/06/30  Flags
>   SCP ...
>   Platform 
> 
>   Status Detail: SHIPMENT - Packaged solution is available for
> shipment.
> 
>   PE PTF List:
> 
>   PTF List:
>   Release 7A0   : UI38655 available 16/06/29 (F606 )
>   Release 790   : UI38656 available 16/06/30 (F606 )
> 
>   * PROBLEM DESCRIPTION: New function to implement the APF, LNK, *
>   *  LPA, PAG, PARM, and  SYS commands using *
>   *  the z/OSMF SDSF plug-in.
> 
> Lizette
> 
> 
> 

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

Re: Which STEPLIB concatenation is not authorized?

[Lizette Koehler]

Actually this can be in z/OS V2.1 with a PTF

APAR Identifier .. PI60831  Last Changed  16/07/04
  NEW FUNCTION
 
 
  Symptom .. NF NEW FUNCTION  Status ... CLOSED  UR1
  Severity ... 4  Date Closed . 16/06/13
  Component .. 566548802  Duplicate of 
  Reported Release . 790  Fixed Release  999
  Component Name SDSF PLUGIN  Special Notice
  Current Target Date ..16/06/30  Flags
  SCP ...
  Platform 
 
  Status Detail: SHIPMENT - Packaged solution is available for
shipment.
 
  PE PTF List:
 
  PTF List:
  Release 7A0   : UI38655 available 16/06/29 (F606 )
  Release 790   : UI38656 available 16/06/30 (F606 )

  * PROBLEM DESCRIPTION: New function to implement the APF, LNK, *
  *  LPA, PAG, PARM, and  SYS commands using *
  *  the z/OSMF SDSF plug-in.

Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Vernooij, Kees (ITOPT1) - KLM
> Sent: Tuesday, November 22, 2016 6:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which STEPLIB concatenation is not authorized?
> 
> I didn't know that one, but now I see I also have it in 2.1
> 
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Marchant
> Sent: 22 November, 2016 14:53
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which STEPLIB concatenation is not authorized?
> 
> On Tue, 22 Nov 2016 13:28:14 +, Vernooij, Kees wrote:
> 
> >Take your libraries and check them against D PROG,APF and you know what
> >you're looking for.
> 
> And if you are at z/OS 2.2, the APF command in SDSF is even easier, because
> the list is sorted by DSNAME.
> 
> --
> Tom Marchant
> 

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

Re: Catalogs in a SYSPLEX

[Allan Staller]

" Prior to this job I worked at a shop where we supported sysplexes from a 
single system to up to 10 LPARs in a single sysplex.  The master catalogs were 
not shared , I think I would put forth one big reason for not sharing the 
master catalog, would be system upgrades, when we went through the z/OS 
upgrades, there were times where SYS1. Level data sets location changed from 
one release to the next and the catalog needed to point to the new location for 
the new release.  We would upgrade one LPAR at a time in a sysplex, which was 
once a week, so it would be several weeks to complete a sysplex."

This is a non-starter. As far as I am concerned, everything that can be shared 
should be shared (Two of anything that do not agree worse than nothing). If you 
go with separate MCATS, you must spend a great deal of time ensuring they are 
in sync w/each other.

Sure, you need multiple MCATs during the upgrade cycle, but when all is done, 
there should be only one MCAT

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Monday, November 21, 2016 3:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Catalogs in a SYSPLEX

We currently have a 2 LPAR sysplex and the master catalog in not shared.  Prior 
to this job I worked at a shop where we supported sysplexes from a single 
system to up to 10 LPARs in a single sysplex.  The master catalogs were not 
shared , I think I would put forth one big reason for not sharing the master 
catalog, would be system upgrades, when we went through the z/OS upgrades, 
there were times where SYS1. Level data sets location changed from one release 
to the next and the catalog needed to point to the new location for the new 
release.  We would upgrade one LPAR at a time in a sysplex, which was once a 
week, so it would be several weeks to complete a sysplex.

I think there are a lot of questions you have to ask yourself about how you are 
going to handle the sysplex and what you are going to keep in the master 
catalog, besides SYS1.  Note: I believe System Symbols are your friend when 
setting up the catalog, for both data set names and VOLSER.


Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Travis
Sent: Monday, November 21, 2016 3:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Catalogs in a SYSPLEX

We are creating a SYSPLEX of two systems and there seems to be some debate 
about using a single shared master catalog or multiple master catalogs on each 
system. The IBM manuals recommend a single shared master catalog but our CE has 
been advocating multiple catalogs. What are the pros and cons of running each? 
We have two identical systems in the PLEX and for right now there is no plan to 
add more, however that could change at any time in the near future.

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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




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

Re: Which STEPLIB concatenation is not authorized?

[Vernooij, Kees (ITOPT1) - KLM]

I didn't know that one, but now I see I also have it in 2.1

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: 22 November, 2016 14:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Which STEPLIB concatenation is not authorized?

On Tue, 22 Nov 2016 13:28:14 +, Vernooij, Kees wrote:

>Take your libraries and check them against D PROG,APF and you 
>know what you're looking for.

And if you are at z/OS 2.2, the APF command in SDSF is even 
easier, because the list is sorted by DSNAME.

-- 
Tom Marchant

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

Re: Which STEPLIB concatenation is not authorized?

[Tom Marchant]

On Tue, 22 Nov 2016 13:28:14 +, Vernooij, Kees wrote:

>Take your libraries and check them against D PROG,APF and you 
>know what you're looking for.

And if you are at z/OS 2.2, the APF command in SDSF is even 
easier, because the list is sorted by DSNAME.

-- 
Tom Marchant

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

Re: Catalogs in a SYSPLEX

[Tom Marchant]

On Mon, 21 Nov 2016 21:44:19 +, Nims,Alva John (Al) wrote:

>I would put forth one big reason for not sharing the master catalog, 
>would be system upgrades, when we went through the z/OS upgrades, 
>there were times where SYS1. Level data sets location changed from 
>one release to the next and the catalog needed to point to the new 
>location for the new release.

You can use system symbols for this. Define a symbol to represent the 
volser of every data set that was on volume X that is now on volume Y. 
Recatalog those data sets using the new symbol. When you IPL the new 
system, you will define the symbol to have a value of Y.

When all the systems have been upgraded and you won't be going back, 
recatalog those data sets normally.

Is it a better solution? YMMV. It worked for me way back in the days 
when we had multi-volume SYSRES sets and had to move things. Is 
anyone still using multi-volume sysres?

>System Symbols are your friend when setting up the catalog, for both 
>data set names and VOLSER.

Yes, they are.

-- 
Tom Marchant

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

Re: IBM-MAIN Digest - 20 Nov 2016 to 21 Nov 2016 (#2016-325)

[Steve Thompson]

Binyamin:

Here is how I have things defined, and I do not get the message that you get:

 LAR1,1   Most TU entries will need "1"   
* 
*  ALLOC w/  DDNAME text unit setup   
 LAR9,UT_DDN  Point to first text unit
 USING S99TUNIT,R9R9 points to "current" TU area  
 LAR0,DALRTDDN... TU for ALLOC Return DDname ...  
 STH   R0,S99TUKEY... store in KEY ...
 LAR0,8   ... get length ...  
 STH   R0,S99TULNG... store length ...
 MVC   S99TUPAR(8),SPACE... Clear the DDname w/ blanks


UT_DDN   DSAL2(0,0,0),CL8   DDN to search (INFO), USE (ALLOC) 
   DS0A

The above is copied out of the listing, and you notice there are no message 
lines (I just truncated off the left side, statement number, etc.).

For all SVC99 work, I did not do anything special with the USING statements (no 
labels, etc.). However, I did make use of that with all my DCBs and DECBs.

So, I don't understand, at this point, why you got that warning message (and I 
have Text Units for several different things we are doing with INFO and 
ALLOCation "calls").


Regards,
Steve Thompson

-Original Message-

Date:Mon, 21 Nov 2016 07:03:52 +0200
From:Binyamin Dissen 
Subject: Re: ASMA033I Storage alignment for unfavorable for dependent DSECT?

It is properly aligned in the main dsect.

ZZZ  DSECT
CNOP   2,8
DDNTXTU DS 3H,CL8



@DDNTXTU  USING S99TUNIT,DDNTXTU

STG   R1,@DDNTXTU.S99TUPAR

The assembler knows that the resolved address is at a doubleword offset in ZZZ

On Sun, 20 Nov 2016 15:01:04 -0800 "ste...@copper.net" 
wrote:

:>I don't have access to listings right now, but having just done a few 
routines that were doing SVC99 and making use of all the DSECTs provided by 
IBM, I found that I had to get alignment set up correctly.
:>
:>So, I would start Text Units on a fullword, so that you have (off the top of 
my head):
:>  DS 0A
:>verb  DS H
:>count DS H
:>len   DS H
:>parm  DS X 
:>
:>And then the parm value would be as long as needed. But, I made sure that the 
next text unit started on a full world. I think that will solve your problems.
:>
:>Sorry, I can't remember the correct names of the IBM DSECTs (and their 
related variables) so I could answer you by their names.
:>
:>Regards,
:>Steve Thompson
:>
:>--- bdis...@dissensoftware.com wrote:
:>
:>From: Binyamin Dissen 
:>To:   IBM-MAIN@LISTSERV.UA.EDU
:>Subject: [IBM-MAIN] ASMA033I Storage alignment for unfavorable for dependent 
DSECT?
:>Date: Sun, 20 Nov 2016 22:42:16 +0200
:>
:>I am receiving
:>
:>ASMA033I Storage alignment for @DDNTXTU.S99TUPAR unfavorable 
:>
:>where the value of S99TUPAR is 6, but it is a dependent using and the actual
:>offset is at a doubleword boundary.
:>
:>Working as designed??

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.


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

Re: Which STEPLIB concatenation is not authorized?

[Vernooij, Kees (ITOPT1) - KLM]

Altogether, to me this all seems a tremendous overkill for a problem that 
occurs a few time per year somewhere in the world.
How many system programmers does it take to switch a lightbulb? How many to 
check a steplib concatenation on 047 abends? 

Take your libraries and check them against D PROG,APF and you know what you're 
looking for. 
And those for whom this too complicated: don't touch a z/OS system until you 
have covered the dummies course.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: 22 November, 2016 14:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Which STEPLIB concatenation is not authorized?


IMHO, we need an enhancement to CSVQUERY/CSVINFO (as appropriate) to 
return the fully-qualified data set name and volume and/or HFS path from 
which a module was actually fetched. (If it came from VLF, that 
information would need to be preserved at the time the module is cached 
so it can be provided to CSV.)


I don't see this ever happening. The system does not keep that 
information. The extra cycles to determine that information cannot be 
justified at this time. The system also does not keep information about 
whether the fetch was satisfied from LPA, LNKLST, joblib, steplib, some 
tasklib or some user-specified DCB.

By the way, CSV never actually knows the full file system path name. It 
knows only when USS provides it (which is not necessarily the full name). 
CSVQUERY and CSVINFO *do* provide the file system path name to the 
invoker.


>However, it's not trivial to determine from where you were loaded. It
>could be STEPLIB/JOBLIB, it could be LPA, it could be LNKLST. 

It shouldn't be that hard if you know the member name. Create a DCB 
for STEPLIB and open it. If that works, do a BLDL on the member name 
and if that works, you've found the module. If the BLDL fails, it's not in 

STEPLIB and JOBLIB isn't used. If the open fails, try the same with 
JOBLIB.


It's not "hard" but it's not trivial either.

If you're running under the job, there's no reason to create a DCB for 
STEPLIB and open it, as the DCB already exists and is open. You could just 
do a BLDL yourself using the DCB pointed to by TCBJLB.

Ignoring the user-specified DCB case, the system search is, approximately:
Do for every task from this task repeating using TCBOTC up through the 
jobstep program task
  look for the member in the TCBJLB task if there is one
End Do
Look for the member in LPA
Look for the member in LNKLST

What the system has, and could return (indeed does provide to the CSVFETCH 
exit as of z/OS 2.2) is the UCB address and CCHH of the data set. I don't 
claim to know exactly how, but you can get from that to the data set name. 
An enhancement could be made to CSVQUERY/CSVINFO to provide that data.

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

Re: Which STEPLIB concatenation is not authorized?

[Peter Relson]

IMHO, we need an enhancement to CSVQUERY/CSVINFO (as appropriate) to 
return the fully-qualified data set name and volume and/or HFS path from 
which a module was actually fetched. (If it came from VLF, that 
information would need to be preserved at the time the module is cached 
so it can be provided to CSV.)


I don't see this ever happening. The system does not keep that 
information. The extra cycles to determine that information cannot be 
justified at this time. The system also does not keep information about 
whether the fetch was satisfied from LPA, LNKLST, joblib, steplib, some 
tasklib or some user-specified DCB.

By the way, CSV never actually knows the full file system path name. It 
knows only when USS provides it (which is not necessarily the full name). 
CSVQUERY and CSVINFO *do* provide the file system path name to the 
invoker.


>However, it's not trivial to determine from where you were loaded. It
>could be STEPLIB/JOBLIB, it could be LPA, it could be LNKLST. 

It shouldn't be that hard if you know the member name. Create a DCB 
for STEPLIB and open it. If that works, do a BLDL on the member name 
and if that works, you've found the module. If the BLDL fails, it's not in 

STEPLIB and JOBLIB isn't used. If the open fails, try the same with 
JOBLIB.


It's not "hard" but it's not trivial either.

If you're running under the job, there's no reason to create a DCB for 
STEPLIB and open it, as the DCB already exists and is open. You could just 
do a BLDL yourself using the DCB pointed to by TCBJLB.

Ignoring the user-specified DCB case, the system search is, approximately:
Do for every task from this task repeating using TCBOTC up through the 
jobstep program task
  look for the member in the TCBJLB task if there is one
End Do
Look for the member in LPA
Look for the member in LNKLST

What the system has, and could return (indeed does provide to the CSVFETCH 
exit as of z/OS 2.2) is the UCB address and CCHH of the data set. I don't 
claim to know exactly how, but you can get from that to the data set name. 
An enhancement could be made to CSVQUERY/CSVINFO to provide that data.

Peter Relson
z/OS Core Technology Design


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

Re: The EHIxxxx execs (CBT Tape 769) - Thank you!

[Robert Prins]

On 2016-11-20 12:47, Robert Prins wrote:

Hi all,

After a long, long time, I've decided to update these legacy-language to
HTML tools again, but I need some help, as I'm only on a z/OS 1.10/1.12
system, which means that I have absolutely no clues about

- the way all new JCL statements are coloured, or
- all the latest COBOL keywords.

As PL/I is my language, I do (try to) keep track of what's new in that
language, and I assume, hopefully rightly so, that REXX and Assembler
haven't been changed with new keywords, unless there are new, "no operand
(pseudo-) instructions", like AEJECT, ANOP, COM, CSECT, etc in the
assembler.

I do have one question with regards to SuperC. Yesterday evening I found
that the normal SuperC line compare suddenly(?) displays the "N-LN#" and
"O-#LN" line numbers in green, whereas I know (from old ISPFHTML
screen-prints) that they used to be displayed in blue and yellow. Can
anyone (IBM) confirm that this is indeed a change that was made (and the
why?), or that the old colourisation has returned on z/OS 2.x? In EHISUPC I
will stick with the old colour scheme.

Also, if anyone could send me an up-to-date copy of
'ISP.SISPSAMP(ISRPXASM)' from z/OS 2.x, with hopefully up-to-date language
keyword lists, I'd be most grateful.

And finally, if you would be able to provide me with some
JCL-with-new-keywords screen-prints using Doug Nadel's ISPFHTML utility,
I'd be the happiest bunny in the world! PM me for a copy (20K WinRAR file
containing the manual and XMIT'ed load module), as Doug no longer provides
it due to his retirement - if Marvin Knight is reading this: Making
ISPFHTML available again on a "TASID"-like semi-supported basis would be
ever so nice!

Robert

PS: EHIC and EHIPANEL execs? I'd think about it if there is sufficient
interest...


I would like to thank those of you who were kind enough to send me copies of 
ISRPXASM and screen-prints. The updated EHI'es are available (at the moment 
only via Cut, I'll put up an XMIT version later today) via 
 - any comments on the 
colour-scheme of that page are welcome. ;)


FWIW, I have (not to general approval) removed the "Edit" style option, so hold 
on to any old copies if that's your preferred option.


Robert

Robert



--
Robert AH Prins
robert(a)prino(d)org
No programming (yet) @ http://prino.neocities.org/

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

Re: TSO Setup on SSH

[Bill Woodger]

Venkat,

Can you please clarify exactly what you want to achieve, what point you are 
trying to reach? By "TSO" do you mean, as Paul suspects, you need direct, 
immediate, access to a TSO prompt for some long-superseded limit on some 
requirement from years 'n' years ago? Or do you, by "TSO", mean you still want 
to access things running on the Mainframe (ISPF, CICS, whatever) through a 
terminal emulator on the assumption that there is now some new odd limitation 
on how that was done previously? Or something else?

Can you describe, in words, the way that whatever-it-is works currently, and 
why something now requires some change for exactly the same to be happening in 
the changed situation? 

Else this topic can continue expanding whilst getting nowhere.

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