Re: Manipulating system symbols

[Bruce Hewson]

one point, if you are running CA products, these days some extra symbols get 
populated by CA code - one of which is LPARNAME.

at CAMASTER initialization these symbols get added.

VMUSER
LPARNAME
HRDWNAME
SMFID
OSLEVEL


been this way at least since 2013

Regards
Bruce Hewson

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

Re: z/VM "load from dvd or server"

[Alan Altmark]

> Note: HMC-based "Integrated 3270 Console" works fine, however I would 
> like to use ICC session for some reasons.

You can use ICC after the system is installed.   Specifying ICC address on 
LOADPARM will cause SAPL to come up on that device.  CONS=addr on the SAPL 
panel defines where the OPERATOR will be logged on.


Alan Altmark
IBM

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

Re: z/VM "load from dvd or server"

[Alan Altmark]

> z/VM Installation Manual says I should first launch Integrated 3270 
> console before Load.
> Otherwise I get wait state.
>
> Q: can I use other console instead, for example ICC console?

No, you can't use ICC or other console.  You must use the integrated 3270, just 
as the instructions say.

Alan Altmark
IBM

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

Re: Deleting a dataset that GRS has enqueued.

[Robert A. Rosenberg]

At 18:19 -0800 on 01/30/2016, Skip Robinson wrote about Re: Deleting 
a dataset that GRS has enqueued.:



I'm not sure what ISPF function you're referring to. This happens all the
time in our bronze-plex. Editing SYS1.PARMLIB(ABC) on one system. Cannot
concurrently edit SYS1.PARMLIB(ABC)--different volume--on the other system
because of GRS.


I am thinking of SPFEDIT which uses an RNAME of DSN+MEMBER. There is 
no valid reason IMO for the RNAME to not be DSN+VOLSER+MEMBER except 
for "Foolish Consistency" (as in "Foolish Consistency is the 
Hobgoblin of small minds") to make it match SYSDSN since the VOLSER 
is ALWAYS known at the time the member is opened for editing and thus 
the ENQ being issued.



It's an inconvenience but not a show stopper. Believe me, we
would not have a bronze-plex if our feet had not been put to the fire with
only months to dodge a pricing penalty in late 2007. I'm still amazed that
we pulled it off in such a short time.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net



 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Robert A. Rosenberg
 Sent: Saturday, January 30, 2016 05:54 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.

 At 14:53 -0600 on 01/30/2016, Paul Gilmartin wrote about Re: Deleting a
 dataset that GRS has enqueued.:

 >Even within a single system, to delete a data from one volume when a
 >like named data set on a diferent volume is in use ENQ SHR on the same
 >system.

 This is a irresolvable design flaw (ie: The Volser is not part of the ENQ

- Only

 the DSN) that is hard/impossible to fix based on the different times and

ways

 the ENQ is issued. IOW: The Volume that the dataset resides on can at

times

 be unknown until AFTER the ENQ is issued. Thus there is no way that an ENQ
 on a dataset named DSN1 which is on VOLSER1 can be told from an ENQ for a
 dataset named DSN1 residing on VOLSER2. JES3 made some allowance but
 even it had to work on with DSN and ignore the VOLSERs. There are ENQs

such

 as that used when SPF Editing which get issued with the knowledge of the
 VOLSER where the dataset resides so they can have use the VOLSER to help
 the ENQ be more specific and thus allow editing of members in different
 datasets with the same DSN - I do not know if this occurs or if the

bare-bones

 DSN-Only is used to be the consistent with SYSDSN's RNAME.


--
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: Deleting a dataset that GRS has enqueued.

[Paul Gilmartin]

On Sat, 30 Jan 2016 20:54:20 -0500, Robert A. Rosenberg wrote:

>At 14:53 -0600 on 01/30/2016, Paul Gilmartin wrote about Re: Deleting
>a dataset that GRS has enqueued.:
>
>>Even within a single system, to delete a data from one volume when
>>a like named data set on a diferent volume is in use ENQ SHR on the
>>same system.
>
>This is a irresolvable design flaw (ie: The Volser is not part of the
>ENQ - Only the DSN) that is hard/impossible to fix based on the
>different times and ways the ENQ is issued. ...
>
I said it was hard.  I said also that it's important.  I don't believe it's
impossible.

> ...  IOW: The Volume that the
>dataset resides on can at times be unknown until AFTER the ENQ is
>issued. ...
>
This does not preclude issuing additional ENQs, SHR, incorporating the
VOLSERs in the RNAME at the point in time that the VOLSERs become
known.

Note that I see this as in addition to, not instead of the current ENQ
performed at allocation time which does not incorporate any VOLSER.

> ...Thus there is no way that an ENQ on a dataset named DSN1
>which is on VOLSER1 can be told from an ENQ for a dataset named DSN1
>residing on VOLSER2. ...
>
You are postulating that no ENQ can be deferred until the VOLSER is knowns
This is just current practice, not axiomatically true.

Then deleting a data set or scratching an extent could issue ENQs EXC on
similar VOLSERs+DSN combinations.  If one of those ENQs fails, the data
set is on the same volume and can not be safely deleted.  If all those ENQs
succeed, the data set is on (a) separate volume(s) and may safely be
deleted.

There would be a hazard that the only instance of a DSN could be scratched
before another job opens it.  I believe this is preferable to the current
situation.  I was accustomed to this, DATA SET NOT FOUND, when a data
set was scratched but left catalogued.

>... There are ENQs such as that used
>when SPF Editing which get issued with the knowledge of the VOLSER
>where the dataset resides so they can have use the VOLSER to help the
>ENQ be more specific and thus allow editing of members in different
>datasets with the same DSN - I do not know if this occurs or if the
>bare-bones DSN-Only is used to be the consistent with SYSDSN's RNAME.
> 
I believe ISPF EDIT issues:
o ENQ SHR on DSN (always done by allocation)
o ENQ EXC on member+DSN
... but VOLSER is not involved.  Skip's followup appears to agree with
this (or at least not to contradict it).

-- gil

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

Re: Deleting a dataset that GRS has enqueued.

[Skip Robinson]

I'm not sure what ISPF function you're referring to. This happens all the
time in our bronze-plex. Editing SYS1.PARMLIB(ABC) on one system. Cannot
concurrently edit SYS1.PARMLIB(ABC)--different volume--on the other system
because of GRS. It's an inconvenience but not a show stopper. Believe me, we
would not have a bronze-plex if our feet had not been put to the fire with
only months to dodge a pricing penalty in late 2007. I'm still amazed that
we pulled it off in such a short time.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Robert A. Rosenberg
> Sent: Saturday, January 30, 2016 05:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
> 
> At 14:53 -0600 on 01/30/2016, Paul Gilmartin wrote about Re: Deleting a
> dataset that GRS has enqueued.:
> 
> >Even within a single system, to delete a data from one volume when a
> >like named data set on a diferent volume is in use ENQ SHR on the same
> >system.
> 
> This is a irresolvable design flaw (ie: The Volser is not part of the ENQ
- Only
> the DSN) that is hard/impossible to fix based on the different times and
ways
> the ENQ is issued. IOW: The Volume that the dataset resides on can at
times
> be unknown until AFTER the ENQ is issued. Thus there is no way that an ENQ
> on a dataset named DSN1 which is on VOLSER1 can be told from an ENQ for a
> dataset named DSN1 residing on VOLSER2. JES3 made some allowance but
> even it had to work on with DSN and ignore the VOLSERs. There are ENQs
such
> as that used when SPF Editing which get issued with the knowledge of the
> VOLSER where the dataset resides so they can have use the VOLSER to help
> the ENQ be more specific and thus allow editing of members in different
> datasets with the same DSN - I do not know if this occurs or if the
bare-bones
> DSN-Only is used to be the consistent with SYSDSN's RNAME.

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

Re: Deleting a dataset that GRS has enqueued.

[Skip Robinson]

I don't know of a 'classic' definition. To me bronze-plex is a fully functional 
parallel sysplex that shares little or nothing more than what's required for 
sysplex, essentially the control data sets plus any others that might be needed 
for 'qualifying' sysplex exploiters. JES is not on the list. My bronze-plex 
does indeed contain two different JES(2) nodes that communicate via NJE as if 
they were 1000s of miles apart. 

OTOH I have run configurations before parallel sysplex even existed that 
contained two separate JES2 nodes. Never had a special name for that other than 
primary/secondary. In my mind, bronze-plex is a configuration born, like mine, 
of the need to qualify for parallel sysplex pricing. That actual need has long 
since disappeared due to configuration changes, but splitting the bronze-plex 
apart would require additional hardware resources--at least CF engines and 
maybe memory plus effort to accomplish--that so far have not seemed compelling. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: Saturday, January 30, 2016 03:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
> 
> On 1/30/2016 8:47 AM, Tom Marchant wrote:
> > However, I believe that skip had written in an earlier append that hos
> > bronzeplex was a combination of two sysplexes. If that is the case ...
> 
> A "classic" bronzeplex is two or more JESplexes within a single sysplex.
> 
> --
> 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

Re: Deleting a dataset that GRS has enqueued.

[Robert A. Rosenberg]

At 14:53 -0600 on 01/30/2016, Paul Gilmartin wrote about Re: Deleting 
a dataset that GRS has enqueued.:



Even within a single system, to delete a data from one volume when
a like named data set on a diferent volume is in use ENQ SHR on the
same system.


This is a irresolvable design flaw (ie: The Volser is not part of the 
ENQ - Only the DSN) that is hard/impossible to fix based on the 
different times and ways the ENQ is issued. IOW: The Volume that the 
dataset resides on can at times be unknown until AFTER the ENQ is 
issued. Thus there is no way that an ENQ on a dataset named DSN1 
which is on VOLSER1 can be told from an ENQ for a dataset named DSN1 
residing on VOLSER2. JES3 made some allowance but even it had to work 
on with DSN and ignore the VOLSERs. There are ENQs such as that used 
when SPF Editing which get issued with the knowledge of the VOLSER 
where the dataset resides so they can have use the VOLSER to help the 
ENQ be more specific and thus allow editing of members in different 
datasets with the same DSN - I do not know if this occurs or if the 
bare-bones DSN-Only is used to be the consistent with SYSDSN's RNAME.


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

Re: zEDC

[Scott Barry]

For CPU offload, you have SMF type 74 subtype 9 and SMF type 30 (ZEDC section) 
available to demonstrate activity (after implementation).  Also for SMF 
LOGSTREAMs, you have z/OS LOGR SMF data source as well.  And as far as 
pre-implementation consideration, I've heard that the zBNA utility offering has 
data-volume / time-frame limitations.  We have only started with DSFHSM and 
have done only a small test with PKZIP thus far.

My personal experience to-date with both SMF LOGSTREAMs and sequential-datasets 
(with 4 cards to allow for concurrent maintenance as well as fail-over) is very 
positive.  One point is to ensure current-maintenance for z/OS is 
tracked/maintained.

Scott Barry
SBBWorks, Inc.

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

SimpList 2.3

[Dave Salt]

(Sent with permission of the list owner)

SimpList version 2.3 is available for download. The price is unchanged at 
$8,000 a year in North America, $12,000 elsewhere.

If you're using an older version or would like to try the new version, or just 
want to know what changed, please click the link below. Feel free to contact me 
off-list if you have any questions.

Regards,

Dave Salt

SimpList(tm) - try it; you'll get it! 

http://www.mackinney.com/products/program-development/simplist.html  
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Ed Jaffe]

On 1/30/2016 8:47 AM, Tom Marchant wrote:
However, I believe that skip had written in an earlier append that hos 
bronzeplex was a combination of two sysplexes. If that is the case ...


A "classic" bronzeplex is two or more JESplexes within a single sysplex.

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

Re: UADS vs TSO Segment [was: COBOL v5]

[Joel C. Ewing]

On 01/30/2016 01:05 PM, Ed Gould wrote:
> On Jan 30, 2016, at 11:11 AM, Skip Robinson wrote:
>
>> Ah, UADS. A prime example of archaic mechanism. Defensible technically?
>> Probably not, although a security administrator who needs to know which
>> account numbers or which proclibs a user is authorized to use might
>> tell a
>> different story. With UADS, a simple list command tells the story.
>> With TSOE
>> segment, it's a data mining operation. This difference alone has
>> inhibited
>> conversion in some shops.
>
> Skip:
>
> I disagree with your "defensibility technically" statement.
> we have at least two groups that do the RACF definitions and while
> they are so so technically they cannot seem to do the job correctly
> and add to the measure adding alias's in the mastercats cannot be
> trusted to do so reliably. I don't know how many times I have
> rewritten(multiple times)  rexx and clist and JCL they simply screw it
> up sometimes.
> I had to rein in the catastrophe that they managed to do.
> The UADS is simply far more easy to do than the RACF definition(s).
> They regularly screw that up as well and I have had to redo both. Is
> this a technical issue (a little) is it a personnel issue yes
> , but without firing people there is no easy solution. I get a
> JR sysprog to do any TSO adds (or changes) to UADS and it gets done
> correctly all the time (although admittedly the change can be tricky
> at times)
>
> Ed
>
> ...
>
We migrated to MVS (and RACF) from DOS/VSE around 1985 and had the
advantage of not having to deal with pre-existing MVS application data
set names or pre-existing security conventions (since DOS/VSE
essentially had no security at the time).  I spent several months coming
up with ways based on our existing application and production batch and
end-user group relationships to implement standards for MVS data set
names, TSO PROC and account standards, and a RACF hierarchical group
structure that allowed all the "usual" permissions to be granted via
generic profiles to groups and connects to RACF groups. 

It quickly became apparent (before MVS went into production) that the
only  way to prevent inconsistencies in user and application area setup
was to automate the daily creation/deletion of users and occasional
creation/deletion of application areas, so that all the standard RACF
group relationships, connects, catalog aliases, etc would be setup at
the same time to essentially eliminate the possibility of omitting a
step or accidentally violating installation conventions.  This was
initially done with CLISTs, later converted to REXX EXECs when that
option became available.  Only the Technical Support RACF Administrators
supporting the Corporate RACF Security Administrators had a need for
detailed knowledge of the underlying RACF structures and installation
conventions.

When UADS could be replaced by RACF TSO segments, it was only a matter
of reworking the EXECs used by the day-to-day Corporate RACF
administrators for routine user maintenance and a mass conversion to TSO
Segments, not a matter of retraining, because those individuals had
never used the TSO ACCOUNT command directly.  When TSO  account number
and PROC authorizations to users are consistently done by RACF group
connects, then RACF can also easily list those authorized to a specific
account or logon PROC by listing connects to a related RACF group, which
eliminates one of the mentioned issues with switching from UADS to RACF
TSO Segments.  Frankly I always found the syntax of the UADS ACCOUNT
command to be very ugly by comparison to RACF command syntax and was
glad to eliminate the need for its use.

My perspective is colored by working in an environment where any change
to RACF group structures, or allowed high-level DS qualifiers, or access
to non-application data sets were strictly under Technical Services
control, either directly or indirectly via EXECs written by Tech
Services for use by Corporate RACF Administrators, and the detailed 
procedures to be followed by Corporate RACF Administrators was also
written by Technical Services RACF support.  Based on our experience, I
find it difficult to conceive of how one could set up installation
conventions for security, TSO or otherwise, and expect to consistently
follow those conventions without the aid of installation-developed tools
like our EXECs -- there are just too many separate interrelated actions
involved  with common tasks like user creation to expect a person to do
them repeatedly and reliably by hand.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: [Bulk] Re: COBOL v5

[Skip Robinson]

I think we're on the same page here, though maybe front and back. Security
administration is complicated, but it should be doable by 'admin types'. You
should not need a sysprog for day-to-day security. One of my biggest
objections to typical non-z/OS architecture is the requirement for fully
trained and authorized 'sysadmins' to manage security definitions that are
not just mundane--a business problem of squandering resources--but totally
outside the appropriate limits of system build and support. Security admins
should report up to a manager at the corporate level outside of IT. The way
to accomplish this goal is not to certify security admins in the intricacies
of RACF (with or without UADS), but to provide tools that simplify the
process of managing user and (particularly) data entities. It should be the
admin's job to verify that a certain user is allowed to access a particular
system with permission to some resources but not to others. The tools should
enable the admin to implement that access without knowing RACF or UADS
keywords. If she knows that much, then make her a sysprog and hire another
admin. 

If a shop has properly implemented this sort of management structure, then
security tools are absolutely crucial to the wellbeing of security
administration. This makes migrating to a new security product or
variation--e.g. TSOE segment--problematic because the tools have to
completely rewritten before the first production user can be migrated. This
is not easy or cheap for older, larger shops. Nor can it be done on the sly
without hoopla. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Gould
> Sent: Saturday, January 30, 2016 11:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: [Bulk] Re: COBOL v5
> 
> On Jan 30, 2016, at 11:11 AM, Skip Robinson wrote:
> 
> > Ah, UADS. A prime example of archaic mechanism. Defensible
> > technically?
> > Probably not, although a security administrator who needs to know
> > which account numbers or which proclibs a user is authorized to use
> > might tell a different story. With UADS, a simple list command tells
> > the story.
> > With TSOE
> > segment, it's a data mining operation. This difference alone has
> > inhibited conversion in some shops.
> 
> Skip:
> 
> I disagree with your "defensibility technically" statement.
> we have at least two groups that do the RACF definitions and while they
are so
> so technically they cannot seem to do the job correctly and add to the
> measure adding alias's in the mastercats cannot be trusted to do so
reliably. I
> don't know how many times I have rewritten(multiple times)  rexx and clist
> and JCL they simply screw it up sometimes.
> I had to rein in the catastrophe that they managed to do.
> The UADS is simply far more easy to do than the RACF definition(s).
> They regularly screw that up as well and I have had to redo both. Is this
a
> technical issue (a little) is it a personnel issue yes , but
without firing
> people there is no easy solution. I get a JR sysprog to do any TSO adds
(or
> changes) to UADS and it gets done correctly all the time (although
admittedly
> the change can be tricky at times)
> 
> Ed

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

Re: [Bulk] Re: COBOL v5

[R.S.]

Benefits of move to UADS? 

Should be:
Benefits of move *FROM* UADS?

--
Radoslaw Skorupka
Lodz, Poland






---
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


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

Re: Deleting a dataset that GRS has enqueued.

[Paul Gilmartin]

On Fri, 29 Jan 2016 16:25:22 -0500, Jim Mulder wrote:
>
>"I worked on that project and wrote some of the code.  I think 
>that the reason that it does not apply to an SMS-managed data set is 
>that it conflicts with the concept that you cannot have two 
>SMS-managed data sets with the same name.  The project was designed for 
>the system programmer that is building another system.  For example he 
>might have multiple SYS1.MACLIBs."
>
>  So dealing with the situation of having separate catalogs and 
>SMS-plexes within the same sysplex (and thus allowing more than one
>SMS-managed data set with the same name in the same sysplex) was not
>a design consideration for that project. 
>  
They gotta fix that.  Reading this list the anguish is evident.

Even within a single system, to delete a data from one volume when
a like named data set on a diferent volume is in use ENQ SHR on the
same system.

I know it's not easy.  They gotta fix it.

-- gil

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

Re: Manipulating system symbols

[Skip Robinson]

Alas, all sysres packs all have the same name. Either mirrored for remote DR or 
the same physical volumes for local DR. Different Load Profile names on the HMC 
for a small measure of sanity, but same VOLSERs. So we're in the same 
(life)boat as you. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jerry Whitteridge
> Sent: Saturday, January 30, 2016 11:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Manipulating system symbols
> 
> Can you derive the value from your IPL Packs ? Something like:
> 
> SYSDEF SYMDEF(&MVSR1='&SYSR1(1:5).1')
>  SYSDEF SYMDEF(&MVSR2='&SYSR1(1:5).2')
>  SYSDEF SYMDEF(&SYSR2='&SYSR1(1:5).1')
>  SYSDEF SYMDEF(&SYSR3='&SYSR1(1:5).2')
> 
> 
> Otherwise we have been forced to keep multiple sets of SYSDEF based on the
> LPARNAME like :
> 
> SYSDEF LPARNAME(SY01) SYSCLONE(T1)
>LPARNAME(SY01) SYMDEF(&PAXC1IN1.='CCA4')
>LPARNAME(SY01) SYMDEF(&PAXC1IN2.='CCA5')
>LPARNAME(SY01) SYMDEF(&PAXC1IN3.='CCA6')
> 
> And yes - When building new LPARS we have to ensure all the new Symbolics
> are setup
> 
> 
> 
> 
> Jerry Whitteridge
> Manager Mainframe Systems & Storage
> Albertsons - Safeway Inc.
> 925 738 9443
> Corporate Tieline - 89443
> 
> If you feel in control
> you just aren't going fast enough.
> 
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Skip Robinson
> Sent: Saturday, January 30, 2016 11:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Manipulating system symbols
> 
> I have LPAR-derived symbols--all set via the same clumsy tests I showed
> earlier. I created that schema 20 years ago and would like to simplify and
> sleeken (is that a word?) it. Here's why I need the function.
> 
> I run system SYSKIP on three different CECs for business reasons. The
> underlying LPAR names are different based on CEC--LPSKIP1, LPSKIP2, and
> LPSKIP3. All three systems are internally &SYSNAME SYSKIP and look nearly
> identical as necessary for 99% of user function. But some resources like 
> TCP/IP
> and VTAM values need to be unique because I cannot have duplicates in the
> network. I would like to be able to set symbols like &USRTCP and &USRVTAM
> by simply extracting SKIP1/SKIP2/SKIP3 from the LPAR name. Unfortunately
> the 'variable' LPARNAME provided for filtering is not actually a system symbol
> and cannot parsed into substrings.
> 
> This would be so easy in even a rudimentary programming language. I've
> considered doing it in a Rexx that would set symbols via the new z/OS V2
> mechanism, but all this needs to happen very early in a serialized, primal 
> state
> such as IEASYMxx before anything else kicks off. For the record, the LPARs on
> the various CECs are used for production or some flavor of disaster recovery.
> That's why each system needs to 'look the same' in each LPAR.
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> jo.skip.robin...@att.net
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Steve Horein
> > Sent: Saturday, January 30, 2016 10:16 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [Bulk] Re: Manipulating system symbols
> >
> > Are your LPARs related to other things such that you could then take
> > advantage of Symbol substring?
> > http://www-
> >
> 01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae2
> > 00/usesubs.htm
> >
> >
> > On Sat, Jan 30, 2016 at 10:47 AM, Skip Robinson
> > 
> > wrote:
> >
> > > For the first time in ages we are in the process of enhancing our
> > > inventory of user defined system symbols (IEASYMxx). I jumped out
> > > half-cocked and attempted to set a symbol equal to the name of the
> > > current LPAR. That sounds easy, but I cannot find an simple way to
> > > do it. Even pored over the V2R1 doc, which looks much as I remember
> > > it from 1995.
> > >
> > >
> > >
> > > There are three names that can be used in SYSDEF statements: HWNAME,
> > > LPARNAME, and VMUSERID. However, these are available only for
> 'filtering'.
> > > That is, I can do something like
> > >
> > >
> > >
> > > SYSDEF LPARNAME(LPARSKIP)   /* If LPAR name is this */
> > >
> > >   SYMDEF(&USRLPARN='LPARSKIP')   /* Then set user symbol to this */
> > >
> > >
> > >
> > > The problem is that I have to have a separate pair of statements for
> > > every LPAR in the Enterprise. If a new LPAR gets created, I have to
> > > clone a new pair of statements.
> > >
> > >
> > >
> > > What I would like is to be able to set &USRLPARN directly to the
> > > name of the current LPAR whatever it is. One statement that would
> > > serve everywher

Re: Manipulating system symbols

[Jerry Whitteridge]

Can you derive the value from your IPL Packs ? Something like:

SYSDEF SYMDEF(&MVSR1='&SYSR1(1:5).1')
 SYSDEF SYMDEF(&MVSR2='&SYSR1(1:5).2')
 SYSDEF SYMDEF(&SYSR2='&SYSR1(1:5).1')
 SYSDEF SYMDEF(&SYSR3='&SYSR1(1:5).2')


Otherwise we have been forced to keep multiple sets of SYSDEF based on the 
LPARNAME like :

SYSDEF LPARNAME(SY01) SYSCLONE(T1)
   LPARNAME(SY01) SYMDEF(&PAXC1IN1.='CCA4')
   LPARNAME(SY01) SYMDEF(&PAXC1IN2.='CCA5')
   LPARNAME(SY01) SYMDEF(&PAXC1IN3.='CCA6')

And yes - When building new LPARS we have to ensure all the new Symbolics are 
setup




Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Skip Robinson
Sent: Saturday, January 30, 2016 11:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Manipulating system symbols

I have LPAR-derived symbols--all set via the same clumsy tests I showed 
earlier. I created that schema 20 years ago and would like to simplify and 
sleeken (is that a word?) it. Here's why I need the function.

I run system SYSKIP on three different CECs for business reasons. The 
underlying LPAR names are different based on CEC--LPSKIP1, LPSKIP2, and 
LPSKIP3. All three systems are internally &SYSNAME SYSKIP and look nearly 
identical as necessary for 99% of user function. But some resources like TCP/IP 
and VTAM values need to be unique because I cannot have duplicates in the 
network. I would like to be able to set symbols like &USRTCP and &USRVTAM by 
simply extracting SKIP1/SKIP2/SKIP3 from the LPAR name. Unfortunately the 
'variable' LPARNAME provided for filtering is not actually a system symbol and 
cannot parsed into substrings.

This would be so easy in even a rudimentary programming language. I've 
considered doing it in a Rexx that would set symbols via the new z/OS V2 
mechanism, but all this needs to happen very early in a serialized, primal 
state such as IEASYMxx before anything else kicks off. For the record, the 
LPARs on the various CECs are used for production or some flavor of disaster 
recovery. That's why each system needs to 'look the same' in each LPAR.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Steve Horein
> Sent: Saturday, January 30, 2016 10:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Manipulating system symbols
>
> Are your LPARs related to other things such that you could then take
> advantage of Symbol substring?
> http://www-
> 01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae2
> 00/usesubs.htm
>
>
> On Sat, Jan 30, 2016 at 10:47 AM, Skip Robinson 
> wrote:
>
> > For the first time in ages we are in the process of enhancing our
> > inventory of user defined system symbols (IEASYMxx). I jumped out
> > half-cocked and attempted to set a symbol equal to the name of the
> > current LPAR. That sounds easy, but I cannot find an simple way to do
> > it. Even pored over the V2R1 doc, which looks much as I remember it
> > from 1995.
> >
> >
> >
> > There are three names that can be used in SYSDEF statements: HWNAME,
> > LPARNAME, and VMUSERID. However, these are available only for 'filtering'.
> > That is, I can do something like
> >
> >
> >
> > SYSDEF LPARNAME(LPARSKIP)   /* If LPAR name is this */
> >
> >   SYMDEF(&USRLPARN='LPARSKIP')   /* Then set user symbol to this */
> >
> >
> >
> > The problem is that I have to have a separate pair of statements for
> > every LPAR in the Enterprise. If a new LPAR gets created, I have to
> > clone a new pair of statements.
> >
> >
> >
> > What I would like is to be able to set &USRLPARN directly to the name
> > of the current LPAR whatever it is. One statement that would serve
> > everywhere and never need cloning. Am I missing something obvious?
> >
> >

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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.
___

Re: [Bulk] Re: COBOL v5

[R.S.]

With all respect, I think there was enough time to move RYO tools to 
RACF segment.
Proclib - ITYM logon procedue - I see no problem with that. More 
important: I see no problem to authorize users to all procedures, since 
it is method of customization, not resource access control
Not to mention I have never understood the purpose of account numbers 
nowadays.


Benefits of move to UADS? Very little *now*.
But in general it is really good idea to migrate from old solutions 
before IBM announce Enf Of Life for them. Time pressure or upgrade 
stopper is really pain in the a...



Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 2016-01-30 o 18:11, Skip Robinson pisze:

Ah, UADS. A prime example of archaic mechanism. Defensible technically?
Probably not, although a security administrator who needs to know which
account numbers or which proclibs a user is authorized to use might tell a
different story. With UADS, a simple list command tells the story. With TSOE
segment, it's a data mining operation. This difference alone has inhibited
conversion in some shops.

Consider a bigger problem. A shop has been in business for decades. In-house
RYO tools have been developed over the years to enable clerical security
personnel to manage addition, modification, and deletion of userids. All
based on UADS. IBM certainly supports the conversion process, but switching
to TSOE segment would require rewriting all of these in-house tools from the
ground up. Benefit? 'Modernization'. For the vast majority of users, there
is no perceivable difference. Who will fund this change and why? The
business units (clients) who must pony up the funds will not see any
demonstrable benefits. A tough sell. So UADS lives on.

I don't believe that native ISAM is even supported anymore. Back then the
ISAM application I referred to was economical to run because it was old, did
what was needed, and best of all did not require any updating. IIP allowed a
few *external* changes to deliver a major performance boost. An easy
business case to sell.

As I said earlier, I'm not arguing against moving forward with COBOL. Just
seeking some forbearance towards shops that see issues on the horizon.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


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

Re: [Bulk] Re: COBOL v5

[Ed Gould]

On Jan 30, 2016, at 11:11 AM, Skip Robinson wrote:

Ah, UADS. A prime example of archaic mechanism. Defensible  
technically?
Probably not, although a security administrator who needs to know  
which
account numbers or which proclibs a user is authorized to use might  
tell a
different story. With UADS, a simple list command tells the story.  
With TSOE
segment, it's a data mining operation. This difference alone has  
inhibited

conversion in some shops.


Skip:

I disagree with your "defensibility technically" statement.
we have at least two groups that do the RACF definitions and while  
they are so so technically they cannot seem to do the job correctly  
and add to the measure adding alias's in the mastercats cannot be  
trusted to do so reliably. I don't know how many times I have  
rewritten(multiple times)  rexx and clist and JCL they simply screw  
it up sometimes.

I had to rein in the catastrophe that they managed to do.
The UADS is simply far more easy to do than the RACF definition(s).  
They regularly screw that up as well and I have had to redo both. Is  
this a technical issue (a little) is it a personnel issue  
yes , but without firing people there is no easy solution. I  
get a JR sysprog to do any TSO adds (or changes) to UADS and it gets  
done correctly all the time (although admittedly the change can be  
tricky at times)


Ed

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

Re: Manipulating system symbols

[Skip Robinson]

I have LPAR-derived symbols--all set via the same clumsy tests I showed 
earlier. I created that schema 20 years ago and would like to simplify and 
sleeken (is that a word?) it. Here's why I need the function.

I run system SYSKIP on three different CECs for business reasons. The 
underlying LPAR names are different based on CEC--LPSKIP1, LPSKIP2, and 
LPSKIP3. All three systems are internally &SYSNAME SYSKIP and look nearly 
identical as necessary for 99% of user function. But some resources like TCP/IP 
and VTAM values need to be unique because I cannot have duplicates in the 
network. I would like to be able to set symbols like &USRTCP and &USRVTAM by 
simply extracting SKIP1/SKIP2/SKIP3 from the LPAR name. Unfortunately the 
'variable' LPARNAME provided for filtering is not actually a system symbol and 
cannot parsed into substrings. 

This would be so easy in even a rudimentary programming language. I've 
considered doing it in a Rexx that would set symbols via the new z/OS V2 
mechanism, but all this needs to happen very early in a serialized, primal 
state such as IEASYMxx before anything else kicks off. For the record, the 
LPARs on the various CECs are used for production or some flavor of disaster 
recovery. That's why each system needs to 'look the same' in each LPAR. 
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Steve Horein
> Sent: Saturday, January 30, 2016 10:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Manipulating system symbols
> 
> Are your LPARs related to other things such that you could then take
> advantage of Symbol substring?
> http://www-
> 01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae2
> 00/usesubs.htm
> 
> 
> On Sat, Jan 30, 2016 at 10:47 AM, Skip Robinson 
> wrote:
> 
> > For the first time in ages we are in the process of enhancing our
> > inventory of user defined system symbols (IEASYMxx). I jumped out
> > half-cocked and attempted to set a symbol equal to the name of the
> > current LPAR. That sounds easy, but I cannot find an simple way to do
> > it. Even pored over the V2R1 doc, which looks much as I remember it
> > from 1995.
> >
> >
> >
> > There are three names that can be used in SYSDEF statements: HWNAME,
> > LPARNAME, and VMUSERID. However, these are available only for 'filtering'.
> > That is, I can do something like
> >
> >
> >
> > SYSDEF LPARNAME(LPARSKIP)   /* If LPAR name is this */
> >
> >   SYMDEF(&USRLPARN='LPARSKIP')   /* Then set user symbol to this */
> >
> >
> >
> > The problem is that I have to have a separate pair of statements for
> > every LPAR in the Enterprise. If a new LPAR gets created, I have to
> > clone a new pair of statements.
> >
> >
> >
> > What I would like is to be able to set &USRLPARN directly to the name
> > of the current LPAR whatever it is. One statement that would serve
> > everywhere and never need cloning. Am I missing something obvious?
> >
> >

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

Re: Manipulating system symbols

[Steve Horein]

Are your LPARs related to other things such that you could then take
advantage of Symbol substring?
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/usesubs.htm


On Sat, Jan 30, 2016 at 10:47 AM, Skip Robinson 
wrote:

> For the first time in ages we are in the process of enhancing our inventory
> of user defined system symbols (IEASYMxx). I jumped out half-cocked and
> attempted to set a symbol equal to the name of the current LPAR. That
> sounds
> easy, but I cannot find an simple way to do it. Even pored over the V2R1
> doc, which looks much as I remember it from 1995.
>
>
>
> There are three names that can be used in SYSDEF statements: HWNAME,
> LPARNAME, and VMUSERID. However, these are available only for 'filtering'.
> That is, I can do something like
>
>
>
> SYSDEF LPARNAME(LPARSKIP)   /* If LPAR name is this */
>
>   SYMDEF(&USRLPARN='LPARSKIP')   /* Then set user symbol to this */
>
>
>
> The problem is that I have to have a separate pair of statements for every
> LPAR in the Enterprise. If a new LPAR gets created, I have to clone a new
> pair of statements.
>
>
>
> What I would like is to be able to set &USRLPARN directly to the name of
> the
> current LPAR whatever it is. One statement that would serve everywhere and
> never need cloning. Am I missing something obvious?
>
>
>
>
>
>
>
> .
>
> .
>
> .
>
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
>   jo.skip.robin...@att.net
>
>
>
>
> --
> 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: Deleting a dataset that GRS has enqueued.

[Skip Robinson]

What Tom said. Running a parallel sysplex, even a bronze one, without GRS 
protection would be, as we observed here recently, 'inconceivable'. The fallout 
of my experiment indicates the need for a Plan B. It's either bypass enqueue 
(File 183 you say?) or, as OP actually did, bring down the enqueuing tasks long 
enough to rename a dataset. 

If it's sandbox, fire away. But in production, in the immortal words of Dirty 
Harry holding a .44, "you've gotta ask yourself one question: 'Do I feel 
lucky?'" OP did the right thing.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tom Marchant
> Sent: Saturday, January 30, 2016 08:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
> 
> On Sat, 30 Jan 2016 11:26:30 -0400, Clark Morris wrote:
> 
> >Could data sets be set up in different catalogs in the bronze-plex with
> >GRS told not to propagate the enqueue (i.e. local to each system) in
> >the 2 LPARS?  If that can be done, would the experiment work
> >differently?  Would any special access be needed?
> 
> I'm not sure what you are asking. Skip said that the data sets are in 
> different
> catalogs on each system.
> 
> If GRS was told that the ENQ was to remain local, then the other system
> wouldn't know that it was enqueued, and would have no problem deleting the
> data set.
> 
> However, I believe that skip had written in an earlier append that hos
> bronzeplex was a combination of two sysplexes. If that is the case, telling 
> GRS
> not to propagate  the ENQ would have been a bad idea because some of the
> other systems in the sysplex would have shared DASD with the system holding
> the ENQ, but they wouldn't have known either.
> 
> --
> Tom Marchant

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

Re: [Bulk] Re: COBOL v5

[Skip Robinson]

Ah, UADS. A prime example of archaic mechanism. Defensible technically?
Probably not, although a security administrator who needs to know which
account numbers or which proclibs a user is authorized to use might tell a
different story. With UADS, a simple list command tells the story. With TSOE
segment, it's a data mining operation. This difference alone has inhibited
conversion in some shops. 

Consider a bigger problem. A shop has been in business for decades. In-house
RYO tools have been developed over the years to enable clerical security
personnel to manage addition, modification, and deletion of userids. All
based on UADS. IBM certainly supports the conversion process, but switching
to TSOE segment would require rewriting all of these in-house tools from the
ground up. Benefit? 'Modernization'. For the vast majority of users, there
is no perceivable difference. Who will fund this change and why? The
business units (clients) who must pony up the funds will not see any
demonstrable benefits. A tough sell. So UADS lives on.

I don't believe that native ISAM is even supported anymore. Back then the
ISAM application I referred to was economical to run because it was old, did
what was needed, and best of all did not require any updating. IIP allowed a
few *external* changes to deliver a major performance boost. An easy
business case to sell.

As I said earlier, I'm not arguing against moving forward with COBOL. Just
seeking some forbearance towards shops that see issues on the horizon. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of R.S.
> Sent: Friday, January 29, 2016 02:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: COBOL v5
> 
> W dniu 2016-01-29 o 19:17, Skip Robinson pisze:
> > We ran an inherited ISAM application in the 80s, a true dog. Then we
> > learned of a VSAM conversion aid that was at the time built in to
> > whatever then passed for DFSMS. It was magical. Simply convert files
> > from ISAM to VSAM and point the application to them. The system
> > automatically transformed all ISAM I/O operations to VSAM and returned
> data to the application as it expected.
> > Absolutely no changes to the application. The result was breath taking.
> >
> > I'd be curious to know if that conversion aid is still delivered with
z/OS.
> >
> It's called IIP - ISAM Interface Program.
> It is designed to use VSAM datasets with ISAM applications. Another reason
to
> not understand people who insisted to use ISAM (which was the case even
> after 2000).
> 
> BTW: Similar example (in human behavior) could be TSO segment. Some
> people still use SYS1.UADS for that, while migration can be done with one
> command, IBM-prepared REXX script. I believe there are no advantages of
> using UADS, despite it is still supported.
> 
> 
> --
> Radoslaw Skorupka
> Lodz, Poland

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

Manipulating system symbols

[Skip Robinson]

For the first time in ages we are in the process of enhancing our inventory
of user defined system symbols (IEASYMxx). I jumped out half-cocked and
attempted to set a symbol equal to the name of the current LPAR. That sounds
easy, but I cannot find an simple way to do it. Even pored over the V2R1
doc, which looks much as I remember it from 1995. 

 

There are three names that can be used in SYSDEF statements: HWNAME,
LPARNAME, and VMUSERID. However, these are available only for 'filtering'.
That is, I can do something like 

 

SYSDEF LPARNAME(LPARSKIP)   /* If LPAR name is this */

  SYMDEF(&USRLPARN='LPARSKIP')   /* Then set user symbol to this */  

 

The problem is that I have to have a separate pair of statements for every
LPAR in the Enterprise. If a new LPAR gets created, I have to clone a new
pair of statements.

 

What I would like is to be able to set &USRLPARN directly to the name of the
current LPAR whatever it is. One statement that would serve everywhere and
never need cloning. Am I missing something obvious?

 

 

 

.

.

.

J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
  jo.skip.robin...@att.net

 


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

Re: Deleting a dataset that GRS has enqueued.

[Tom Marchant]

On Sat, 30 Jan 2016 11:26:30 -0400, Clark Morris wrote:

>Could data sets be set up in different catalogs in the bronze-plex
>with GRS told not to propagate the enqueue (i.e. local to each system)
>in the 2 LPARS?  If that can be done, would the experiment work
>differently?  Would any special access be needed?

I'm not sure what you are asking. Skip said that the data sets are in different 
catalogs on each system.

If GRS was told that the ENQ was to remain local, then the other system 
wouldn't 
know that it was enqueued, and would have no problem deleting the data set.

However, I believe that skip had written in an earlier append that hos 
bronzeplex 
was a combination of two sysplexes. If that is the case, telling GRS not to 
propagate
 the ENQ would have been a bad idea because some of the other systems in the 
sysplex would have shared DASD with the system holding the ENQ, but they 
wouldn't have known either.

-- 
Tom Marchant

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

Re: Deleting a dataset that GRS has enqueued.

[Clark Morris]

On 29 Jan 2016 20:48:15 -0800, in bit.listserv.ibm-main Skip wrote:

>I finally got TSO access. Yay for me. Meaning that I can experiment. I'm
>grateful to this thread for education on what to expect in a crunch. Here's
>what I found as a user who has access to the magic RACF profile. 
>
Could data sets be set up in different catalogs in the bronze-plex
with GRS told not to propagate the enqueue (i.e. local to each system)
in the 2 LPARS?  If that can be done, would the experiment work
differently?  Would any special access be needed?

Clark Morris
>
>1. Allocated two SMS managed data sets from two members of the bronze-plex.
>Same name, different volumes. Cataloged in two different user catalogs. That
>is, two entirely different datasets associated by name only. Allocated SHR
>on one system. Tried to rename on the other system. Got 'data set in use'
>with no opportunity to override GRS. Total failure.
>
> 
>
>2. Allocated two data sets as in #1 except HLQ SYS1, no SMS involved.
>Cataloged on both systems in two different master catalogs. Got the same
>failure: no can do. No opportunity to override GRS. I began to doubt the
>efficacy of the magic profile. 
>
> 
>
>3. Uncatalogued the data set in #2 on the second system. Still on the same
>volume, still enqueued. Note that this cannot be done with SMS data set.
>This time I got a whole nother sequence.
>
> 
>
>+---
>--+
>
>|   Rename Data Set In Use
>|
>
>| Command ===>
>|
>
>|
>|
>
>| Data Set Name . : SYS1.TEST.DELETE   |
>
>| Volume  . . . . : xx
>|
>
>|
>|
>
>|   The system detected that a data set with the above name is in use
>|
>
>|   (possibly on another system) but it cannot determine whether it is the
>|
>
>|   data set you wish to rename. If it is the same data set and any program
>|
>
>|   has it open, renaming it could cause serious system and data integrity
>|
>
>|   problems.
>|
>
>|
>|
>
>|   You have the extra security authority to rename the data set even though
>|
>
>|   its name is in use. Refer to the DFSMS documentation on the RENAME macro
>|
>
>|   for further information.
>|
>
>|
>|
>
>| Instructions:
>|
>
>|   Press ENTER to override data set name protection and rename the data
>|
>
>|   set.
>|
>
>|   Enter CANCEL or EXIT to cancel the rename request.
>|
>
>|
>|
>
>|
>|
>
>+---
>--+
>
> 
>
>I have to conclude from this experiment that cataloging makes all the
>difference. SMS is a factor only because it requires that all datasets be
>cataloged. If a dataset can be uncataloged, then the RACF profile allows
>that dataset to be renamed despite the GRS enqueue.
>
>.
>
>.
>
>.
>
>J.O.Skip Robinson
>
>Southern California Edison Company
>
>Electric Dragon Team Paddler 
>
>SHARE MVS Program Co-Manager
>
>323-715-0595 Mobile
>
>jo.skip.robin...@att.net
>
> 
>
>> -Original Message-
>
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>
>> On Behalf Of Jim Mulder
>
>> Sent: Friday, January 29, 2016 01:25 PM
>
>> To: IBM-MAIN@LISTSERV.UA.EDU
>
>> Subject: Re: Deleting a dataset that GRS has enqueued.
>
>> 
>
>> > We took the easy way out and brought down the two STCs that had the
>
>> > SMS dataset enqueued, then deleted the version of the dataset that was
>
>> > not being used.
>
>> >
>
>> > It was mentioned in this thread that GRS could have been modified to
>
>> > change the scope of the enqueue on the LPAR that the dataset was not
>
>> > being used on by making it local. Therefore no longer considered in
>
>> > use by GRS. I did not try this, but wonder if this was done for a
>
>> > dataset that was already enqueued if this would work... thoughts?
>
>> >
>
>> > I never found or saw mention a straight forward IBM supported way to
>
>> > delete or rename a SMS dataset in this situation.  If someone comes
>
>> > across a way please post I am curious.
>
>> 
>
>> I asked Wayne Rhoten about this.  He replied:
>
>> 
>
>> "I worked on that project and wrote some of the code.  I think that the
>reason
>
>> that it does not apply to an SMS-managed data set is that it conflicts
>with the
>
>> concept that you cannot have two SMS-managed data sets with the same
>
>> name.  The project was designed for the system programmer that is building
>
>> another system.  For example he might have multiple SYS1.MACLIBs."
>
>> 
>
>>   So dealing with the situation of having separate catalogs and SMS-plexes
>
>> within the same sysplex (and thus allowing more than one SMS-managed data
>
>> set with the same name in the same sysplex) was not a design consideration
>
>> for that project.
>
>> 
>
>> Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY
>
>> 
>
>> 
>
>> --
>
>> For IBM-MAIN subscribe / signoff / archive access instructions, send email
>to
>
>>