Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Edward Gould]

> On Jul 12, 2017, at 5:33 AM, John Eells  wrote:
> 
> 
> And no, the graphic on p. 35 has nothing to do with robots.  I just thought 
> it was a neat graphic that helped illustrate the modernization of a 25+ year 
> old installation process.\

I guess I have been watching STNG to much it reminded me of a female “Data”.

Ed
> 
> 
> -- 
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.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: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Charles Mills]

> Might DB2/CICS/etc. have their own predefined workflows

Yes

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Turner Cheryl L
Sent: Wednesday, July 12, 2017 5:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and
SYSRES)

Not sure what is being planned but is this an all or nothing proposal?
Meaning you either have to use it for installation or the order doesn't get
installed? I don't know if others here may agree with me, but I, and some
others in my shop, would prefer to use our existing local installation
process. However, I would not impede an alternative from being developed, if
my future replacement may find it a better alternative and want to use it. 

We, like others, use z/OSMF purely because of the Communication Server
requirement.  In our shop, fortunate or no, one person is also not
responsible for installing key components (i.e. z/OS is by itself.
CICS/DB2/MQ and various vendor and IBM supplemental products are installed
by several other individuals and their migration may happen after the z/OS
install is complete.)  Has this post installation separation of components
also been taken into consideration/discussed with the z/OSMF process? Might
DB2/CICS/etc. have their own predefined workflows or would the CBPDO or like
process still be applicable in that situation?

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

Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Charles Mills]

BMC was very, very much on-board from the get-go in the design of the
installation process, so I would think that whatever internal knowledge BMC
had of how to make a good install process got incorporated into the z/OSMF
process.

Charles




Good point.
Since the term 'ISV' has already been mentioned, I would like to point to
BMC's ISR installation system for an example of ease of use and flexibility.
With a couple of panels, you select, download and unpack your software. With
another couple of jobs (panel driven) all the SMP work is done and the
software is ready. Different people can work with it, installing different
products simultaneously. I found it an eye-opener and relief how easily
software can be installed and maintained since I switched to this installer.

Maybe z/OSMF can learn one or two userfriendly features from it. 
Beware: since everything is under the cover of the installer, it must be
real good or you will be lost without any clue where to start or go. I can
resist to mention Omegamon as an example of this.

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

Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Carmen Vitullo]

A double AMEN - 
I have not had the luxury of time to use Z/OSMF, my TCPIP guy requested I 
install it for ease of managing TLS Policies, my big mistake was installing the 
product in my /Service directory and there it stayed for almost 2 years. 
a call to suppose and no help fixing my configuration mistakes, so now the ZFS 
file-system needs to be mounted @ /Service. 
No changes I've made, nor any suggestions from support could fix this issue, 
somewhere in the file system, buried is the mount-point and I don't have the 
time to investigate further where this may be. 
I've have had conference calls with the developers to discuss my use and my 
plans for 2.2, and still no offers to help me with something I think support 
can help with or the a developer. ?! 
Now I'm in the process of migration to z/OS 2.2 and went thru the task of 
migrating z/OSMF to 2.2, from what I see all this job did was create a new 
parmlib member but the address space IZUSRV1 in the new proclib does not appear 
to point to ANY PARMLIB's for any configuration information, so I'll wait and 
see my first IPL and startup of Z/osmf. 
documentation is lacking, at least for myself on what the migration tasks are 
suppose to perform. 
my 2 cents 


Carmen 
- Original Message -

From: "Barbara Nitz" <nitz-...@gmx.net> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, July 12, 2017 6:50:07 AM 
Subject: Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and 
SYSRES) 

>But is it a valid data point? We use z/OSMF only insofar as we are forced to 
>for IP configuration and upkeep. We did not use z/OSMF to install v2.2, and I 
>don't know whether we'll use it to install v2.3. There is talk of it, but it 
>seems to be largely motivated by the thought that we will be forced into it 
>(kind of like zFS). 
> 
>Don't get me wrong, we've had talks... I'm with simple and common software 
>management processes, and I'm glad to see ISVs on board, but I'm not convinced 
>that z/OSMF in and of itself is either necessary or sufficient to achieve the 
>goal. If you have good SMP/E packaging, z/OSMF is unnecessary as an installer. 
>If you have crappy SMP/E packaging, front-ending it with z/OSMF will not be 
>sufficient to address the shortfall. 
> 
>I don't see the need for z/OSMF for software deployment. We have plenty of 
>experience here, and are easily passing that along to our newer sysprogs. I 
>recoil at the thought of using it for configuration. ISPF is sufficient to 
>edit PARMLIB, et al, and it runs in a WS client, if you so choose. 
> 
>Seems to me, any of the substantive improvements offered by z/OSMF ought to be 
>UI-agnostic. It doesn't take a "sticky" UI and and the overhead (FSVO minimal) 
>of a server address space to improve product installation. These might have 
>been made accessible ServerPac, or even the SMP/E dialogs, but they weren't. 
>It's a fine thing for someone who wants the trouble of installing and 
>configuring Liberty et al (and I've heard the cursing all the way from Austin 
>and Phoenix), but ISPF apps ought to continue as supported options for those 
>who prefer them. 

Amen to that, from the bottom of my heart. 

I managed to configure ATTLS at z/OS 2.1 just fine without z/OSMF, and 
eventually understood what needs to get done and how things work together, and 
I will certainly not activate z/OSMF under z/OS 2.3. It will be just so much 
more dead weight on the sysres - together with all the useless fonts that were 
pushed down our throats, as far as I am concerned. 

>From the timetable John has sketched in that presentation - it may well be 
>that I will have to use the deadweight to install z/OS 2.5 in 2021. Retirement 
>cannot come soon enough! 

As far as enforcing naming conventions go - we just had that exact same 
discussion here when a vendor naming convention wants to enforce  
usage when that symbol has never been used here. And I am fairly sure that all 
the so-called simplification within z/OSMF will just take away the 
configuration choices that we have grown used to to make all systems look like 
what IBM envisions. 

Barbara 

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


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

Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Vernooij, Kees (ITOPT1) - KLM]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Turner Cheryl L
> Sent: 12 July, 2017 14:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and
> SYSRES)
> 
> Not sure what is being planned but is this an all or nothing proposal?
> Meaning you either have to use it for installation or the order doesn't
> get installed? I don't know if others here may agree with me, but I, and
> some others in my shop, would prefer to use our existing local
> installation process. However, I would not impede an alternative from
> being developed, if my future replacement may find it a better
> alternative and want to use it.
> 
> We, like others, use z/OSMF purely because of the Communication Server
> requirement.  In our shop, fortunate or no, one person is also not
> responsible for installing key components (i.e. z/OS is by itself.
> CICS/DB2/MQ and various vendor and IBM supplemental products are
> installed by several other individuals and their migration may happen
> after the z/OS install is complete.)  Has this post installation
> separation of components also been taken into consideration/discussed
> with the z/OSMF process? Might DB2/CICS/etc. have their own predefined
> workflows or would the CBPDO or like process still be applicable in that
> situation?
> 
> Thanks,
> Cheryl
> 

Good point.
Since the term 'ISV' has already been mentioned, I would like to point to BMC's 
ISR installation system for an example of ease of use and flexibility. With a 
couple of panels, you select, download and unpack your software. With another 
couple of jobs (panel driven) all the SMP work is done and the software is 
ready. Different people can work with it, installing different products 
simultaneously. I found it an eye-opener and relief how easily software can be 
installed and maintained since I switched to this installer. 
Maybe z/OSMF can learn one or two userfriendly features from it. 
Beware: since everything is under the cover of the installer, it must be real 
good or you will be lost without any clue where to start or go. I can resist to 
mention Omegamon as an example of this.

Kees.


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: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Turner Cheryl L]

Not sure what is being planned but is this an all or nothing proposal? Meaning 
you either have to use it for installation or the order doesn't get installed? 
I don't know if others here may agree with me, but I, and some others in my 
shop, would prefer to use our existing local installation process. However, I 
would not impede an alternative from being developed, if my future replacement 
may find it a better alternative and want to use it. 

We, like others, use z/OSMF purely because of the Communication Server 
requirement.  In our shop, fortunate or no, one person is also not responsible 
for installing key components (i.e. z/OS is by itself. CICS/DB2/MQ and various 
vendor and IBM supplemental products are installed by several other individuals 
and their migration may happen after the z/OS install is complete.)  Has this 
post installation separation of components also been taken into 
consideration/discussed with the z/OSMF process? Might DB2/CICS/etc. have their 
own predefined workflows or would the CBPDO or like process still be applicable 
in that situation?

Thanks,
Cheryl

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John Eells
Sent: Tuesday, July 11, 2017 7:36 AM
To: IBM-MAIN@listserv.ua.edu
Subject: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

Peter Hunkeler wrote:
> Topic change due? Possibly more opinions if people understand it is about 
> z/OSF now.
>
>

Peter, good idea.

Everyone: IBM is headed toward using z/OSMF Software Management as the 
installer.  Please go back to near the beginning of this thread with the old 
topic name to catch up on the discussion thus far.

More on the SHARE website, here:

https://share.confex.com/data/handout/share/128/Session_20728_handout_10028_0.pdf

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.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: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Barbara Nitz]

>But is it a valid data point?  We use z/OSMF only insofar as we are forced to 
>for IP configuration and upkeep.  We did not use z/OSMF to install v2.2, and I 
>don't know whether we'll use it to install v2.3.  There is talk of it, but it 
>seems to be largely motivated by the thought that we will be forced into it 
>(kind of like zFS).  
>
>Don't get me wrong, we've had talks... I'm with simple and common software 
>management processes, and I'm glad to see ISVs on board, but I'm not convinced 
>that z/OSMF in and of itself is either necessary or sufficient to achieve the 
>goal.  If you have good SMP/E packaging, z/OSMF is unnecessary as an 
>installer.  If you have crappy SMP/E packaging, front-ending it with z/OSMF 
>will not be sufficient to address the shortfall.
>
>I don't see the need for z/OSMF for software deployment.  We have plenty of 
>experience here, and are easily passing that along to our newer sysprogs.  I 
>recoil at the thought of using it for configuration.  ISPF is sufficient to 
>edit PARMLIB, et al, and it runs in a WS client, if you so choose.
>
>Seems to me, any of the substantive improvements offered by z/OSMF ought to be 
>UI-agnostic.  It doesn't take a "sticky" UI and and the overhead (FSVO 
>minimal) of a server address space to improve product installation.  These 
>might have been made accessible ServerPac, or even the SMP/E dialogs, but they 
>weren't.  It's a fine thing for someone who wants the trouble of installing 
>and configuring Liberty et al (and I've heard the cursing all the way from 
>Austin and Phoenix), but ISPF apps ought to continue as supported options for 
>those who prefer them. 

Amen to that, from the bottom of my heart. 

I managed to configure ATTLS at z/OS 2.1 just fine without z/OSMF, and 
eventually understood what needs to get done and how things work together, and 
I will certainly not activate z/OSMF under z/OS 2.3. It will be just so much 
more dead weight on the sysres - together with all the useless fonts that were 
pushed down our throats, as far as I am concerned.

From the timetable John has sketched in that presentation - it may well be that 
I will have to use the deadweight to install z/OS 2.5 in 2021. Retirement 
cannot come soon enough!

As far as enforcing naming conventions go - we just had that exact same 
discussion here when a vendor naming convention wants to enforce  
usage when that symbol has never been used here. And I am fairly sure that all 
the so-called simplification within z/OSMF will just take away the 
configuration choices that we have grown used to to make all systems look like 
what IBM envisions. 

Barbara

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

Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[John Eells]

Art Gutowski wrote:


At the last SHARE, the question was asked at the multivendor 
installation-related
session about how many in the room were z/OSMF users.  In the past, I've seen
those raising a hand to be perhaps 25% of a similarly-sized crowd, but in March
about 2/3 of those present raised a hand (a pleasant surprise).  Of course, one
room at SHARE does not a valid statistical sample make, but it's one data point.


But is it a valid data point?  We use z/OSMF only insofar as we are forced to 
for IP configuration and upkeep.  We did not use z/OSMF to install v2.2, and I 
don't know whether we'll use it to install v2.3.  There is talk of it, but it 
seems to be largely motivated by the thought that we will be forced into it 
(kind of like zFS).


It's certainly a valid data point (by which I mean, some people sent me 
notes and their estimates were similar!), but it might or might not be 
representative of the population at large.



Don't get me wrong, we've had talks... I'm with simple and common software 
management processes, and I'm glad to see ISVs on board, but I'm not convinced 
that z/OSMF in and of itself is either necessary or sufficient to achieve the 
goal.  If you have good SMP/E packaging, z/OSMF is unnecessary as an installer. 
 If you have crappy SMP/E packaging, front-ending it with z/OSMF will not be 
sufficient to address the shortfall.


SMP/E packaging, good or bad, cannot by itself:

- Aggregate products into a single package with a single installation 
path to use no matter how many products are included
- Support integrating service "back at the ranch" so that you don't have 
to do that on the receiving end
- Address the direction and management of tasks to the appropriate 
people on your teams in the right order
- Help you get through setup tasks that must be done everywhere the 
software is deployed

- ...and so on.

We need a platform to do that, and we have it in z/OSMF.  That's why 
we're going to use it.  Also, one point is that, like ServerPac, you can 
*avoid* the lion's share of the SMP/E-related work.  Another is that 
things that are not SMP/E packaged, and are likely never to be SMP/E 
packaged, can be installed and deployed across your shop with the same 
process.



I don't see the need for z/OSMF for software deployment.  We have plenty of 
experience here, and are easily passing that along to our newer sysprogs.  I 
recoil at the thought of using it for configuration.  ISPF is sufficient to 
edit PARMLIB, et al, and it runs in a WS client, if you so choose.

Seems to me, any of the substantive improvements offered by z/OSMF ought to be 
UI-agnostic.  It doesn't take a "sticky" UI and and the overhead (FSVO minimal) 
of a server address space to improve product installation.  These might have been made 
accessible ServerPac, or even the SMP/E dialogs, but they weren't.  It's a fine thing for 
someone who wants the trouble of installing and configuring Liberty et al (and I've heard 
the cursing all the way from Austin and Phoenix), but ISPF apps ought to continue as 
supported options for those who prefer them.

That's my buck-two-eight-five, after adjusting for inflation. :)


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[John Eells]

Edward Gould wrote:


Interesting but I am not convinced that this is any better than what is 
currently available. It also looks (to me) complicated and one person seems to 
have to be doing “it” from start to end, is that the case?
Slide 35(?) are you trying to show a robot can do this but not a human?


Of course it's complicated, under the covers.  We have a complex 
installation process (too complex).  One goal is to remove needless 
steps and options.  The point of driving workflows is that workflows can 
be divided among members of a team that need to act independently to 
reach a common goal, so no, it's not one person end to end.  The other 
point of driving workflows is to handle tasks outside the scope of 
"moving the bits around" so we can address setup and migration kinds of 
actions.


And no, the graphic on p. 35 has nothing to do with robots.  I just 
thought it was a neat graphic that helped illustrate the modernization 
of a 25+ year old installation process.



--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Art Gutowski]

On Tue, 11 Jul 2017 07:35:52 -0400, John Eells  wrote:

>Everyone: IBM is headed toward using z/OSMF Software Management as the
>installer.  Please go back to near the beginning of this thread with the
>old topic name to catch up on the discussion thus far.
>
>More on the SHARE website, here:
>
>https://share.confex.com/data/handout/share/128/Session_20728_handout_10028_0.pdf

From the previously titled thread:

>At the last SHARE, the question was asked at the multivendor 
>installation-related 
>session about how many in the room were z/OSMF users.  In the past, I've seen 
>those raising a hand to be perhaps 25% of a similarly-sized crowd, but in 
>March 
>about 2/3 of those present raised a hand (a pleasant surprise).  Of course, 
>one 
>room at SHARE does not a valid statistical sample make, but it's one data 
>point.

But is it a valid data point?  We use z/OSMF only insofar as we are forced to 
for IP configuration and upkeep.  We did not use z/OSMF to install v2.2, and I 
don't know whether we'll use it to install v2.3.  There is talk of it, but it 
seems to be largely motivated by the thought that we will be forced into it 
(kind of like zFS).  

Don't get me wrong, we've had talks... I'm with simple and common software 
management processes, and I'm glad to see ISVs on board, but I'm not convinced 
that z/OSMF in and of itself is either necessary or sufficient to achieve the 
goal.  If you have good SMP/E packaging, z/OSMF is unnecessary as an installer. 
 If you have crappy SMP/E packaging, front-ending it with z/OSMF will not be 
sufficient to address the shortfall.

I don't see the need for z/OSMF for software deployment.  We have plenty of 
experience here, and are easily passing that along to our newer sysprogs.  I 
recoil at the thought of using it for configuration.  ISPF is sufficient to 
edit PARMLIB, et al, and it runs in a WS client, if you so choose.

Seems to me, any of the substantive improvements offered by z/OSMF ought to be 
UI-agnostic.  It doesn't take a "sticky" UI and and the overhead (FSVO minimal) 
of a server address space to improve product installation.  These might have 
been made accessible ServerPac, or even the SMP/E dialogs, but they weren't.  
It's a fine thing for someone who wants the trouble of installing and 
configuring Liberty et al (and I've heard the cursing all the way from Austin 
and Phoenix), but ISPF apps ought to continue as supported options for those 
who prefer them. 

That's my buck-two-eight-five, after adjusting for inflation. :)

Art Gutowski
General Motors, LLC
PS - While some of the observations herein are the result of my place of 
employ, the opinions expressed are my own.

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

z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John Eells
> Sent: Tuesday, July 11, 2017 4:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: EAV volumes and SYSRES
> 
> Gibney, Dave wrote:
> > z/OSMF assumes access to zIIP. Otherwise, the Java CPU load on general
> CP's impacts the SCRT reports, or runs up on the cap.
> 
> 
> There is negligible idle load imposed by the z/OSMF server; it uses 
> significant
> CPU only when you do something with it.  I just checked again using RMF
> Monitor III (RMFWDM) on our current level of z/OS V2.3 code.  As I started to
> compose this note, I looked at its CPU usage, and I did so again after several
> minutes had elapsed. It hadn't budged.
> 
> I believe this has been the case since we switched to WebSphere with the
> Liberty profile some time ago. Another interesting datum is that has used
> about 20% more zIIP time than CP time since the last server start.
> 
> But, just to make sure it was actually working (hey, it's a system in z/OS
> System Test, after all!), I logged into z/OSMF.  That was not enough to make
> the numbers move, either.
> 
> So, I defined a new (fairly small, about 150 data seats) software instance to
> drive discovery by a pattern, which does a bunch of Catalog and
> CVAF/DADSM operations to locate data sets by high-level qualifier, and went
> back to check again.  It had ticked up by a bit less than two tenths of a CPU
> second total, the sum of zIIP time and CP time.  I'll grant that this is on a 
> top
> end processor, but this is still not moving the needle by much; you can barely
> see it twitch.
> 
> The heavy lifting (data movement) for Software Management is currently
> done in batch.  I have not run a side-by-side comparison of CPU consumption
> for ServerPac and z/OSMF Software Management deployment operations,
> and I don't plan to, but the former is certainly nonzero, and the latter does
> not involve a huge amount of frequent activity.
> Also, Software Management should use less resource when you model after
> previous deployments (as many likely do in ServerPac, too, by "merging
> with" a saved configuration).

Thank you for this information. It could make this barely palatable.
Still, I've not even installed z/OSMF or Liberty. Running z/OS 2.1 now. Doubt 
my installation will even exist by the time someone needs to that it beyond 2.3

> 
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.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: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Edward Gould]

> On Jul 11, 2017, at 6:35 AM, John Eells  wrote:
> 
> Peter Hunkeler wrote:
>> Topic change due? Possibly more opinions if people understand it is about 
>> z/OSF now.
>> 
>> 
> 
> Peter, good idea.
> 
> Everyone: IBM is headed toward using z/OSMF Software Management as the 
> installer.  Please go back to near the beginning of this thread with the old 
> topic name to catch up on the discussion thus far.
> 
> More on the SHARE website, here:
> 
> https://share.confex.com/data/handout/share/128/Session_20728_handout_10028_0.pdf
> 
John,:

Interesting but I am not convinced that this is any better than what is 
currently available. It also looks (to me) complicated and one person seems to 
have to be doing “it” from start to end, is that the case?
Slide 35(?) are you trying to show a robot can do this but not a human?

Ed

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

z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[John Eells]

Peter Hunkeler wrote:

Topic change due? Possibly more opinions if people understand it is about z/OSF 
now.




Peter, good idea.

Everyone: IBM is headed toward using z/OSMF Software Management as the 
installer.  Please go back to near the beginning of this thread with the 
old topic name to catch up on the discussion thus far.


More on the SHARE website, here:

https://share.confex.com/data/handout/share/128/Session_20728_handout_10028_0.pdf

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

AW: Re: EAV volumes and SYSRES

[Peter Hunkeler]

Topic change due? Possibly more opinions if people understand it is about z/OSF 
now.


--
Peter Hunkeler



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

Re: AW: Re: EAV volumes and SYSRES

[R.S.]

W dniu 2017-07-10 o 18:01, Peter Hunkeler pisze:

I have lost track of this for a few years, but when I last knew, these
things *were* supported in EAS:

  >

- PDS and PDSE (including load modules and program objects)
- Plain vanilla (nonextended format) sequential
- BDAM


But as you wrote, it also depends on the software accessing the data. I was 
involved in installing a new product which abended in a stange way. It turned 
out it was because one of the configuration data set (I think a PS) was  in the 
EAS space, and the software was using some elder C based framework to read the 
data. That framework did not support data sets in EAS.


As always, it depends on the software and the system software was always 
big exception whe compared to regular application software.

There are many of exceptions:
SYS1.MANx dasets shouldn't have secondary extents, also RACF db, JES 
CKPT and SPOOL, etc.

No serialization for RACF db, JES datasets, etc.
No PDSE in LPA

That's why VVDS, ICF BCS (catalogs), LPA, LNKLST, RACF db etc. are 
separatly enumerated, despite it is VSAM, PDS/PDSE, PS.


The rule is quite simple: if given type of dataset cannot be (... - EAS 
is one of examples), then you're 99% sure a system dataset of this type 
also cannot be (...). However this is necessary, but not sufficient 
condition.


--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

AW: Re: EAV volumes and SYSRES

[Peter Hunkeler]

> I have lost track of this for a few years, but when I last knew, these
> things *were* supported in EAS:
 >
> - PDS and PDSE (including load modules and program objects)
> - Plain vanilla (nonextended format) sequential
> - BDAM


But as you wrote, it also depends on the software accessing the data. I was 
involved in installing a new product which abended in a stange way. It turned 
out it was because one of the configuration data set (I think a PS) was  in the 
EAS space, and the software was using some elder C based framework to read the 
data. That framework did not support data sets in EAS.


--
Peter Hunkeler



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