Re: load library lrecl=??

[Paul Gilmartin]

On 2018-09-05, at 21:49:56, Mike Schwab wrote:

> I am guessing the LRECL-256 is handy when reading the directory?
>   
You still need to override to DSORG=PS.

> The loader handles reading the actual programs. 

-- gil

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

Re: load library lrecl=??

[Mike Schwab]

I am guessing the LRECL-256 is handy when reading the directory?
The loader handles reading the actual programs.
On Wed, Sep 5, 2018 at 10:41 PM Brian Westerman
 wrote:
>
> Hi,
>
> I had an "interesting" conversation today.  Apparently some of the libraries 
> shipped by some vendors or at least the directions to define them specify 
> RECFM=U,LRECL=256.  I had never considered LRECL as an valid option when 
> defining a load library and so always coded RECFM=U,LRECL=0.
>
> Is there any advantage to LRECL=256 that I am missing?
>
> I'm used to seeing load library block sizes in various values, but LRECL I 
> had thought was always a constant.  I looked it up in the IBM manual and the 
> best I can see is that it says that LRECL=0 is "only valid for RECFM=U 
> datasets".  Which doesn't tell me very much or answer the question.
>
> I know that LRECL=256 works, apparently SoftwareAG has shipped their load 
> libraries as RECFM=U,LRECL=256,BLKSIZE=6144 for more years than I have been a 
> systems programmer, but I can't find anywhere where there seem to be any 
> "rules".
>
> Anyone have a answer for this?  Is it possible that for RECFM=U that LRECL is 
> plain old "ignored:?
>
> Brian
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

load library lrecl=??

[Brian Westerman]

Hi,

I had an "interesting" conversation today.  Apparently some of the libraries 
shipped by some vendors or at least the directions to define them specify 
RECFM=U,LRECL=256.  I had never considered LRECL as an valid option when 
defining a load library and so always coded RECFM=U,LRECL=0.

Is there any advantage to LRECL=256 that I am missing?  

I'm used to seeing load library block sizes in various values, but LRECL I had 
thought was always a constant.  I looked it up in the IBM manual and the best I 
can see is that it says that LRECL=0 is "only valid for RECFM=U datasets".  
Which doesn't tell me very much or answer the question.

I know that LRECL=256 works, apparently SoftwareAG has shipped their load 
libraries as RECFM=U,LRECL=256,BLKSIZE=6144 for more years than I have been a 
systems programmer, but I can't find anywhere where there seem to be any 
"rules".

Anyone have a answer for this?  Is it possible that for RECFM=U that LRECL is 
plain old "ignored:?

Brian

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

Re: VSAM share-option 4

[Graham Harris]

You may want to look at CA Shareoption5.  I know that was used in a
VSE->z/OS migration in a past life, and seem to recall it was something to
do with addressing online & batch concurrency/integrity.


On Wed, 5 Sep 2018 at 23:24, Mark Waterbury <
01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote:

> Who said SVS did not have VSAM?
> SVS certainly did have VSAM ...
>
> It was an ICR -- Independent Component Release -- so somewhat tricky to
> get it installed into SVS, but once installed, it did work... and CICS/VS
> used it ...
> This was on SVS 1.7 circa 1976-77...
> And, just like on MVS, on SVS, we were taught that:
> Share optionsmeans3Close your eyes
> 4Close your eyes and step on the gas!
> Does that jog anyone's memory?
> Mark S. Waterbury
>
>On Wednesday, September 5, 2018, 12:35:26 AM EDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
>
>  >
> VSAM was implemented at the OS level with DOS/VS (and IIRC,
> > DOS/VS was first to have VSAM with MVS|VS1 to follow), where with
> > OS (OS/VS1 or MVS)
>
> What was SVS, chopped liver?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Steve Thompson 
> Sent: Tuesday, September 4, 2018 8:35 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: VSAM share-option 4
>
> Yes your reading and interpretation is essentially correct.
>
> VSAM was implemented at the OS level with DOS/VS (and IIRC,
> DOS/VS was first to have VSAM with MVS|VS1 to follow), where with
> OS (OS/VS1 or MVS) it was implemented at the address space level.
>
> Whoever did your migration, if they did not have a background
> involving DOS/VS_ and just did a flat migration to MVS (z/OS),
> you can get royally shafted.
>
> The SHARE OPTIONS between the two systems are very different and
> one has to know and understand this to do a proper migration and
> Catalog structures are very different between the two systems.
> Where you would do backups by CATALOG, a CATALOG does not OWN the
> volumes in an MVS shop. But they did in a DOS/VS shop.
>
> And I hate to break this to you at this late date, but if the
> migrators didn't know it, the z/VSE system was an XA I/O system
> and so the performance increase for I/O that one expected in days
> of yore in going to z/OS will not be there (until DOS/VSE/ESA,
> DOS systems were BASE S/370 using the OLD SIO/SIOF, etc. and not
> SSCH and related instructions).
>
> You may actually lose performance in the z/OS environment as a
> result.
>
> Regards,
> Steve Thompson
>
>
> On 09/04/2018 07:42 PM, Tony Thigpen wrote:
> > My main background is z/VSE but now I have to manage a bunch of
> > z/OS sites, including one that recently converted from z/VSE to
> > z/OS.
> >
> > On z/VSE, share-option 4 means that VSAM will prevent any read or
> > write integrity exposures when multiple tasks are accessing the
> > same VSAM file.
> >
> > z/VSE VSAM will internally lock any CI that is being updated so
> > that nobody else can update the CI. This ENQ/DEQ is handled by
> > the IBM provided VSAM IO routines at the task level.
> > Additionally, VSAM will flush all update buffers after a write or
> > update. And, it will not buffer reads when reading a share-option
> > 4 file. (I am being somewhat general in the descriptions, so the
> > details are a little more complicated.) All this to make sure
> > that the records on disk and the records in buffers match.
> >
> > Now, with z/OS, my reading of the VSAM Demystified RedBook leads
> > me to the following:
> > 1) Share-option 4 allows multiple open for update, but expects
> > the program, not the VSAM subsystem, to perform the ENQ/DEQs.
> > 2) If a program does not perform ENQ/DEQs, then data integrity is
> > lost as multiple tasks can update the same record concurrently.
> > 3) VSAM/RLS is one way to protect the data, but that is another
> > can of worms.
> >
> > Am I understanding the z/OS side correctly?
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> 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: VSAM share-option 4

[Mark Waterbury]

Who said SVS did not have VSAM?
SVS certainly did have VSAM ... 

It was an ICR -- Independent Component Release -- so somewhat tricky to get it 
installed into SVS, but once installed, it did work... and CICS/VS used it ...
This was on SVS 1.7 circa 1976-77...
And, just like on MVS, on SVS, we were taught that:
Share options    means    3    Close your eyes    4 
   Close your eyes and step on the gas!
Does that jog anyone's memory? 
Mark S. Waterbury

   On Wednesday, September 5, 2018, 12:35:26 AM EDT, Seymour J Metz 
 wrote:  
 
 > 
VSAM was implemented at the OS level with DOS/VS (and IIRC,
> DOS/VS was first to have VSAM with MVS|VS1 to follow), where with
> OS (OS/VS1 or MVS)

What was SVS, chopped liver?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Tuesday, September 4, 2018 8:35 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: VSAM share-option 4

Yes your reading and interpretation is essentially correct.

VSAM was implemented at the OS level with DOS/VS (and IIRC,
DOS/VS was first to have VSAM with MVS|VS1 to follow), where with
OS (OS/VS1 or MVS) it was implemented at the address space level.

Whoever did your migration, if they did not have a background
involving DOS/VS_ and just did a flat migration to MVS (z/OS),
you can get royally shafted.

The SHARE OPTIONS between the two systems are very different and
one has to know and understand this to do a proper migration and
Catalog structures are very different between the two systems.
Where you would do backups by CATALOG, a CATALOG does not OWN the
volumes in an MVS shop. But they did in a DOS/VS shop.

And I hate to break this to you at this late date, but if the
migrators didn't know it, the z/VSE system was an XA I/O system
and so the performance increase for I/O that one expected in days
of yore in going to z/OS will not be there (until DOS/VSE/ESA,
DOS systems were BASE S/370 using the OLD SIO/SIOF, etc. and not
SSCH and related instructions).

You may actually lose performance in the z/OS environment as a
result.

Regards,
Steve Thompson


On 09/04/2018 07:42 PM, Tony Thigpen wrote:
> My main background is z/VSE but now I have to manage a bunch of
> z/OS sites, including one that recently converted from z/VSE to
> z/OS.
>
> On z/VSE, share-option 4 means that VSAM will prevent any read or
> write integrity exposures when multiple tasks are accessing the
> same VSAM file.
>
> z/VSE VSAM will internally lock any CI that is being updated so
> that nobody else can update the CI. This ENQ/DEQ is handled by
> the IBM provided VSAM IO routines at the task level.
> Additionally, VSAM will flush all update buffers after a write or
> update. And, it will not buffer reads when reading a share-option
> 4 file. (I am being somewhat general in the descriptions, so the
> details are a little more complicated.) All this to make sure
> that the records on disk and the records in buffers match.
>
> Now, with z/OS, my reading of the VSAM Demystified RedBook leads
> me to the following:
> 1) Share-option 4 allows multiple open for update, but expects
> the program, not the VSAM subsystem, to perform the ENQ/DEQs.
> 2) If a program does not perform ENQ/DEQs, then data integrity is
> lost as multiple tasks can update the same record concurrently.
> 3) VSAM/RLS is one way to protect the data, but that is another
> can of worms.
>
> Am I understanding the z/OS side correctly?
>

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

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

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

Re: "Library Server" Access Now "Forbidden"?

[Susan Shumway]

Hi all,

I just received another update on this issue with the hosted Library 
Server (BookManager site). I can assure you that Claus doesn't have any 
special insider knowledge - the site wasn't 'CLOSED DOWN' and its 
temporary offline status was indeed not planned. Nothing has changed - 
the plan is still to get it back up and running as soon as possible, 
with "as soon as possible" occurring within the next few weeks or 
hopefully even few days.


For those of you who need to access older z/OS content in the meantime, 
keep checking 
https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zos-library-archives 
as Geoff Smith continues to add alternative formats.


(Feel free to quote any of this in Claus' LinkedIn group, of which I'm 
not a member.)


-Sue Shumway


On 9/4/2018 2:42 PM, David Staudacher wrote:

The link you included has nothing to do with your post.


I should have realized the link might resolve differently for anyone either not connected 
to Claus Mikkelsen, and/or not a member of his "Mainframe Support Tips" 
LinkedIn group.  My fault.

But Claus' post is quite germane, so I'll copy it here [emphasis mine]:

"If you haven't noticed I can inform you IBM has CLOSED DOWN their good old and well 
functioning BookManager Site on the internet. This means that a lot of the links in my 
tips does not work anymore. I apologise for any inconvenience. Maybe I will fix this 
problem some day, but I will not make any promises".

I posted a reply to him, requesting the source of information for his assertion that IBM had CLOSED DOWN Bookmanger 
internet access, and with a link to assurances given here that the outage is "unplanned", 
"unintentional", to "stay tuned" and that "work is under way to restore access to it as 
quickly as possible".

I have yet to hear a reply, but am nonetheless unconvinced he doesn't have some 
kind of insider knowledge we lack.  And that the lack of any further assurances 
from John, Scott or Susan on the matter also has me very concerned.  Claus 
isn't the only one with hundreds of published links to pages on the Bookmanager 
site which no longer work and will never work again unless access is restored.

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



--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@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: VSAM share-option 4

[Steve Smith]

Ah good ol' SVS, the red-headed stepchild, the rented mule, the forgotten
step-sister of Cinderella, the Spam & powdered eggs puree.  It don't get no
respect.

sas

On Wed, Sep 5, 2018 at 12:35 AM Seymour J Metz  wrote:

> >
> VSAM was implemented at the OS level with DOS/VS (and IIRC,
> > DOS/VS was first to have VSAM with MVS|VS1 to follow), where with
> > OS (OS/VS1 or MVS)
>
> What was SVS, chopped liver?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3

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

Re: Auto backup of zfs

[Lizette Koehler]

As I stated.  If you use DFDSS, it will quiesce the zfs file, making it 
unavailable during the time of the backup.

All work needs to be stopped against a zFS in order to back it up.  Otherwise 
you could have a corrupted backup.  As others have pointed out

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Munif Sadek
> Sent: Tuesday, September 04, 2018 10:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Auto backup of zfs
> 
> Thanks Lizette / Tim
> 
> I still have to disable Migrate before Backup would work but have another
> question. My zFS is big and I am happy to take a backup with TOL(ENQF) as it
> contains extremely STATIC Objects which are FTPed from GIT (window$) during
> the deployment cycle.
> 
> My zFS is mounted R/W but I really do not care about sysplex wide Quiesce as
> long as Static data is recoverable without any data concurrency requirement.
> 
> Its Just that Windows recovery had failed in the past and being mainframe we
> should be able recover everything.
> 
> thanks for your answer.
> 
> regards
> Prabhat
> 
> 
> --
> 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: Measuring Usage of zIIP per address space

[Horst Sinram]

The SMF30 Processor Accounting Section is a good place for the total and zIIP 
processor consumption but if you are also interested in the delay aspects you 
won't find anything in SMF30. For delay information you can turn to RMF Mon 
III, or just use the postprocessor reports with report classes defined over 
those address spaces that you're interested in.
As to what fields you should look at, be sure to read to the introduction to 
SMF30 in the SMF manual.
If enclaves are involved then 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaw200/ieaw20046.htm
 describes the accounting scheme. 
Horst Sinram - STSM, IBM z/OS Workload and Capacity Management

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

Re: Zowe for systems programmer ?

[Sean Gleann]

Jerry Callen jcal...@narsil.org via
 ua.edu
13:38 (34 minutes ago)
to IBM-MAIN
On Sun, Sep 2, 2018, 9:56 AM Bruce Armstrong  wrote:

> If you know what ISPF is and are happy with it you may not be the
> target market for Zowe. Zowe is primarily targeted for the "next gen"
> sysprog who does not have 30+ years of learning the the nuances of
> z/OS and ISPF.

Or - maybe you are the target market, but don't yet know it.

I *DO* have many years of experience with z/OS -- I learned to program in
PL/I and assembler on OS/MVT in the early 1970s and was a systems
programmer through the mid 1980s. I've worked on more modern z/OS systems
for the past 4 years.

I also have many years of experience with both Unix and Windows systems.
It's that experience that makes me so excited about the potential of Zowe.
It's providing a framework for bringing highly-evolved system management
tools of all kinds to z/OS. This will ultimately make the systems
programmer's job easier. That's not a bad thing.

"...it's time for established z/OS programmers to start adopting tools and
practices from other platforms, too."


Well said, Jerry!
...and I'm glad I'm retiring soon... :)

On Wed, 5 Sep 2018 at 14:10, Seymour J Metz  wrote:

> I agree that programmers should adopt tools from other platforms, but only
> when they are appropriate tools for the job at hand, not simply because
> they are in style. A good hammer is an essential tool, but it's a terrible
> screwdriver.
>
> When it comes to configuration control and serialization tools, the
> infrastructure had better match the tool set or chaos will result. I'd
> advise looking at things on a project by project basis and concentrate on
> selecting appropriate tools for new projects rather than making disruptive
> changes to old projects.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Jerry Callen 
> Sent: Wednesday, September 5, 2018 8:37 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Zowe for systems programmer ?
>
> On Sun, Sep 2, 2018, 9:56 AM Bruce Armstrong  wrote:
>
> > If you know what ISPF is and are happy with it you may not be the
> > target market for Zowe. Zowe is primarily targeted for the "next gen"
> > sysprog who does not have 30+ years of learning the the nuances of
> > z/OS and ISPF.
>
> Or - maybe you are the target market, but don't yet know it.
>
> I *DO* have many years of experience with z/OS -- I learned to program in
> PL/I and assembler on OS/MVT in the early 1970s and was a systems
> programmer through the mid 1980s. I've worked on more modern z/OS systems
> for the past 4 years.
>
> I also have many years of experience with both Unix and Windows systems.
> It's that experience that makes me so excited about the potential of Zowe.
> It's providing a framework for bringing highly-evolved system management
> tools of all kinds to z/OS. This will ultimately make the systems
> programmer's job easier. That's not a bad thing.
>
> It's not just that the "next gen" programmers need to learn z/OS -- it's
> time for established z/OS programmers to start adopting tools and practices
> from other platforms, too.
>
> -- Jerry
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: (Very) old HMC versions

[R.S.]

W dniu 2018-09-04 o 14:38, Allan Staller pisze:

Resource Link?


Neither Resource Link, nor bitsavers or google or...

--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

Re: Zowe for systems programmer ?

[Seymour J Metz]

I agree that programmers should adopt tools from other platforms, but only when 
they are appropriate tools for the job at hand, not simply because they are in 
style. A good hammer is an essential tool, but it's a terrible screwdriver.

When it comes to configuration control and serialization tools, the 
infrastructure had better match the tool set or chaos will result. I'd advise 
looking at things on a project by project basis and concentrate on selecting 
appropriate tools for new projects rather than making disruptive changes to old 
projects.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Jerry Callen 
Sent: Wednesday, September 5, 2018 8:37 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Zowe for systems programmer ?

On Sun, Sep 2, 2018, 9:56 AM Bruce Armstrong  wrote:

> If you know what ISPF is and are happy with it you may not be the
> target market for Zowe. Zowe is primarily targeted for the "next gen"
> sysprog who does not have 30+ years of learning the the nuances of
> z/OS and ISPF.

Or - maybe you are the target market, but don't yet know it.

I *DO* have many years of experience with z/OS -- I learned to program in PL/I 
and assembler on OS/MVT in the early 1970s and was a systems programmer through 
the mid 1980s. I've worked on more modern z/OS systems for the past 4 years.

I also have many years of experience with both Unix and Windows systems. It's 
that experience that makes me so excited about the potential of Zowe. It's 
providing a framework for bringing highly-evolved system management tools of 
all kinds to z/OS. This will ultimately make the systems programmer's job 
easier. That's not a bad thing.

It's not just that the "next gen" programmers need to learn z/OS -- it's time 
for established z/OS programmers to start adopting tools and practices from 
other platforms, too.

-- Jerry

--
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: Zowe for systems programmer ?

[Jerry Callen]

On Sun, Sep 2, 2018, 9:56 AM Bruce Armstrong  wrote:

> If you know what ISPF is and are happy with it you may not be the
> target market for Zowe. Zowe is primarily targeted for the "next gen"
> sysprog who does not have 30+ years of learning the the nuances of
> z/OS and ISPF.

Or - maybe you are the target market, but don't yet know it.

I *DO* have many years of experience with z/OS -- I learned to program in PL/I 
and assembler on OS/MVT in the early 1970s and was a systems programmer through 
the mid 1980s. I've worked on more modern z/OS systems for the past 4 years.

I also have many years of experience with both Unix and Windows systems. It's 
that experience that makes me so excited about the potential of Zowe. It's 
providing a framework for bringing highly-evolved system management tools of 
all kinds to z/OS. This will ultimately make the systems programmer's job 
easier. That's not a bad thing.

It's not just that the "next gen" programmers need to learn z/OS -- it's time 
for established z/OS programmers to start adopting tools and practices from 
other platforms, too.

-- Jerry

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

Re: Auto backup of zfs

[Michael Babcock]

See the zFS Admin book for the proper way to back up a zFS dataset.   If
the zFS is mounted TOL(ENQF) is NOT recommended.  Further, it should be
backed up from the same system where it’s mounted (I can’t remember if that
still applies if you are using zFS sysplex sharing).

In the past, I’ve had zFS datasets become unusable because they were not
backed up properly while mounted.

On Wed, Sep 5, 2018 at 12:13 AM Munif Sadek  wrote:

> Thanks Lizette / Tim
>
> I still have to disable Migrate before Backup would work but have another
> question. My zFS is big and I am happy to take a backup with TOL(ENQF) as
> it contains extremely STATIC Objects which are FTPed from GIT (window$)
> during the deployment cycle.
>
> My zFS is mounted R/W but I really do not care about sysplex wide Quiesce
> as long as Static data is recoverable without any data concurrency
> requirement.
>
> Its Just that Windows recovery had failed in the past and being mainframe
> we should be able recover everything.
>
> thanks for your answer.
>
> regards
> Prabhat
>
>
> --
> 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

Measuring Usage of zIIP per address space

[Elardus Engelbrecht]

To all zIIP gurus,

I have read Martin Packer's SHARE presentation and the thread 'Why are highly 
busy zIIPs worse than highly busy CPs?' in June 2018 amongst other things like 
Google searches, SMF and RMF books.

I want to know how can I see (from SMF records 30 according to Martin Packer 
and others), how much CPU was used in total by an address space.
 
Something like a total of SMF30CPT, SMF30CPS, SMF30HPT plus SMF30_TIME_ON_zIIP?

To what all fields should I look so I can get the total time (actual work done 
and delays) spend on general CPU and zIIP? I am sure I have missed useful 
fields which I can use?

Should I also consider the fields about delays too?

What is 'independent enclave time' and 'derived processor times'? 

Many thanks in advance.

PS: I did read in the SMF book where it is described partially how CPU and SRB 
times are calculated.
PS: I am not interested how WLM and RMF is reporting on usage and scheduling of 
zIIP. I got that info. I just need the info PER address space.

Groete / Greetings
Elardus Engelbrecht

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

SOF dispatcher manual IBM(00-5798)

[Peter]

Hi

Does anyone have manuals of SOF dispatcher ? It's an IBM product once


The module are all starting with CREx

Any suggestions would be much appreciated

Peter

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