Re: Tech Library -- Where is it hidden now

[Michael Watkins]

I feel your pain. Why IBM hides the documentation that allows people to train 
themselves (and reduces the TCO of the mainframe environment) is beyond me. 
Have you tried this:

https://www.ibm.com/docs/en/zos/3.1.0  


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Friday, July 12, 2024 7:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Tech Library -- Where is it hidden now

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

I have been doing various searches, and M/S pilot doesn't help.

I can't seem to find a link to the z/OS (and related) pdf documentation. I'd 
like to download the current z/OS environment manuals (or a subset specific to 
what I'm working on).

Anyone know the link or keywords that would find it. I'm getting tired of 
running into IBM sales literature. :)

--
Regards,
Steve Thompson

--
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: VTOCs vs. catalogs

[Michael Watkins]

Yes, absolutely. MVS systems were becoming larger and creating backups was 
becoming an issue. Backing up to physical tape was the only real option then. 
Not only were there more volumes, but there were more datasets that spanned 
volumes.

Before ICF catalogs, catalog records contained VSAM time stamps. When restoring 
from a backup, getting the timestamps in the catalog to match up with the 
dataset on a volume where the catalog did not reside became an issue (unless 
all other processing was halted while creating the backups) because the tape 
backups themselves took a considerable amount of time. This problem was 
compounded when datasets spanned volumes. The solution was to move the volatile 
fields (e.g. timestamps) from the catalog and place them onto the DASD volume 
where the data was; then they would be backed up at the same time that the data 
was backed up. This was the origin of, and reason for, the VVDS. The volatile 
catalog fields describing the datasets were moved to where the dataset was so 
they could be backed up with the data. An IBM SSR told me at the time that the 
VVDS would eventually replace the VTOC, but this, obviously, never came to pass.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Friday, May 24, 2024 8:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCs vs. catalogs

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Hi Rex,
"...Followed by SMS and VVDS for non-VSAM datasets ..."
This was meant (AFAIK) to state that VVDS for Non-VSAMs came into use with 
SMS-Controlled DASD Volumes.
It is also true that VVDSs were introduced with ICF Catalogs (circa 1981, 
recalled and re-released in 1982).

Regards,
David

On 2024-05-24 09:44, Pommier, Rex wrote:
> Didn't the VVDS come along with the ICF catalog structure?
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Gibney, Dave
> Sent: Thursday, May 23, 2024 10:32 PM
> To:IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: VTOCs vs. catalogs
>
> All speculation on my part. One system with no DASD, you need neither.
> On a system with only one, of just a few DASD volumes, a VTOC is required to 
> say where on the volume a dataset is and the basic attributes of PS and PDS 
> datasets.
>
> Once you get to several always mounted DASSD volumes, it becomes a pain to 
> need to remember and specify VOLSER in the JCL.
>
> CVOLs where an early attempt to solve this problem. Then came  VSAM 
> (and VVDS?) and VSAM Catalogs, and somewhile later ECf/Catalogs. 
> Followed by SMS and VVDS for non-VSAM datasets
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Mike Schwab
>> Sent: Thursday, May 23, 2024 8:24 PM
>> To:IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: VTOCs vs. catalogs
>>
>> [EXTERNAL EMAIL]
>>
>> For the most part the catalog lets you locate your dataset no matter 
>> which volume you put it on.
>> For non-vsam, that is about all that is stored, dataset 
>> characteristics are in the VTOC.
>> And with non-SMS volumes you can have uncataloged datasets on DASD or 
>> tape.
>>
>> VSAM came from the Future Systems development as a complete 
>> replacement, Lynn Wheeler has posts about that.
>> It was cut back to be an addition to MVS, then combined with CVOL 
>> catalogs to ICF.
>>
>> On Thu, May 23, 2024 at 9:32 PM Phil Smith III  wrote:
>>> I'm curious whether any of you old-timers can explain why we have 
>>> both VTOCs and catalogs. I'm guessing it comes down to (a) VTOCs 
>>> came first and catalogs were added to solve some problem (what?) 
>>> and/or (b) catalogs
>> were added to save some I/O and/or memory, back when a bit of those 
>> mattered. But I'd like to understand. Anyone?
>>>
>>> 
>>> -- For IBM-MAIN subscribe / signoff / archive access instructions, 
>>> send email tolists...@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 tolists...@listserv.ua.edu  with the message: INFO 
>> IBM-MAIN
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN
>
> --
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged. If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the 

Re: What happens in HSM when I change a Management Class

[Michael Watkins]

Even though virtual tapes are essentially tape images on DASD, if a virtual 
tape dataset is allocated to a job or user, another dataset on the same virtual 
tape volume cannot be mounted elsewhere for use by another job or user. 
However, many virtual tape systems allow the size of each tape to be the size 
of the dataset being written to tape. Unless you're constrained by the number 
of tape volumes, why not put each dataset on its own tape? There is no wasted 
space, as there would be on a physical tape. Recycles then become unnecessary.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Wednesday, March 13, 2024 5:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What happens in HSM when I change a Management Class

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

With the relatively fast response of virtual tape, the recycle threshold can be 
set fairly high.
I recycled daily. Assuming sufficient number of drives, it won't interfere with 
recall unless coincidentally actively recycling the dataset requested by the 
recall.

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Paul Feller
> Sent: Wednesday, March 13, 2024 2:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What happens in HSM when I change a Management Class
>
> [EXTERNAL EMAIL]
>
> Gadi, Mike has a good point.  Doing HSM tape recycles could help free 
> up any tapes with a low number of datasets on them.  This is true for 
> migration tapes and backup tapes.  Be warned that if you don't do tape 
> recycles on a scheduled basis the process could possibly run for a 
> long time.  As an example, I think that could then impact HSM process 
> of recalls from tape.  I believe the place I last worked at did tape recycles 
> every day.
>
> Also, I should have mentioned the information I pasted in my earlier 
> reply came from the "DFSMSdfp Storage Administration" manual for z/OS 
> 2.5.  It can be found in "Chapter 8. Defining management classes".
>
>
> Paul
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Mike Schwab
> Sent: Wednesday, March 13, 2024 1:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What happens in HSM when I change a Management Class
>
> You should be recycling tapes with a low percent of active datasets.
> This copies the remaining active datasets to a new tape then marking 
> this on as inactive.  You can manually issue a recycle command against 
> a specific volume.
>
> On Wed, Mar 13, 2024 at 10:56 AM Gadi Ben-Avi 
> wrote:
> >
> > Hi Paul,
> > Thanks for your detailed explanation.
> >
> > I would like to delete extra copies of backups, backups that have 
> > been on
> HSM for more than a specified number of days, and as a result of that, 
> tapes that become empty will be deleted.
> >
> > The end result would be that every backed-up dataset that still 
> > exists could
> have more than one backup, and datasets that do not exist anymore 
> would have only one backup.
> >
> > Gadi
> > 
> > From: IBM Mainframe Discussion List  on 
> > behalf of Paul Feller <05aa34d46684-dmarc-
> requ...@listserv.ua.edu>
> > Sent: Wednesday, March 13, 2024 16:09
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Re: What happens in HSM when I change a Management Class
> >
> > [You don't often get email from
> > 05aa34d46684-dmarc-requ...@listserv.ua.edu. Learn why this is 
> > important at
> >
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> %2F=05%7C02%7Cmichael.watkins%40CPA.TEXAS.GOV%7Cff65a2908dfe4f9fd
> 94b08dc43aa4a31%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C638459645
> 889907153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=qPR9LRq6TQnwML%2FpiE
> TibumyZj%2BmeN5b68CcpzTYKgU%3D=0
> >
> efense.com%2Fv3%2F__https%3A%2F%2Faka.ms%2FLearnAboutSenderIden
> tificat
> > ion__%3B!!JmPEgBY0HMszNaDT!r6UGjtMncSAT8VIJBN7GBgbaSWinibhN-
> 31YdPqywAj
> > 7VEo49ten-ZD68xvnm5B2SJnH0-
> XRSX7NjMjKjetkygWrQLY1f7Lg%24=05%7C02%
> >
> 7CGIBNEY%40WSU.EDU%7C49b83bc6d619488994da08dc43a87355%7Cb5
> 2be471f7f147
> >
> b4a8790c799bb53db5%7C0%7C0%7C638459637979687136%7CUnknown
> %7CTWFpbGZsb3
> >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7
> >
> C0%7C%7C%7C=fx4o6v0XTZNQ79rXpyzyI6vHU8MBgknw4bNfjJ8ctU
> Q%3D
> > ved=0  ]
> >
> > Gadi, I have to ask.  Are trying to delete backups of individual 
> > datasets or the actual tapes created during dataset backup processing?
> >
> > If you are trying to manage the actual backups of individual 
> > datasets, have you looked at the different management classes used for the 
> > datasets?
> >
> > The following fields in the management class affect backups taken 
> > for an individual dataset.
> >
> > Retain 

Re: Something keeps releasing space on a large (annual) DS

[Michael Watkins]

DSNTYPE=LARGE allows the 65,535 track (4,369 cylinder) limit to be exceeded. 
This should be restricted to SPOOL datasets and the like.

DSNTYPE=EXTENDED does NOT allow this size limit to be exceeded.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Feller
Sent: Wednesday, February 21, 2024 4:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Bob, sorry we should have answered some of your questions at the end of your 
email

Let me start by saying your storage management team should be able to answer 
all your questions.  That said I'll answer some of your questions based on what 
I know.  These are general answers.  The SMS environment you are running under 
could have overrides that may affect what happens.

You asked "What IS extended PS, anyway?  I'm told it allows more than 16 
extents, but a) how many more? And b) how else is it different?"

Basically, an extended format dataset is allowed to be bigger than a standard 
(or none extended) in several ways.
Extended format allows for 123 volumes where non-extended is 16 volumes.
Extended format allows for far larger allocation of a dataset on one volume 
then a non-extended.  If I recall a non-extended max size is 65,535 tracks.


As far as I know using 3.2 to allocate the data should not be an issue.  It 
should (as far as I know) drive the same SMS ACS routines that are used in 
batch.


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Wednesday, February 21, 2024 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Something keeps releasing space on a large (annual) DS

I'm not a sysprog (just a security geek), but I can at least allocate datasets, 
and at the start of this year it fell to me to allocate a new dataset in which 
are logged all changes made in the security system.  Past year's log are in the 
12000-track range, so I started with a smaller allocation while I took the time 
to talk to our sysprog about space requirements.  It's populated from a daily 
production job, by the way.

When I re-allocated it, on his advice I tried a multi-volume and extended 
allocation (PS-E).  Almost immediately the job started bombing, claiming that 
the first four volumes it tried didn't have the necessary space to add an 
extension.  The sysprog is puzzled - says it should have looked in volumes that 
DO have the space, not the ones that don't.

Second attempt (I don't count the temporary smaller allocation) I kept PS-E but 
dropped the multi-volume requirement.  I've never done one of those anyway, and 
don't trust 'em.  The system promptly dropped the extra tracks I allocated, and 
a day or two later the job started bombing with a B37-04.

Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I just 
noticed that something, somewhere, has released extra space AGAIN; 3.4 tells me 
it's now 1960 tracks and 83%.  The job isn’t bombing yet; some time later in 
the year I'm guessing it's going to.

Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep releasing 
space although I never specified RLSE?  The sysprog doesn't know either - but 
he's an external contractor who just took over the system a few months ago and 
if it's something simple he may not be aware yet of ... I dunno, something in 
SMS maybe?

Some wrinkles that may or may not be relevant:

1) The dataset is written using a REXX exec that calculates the DSN by 
reference to the current year.  This relieves folks from having to update the 
JCL every year, but maybe something about the way the exec does the allocate is 
causing the problem?  I'm guessing not, because as far as I now this job has 
run correctly for years.  But just in case:

  "ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
  "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"

2) I don't know anything about SMS, but could something there be releasing 
space?

3) What IS extended PS, anyway?  I'm told it allows more than 16 extents, but 
a) how many more? And b) how else is it different?

4) I allocated the dataset each time using not batch JCL but 3.2 ... expecting 
there's no difference.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Law #6 of combat operations:  If it's stupid but it works, it isn't stupid. 
*/

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

Re: Something keeps releasing space on a large (annual) DS

[Michael Watkins]

Also, forgot to add: list the dataset and note the management class (MGMTCLAS). 
This will tell you how DFSMShsm is managing the dataset and whether space is 
routinely being released.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Wednesday, February 21, 2024 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

"ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE", "SPACE(300,30) CYLINDERS 
RECFM(V,B) LRECL(304) BLKSIZE(27998)"

Yes, always allocate anything other than a very small dataset in cylinders.

Also, keep in mind that an extended PS appends a 32-byte suffix onto every 
block of data (an 8-byte prefix onto blocks of datasets allocated as  
DSNTYPE=LARGE). Specifying BLKSIZE=27998 may mean that you only have 1 block on 
each virtual 3390 track on your RAID storage frame. Perhaps code BLKSIZE=0 and 
let the system determine the BLKSIZE.

One advantage extended format datasets enjoy is that up to 123 extents can be 
allocated on each volume, although the 65,535 tracks (4,369 CYLs) per volume 
z/OS limit is still adhered to.

Unless there are limits imposed by your application, do not hesitate to span up 
to the z/OS limit of 59 volumes or take advantage of zEDC compression.

Also: Not all applications, particularly those that have a special internal 
format (like SAS) or that write their own I/O (like Adabase) can use extended 
format datasets.

Inquire with your storage manager whether there is an existing DATACLAS that 
meets your needs. Or explain your issues and perhaps the storage manager will 
design a DATACLAS for you.

Good luck!



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Wednesday, February 21, 2024 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Its probably doing a release.
Do a cylinder allocation to at average 7 tracks after release.
Defragment to consolidate extents weekly / twice a week / MWF / daily.

On Wed, Feb 21, 2024 at 11:45 AM Bob Bridges 
<0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:

I'm not a sysprog (just a security geek), but I can at least allocate datasets, 
and at the start of this year it fell to me to allocate a new dataset in which 
are logged all changes made in the security system.  Past year's log are in the 
12000-track range, so I started with a smaller allocation while I took the time 
to talk to our sysprog about space requirements.  It's populated from a daily 
production job, by the way.

When I re-allocated it, on his advice I tried a multi-volume and extended 
allocation (PS-E).  Almost immediately the job started bombing, claiming that 
the first four volumes it tried didn't have the necessary space to add an 
extension.  The sysprog is puzzled - says it should have looked in volumes that 
DO have the space, not the ones that don't.

Second attempt (I don't count the temporary smaller allocation) I kept PS-E but 
dropped the multi-volume requirement.  I've never done one of those anyway, and 
don't trust 'em.  The system promptly dropped the extra tracks I allocated, and 
a day or two later the job started bombing with a B37-04.

Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I just 
noticed that something, somewhere, has released extra space AGAIN; 3.4 tells me 
it's now 1960 tracks and 83%.  The job isn’t bombing yet; some time later in 
the year I'm guessing it's going to.

Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep releasing 
space although I never specified RLSE?  The sysprog doesn't know either - but 
he's an external contractor who just took over the system a few months ago and 
if it's something simple he may not be aware yet of ... I dunno, something in 
SMS maybe?

Some wrinkles that may or may not be relevant:

1) The dataset is written using a REXX exec that calculates the DSN by 
reference to the current year.  This relieves folks from having to update the 
JCL every year, but maybe something about the way the exec does the allocate is 
causing the problem?  I'm guessing not, because as far as I now this job has 
run correctly for years.  But just in case:

"ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE", "SPACE(300,30) CYLINDERS 
RECFM(V,B) LRECL(304) BLKSIZE(27998)"

2) I don't know anything about SMS, but could something there be releasing 
space?

3) What IS extende

Re: Something keeps releasing space on a large (annual) DS

[Michael Watkins]

"ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE", "SPACE(300,30) CYLINDERS 
RECFM(V,B) LRECL(304) BLKSIZE(27998)"

Yes, always allocate anything other than a very small dataset in cylinders.

Also, keep in mind that an extended PS appends a 32-byte suffix onto every 
block of data (an 8-byte prefix onto blocks of datasets allocated as  
DSNTYPE=LARGE). Specifying BLKSIZE=27998 may mean that you only have 1 block on 
each virtual 3390 track on your RAID storage frame. Perhaps code BLKSIZE=0 and 
let the system determine the BLKSIZE.

One advantage extended format datasets enjoy is that up to 123 extents can be 
allocated on each volume, although the 65,535 tracks (4,369 CYLs) per volume 
z/OS limit is still adhered to. 

Unless there are limits imposed by your application, do not hesitate to span up 
to the z/OS limit of 59 volumes or take advantage of zEDC compression.

Also: Not all applications, particularly those that have a special internal 
format (like SAS) or that write their own I/O (like Adabase) can use extended 
format datasets.

Inquire with your storage manager whether there is an existing DATACLAS that 
meets your needs. Or explain your issues and perhaps the storage manager will 
design a DATACLAS for you.

Good luck!



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Wednesday, February 21, 2024 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Its probably doing a release.
Do a cylinder allocation to at average 7 tracks after release.
Defragment to consolidate extents weekly / twice a week / MWF / daily.

On Wed, Feb 21, 2024 at 11:45 AM Bob Bridges 
<0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:

I'm not a sysprog (just a security geek), but I can at least allocate datasets, 
and at the start of this year it fell to me to allocate a new dataset in which 
are logged all changes made in the security system.  Past year's log are in the 
12000-track range, so I started with a smaller allocation while I took the time 
to talk to our sysprog about space requirements.  It's populated from a daily 
production job, by the way.

When I re-allocated it, on his advice I tried a multi-volume and extended 
allocation (PS-E).  Almost immediately the job started bombing, claiming that 
the first four volumes it tried didn't have the necessary space to add an 
extension.  The sysprog is puzzled - says it should have looked in volumes that 
DO have the space, not the ones that don't.

Second attempt (I don't count the temporary smaller allocation) I kept PS-E but 
dropped the multi-volume requirement.  I've never done one of those anyway, and 
don't trust 'em.  The system promptly dropped the extra tracks I allocated, and 
a day or two later the job started bombing with a B37-04.

Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I just 
noticed that something, somewhere, has released extra space AGAIN; 3.4 tells me 
it's now 1960 tracks and 83%.  The job isn’t bombing yet; some time later in 
the year I'm guessing it's going to.

Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep releasing 
space although I never specified RLSE?  The sysprog doesn't know either - but 
he's an external contractor who just took over the system a few months ago and 
if it's something simple he may not be aware yet of ... I dunno, something in 
SMS maybe?

Some wrinkles that may or may not be relevant:

1) The dataset is written using a REXX exec that calculates the DSN by 
reference to the current year.  This relieves folks from having to update the 
JCL every year, but maybe something about the way the exec does the allocate is 
causing the problem?  I'm guessing not, because as far as I now this job has 
run correctly for years.  But just in case:

"ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE", "SPACE(300,30) CYLINDERS 
RECFM(V,B) LRECL(304) BLKSIZE(27998)"

2) I don't know anything about SMS, but could something there be releasing 
space?

3) What IS extended PS, anyway?  I'm told it allows more than 16 extents, but 
a) how many more? And b) how else is it different?

4) I allocated the dataset each time using not batch JCL but 3.2 ... expecting 
there's no difference.

 ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
/* Law #6 of combat operations:  If it's stupid but it works, it isn't stupid. 
*/
> --
> 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?

Re: Antiquarian Curiosity: Pre-MVS/XA Mount Command for DASD Volumes

[Michael Watkins]

Wow! I did not realize that this was still part of the system console command 
documentation. Thanks!

Thanks to all that replied.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jim 
Mulder
Sent: Thursday, February 1, 2024 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Antiquarian Curiosity: Pre-MVS/XA Mount Command for DASD Volumes

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

https://www.ibm.com/docs/en/zos/3.1.0?topic=reference-mount-command

Jim Mulder

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Thursday, February 1, 2024 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Antiquarian Curiosity: Pre-MVS/XA Mount Command for DASD Volumes

Before MVS/XA and RAID DASD, offline DASD volumes (e.g. 3330, 3350 & 3380 
units) had to be mounted instead of simply being varied online. The mount 
command used the volser of the offline DASD volume as a parameter.

Does anyone remember the format of the mount command?

Does anyone have the documentation in .pdf format?

--
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: Antiquarian Curiosity: Pre-MVS/XA Mount Command for DASD Volumes

[Michael Watkins]

Thanks! Sorry if you took umbrage at 'antiquarian'; no offense intended.

Question: Was 'PRIVATE' the default value for the USE parameter?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jay 
Maynard
Sent: Thursday, February 1, 2024 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Antiquarian Curiosity: Pre-MVS/XA Mount Command for DASD Volumes

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

M addr,VOL=(SL,volser),USE={PUBLIC|PRIVATE|STORAGE}

There are those of us who use that command frequently when building not-current 
versions of MVS...

On Thu, Feb 1, 2024 at 10:44 AM Michael Watkins < 
032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote:

> Before MVS/XA and RAID DASD, offline DASD volumes (e.g. 3330, 3350 & 
> 3380
> units) had to be mounted instead of simply being varied online. The 
> mount command used the volser of the offline DASD volume as a parameter.
>
> Does anyone remember the format of the mount command?
>
> Does anyone have the documentation in .pdf format?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
Jay Maynard

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

Antiquarian Curiosity: Pre-MVS/XA Mount Command for DASD Volumes

[Michael Watkins]

Before MVS/XA and RAID DASD, offline DASD volumes (e.g. 3330, 3350 & 3380 
units) had to be mounted instead of simply being varied online. The mount 
command used the volser of the offline DASD volume as a parameter.

Does anyone remember the format of the mount command?

Does anyone have the documentation in .pdf format?

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

Re: Stupid JCL question

[Michael Watkins]

Since the subsequent JCL statements won't be preceded by a JOB card, they will 
be discarded.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Friday, December 22, 2023 10:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Stupid JCL question

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

I should know this - I've been using JCL for decades - but I find I'm uncertain 
about something I haven't done in a while.  I have a production job here that 
will eventually be rewritten, but for now I'm just going to tell it to execute 
only the first couple steps.  I had in mind inserting "//" before the part of 
the JCL that I want to skip.  Very simple.

But wait - does the JCL interpreter discard the rest of the job when it sees 
that empty '//', or does it interpret the rest as the start of a new job?  
(Since there's no subsequent JOB statement I'm not terribly worried about it, 
but it's sloppy; maybe I should just use a COND parm on the JOB card.)  This 
info is probably in the JCL ref, but I don't immediately see it.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* "Poor Diogenes; if you knew how to get on with people you wouldn't have to 
live like that." / "Poor Aristippos; if you knew how to live like this you 
wouldn't have to get on with people."  -a condensation of their respective 
schools of thought a few centuries BC */

--
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: JES3plus & TDMF

[Michael Watkins]

-DS QD,VOL=A01P01,UCB
 IEE459I 06.45.24 DEVSERV QDASD 687
  UNIT VOLSER SCUTYPE DEVTYPE   CYL  SSID SCU-SERIAL DEV-SERIAL EFC
 049A8 A01P01 2107986 2107900 10017  4900 0175-KAD51 0175-KAD51 *OK
   UCB AT V026FA5B0
 0088FF8C49A8 00E4C3C2 3030200F006FA589 00010100C1F0F1D7
 F0F110A20001 026FA3B002898608 0012
   UCB PREFIX AT V028FB200
 000D9040 000116E8 289C16A9FF0002FF 27282B2C2E2F3435
 01080A01 01C2BEA0
   UCB COMMON EXTENSION AT V026FA588
 094020AA0008 028FB2000131 00FD44D4 026FA5401B00
   1 DEVICE(S) MET THE SELECTION CRITERIA
   0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING

The UCBJ3DV flag is the high-order byte of the UCB common extension. X'00' 
denotes the volume is not managed by JES3.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Friday, December 1, 2023 12:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES3plus & TDMF

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Thanks! Looking through 'DS QD,VOL=vv,UCB' now.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Friday, December 1, 2023 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES3plus & TDMF

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Those three APARs are over 20 years old and were fixed in 2001, so yes they're 
on. Have you looked at the DS QD command with the UCB option to display the 
UCB, Prefix and Common Extension?

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

On Friday, December 1st, 2023 at 12:46 PM, Michael Watkins 
<032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote:

> Apologies for the double listing to anyone who's also seen this on the JES3-L 
> LISTSERV.
>
> The government agency that employs me has three z/OS LPARs (V2R5) running on 
> a z15 server. The lone mainframe storage subsystem is a non-replicated, 
> channel-attached DS8886. This has never been a JES2 installation and Phoenix 
> Software's JES3plus is now installed. While the JES3 initialization deck has 
> DEVICE statements for all tape drives, it has not contained a DEVICE 
> statement for a DASD address in over a decade. In other words, DASD 
> allocation is not managed by JES3.
>
> The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to 
> migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can 
> move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD 
> volumes where the coupling facility resides without issues. A co-worker 
> insists that all of the LPARs must be brought down, separately, so that each 
> LPAR's 'sensitive' volumes can be moved from another LPAR.
>
> IBM documents state: 'JES3 considerations: In order to ensure that JES3 
> system defined volumes will migrate (not required for a Point-In-Time 
> migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and 
> OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS and 
> therefore, will allow the swapping of volumes. Important: All systems sharing 
> devices where JES3 manages the devices must be involved in the TDMF session 
> running. This ensures that all JES3 internal tables are properly updated. 
> Failure to do so will cause unpredictable results. It is recommended that the 
> user check the UCB for the following bit prior to copying volumes in a JES3 
> environment: UCBJ3DV - device is defined to JES3. If the bit is off, TDMF 
> will migrate the volume(s) with no errors. If the bit is on, TDMF will make 
> the appropriate calls to JES3 to notify JES3 of the volume redirection 
> needed.'
>
> Since the DASD volumes at this installation are not managed by JES3, I don't 
> think these APARs are an issue. However, to assuage my co-worker's fears, I'd 
> like to see whether the corresponding PTFs have been applied. Unfortunately, 
> I cannot find the PTFs that correspond to any of them.
>
> Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457?
>
> Also, I'm not sure how to display the UCBs involved to verify that the 
> UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help you 
> can provide on would be appreciated, particularly on how to use either 
> UCBSCAN or UCBLOOK macros.
>
>
> -

Re: JES3plus & TDMF

[Michael Watkins]

Thanks! Looking through 'DS QD,VOL=vv,UCB' now.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Friday, December 1, 2023 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES3plus & TDMF

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Those three APARs are over 20 years old and were fixed in 2001, so yes they're 
on. Have you looked at the DS QD command with the UCB option to display the 
UCB, Prefix and Common Extension?

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com


On Friday, December 1st, 2023 at 12:46 PM, Michael Watkins 
<032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote:


> Apologies for the double listing to anyone who's also seen this on the JES3-L 
> LISTSERV.
>
> The government agency that employs me has three z/OS LPARs (V2R5) running on 
> a z15 server. The lone mainframe storage subsystem is a non-replicated, 
> channel-attached DS8886. This has never been a JES2 installation and Phoenix 
> Software's JES3plus is now installed. While the JES3 initialization deck has 
> DEVICE statements for all tape drives, it has not contained a DEVICE 
> statement for a DASD address in over a decade. In other words, DASD 
> allocation is not managed by JES3.
>
> The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to 
> migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can 
> move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD 
> volumes where the coupling facility resides without issues. A co-worker 
> insists that all of the LPARs must be brought down, separately, so that each 
> LPAR's 'sensitive' volumes can be moved from another LPAR.
>
> IBM documents state: 'JES3 considerations: In order to ensure that JES3 
> system defined volumes will migrate (not required for a Point-In-Time 
> migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and 
> OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS and 
> therefore, will allow the swapping of volumes. Important: All systems sharing 
> devices where JES3 manages the devices must be involved in the TDMF session 
> running. This ensures that all JES3 internal tables are properly updated. 
> Failure to do so will cause unpredictable results. It is recommended that the 
> user check the UCB for the following bit prior to copying volumes in a JES3 
> environment: UCBJ3DV - device is defined to JES3. If the bit is off, TDMF 
> will migrate the volume(s) with no errors. If the bit is on, TDMF will make 
> the appropriate calls to JES3 to notify JES3 of the volume redirection 
> needed.'
>
> Since the DASD volumes at this installation are not managed by JES3, I don't 
> think these APARs are an issue. However, to assuage my co-worker's fears, I'd 
> like to see whether the corresponding PTFs have been applied. Unfortunately, 
> I cannot find the PTFs that correspond to any of them.
>
> Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457?
>
> Also, I'm not sure how to display the UCBs involved to verify that the 
> UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help you 
> can provide on would be appreciated, particularly on how to use either 
> UCBSCAN or UCBLOOK macros.
>
>
> --
> 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

JES3plus & TDMF

[Michael Watkins]

Apologies for the double listing to anyone who's also seen this on the JES3-L 
LISTSERV.

The government agency that employs me has three z/OS LPARs (V2R5) running on a 
z15 server. The lone mainframe storage subsystem is a non-replicated, 
channel-attached DS8886. This has never been a JES2 installation and Phoenix 
Software’s JES3plus is now installed. While the JES3 initialization deck has 
DEVICE statements for all tape drives, it has not contained a DEVICE statement 
for a DASD address in over a decade. In other words, DASD allocation is not 
managed by JES3. 

The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to 
migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can move 
the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD volumes 
where the coupling facility resides without issues. A co-worker insists that 
all of the LPARs must be brought down, separately, so that each LPAR’s 
‘sensitive’ volumes can be moved from another LPAR.

IBM documents state: ‘JES3 considerations: In order to ensure that JES3 system 
defined volumes will migrate (not required for a Point-In-Time migration) in a 
TDMF (or P/DAS) environment, APARs OW23271, OW28455, and OW28457 must be 
applied. These APARs provides JES3 DDR support for P/DAS and therefore, will 
allow the swapping of volumes. Important: All systems sharing devices where 
JES3 manages the devices must be involved in the TDMF session running. This 
ensures that all JES3 internal tables are properly updated. Failure to do so 
will cause unpredictable results. It is recommended that the user check the UCB 
for the following bit prior to copying volumes in a JES3 environment: UCBJ3DV - 
device is defined to JES3. If the bit is off, TDMF will migrate the volume(s) 
with no errors. If the bit is on, TDMF will make the appropriate calls to JES3 
to notify JES3 of the volume redirection needed.’

Since the DASD volumes at this installation are not managed by JES3, I don’t 
think these APARs are an issue. However, to assuage my co-worker’s fears, I’d 
like to see whether the corresponding PTFs have been applied. Unfortunately, I 
cannot find the PTFs that correspond to any of them.

Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457?

Also, I’m not sure how to display the UCBs involved to verify that the UCBJ3DV 
flag indicates that the volumes are not managed by JES3. Any help you can 
provide on would be appreciated, particularly on how to use either UCBSCAN or 
UCBLOOK macros.


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

Re: With regrets, after many years I will no longer be following IBM-MAIN

[Michael Watkins]

Does the 'System Z Enthusiasts' Discord server require an individual 
invitiation?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: Wednesday, August 30, 2023 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: With regrets, after many years I will no longer be following 
IBM-MAIN

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Thanks for the link Lionel.  I recall seeing this before but didn't follow 
through.  Now if I can only figure out Discord's bizarre account architecture 
(I seem to have an old account I can't link)

Matt Hogstrom

"To achieve great things two things are needed: a plan, and not quite enough 
time."
- Leonard Bernstein

> On Aug 30, 2023, at 10:21 AM, Lionel B. Dyck  wrote:
>
> There is now an option - the System Z Enthusiasts discord server.
>
> Join here 
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdisc
> ord.gg%2FdvPuM5dg2Y=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7Cc
> 727acb4378c4059b9a508dba9727766%7C2055feba299d4d0daa5a73b8b42fef08%7C0
> %7C0%7C638290081345953367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=2
> 4SyDYJb4oSCUcq97WO8t1Trq4I%2F69306emc8NFNZK4%3D=0


--
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: With regrets, after many years I will no longer be following IBM-MAIN

[Michael Watkins]

I've worked in this field for over 40 years and have met a few characters. The 
work seems to attract them. They are sometimes cantankerous.

Suggestion: If someone's post annoys you, don't read their contributions.

I'll continue to follow the threads because even the abrasive people sometimes 
contribute something worth reading.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kirk Wolf
Sent: Wednesday, August 30, 2023 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: With regrets, after many years I will no longer be following IBM-MAIN

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Dear ibm-mainers,

It is with regrets that after many years I will no longer be actively following 
IBM-MAIN.

The list has become intolerable because of trolling, off-topic thread 
hijacking, and personal attacks. The signal-to-noise ratio is approaching "1".  
 My assessment is that without some form of community governance and real 
moderation, IBM-MAIN will soon be completely useless except for the archives.

I want to sincerely thank all of the extremely knowledgeable and kind 
contributors from whom I have learned so much.   You are more than welcome to 
contact me directly for questions in my area of expertise.

Kirk Wolf
Dovetailed Technologies
http:// coztoolkit.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: Help for US Talent

[Michael Watkins]

Ha! When I was last looking for a job as a storage manager on the z/OS 
platform, a recruiter approached me with a position where I'd be responsible 
for renting out 10' x 10' storage units to people who'd already filled their 
garages with belongings they could not part with.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Tuesday, August 15, 2023 4:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help for US Talent

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Why do you want to get rid of them? If a recruiter calls, I politely say that 
I'm not interested at this time.
Depending on the context, I may politely explain that assembler programmer and 
assembly line technician are very different skill sets, and that the skills 
don't transfer well in either direction. No, I did not make this up, and it 
isn't a one-time thing.

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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Beaver [050e0c375a14-dmarc-requ...@listserv.ua.edu]
Sent: Monday, August 14, 2023 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Help for US Talent

Every time a recruiter calls me I have a sure way get rid of them and increase 
what they need to pay.
They ask me if I'm Steve, and I say yes
Then I tell them "Are you calling me with a job that pays $125/HR W2 or 
$210,000 perm?"
You hear them fade or die on the other end then I hang up.

--
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: Will z/OS be obsolete in 5 years?

[Michael Watkins]

What a BS 'survey'.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Tuesday, July 18, 2023 7:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Will z/OS be obsolete in 5 years?

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

IBM RHEL announced it's move to closed source (IBM RedHat Enterprise Linux). 
With some changes, DB2, RACF and other z/OS products could run in Linux on z16 
in one sysplexed Linux image. We know it's possible because IBM moved Unix and 
TCP into z/OS. IBM RHEL said closed source would force non-paying customers to 
buy RHEL licenses but this makes no sense. Something else must be in play.
I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain insights into 
IBM's decision to close source RHEL. You can skip the survey if you don't want 
to take it and view the survey results through this website. Feel free to pass 
this along.
 I think IBM wants to integrate z/OS products to retain their investments and 
expand their customer base..
Why is the z/OS community ignoring IBM RHEL closed source? Are software vendors 
preparing their products for Linux?


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

RSU Maintenance: Asking For a Friend

[Michael Watkins]

There is a shop where the current philosophy is to not put on any maintenance 
other than a PTF here and there if it is needed for a problem. But no RSU 
maintenance. Instead of maintenance, the plan is to just reinstall z/OS and all 
related products anytime they want to refresh the maintenance level, including 
in between z/OS upgrades. 

When it was suggested that a reinstall requires so much more effort and risk 
compared to RSU maintenance, the response was "it doesn't really and that a lot 
of shops do it that way". Sure there are some shops that never put on 
maintenance in-between upgrades, except the PTFs required for a problem. Are 
there other places that regularly reinstall everything instead of putting on 
maintenance? Are there benefits to this approach? Would this approach bother 
you?

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

.pdf Copy of 'Enhanced Catalog Sharing and Management, SG24-5594' (1999)?

[Michael Watkins]

Does anyone have a pdf copy of the IBM TotalStorage Redbook, 'Enhanced Catalog 
Sharing and Management, SG24-5594' that they'd be willing to share?

I think it was originally published in 1999.


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

pdf Copy of 'Enhanced Catalog Sharing and Management, SG24-5594' (1999)?

[Michael Watkins]

Does anyone have a pdf copy of the IBM TotalStorage Redbook, 'Enhanced Catalog 
Sharing and Management, SG24-5594' that they'd be willing to share?

I think it was originally published in 1999.

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

Re: Announcement Letters

[Michael Watkins]

'check announcement letters in new site'? Where is this new site with 
'announcement letters'?

The move from easily-obtainable PDFs to the online 'knowledge Center' means 
that retirement cannot come too quickly.

If I was more than a decade from retireing, I'd consider acquiring expertise on 
another platform.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bodra - Pessoal
Sent: Wednesday, May 17, 2023 2:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Announcement Letters

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Cross posted in zVSE, zVM and zOS lists.

It's unfortunate what IBM (unilaterally) did with changing the disclosure of 
their product announcement letters.
Every Tuesday for many years, I received an email with the summary, I just had 
to click on the desired link and that was it, the information was quickly 
accessible.
Today, when I received the e-mail announcing the publication of the new 
Redbooks, I remembered to check announcement letters in new site. Bad, very bad 
to found what you need to check in this new website.
Don't tell me that not sending the weekly email helps to improve life on the 
planet and other similar bla bla bla that doesn't convince me.
Very bad this new way that IBM has chosen to publicize its products. Sending 01 
weekly e-mail is not difficult at all and certainly, like me, many people liked 
it.

Carlos Bodra
IBM zEnterprise Certified
São Paulo - SP - Brazil
--
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

DITTO/ESA V1R3 User’s Guide, SH19-8221

[Michael Watkins]

DITTO/ESA V1R3 User’s Guide, SH19-8221

Does anyone have a .pdf copy of this document that could be emailed to me?

michael.watk...@cpa.texas.gov

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

Re: DLM Tape reading

[Michael Watkins]

'Inspect' in what way? What information about the tape dataset do you need? To 
determine with certainty that the dataset on the tape can be read?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Monday, March 20, 2023 10:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DLM Tape reading

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Hi Mike

I would like to inspect the tape dataset

On Mon, Mar 20, 2023, 7:42 PM Michael Watkins < 
032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote:

> Are you looking for the names of the datasets on the 3990 volumes that 
> are being backed up? If you're taking 'volume level' backups with (for
> instance) ADRDSSU, the contents of the entire volume will be put into 
> one output DUMP dataset and only the name of that full volume DUMP 
> dataset will be in the tape label.
>
> If you are looking for the dataset names on each 3390 volume being 
> backed up, consider running an IDCAMS 'DCOLLECT' on those 3390 volumes 
> immediately prior to the volume-level backups. Are you backing up the entire 
> shop?
> Depending on the size of your shop, a DSCOLLECT might take 20-30 
> minutes to complete with a SYSIN control card along the lines of:
>
> DCOLLECT OUTFILE(DCOUT) VOLUMES(*) EXCLUDEVOLUMES(XX* FC* F2* Z1*)
>
> Perhaps keep the DCOLLECT output in a GDG with a LIMIT that matches 
> the numer of backup tapes for each 3390 volume that you keep.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Mark Zelden
> Sent: Monday, March 20, 2023 10:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DLM Tape reading
>
> CAUTION: This email originated from outside of the Texas Comptroller's 
> email system.
> DO NOT click links or open attachments unless you expect them from the 
> sender and know the content is safe.
>
> On Mon, 20 Mar 2023 17:10:20 +0400, Jake Anderson < 
> justmainfra...@gmail.com> wrote:
>
> >Hello
> >
> >I would like to understand how DLM users are able to read the 
> >contents of the virtual tape and the print the dataset with in each label of 
> >it ?
> >
> >We are taking volume level backup to the virtual tape and is it 
> >possible to list a particular tape dataset to see it's content?
> >
> >Regards
> >Jake
>
> I'm not sure I understand the question.  Are you thinking there are 
> stacked virtual volumes like Oracle/STK VSM?  The virtual tapes are 
> just like physical tapes and you can print them any number of utilities.
>
> Or are you asking from a DLm perspective?  If so, research the "awsprint"
> command from DLm.
>
> It just asking about from z/OS, again... lots of utilities.  From ISV
> (FATS/FATAR) to IBM DITTO, to IEBGENER to "print" the contents.  If 
> just interested in labels, I haven't used this PROC in probably 25 
> years, but here is something to just print the labels.
>
>
> //MPROC  PROC  HP=1
> //PS10   EXEC  PGM=IEBPTPCH
> //SYSPRINT DD  SYSOUT=*
> //SYSUT1   DD  DSN=MZELDEN.TAPE,
> // DISP=(SHR,KEEP,KEEP),
> // UNIT=TAPE,
> // LABEL=(,BLP,EXPDT=98000),
> // VOL=SER=vv,
> // DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
> //SYSUT2   DD  SYSOUT=*
> //SYSINDD  DDNAME=SYSIN1
> //MPROC  PEND
> //*
> //* HP=1 FOR VOL1 HDR1 HDR2   *
> //* HP=3 FOR EOF1 EOF2*
> //*
> //JS10   EXEC  PROC=MPROC,HP=1
> //SYSPRINT DD  SYSOUT=*
> //SYSIN1   DD  *
>  PRINT MAXFLDS=1
>  TITLE ITEM=('TAPE LABEL INFO',30)
>  RECORDFIELD=(80,1)
>  LABELSDATA=YES
> /*
>
>
> Best Regards,
>
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL 
> v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities:
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.m
> zelden.com%2Fmvsutil.html=05%7C01%7Cmichael.watkins%40CPA.TEXAS.G
> OV%7C55829aad693745531ef408db29bd3132%7C2055feba299d4d0daa5a73b8b42fef
> 08%7C0%7C0%7C638149664781144530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> data=DgfTwNjPBeinsIxgG2svm%2Bh9UKDdElWIHTBLDgTMygA%3D=0
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --

Re: DLM Tape reading

[Michael Watkins]

Are you looking for the names of the datasets on the 3990 volumes that are 
being backed up? If you're taking 'volume level' backups with (for instance) 
ADRDSSU, the contents of the entire volume will be put into one output DUMP 
dataset and only the name of that full volume DUMP dataset will be in the tape 
label.

If you are looking for the dataset names on each 3390 volume being backed up, 
consider running an IDCAMS 'DCOLLECT' on those 3390 volumes immediately prior 
to the volume-level backups. Are you backing up the entire shop? Depending on 
the size of your shop, a DSCOLLECT might take 20-30 minutes to complete with a 
SYSIN control card along the lines of:

DCOLLECT OUTFILE(DCOUT) VOLUMES(*) EXCLUDEVOLUMES(XX* FC* F2* Z1*)

Perhaps keep the DCOLLECT output in a GDG with a LIMIT that matches the numer 
of backup tapes for each 3390 volume that you keep.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Zelden
Sent: Monday, March 20, 2023 10:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DLM Tape reading

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

On Mon, 20 Mar 2023 17:10:20 +0400, Jake Anderson  
wrote:

>Hello
>
>I would like to understand how DLM users are able to read the contents 
>of the virtual tape and the print the dataset with in each label of it ?
>
>We are taking volume level backup to the virtual tape and is it 
>possible to list a particular tape dataset to see it's content?
>
>Regards
>Jake

I'm not sure I understand the question.  Are you thinking there are stacked 
virtual volumes like Oracle/STK VSM?  The virtual tapes are just like physical 
tapes and you can print them any number of utilities.

Or are you asking from a DLm perspective?  If so, research the "awsprint" 
command from DLm.

It just asking about from z/OS, again... lots of utilities.  From ISV 
(FATS/FATAR) to IBM DITTO, to IEBGENER to "print" the contents.  If just 
interested in labels, I haven't used this PROC in probably 25 years, but here 
is something to just print the labels.


//MPROC  PROC  HP=1
//PS10   EXEC  PGM=IEBPTPCH
//SYSPRINT DD  SYSOUT=*
//SYSUT1   DD  DSN=MZELDEN.TAPE,
// DISP=(SHR,KEEP,KEEP),
// UNIT=TAPE,
// LABEL=(,BLP,EXPDT=98000),
// VOL=SER=vv,
// DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
//SYSUT2   DD  SYSOUT=*
//SYSINDD  DDNAME=SYSIN1
//MPROC  PEND
//*
//* HP=1 FOR VOL1 HDR1 HDR2   *
//* HP=3 FOR EOF1 EOF2*
//*
//JS10   EXEC  PROC=MPROC,HP=1
//SYSPRINT DD  SYSOUT=*
//SYSIN1   DD  *
 PRINT MAXFLDS=1
 TITLE ITEM=('TAPE LABEL INFO',30)
 RECORDFIELD=(80,1)
 LABELSDATA=YES
/*


Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mzelden.com%2Fmvsutil.html=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7Cc18942d930434b8fb26808db29548e55%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C638149215366690623%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=oYfDMeAZjDdo9%2BRo8UVTwy0N2FhXhWVptjygw2YmXFw%3D=0

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

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

Re: IBM's Fall From World Dominance

[Michael Watkins]

Why? As the article you posted notes : In 1982, the case was dropped by a 
judgement ruling it "without merit." See: 
https://www.nytimes.com/1981/02/15/business/us-vsibm.html which claims:

The trial began in May 1975. Before the outset, the Government estimated that 
the presentation of its case would last 60 days. Instead, it took three years. 
The Justice Department is on its third lead counsel. Robert H. Bork, a Yale law 
professor, has dubbed the case ''the antitrust division's Vietnam.''

Moreover, given the rapid pace of change in the computer industry, the case now 
centers on a market situation that existed two or three technological 
generations ago. ''It's pretty much an historical curiosity,'' an I.B.M. 
competitor concedes.

Some outside observers view the I.B.M. case as proof that the Justice 
Department cannot and should not be trying to restructure major global 
industries. Irving S. Shapiro, chairman of E.I. duPont de Nemours & Company, a 
lawyer who spent several years in Justice, says: ''All the ballplayers are 
above their heads in these cases that concern the structure of key industries. 
From the lawyer who drafted the case right on up, you're talking about people 
who have no experience in economics or industry.''


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Tuesday, February 28, 2023 3:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM's Fall From World Dominance

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

I find it disingenuous when someone doesn't mention the antitrust lawsuit filed 
against IBM in 1969 and dropped in 1982.

https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcs.stanford.edu%2Fpeople%2Feroberts%2Fcs181%2Fprojects%2Fcorporate-monopolies%2Fgovernment_ibm.html=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C0c7eb32d389147a4d8d608db19d51d54%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C638132175332879927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=1AB7x6vngOKZs4xUbWETKljQKD8miQNyYFi9fQAhb2k%3D=0





Sent from Yahoo Mail for iPhone


On Tuesday, February 28, 2023, 4:15 PM, Phil Smith III  wrote:

https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspectrum.ieee.org%2Fibms-fall-from-world-dominance=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C0c7eb32d389147a4d8d608db19d51d54%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C638132175332879927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=sLXMAqg%2FEOpsL9aVRAPRxa%2FZOBHM22g0d3L9G8VI8EA%3D=0



Not negative overall, just recognizing that things have changed, for the most 
part.






--
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: Goodbye and thanks for all the fish

[Michael Watkins]

It's a Microsoft communication product that includes video calling, instant 
messaging and bulletin board features. And who knows what else.

But don't you have to be using the same Microsoft server to communicate with 
someone else on Teams? My employer uses it for communication within the 
organization.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: Wednesday, February 8, 2023 8:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Goodbye and thanks for all the fish

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

That's how we communicate quick messages used to be Skype should be on your 
laptop

On Wed, Feb 8, 2023 at 9:20 AM Seymour J Metz  wrote:

> I'm not familiar with teams.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason
> .gmu.edu%2F~smetz3=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C5e
> c7d46360ec4cf88cb108db09dfdb67%7C2055feba299d4d0daa5a73b8b42fef08%7C0%
> 7C0%7C638114629285910596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=2g
> 9%2FTLskXsblDHUVhB31N67%2BURXonQeMIBc2wYtBYQY%3D=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Joseph Reichman [reichman...@gmail.com]
> Sent: Wednesday, February 8, 2023 9:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Goodbye and thanks for all the fish
>
> Seymour I dont see you on teams
>
> On Wed, Feb 8, 2023 at 9:09 AM Seymour J Metz  wrote:
>
> > Good luck in your retirement.
> >
> > FWIW, I got a lot of queries since I accepted my new job, so if you
> decide
> > to go back to the workplace this might be a good time. Are you on 
> > DICE, linkedIn or Monster?
> >
> > 42.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmas
> > on.gmu.edu%2F~smetz3=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%
> > 7C5ec7d46360ec4cf88cb108db09dfdb67%7C2055feba299d4d0daa5a73b8b42fef0
> > 8%7C0%7C0%7C638114629285910596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > C=2g9%2FTLskXsblDHUVhB31N67%2BURXonQeMIBc2wYtBYQY%3D=
> > 0
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> > behalf of carl swanson 
> > [0252c152a1b5-dmarc-requ...@listserv.ua.edu]
> > Sent: Wednesday, February 8, 2023 7:46 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Goodbye and thanks for all the fish
> >
> > While I have not been a very active member, I have 
> > been a very active lurker for years. My 45+ year journey is coming 
> > to an end
> again
> > as my employer has picked my retirement date for me. I hope this 
> > time to
> do
> > retirement correctly and make it work, previous attempts have failed
> maybe
> > this time I can get it right.
> >
> >
> >
> > It has been a pleasure for me to work with 
> > Mainframes and in my case Mainframe Virtual tape, that last part for 
> > most of my last 30 years.
> > I have learned many things from this group, including many that I 
> > would never use but were interesting.
> >
> >
> >
> > Good luck to all and show the world that Mainframes 
> > are here to stay
> >
> >
> >
> > Carl Swanson
> >
> > 215-688-1459
> >
> > carl.swans...@verizon.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
> >
> --
> Joe Reichman
>
> --
> 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
>
--
Joe Reichman

--
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: Goodbye and thanks for all the fish

[Michael Watkins]

It was an honor and a pleasure to work with you during the install of the 
Dell/EMC Data Domain (DD9800) & Disk Library for the mainframe (DLm2100).
Your technical expertise and clear explanations were invaluable to the success 
of the project, despite my clear preference for the IBM TS7700 alternative.
Your humor and positive attitude were appreciated and you will be missed as my 
employer now looks to refresh this solution.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
carl swanson
Sent: Wednesday, February 8, 2023 6:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Goodbye and thanks for all the fish

While I have not been a very active member, I have been a very active lurker 
for years. My 45+ year journey is coming to an end again as my employer has 
picked my retirement date for me. I hope this time to do retirement correctly 
and make it work, previous attempts have failed maybe this time I can get it 
right.

It has been a pleasure for me to work with Mainframes and in my case Mainframe 
Virtual tape, that last part for most of my last 30 years.
I have learned many things from this group, including many that I would never 
use but were interesting.

Good luck to all and show the world that Mainframes are here to stay

Carl Swanson
215-688-1459
carl.swans...@verizon.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: I want to cry

[Michael Watkins]

I'd guess there is no one that receives these emails who has an interest in 
every topic discussed, whether those topics are in technical threads or more 
the more 'off-topic' threads.

If a thread does not interest me, I simply ignore it. I find that works for me, 
whether the thread is technical or off-topic. If or when that doesn't work for 
me, I'll unsubscribe.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Monday, February 6, 2023 12:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: I want to cry

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Bingo. There are more people here who never help versus those that do. Also, 
there are far more mainframe people who aren’t even subscribed to IBM-MAIN than 
are subscribed. I have rarely needed assistance but when I did, I RTFM, or went 
directly to IBM or IBMers. Sent direct emails to Mr. Thomen,(RIP) Mr. 
Quackenbush, and others whose expertise is beyond this forum. Do I think there 
are talented individuals here? Of course. But, there are also some who are full 
of crap or just here for the professional networking.


Sent from Yahoo Mail for iPhone


On Monday, February 6, 2023, 12:52 PM, Seymour J Metz  wrote:

It's a bit more complicated. While there ma be people who never help and people 
who always help, there are also people whose response depends on how busy they 
are at the time and who is requesting assistance.


From: IBM Mainframe Discussion List  on behalf of Tom 
Brennan 
Sent: Monday, February 6, 2023 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: I want to cry

"IT was just the means to an end"

Ah, that explains why I can't remember you ever helping someone here with a 
technical issue.  Pretty-much anyone I've ever worked with who got into this 
business *only* because they saw money, was generally less-technical and often 
ended up in management.  The folks who were truly interested in computers were 
the ones who got things done technically and were always ready to help others.

On 2/6/2023 9:01 AM, Bill Johnson wrote:
> Me too. People who post non-stop, every day, all day, obviously have no life 
> outside of IBM-MAIN. Whereas, I rarely post because I’m doing a ton of 
> traveling. But, that’s been true throughout my IT career. Whether it was my 
> travels to NY to be on the MILLIONAIRE show, my $10,000 reward for helping 
> the FBI solve a robbery of an armored car facility, to global travels, IT was 
> just the means to an end. Not what defined me. Back to lurking.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, February 6, 2023, 11:50 AM, Steve Smith  wrote:
>
> I do feel sorry for those of you who evidently have no social life 
> whatsoever outside of IBM-MAIN.
>
> But most of us would be very gratified if you'd STFU about off-topics.
> You're polluting the forum and wasting our time.
>
> sas
>
> --
> 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




--
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: Transmitting SMF records

[Michael Watkins]

Glenn Wilcock shared 
https://public.dhe.ibm.com/eserver/zseries/zos/DFSMS/CDA/OA62318/Cloud_Object_Utility_Pub_updates.pdf

The document at this URL states: z/OS MVS Programming: Callable Services for 
High Level Languages is updated to add a new chapter after 'Part 10: SMF 
Services' as follows: 'Part 11: Cloud Data Access Services'.

However, when I use either google or an IBM URL 
(https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5Library?OpenDocument)
 to search for this document, I only find an earlier version without the 
additional Part 11.

Can anyone provide a newer link to IBM documentation where I can find this 
updated version of the SA23-1377 document?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Glenn Wilcock
Sent: Thursday, January 19, 2023 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Transmitting SMF records

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Late to the party on this discussion... DFSMS recently shipped a new utility 
named GDKUTIL.  It converts z/OS data sets and UNIX files to cloud objects and 
visa-versa.  This enables utilizing cloud object storage as a method for z/OS 
sharing data, such as SMF, as opposed to FTPing.  Use GDKUTIL to write the data 
to object storage for shared access across sysplexes / platforms and visa-versa 
- ingest off-platform data into z/OS.  DFSMS CDA (Cloud Data Access) is used to 
securely manage cloud access.

https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.dhe.ibm.com%2Feserver%2Fzseries%2Fzos%2FDFSMS%2FCDA%2FOA62318%2FCloud_Object_Utility_Pub_updates.pdf=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C22dc17e633fc4131b2d908dafa58c9cd%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C638097556513326232%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=grotivTONiSwuDBIiUJdl6Pb7uZAcsgMkWFgAgIzyXk%3D=0

Glenn Wilcock, DFSMS Chief Product Owner

--
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: KMOD1 DS8k box

[Michael Watkins]

I understood Jake's question differently; I thought he was just asking what was 
indicated by what he saw in the DS8k GUI and whether his z/OS capacity could be 
determined from the DS8k GUI. I do not believe it can be.

People familiar with DS8k frames configured as ECKD storage can quibble about 
how much of the magnetic surface actually contains application data until the 
cows come home. All good.

The question I hinted at (sorry, should have clearly asked) was how any of this 
changes as we move from a DS8k with spinning disked RAIDed together to a 
flash-based DS8900F. I ask because I have no experience with DS8900F technology.

Without spinning parts, are there still IRGs, even virtual, when a DS8900F is 
configured as ECKD? An ECKD-configured DS8k still has this 'wasted' space, even 
though the 3390 IRGs do not necessarily correspond to anything phsical on the 
Seagate disks spinning inside the frame. The IRGs exist (I assume) so 
facilitate the DS8k appearing to be a native 3390 to z/OS.

I intended to ask: 'Are all of these inefficienies still mirrored in this next 
generation (DS8900F) for the sake of still appearing to be a native 3390 to 
z/OS?'

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Friday, January 20, 2023 7:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: KMOD1 DS8k box

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Classification: Confidential

With IRGs and other "overhead" the usable capacity is about 0.8 GB whis is what 
I use when making "capacity" calculations.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Thursday, January 19, 2023 7:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: KMOD1 DS8k box

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

See 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzvse%2F6.2%3Ftopic%3DSSB27H_6.2.0%2Ffe6rf_optimizing_casize_disksizes.htm=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C25d11e0d5d97418180ba08dafaeaf23b%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C638098184244423910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=rd9gpav7skfFG71CwkHBsbThcTi2c1QopulawSE4WGA%3D=0

A 3390 MOD-1 has 1,113 cylinders. Each 3390 cylinder has 15 tracks. Each 3390 
track has 56,664 bytes.

1,113 x 15 x 56,664 = 946,005,480

There are 946,005,480 bytes in a 3390 MOD-1 disk drive. Or roughly 0.946 GB.

The PC-compatible disk drives in your DS8k frame have a fixed block 
architecture (FBA) which, after being RAIDed together (RAID is 'Redundant Array 
of Independent Disks'), create virtual FBA volumes consisting of multiple 1GB 
(1,000,000,000) extents. These extents are 'raw' storage.
However, z/OS only recognizes count key data (CKD) formatted tracks and native 
3390 drives (with a multiple platters on a single spindle) have not been 
manufactured in this century.
To remedy this, when the DS8k frame is installed, each 1 GB FBA extent is 
configured as 1,113 CKD cylinders. Larger virtual 3390s are then constructed 
from these configured extents.

Not exactly sure what you're looking at in the DS8k GUI, but '1.99Kmod1' sounds 
like '1.99 k mod1' 3390s, or 1.99 x 1000 x 946,005,480 bytes. Or 
1,882,550,905,200 bytes. Or 1.88 TB

Notice that almost 5.4% of the raw storage has been 'lost' when the FBA disk is 
configured as CKD storage. Now add the space 'lost' to VTOCs, VTOC indices, 
VVDSs, and unused space, both within the boundaries of an allocated data set 
and the free space on each 3390 volume. The remainder is data. Not sure how the 
all-flash DS8900F works as far as configuring and 'lost' space.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Thursday, January 19, 2023 3:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: KMOD1 DS8k box

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

 846,236,160 bytes * 1990 M1s is 1,684,009,958,400 bytes.

On Thu, Jan 19, 2023 at 3:53 AM Mike Schwab  wrote:

3390-1 is 846,236,160 bytes.  Divide by 1000 or 1024 three times for a Gigabyte 
factor, or four times for a Terabyte conversion factor.

On Thu, Jan 19, 2023 at 1:29 AM Jake Anderson  wrote:

Hello

I was going through the storage usage in DS8K Gui login And I can see the 
utilization of CKD Pool is given as 1.99Kmod1

Is there a way to convert these value in Terabyte?

Jake

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers

Re: KMOD1 DS8k box

[Michael Watkins]

I could be wrong, but I suspect that any information you get from the GUI will 
simply tell you how much of the raw storage has been configured as volumes that 
can be used by the operating systems connected to your DS8k. The GUI cannot 
make sense of the data on the volumes. To the GUI, I think those volumes appear 
to be no more than a stream of zeros and ones. It cannot tell the difference 
between unused space and data. To ascertain the utilization of those volumes, 
you must use the commands or utilities executed on the operating systems that 
know them as data. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Thursday, January 19, 2023 11:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: KMOD1 DS8k box

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Is there a command or facility within DS8K to generate storage array 
utilization report ?

On Thu, Jan 19, 2023, 5:51 PM Paul Gorlinsky  wrote:

> This is the theoretical maximum… not realistic… the available usable 
> space is 100% determined by the blksize and optional key size… zOS use 
> at most
> 1/2 track blocking … it you force a 32760 block size you will waste 
> about 12k per track… safe numbers are about 90% for estimating
>
> --
> 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: KMOD1 DS8k box

[Michael Watkins]

See 
https://www.ibm.com/docs/en/zvse/6.2?topic=SSB27H_6.2.0/fe6rf_optimizing_casize_disksizes.htm

A 3390 MOD-1 has 1,113 cylinders. Each 3390 cylinder has 15 tracks. Each 3390 
track has 56,664 bytes.

1,113 x 15 x 56,664 = 946,005,480

There are 946,005,480 bytes in a 3390 MOD-1 disk drive. Or roughly 0.946 GB.

The PC-compatible disk drives in your DS8k frame have a fixed block 
architecture (FBA) which, after being RAIDed together (RAID is 'Redundant Array 
of Independent Disks'), create virtual FBA volumes consisting of multiple 1GB 
(1,000,000,000) extents. These extents are 'raw' storage.
However, z/OS only recognizes count key data (CKD) formatted tracks and native 
3390 drives (with a multiple platters on a single spindle) have not been 
manufactured in this century.
To remedy this, when the DS8k frame is installed, each 1 GB FBA extent is 
configured as 1,113 CKD cylinders. Larger virtual 3390s are then constructed 
from these configured extents.

Not exactly sure what you're looking at in the DS8k GUI, but '1.99Kmod1' sounds 
like '1.99 k mod1' 3390s, or 1.99 x 1000 x 946,005,480 bytes. Or 
1,882,550,905,200 bytes. Or 1.88 TB

Notice that almost 5.4% of the raw storage has been 'lost' when the FBA disk is 
configured as CKD storage. Now add the space 'lost' to VTOCs, VTOC indices, 
VVDSs, and unused space, both within the boundaries of an allocated data set 
and the free space on each 3390 volume. The remainder is data. Not sure how the 
all-flash DS8900F works as far as configuring and 'lost' space.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Thursday, January 19, 2023 3:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: KMOD1 DS8k box

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

 846,236,160 bytes * 1990 M1s is 1,684,009,958,400 bytes.

On Thu, Jan 19, 2023 at 3:53 AM Mike Schwab  wrote:

3390-1 is 846,236,160 bytes.  Divide by 1000 or 1024 three times for a 
Gigabyte factor, or four times for a Terabyte conversion factor.

On Thu, Jan 19, 2023 at 1:29 AM Jake Anderson  wrote:

Hello

I was going through the storage usage in DS8K Gui login And I can 
see the utilization of CKD Pool is given as 1.99Kmod1

Is there a way to convert these value in Terabyte?

Jake

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

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

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

Using CATLIST on z/OS?

[Michael Watkins]

'DFSMS Managing Catalogs', V2R5, p.59: 'You can list catalog records using the 
access method services LISTCAT command, or the ISMF line operator CATLIST. 
CATLIST produces the same output as LISTCAT, but places the output in a data 
set that can be browsed.'

'DFSMS Using the Interactive Storage Management Facility', V2R4, tells you on 
p.69 that CATLIST is the name of a CLIST and cannot be abbreviated and 
describes CATLIST on p.141: 'Obtain an IDCAMS LISTCAT output for a particular 
data set.'

Does anyone know where to find more documentation on how to use the ISPF line 
operator 'CATLIST', perhaps with an example? 

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

Re: SAS ODS in the Mainframe environment

[Michael Watkins]

All mainframe-related questions are welcome as far as I know, but you might 
have better luck on: MXG Software LIST 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kenneth J. Kripke
Sent: Tuesday, November 22, 2022 12:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SAS ODS in the Mainframe environment

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Hello;

 I realize this is not the correct forum to be asking questions regarding 
SAS, but, it appears that SAS-L is no longer available?

The question is as follows:

I would like to produce an XCEL spreadsheet written to a member of a 
pre-allocated PDSE.  I have fiddled with the various statements to accomplish 
this, but, to no avail.

The type of data to be stored is the result of a PROC PRINT with character 
data.  Does anyone else on the list have some experience and suggestions on 
this?



Kenneth J. Kripke



k.kri...@comcast.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: Is HFS still a thing?

[Michael Watkins]

IBM says: 'Before z/OS V1R7, the HFS file system was the primary hierarchical 
file system. As of z/OS V1R7, you can use any combination of HFS and zFS file 
systems. Because zFS has higher performance characteristics than HFS and is the 
strategic file system, you should migrate your HFS file systems to zFS.'

See: 'z/OS DFSMS Using Data Sets', Version 2, Release 5, p.451



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Wednesday, September 14, 2022 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is HFS still a thing?

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Well, both JCL and the TSO/E ALLOCATE command still only take "HFS" as a value 
for DSNTYPE when allocating a Unix PATH file.

E.G. for ALLOC:

ALLOC FI(MYDDNAME) PATH('/u/tsouser/file') DSNTYPE(HFS) PATHMODE(SIRUSR) 
PATHOPTS(ORDONLY) FILEDATA(TEXT) PATHDISP(KEEP, KEEP)

For JCL, see here:  
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.5.0%3Ftopic%3Ddp-syntax-10data=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C38bbe74c449f46f0f16308da967dd705%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637987764474288674%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=PRgUqloWkSzEy0OdPI93ByVVHYmenqJ4%2BGE6A6OVZqA%3Dreserved=0
For ALLOCATE see here:  
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.5.0%3Ftopic%3Dcommand-allocate-operandsdata=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C38bbe74c449f46f0f16308da967dd705%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637987764474288674%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=fXVHhkfKLjpRSr0zmUfk69mvtkjQPE0vmRLEOnhNR3s%3Dreserved=0

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Wednesday, September 14, 2022 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Is HFS still a thing?

I just submitted an RCF on various z/OS 2.5. TSO/E publications which mention 
HFS with no mention of HFS EOS.

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
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: ADR971E RC 8

[Michael Watkins]

Answered, I think: 

When I try to create a DATACLAS for non-SMS-managed VSAM clusters with extended 
addressability, ISMF seems to tell me that if the cluster will not be in 
extended format, the cluster must be a linear dataset. That is, it cannot be, 
for instance, a KSDS cluster.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Tuesday, September 13, 2022 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ADR971E RC 8

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

To create a non-SMS-managed VSAM cluster with extended addressability, what is 
required other than assigning a DATACLAS with column 27 (EXTENDED 
ADDRESSABILITY) specified as 'YES'?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, September 13, 2022 11:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ADR971E RC 8

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

I can define an EA/EF VSAM Linear dataset on both SMS and Non-SMS volumes. Both 
are usable and the catalog entries for both reflect their EA/EF status.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.comdata=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7Cce30a1b17839419bce7908da95b3d94a%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637986896933815126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=9FizR75U%2FUgDbxdeEixQ%2B5ye87wDx7riOJD0d5nBnsw%3Dreserved=0


--- Original Message ---
On Tuesday, September 13th, 2022 at 12:05 PM, Ernesto Figueroa 
 wrote:


> Hi Mark,
>
> The reason ADRDSSU cannot copy/restore non-SMS extended addressable VSAM LDS 
> data sets to SMS managed extended addressable VSAM LDS is because the non-SMS 
> EA is not an extended-format data set, which requires it to be SMS. The SMS 
> EA is extended-format, and therefore it has an additional 32bytes per 
> physical block. Since the blocks are not the same, we cannot copy/restore 
> tracks between them.
>
> I hope this answers your question,
> Thanks!
>
> Ernesto E. Figueroa
> DFSMSdss Product Owner
>
>
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf 
> of Mark Jacobs 0224d287a4b1-dmarc-requ...@listserv.ua.edu
>
> Date: Monday, September 12, 2022 at 10:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: [EXTERNAL] ADR971E RC 8
> I got around the problem a different way, but I'd really like to understand 
> why ADRDSSU won't restore(logically dumped) or copy a non-SMS extended 
> addressable VSAM LDS dataset to an SMS managed extended addressable VSAM LDS. 
> Is there something within the physical dataset that's different between it 
> being SMS managed vs not being SMS managed?
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key -
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.
> protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40proton
> mail.comdata=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7Ca87ac70e
> 107c4a816c2208da95a31004%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C
> 637986824836113089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mJHJ
> wSHMqVq4GEqbNCa9wNgSN1HddqdKXNOv9fvvVW0%3Dreserved=0
>
> --
> 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

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

Re: ADR971E RC 8

[Michael Watkins]

To create a non-SMS-managed VSAM cluster with extended addressability, what is 
required other than assigning a DATACLAS with column 27 (EXTENDED 
ADDRESSABILITY) specified as 'YES'?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, September 13, 2022 11:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ADR971E RC 8

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

I can define an EA/EF VSAM Linear dataset on both SMS and Non-SMS volumes. Both 
are usable and the catalog entries for both reflect their EA/EF status.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.comdata=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7Ca87ac70e107c4a816c2208da95a31004%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637986824836113089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mJHJwSHMqVq4GEqbNCa9wNgSN1HddqdKXNOv9fvvVW0%3Dreserved=0


--- Original Message ---
On Tuesday, September 13th, 2022 at 12:05 PM, Ernesto Figueroa 
 wrote:


> Hi Mark,
>
> The reason ADRDSSU cannot copy/restore non-SMS extended addressable VSAM LDS 
> data sets to SMS managed extended addressable VSAM LDS is because the non-SMS 
> EA is not an extended-format data set, which requires it to be SMS. The SMS 
> EA is extended-format, and therefore it has an additional 32bytes per 
> physical block. Since the blocks are not the same, we cannot copy/restore 
> tracks between them.
>
> I hope this answers your question,
> Thanks!
>
> Ernesto E. Figueroa
> DFSMSdss Product Owner
>
>
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf 
> of Mark Jacobs 0224d287a4b1-dmarc-requ...@listserv.ua.edu
>
> Date: Monday, September 12, 2022 at 10:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: [EXTERNAL] ADR971E RC 8
> I got around the problem a different way, but I'd really like to understand 
> why ADRDSSU won't restore(logically dumped) or copy a non-SMS extended 
> addressable VSAM LDS dataset to an SMS managed extended addressable VSAM LDS. 
> Is there something within the physical dataset that's different between it 
> being SMS managed vs not being SMS managed?
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key - 
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.
> protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40proton
> mail.comdata=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7Ca87ac70e
> 107c4a816c2208da95a31004%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C
> 637986824836113089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mJHJ
> wSHMqVq4GEqbNCa9wNgSN1HddqdKXNOv9fvvVW0%3Dreserved=0
>
> --
> 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: Extending a VTOC

[Michael Watkins]

I hope I'm only stating the obvious, but back the volume up before you do 
anything.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jack Zukt
Sent: Monday, August 1, 2022 10:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extending a VTOC

Thank you all for your input.
I am going to try it like that
Regards,
Jack

On Mon, 1 Aug 2022 at 11:58, Immo  wrote:

> P.S.
> EXTVTOC(n) is a parameter of the ICKDSF command REFORMAT.
> Michael
>
> -Ursprüngliche Nachricht-
> Von: IBM Mainframe Discussion List  Im 
> Auftrag von Jack Zukt
> Gesendet: Montag, 1. August 2022 12:15
> An: IBM-MAIN@LISTSERV.UA.EDU
> Betreff: Extending a VTOC
>
> Hi all,
> It has been way too many years since the last time I dabbled with 
> ICKDSF and VTOC definitions (probably over twenty, but I would rather 
> not do the math).
> Back on those days, if memory serves me right, the only way to extend 
> a VTOC was to clean the DASD of all its contents, put it offline, and 
> recreate the VTOC with the new size. As a few years have passed, I 
> have been going through the ICKDSF manual trying to find out if a VTOC 
> can be extended without having to clear the volume first. I can not 
> say that I have became enlightened. It seems to be possible but I am 
> not quite sure about it. And this being a production volume I really 
> would hate if things do not work as expected.
> So, in a nut shell, can I extend a VTOC from 90 to 900 tracks without 
> having first to clean the DASD of all its files?
> Thank you in advance for any help,
> Best regards
> Jack
>
> --
> 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: DLMSCR - EDGJRPTE

[Michael Watkins]

DFSMSrmm/DLm guy here says:

The RMM scratch report that comes out of the housekeeping job RMMHSKP is when 
needs to be sent to DLMSCR. Or if you choose another way to produce the report 
it needs to match exactly. Below is the JCL EXEC card used to produce the 
report.

//SCRATCHL EXEC PGM=EDGRPTD, 
// PARM='SEC(''DAILY SCRATCH''),DATEFORM(I)'


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Friday, July 29, 2022 12:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DLMSCR - EDGJRPTE

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Hello

I am trying to run a DLM scratch job using EDGJRPTE output but unfortunately 
DLMSCR is not able to recognize the header of the RPTE.

Is there any kind of tweak needs to be done in EDGRRPTE exec so that DLMSCR 
understand the format ?

Could someone please help me with this?

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

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

Latest Release? DFSMSdfp Diagnosis Reference (GY27-7618-03) Fourth Edition, June 2003, z/OS V1R3

[Michael Watkins]

z/OS DFSMSdfp Diagnosis Reference (GY27-7618-03) Fourth Edition, June 2003, 
z/OS V1R3

Does anyone know whether there is a more recent edition of 'DFSMSdfp Diagnosis 
Reference'? I can't find one and this seems pretty old...

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

Re: Finding uncatalogued datasets

[Michael Watkins]

The installation where I'm employed has MVS/QuickRef installed, but we do not 
currently use it to find uncataloged datasets.

Can you provide a sample of the batch job using MVS/Quickref to find all 
uncataloged datasets? Preferably one that would employ a mask for volumes to 
exclude, since temporary datasets, restricted to one pool where I work, are not 
cataloged by design. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Shaw
Sent: Friday, July 22, 2022 10:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Finding uncatalogued datasets

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Jack,

MVS/QuickRef will give you a list of the uncataloged data sets across all your 
online DASD volumes, with one batch job, and you don't need to code any DD 
statements.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

On Fri, Jul 22, 2022, 10:00 AM Jack Zukt  wrote:

> Hi all,
> As a byproduct of what I am working now, I have found out a few 
> uncatalogued datasets. Now I would like to find out all the 
> uncatalogued datasets that are forgotten on the hundred of volumes that are 
> out there.
> Using ADRDDSU and   (CATLG EQ NO) is not an option as it would need a DD
> for each VOLSER. I could write a rexx that would read the DCOLLECT
> VOLUMES(*) NODATAINFO and generate a JOB for each VOLSER or group of 
> VOLSERs but I really would like to use a more standard approach. I 
> seem to remember, from another age, that FDRABR could do it. However 
> Dr. Google has not been able to find me anything to that effect using only 
> IBM tools.
> Do you have any ideas how to go about this?
> Your help will be, as always, greatly appreciated.
> Regards,
> Jack
>
> --
> 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: SMS volume status of QUINEW?

[Michael Watkins]

So QUNEW can function to 'reserve' volumes for datasets with very large primary 
allocations, requests that might not be satisfied if free space was not 
consolidated on the QUINEW volume? 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Thursday, July 21, 2022 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMS volume status of QUINEW?

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

QuiNew keeps volumes as empty as possible, but if a dataset cannot be allocated 
on all the other volumes it will be allocated on a QuiNew volume.  VS a DisNew 
volume is destined to be taken offline when empty and new datasets cannot be 
allocated on the volume..

On Thu, Jul 21, 2022 at 10:32 AM Claude Richbourg 
 wrote:
>
> Good morning all,
>
> We are curious about the reasoning behind the QUINEW status for SMS 
> volume(s). We use DISNEW for SMS volumes that we want to eventually phase out 
> and we discovered there were older volumes that had an existing assignment of 
> QUINEW within some storage groups.
>
> It appears that the status of QUINEW would allow SMS to allocate space on 
> those volumes if needed. I had never heard of that status before until 
> recently when  I was cleaning up the different storage pools.
>
> Imagine my surprise when I set the volume status of those that had QUINEW to 
> DISNEW and a couple of batch jobs failed. I had to throw a few mod-27’s into 
> the pool to bring up the free space.
>
> Apparently, QUINEW works differently then DISNEW and we were wondering about 
> the history and reasoning behind that status?
> Does anyone know why it was created and to what purpose would it serve, or 
> does it pre-date DISNEW?
>
> Thanks up front.
> Claude
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

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

SG24-2557 'System/390 MVS Parallel Sysplex Batch Performance' .pdf?

[Michael Watkins]

Does anyone have a .pdf of an old IBM redbook called 'System/390 MVS Parallel 
Sysplex Batch Performance' (SG24-2557) that they'd be willing to share?

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

Re: [EXTERNAL] Re: IBM BLSR subsystem

[Michael Watkins]

"At some sites, the most gargantuan thing about making a change like this is 
getting past the politics of getting managers who don't want to change 
anything." Exactly, and any little burp will be evidence the platform isn't as 
reliable as it's cracked up to be and/or that the people administering it 
aren't competent. All existing SLAs are being met, so the attitude tends toward 
'If it ain't broke, why fix it?'.

Higher management in this organization once refused funds to upgrade the 
mainframe operating system. Their reasoning was 'the mainframe is due to be 
replaced next year and the new machine will come with the upgraded operating 
system already installed, so why do this now?' Ever feel like you're wading in 
molasses?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Friday, May 20, 2022 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM BLSR subsystem

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

When change means being able to more consistently meet your contractual SLA's 
and handle ever-increasing client input volume that tends to make the politics 
a lot easier.  Missed SLA's hit their bottom line, so that's where they tend to 
focus.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Friday, May 20, 2022 9:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM BLSR subsystem

At some sites, the most gargantuan thing about making a change like this is 
getting past the politics of getting managers who don't want to change anything.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Thursday, May 19, 2022 6:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IBM BLSR subsystem

Excuse me, what is gargantuan in moving to extended format?
Note: we are talking about *application* datasets, not ICF, SyS1.MANx, system, 
VVDS or whatever.
Note2: it need NOT to be big bang approach, you can change definitions for 
some/few datasets. And only for new allocations.

IMHO it is like walk to the park - the most gargantuan thing is to make first 
step.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 19.05.2022 o 16:48, Michael Watkins pisze:
> Thanks for the history and a definitive word on BLSR. From your (and others') 
> remarks, it seems obvious that BLSR has been supereceded by SMB. So why not 
> just implement SMB?
>
> Doesn't SMB only work if the clusters whose buffers you want to manage are 
> defined as extended format? In contrast, BLSR does not require extended 
> format, correct?
>
> Extended format datasets are the exception where I am employed, not the rule. 
> Recreating the DASD farm in extended format would be a gargantuan task, 
> requiring the buy-in of far-flung managers with limited technical acumen 
> who'd see such efforts as a lot of work for very little benefit. At this 
> point, implementing BLSR until SMB can be a reality might provide some 
> immediate relief.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Jim Mulder
> Sent: Thursday, May 19, 2022 12:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IBM BLSR subsystem
>
> BLSR was initially developed by Washinton System Center as an assembler 
> language sample program to go along with a book they were writing about using 
> the Subsystem Interface.  At the time, IBM was desperately looking for "ESA 
> Exclusives" in order to sell 3090 machines vs the PCM manufacturers, who 
> machines had not yet implemented ESA.  This sample program happened to use 
> one BAKR/PR, which meant that it did require ESA.
>
>   So MVS management wanted to instead ship the program an OCO part of the MVS 
> BCP, and I was commanded to review the code to see what that would  entail.
> I raised several objections concerning the maintainability of the code, the 
> lack of serviceability (no ESTAEs, no dumping, no control block eyecatchers,  
> we didn't want new assembler code), no message IDs, lack of messages and 
> message control, an integrity exposure, etc, etc.  Also, VSAM functionality 
> was not really in the BCP's bailiwick, and we would end up having to support 
> this code for decades.
> So I recommended that we should not do this.
>
>But, since selling machines trumps everything, I lost that argument, and 
> was instead assigned to remediate all of my objections to the sample code.
> I recoded  the whole thing in PL/AS and fixed all of the issues, and wrote 
> lots of testcases,  and it got shipped as a PTF on top of MVS/ESA SP3.1.3.
> MVS Project Management did contribute the "Batch LSR&q

Re: IBM BLSR subsystem

[Michael Watkins]

Thank you for your reply. I'd be curious to know what was in your small list.

Specifically:

(1) What programming techniques were employed that disallowed home-grown 
application files from being in extended format?
(2) What vendor proctucts (if any) required datasets that could not be extended 
format?

I don't mean to make a project for you, but any light you could shed would be 
appreciated.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
PINION, RICHARD W.
Sent: Thursday, May 19, 2022 10:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM BLSR subsystem

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

We did something similar in our QA LPAR.  We changed our ACS routines to assign 
everything to extended format and extended addressing.  During the mock 
production run, we were able to identify, and exclude the datasets that could 
not be extended/extended.  The list is quite small.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Thursday, May 19, 2022 10:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM BLSR subsystem

[External Email. Exercise caution when clicking links or opening attachments.]

For the past few years, I've been looking at re-writing the ACS routines with 
an eye toward making extended format datasets the default, ferreting out 
datasets that cannot tolerate extended format and then assigning a DATACLAS 
that includes extended formating. To my knowledge, the following cannot be in 
extended format:

  * Catalogs
  * System data sets (SMS is not active at early IPL stages)
  * Temporary data sets
  * SAS-formatted data sets (?)

To help me with this task,  does anyone know of other datasets that cannot be 
defined as extended format? Has anyone else considered including extended 
formating as a default and encountered problems? Any advice or experiences you 
could share would be appreciated.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Thursday, May 19, 2022 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM BLSR subsystem

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Thanks for the history and a definitive word on BLSR. From your (and others') 
remarks, it seems obvious that BLSR has been supereceded by SMB. So why not 
just implement SMB?

Doesn't SMB only work if the clusters whose buffers you want to manage are 
defined as extended format? In contrast, BLSR does not require extended format, 
correct?

Extended format datasets are the exception where I am employed, not the rule. 
Recreating the DASD farm in extended format would be a gargantuan task, 
requiring the buy-in of far-flung managers with limited technical acumen who'd 
see such efforts as a lot of work for very little benefit. At this point, 
implementing BLSR until SMB can be a reality might provide some immediate 
relief.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jim 
Mulder
Sent: Thursday, May 19, 2022 12:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM BLSR subsystem

BLSR was initially developed by Washinton System Center as an assembler 
language sample program to go along with a book they were writing about using 
the Subsystem Interface.  At the time, IBM was desperately looking for "ESA 
Exclusives" in order to sell 3090 machines vs the PCM manufacturers, who 
machines had not yet implemented ESA.  This sample program happened to use one 
BAKR/PR, which meant that it did require ESA.

 So MVS management wanted to instead ship the program an OCO part of the MVS 
BCP, and I was commanded to review the code to see what that would  entail.
I raised several objections concerning the maintainability of the code, the 
lack of serviceability (no ESTAEs, no dumping, no control block eyecatchers,  
we didn't want new assembler code), no message IDs, lack of messages and 
message control, an integrity exposure, etc, etc.  Also, VSAM functionality was 
not really in the BCP's bailiwick, and we would end up having to support this 
code for decades.
So I recommended that we should not do this.

  But, since selling machines trumps everything, I lost that argument, and was 
instead assigned to remediate all of my objections to the sample code.
I recoded  the whole thing in PL/AS and fixed all of the issues, and wrote lots 
of testcases,  and it got shipped as a PTF on top of MVS/ESA SP3.1.3.
MVS Project Management did contribute the "Batch LSR" name.

  Decades later, we continue to support it and probably always will, but at 
least the right solution eventually got implemented by SMB in DFSMS.

  And now you know...  the rest 

Re: IBM BLSR subsystem

[Michael Watkins]

For the past few years, I've been looking at re-writing the ACS routines with 
an eye toward making extended format datasets the default, ferreting out 
datasets that cannot tolerate extended format and then assigning a DATACLAS 
that includes extended formating. To my knowledge, the following cannot be in 
extended format:

  * Catalogs  
  * System data sets (SMS is not active at early IPL stages)  
  * Temporary data sets   
  * SAS-formatted data sets (?)

To help me with this task,  does anyone know of other datasets that cannot be 
defined as extended format? Has anyone else considered including extended 
formating as a default and encountered problems? Any advice or experiences you 
could share would be appreciated.
 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Thursday, May 19, 2022 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM BLSR subsystem

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Thanks for the history and a definitive word on BLSR. From your (and others') 
remarks, it seems obvious that BLSR has been supereceded by SMB. So why not 
just implement SMB?

Doesn't SMB only work if the clusters whose buffers you want to manage are 
defined as extended format? In contrast, BLSR does not require extended format, 
correct?

Extended format datasets are the exception where I am employed, not the rule. 
Recreating the DASD farm in extended format would be a gargantuan task, 
requiring the buy-in of far-flung managers with limited technical acumen who'd 
see such efforts as a lot of work for very little benefit. At this point, 
implementing BLSR until SMB can be a reality might provide some immediate 
relief.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jim 
Mulder
Sent: Thursday, May 19, 2022 12:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM BLSR subsystem

BLSR was initially developed by Washinton System Center as an assembler 
language sample program to go along with a book they were writing about using 
the Subsystem Interface.  At the time, IBM was desperately looking for "ESA 
Exclusives" in order to sell 3090 machines vs the PCM manufacturers, who 
machines had not yet implemented ESA.  This sample program happened to use one 
BAKR/PR, which meant that it did require ESA.

 So MVS management wanted to instead ship the program an OCO part of the MVS 
BCP, and I was commanded to review the code to see what that would  entail.
I raised several objections concerning the maintainability of the code, the 
lack of serviceability (no ESTAEs, no dumping, no control block eyecatchers,  
we didn't want new assembler code), no message IDs, lack of messages and 
message control, an integrity exposure, etc, etc.  Also, VSAM functionality was 
not really in the BCP's bailiwick, and we would end up having to support this 
code for decades.
So I recommended that we should not do this.

  But, since selling machines trumps everything, I lost that argument, and was 
instead assigned to remediate all of my objections to the sample code.
I recoded  the whole thing in PL/AS and fixed all of the issues, and wrote lots 
of testcases,  and it got shipped as a PTF on top of MVS/ESA SP3.1.3.
MVS Project Management did contribute the "Batch LSR" name.

  Decades later, we continue to support it and probably always will, but at 
least the right solution eventually got implemented by SMB in DFSMS.

  And now you know...  the rest of the story.

James Harvey Mulder  z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY



From: IBM Mainframe Discussion List  on behalf of 
Dave Barry <00a5644c6d08-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, May 18, 2022 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: [EXTERNAL] Re: IBM BLSR subsystem

>IIRC, Batch LSR was developed at IBM by the BCP team; SMB was later developed 
>by the DFdfp team.  SMB is not BLSR under-the-covers, but it offers the same 
>advantages.

>SMB is the more modern solution.  It has worked wonders at my shop.  Just mind 
>your REGION size.  If you haven't converted some VSAM files to Extended 
>Format, this is a good reason to do so.

>The VSAM Demystified Redbook is a good resource.  Lots on the Web, e.g.
>https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
>%2Fdata=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C7ea0404c10b340
>b10ded08da39a6a48a%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C6378856
>85137992926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
>iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=3CXUAs1BAzYCn
>1dAXwnV0wQ8j8cKufRXZzVMNGwjQUc%3Dreserved=0
>bm.

Re: IBM BLSR subsystem

[Michael Watkins]

Thanks for the history and a definitive word on BLSR. From your (and others') 
remarks, it seems obvious that BLSR has been supereceded by SMB. So why not 
just implement SMB?

Doesn't SMB only work if the clusters whose buffers you want to manage are 
defined as extended format? In contrast, BLSR does not require extended format, 
correct?

Extended format datasets are the exception where I am employed, not the rule. 
Recreating the DASD farm in extended format would be a gargantuan task, 
requiring the buy-in of far-flung managers with limited technical acumen who'd 
see such efforts as a lot of work for very little benefit. At this point, 
implementing BLSR until SMB can be a reality might provide some immediate 
relief.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jim 
Mulder
Sent: Thursday, May 19, 2022 12:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM BLSR subsystem

BLSR was initially developed by Washinton System Center as an assembler 
language sample program to go along with a book they were writing about using 
the Subsystem Interface.  At the time, IBM was desperately looking for "ESA 
Exclusives" in order to sell 3090 machines vs the PCM manufacturers, who 
machines had not yet implemented ESA.  This sample program happened to use one 
BAKR/PR, which meant that it did require ESA.

 So MVS management wanted to instead ship the program an OCO part of the MVS 
BCP, and I was commanded to review the code to see what that would  entail.
I raised several objections concerning the maintainability of the code, the 
lack of serviceability (no ESTAEs, no dumping, no control block eyecatchers,  
we didn't want new assembler code), no message IDs, lack of messages and 
message control, an integrity exposure, etc, etc.  Also, VSAM functionality was 
not really in the BCP's bailiwick, and we would end up having to support this 
code for decades.
So I recommended that we should not do this.

  But, since selling machines trumps everything, I lost that argument, and was 
instead assigned to remediate all of my objections to the sample code.
I recoded  the whole thing in PL/AS and fixed all of the issues, and wrote lots 
of testcases,  and it got shipped as a PTF on top of MVS/ESA SP3.1.3.
MVS Project Management did contribute the "Batch LSR" name.

  Decades later, we continue to support it and probably always will, but at 
least the right solution eventually got implemented by SMB in DFSMS.

  And now you know...  the rest of the story.

James Harvey Mulder  z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY



From: IBM Mainframe Discussion List  on behalf of 
Dave Barry <00a5644c6d08-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, May 18, 2022 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: [EXTERNAL] Re: IBM BLSR subsystem

>IIRC, Batch LSR was developed at IBM by the BCP team; SMB was later developed 
>by the DFdfp team.  SMB is not BLSR under-the-covers, but it offers the same 
>advantages.

>SMB is the more modern solution.  It has worked wonders at my shop.  Just mind 
>your REGION size.  If you haven't converted some VSAM files to Extended 
>Format, this is a good reason to do so.

>The VSAM Demystified Redbook is a good resource.  Lots on the Web, e.g. 
>https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
>bm.com%2Fdocs%2Fen%2Fzos%2F2.5.0%3Ftopic%3Dresource-tuning-system-manag
>ed-bufferingdata=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C2ea34
>0e656744339ec3b08da395c32ba%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%
>7C637885365415122967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
>oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=8kne
>cZQfc8fCOXxtg2R0PiSnEkiHPgN3ZbJIv8o6Q%2FA%3Dreserved=0


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

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

Re: IBM BLSR subsystem

[Michael Watkins]

BLSR is referenced on page 305 of 'Batch Modernization on z/OS' (July, 2012; 
z/OS V1R9):

Implementing data in memory (DIM) techniques is a complex task, but one likely 
to yield good results. It means exploiting appropriately the various software 
facilities available to eliminate unnecessary I/Os. These I/Os include repeated 
reads of the same data, such as:

 * DB2 buffer pools
 * Virtual I/O (VIO) in Central Storage
 * Queued Sequential Access Method (QSAM) buffering
 * Batch LSR Subsystem (BLSR) exploiting VSAM Local Shared Resources buffering
 * DFSORT Large Memory Object sorting

To be able to implement DIM techniques, you need spare memory, spare CPU 
capacity, and a batch workload that is I/O-intensive


I can find no 'guide' for BLSR except the 1994 reference. Some z/OS features 
don't change very fast. A JCL reference from 1994 would be adequate for 99% of 
all inquires.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Monday, May 16, 2022 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM BLSR subsystem

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

The subsysten initialization module is still in SYS1.LINKLIB for z/OS 2.5. 
There's an eyecatcher with 17259 and HBB77C0 in it.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.comdata=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C2b813d3f29024dd1dc1c08da375ba3b6%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637883163979035974%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=8z0medXxVEs2B7XfBWdd9Qw%2BlI4J%2F25TcY4BhSW1V2Q%3Dreserved=0


--- Original Message ---
On Monday, May 16th, 2022 at 12:00 PM, allan winston  
wrote:


> Building upon Mark and Peter's replies...
>
> Having retired in 2005, I can't be absolutely certain, but it is 
> highly likely that it is still supported, as I am finding reference to 
> Batch LSR when searching z/OS 2.5 manuals.
>
>
>
> If you have MXG in your shop, potential candidates for batch LSR can 
> be found by running the ANALBLSR program, referring to the 
> documentation in member ADOCBLSR. In effect, this will find candidate 
> jobs where the VSAM access is random instead of sequential. You do not 
> want to use LSR when the VSAM file is accessed sequentially.
>
>
>
> To some extent, it can be argued that Batch LSR has been superseded by 
> facilities within DFSMS.
>
> System Managed Buffering(SMB) will implement LSR if all the DFSMS 
> constructs are in place and Direct Optimized has been chosen:
>
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> lascon.co.uk%2FVSAM-System-Buffers.phpdata=05%7C01%7Cmichael.watk
> ins%40CPA.TEXAS.GOV%7C2b813d3f29024dd1dc1c08da375ba3b6%7C2055feba299d4
> d0daa5a73b8b42fef08%7C0%7C0%7C637883163979035974%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7Csdata=xDE8FUDazw6nILBx%2Fih3G1AKakOSecCzmpaKUP4Cpd
> s%3Dreserved=0
>
>
>
>
>
>
>
> For the non-DFSMS case, there are also 3rd party software products 
> that can be used to alter batch programs to use LSR instead of the 
> default NSR mode. I was in a shop that used the Data Optimizer 
> component of the BMC Mainview Batch Optimizer for that purpose. Going 
> this route was simpler than modifying a large number of catalogued procedures.
>
>
>
> Note that in the rare case that you are using LSR, rather than the 
> more modern RLS, within CICS that you can choose specific buffer sizes 
> for the index and data buffer pools using Resource Definition Online. 
> Do not let your heavily accessed files default to buffer pool 1, where 
> an inferior algorithm will be used to choose buffer assignments.
>
>
>
> There is a very interesting GTF trace, F61,that can give you 
> additional insight into the random access pattern of your VSAM file 
> accesses - both batch and CICS. There was a package from MKTTOOLS 
> called VLBPAA, that was based on the F61 GTF trace which I used 
> extensively for gaining insight into optimizing buffer assignments. No 
> one seems to have been able to obtain this product from IBM for the 
> past 20 years. The results did become slightly inaccurate with the 
> introduction of extended format datasets which modified the meaning of one of 
> the fields within the GTF trace.
>
>
>
> The use of VLBPAA and the layout of the F61 GTF trace was documented 
> in a
> 1995 Redbook, SG24-2557 System/390 MVS Parallel Sysplex Batch Performance.
> Additionally, that manual shows an ICETOOL job stream that can perform 
> a rudimentary analysis. That book has been removed from the Redbooks 
> web site - 

Re: Remove a storage group from the SCDS

[Michael Watkins]

Yes. Try this:

(1) ISMF option 6, ('Storage Group')
  Select option 1 ('List')
  Enter 'DELETE' as a line operator to the left of the storage group name

(2) ISMF option 7 ('Automatic Class Selection')
  Select option 3 ('Validate') <= assumes the current ACS routines have 
already been translated (ISMF option 7;2)
  Note active SCDS name

(3) Issue MVS console command 'SETSMS SCDS(active SCDS name)'
  Verify all members of the SMSplex have been updated with MVS console 
command 'D SMS'


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Doug Shupe
Sent: Monday, May 16, 2022 1:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Remove a storage group from the SCDS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Is the Storage Group still in the  Storage Group List ?

If yes, I believe you can delete it with DELETE in the line operator column.

Best Regards,
Doug

> On May 16, 2022, at 13:43, Binyamin Dissen  wrote:
>
> IGD06122I STORAGE GROUP ?? HAS NO VOLUMES IGD06023I STORAGE GROUP 
> ??  IS NOT REFERENCED BY THE STORAGE GROUP
>
> So, no, it isn't in the ACS routine.
>
> On Mon, 16 May 2022 18:12:32 +0100 Nigel Morton 
> 
> wrote:
>
> :>Have you removed the storage group from the storage group ACS routine?
>
> :>On Mon, 16 May 2022 at 16:44, Binyamin Dissen 
> 
> :>wrote:
>
> :>> I removed all volumes from a storage group, and could not activate 
> the SCDS :>> since the storage group was empty.
>
> :>> But I cannot figure out how to remove the empty storage group.
>
> :>> What step am I missing?
>
> --
> Binyamin Dissen 
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d
> issensoftware.com%2Fdata=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GO
> V%7Cbd674b989d32435e174508da3765f0f0%7C2055feba299d4d0daa5a73b8b42fef0
> 8%7C0%7C0%7C637883208224415117%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> p;sdata=cA9s417YxvzBFtbt217AB6CxDPMCje3s7aButUYAcHY%3Dreserved=0
>
> Director, Dissen Software, Bar & Grill - Israel
>
> --
> 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: Use of zCX

[Michael Watkins]

Does anyone have a URL for the LINUX-390 list?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kirk Wolf
Sent: Tuesday, April 26, 2022 10:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Use of zCX

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Very good point.
Phil - I haven't been subscribed for a year or two to linux-390  - are they 
discussing arch=390x docker packages as needed for zCX as well?   VM/Linux vs  
zCX?   I would assume yes to both.

On Tue, Apr 26, 2022, at 10:07 AM, Phil Smith III wrote:
> I'm compelled to note that all of the discussion of third-party 
> product availability, difficulty (or not) of porting, etc. has been 
> rehashed over the last 20 years on the LINUX-390 list. That doesn't 
> mean it's not a valid discussion, just that joining that list will 
> likely get more detailed answers.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

Kirk Wolf
Dovetailed Technologies
https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdovetail.com%2Fdata=05%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C9357a9407d7f43a4d39408da27971f94%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637865827534086101%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=L7bqJzoJVj6jRnbCeyFMxEz3Votf6UStcw4UfUFDdtY%3Dreserved=0

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

FYI: IBM z16 Day SE Starts Soon!

[Michael Watkins]

From: Kim | BeMyApp 
Sent: Tuesday, April 5, 2022 4:00 AM
To: Michael Watkins 
Subject: IBM z16 Day SE Starts Soon!

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.
[https://mcusercontent.com/7605d9f2f2cc8f3d1a43d7f54/images/d29c2810-3edf-e37c-96d9-659a57ed63c4.png]
Hello,
IBM z16 Day SE is about to begin! The conference kicks off today, April 5th, 
10:00 AM to 6:30 PM EST. We hope you're ready to connect, learn, and be 
inspired by IBM z16 Day SE.

To view the presentations, just log into the platform 
(https://ibmz16day-se.bemyapp.com<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbemyapp.us2.list-manage.com%2Ftrack%2Fclick%3Fu%3D7605d9f2f2cc8f3d1a43d7f54%26id%3D4fa586a8d9%26e%3D80aa07d0d5=04%7C01%7Cmichael.watkins%40cpa.texas.gov%7C9d6b94ca7eb047887e3808da16e2cf6a%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637847460657430595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=l0wFBATPNz16shB7d%2BRNowMmJCoKj34sjsIlYkHXkfs%3D=0>)
 using your user name and password. If you have attended previous IBM events, 
the credentials should be the same. Don't hesitate to reach out to me if you 
have any issues.

You can find the full conference agenda and plan your day here: 
https://ibmz16day-se.bemyapp.com/#/agenda<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbemyapp.us2.list-manage.com%2Ftrack%2Fclick%3Fu%3D7605d9f2f2cc8f3d1a43d7f54%26id%3Dd772ba56ea%26e%3D80aa07d0d5=04%7C01%7Cmichael.watkins%40cpa.texas.gov%7C9d6b94ca7eb047887e3808da16e2cf6a%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637847460657430595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=N5xHjnCvPb2ui0IR%2BtEv3RAo%2BrQF3Z7Dppotquhtua4%3D=0>

Quick reminder, if you are unable to attend a session live, you can view a 
replay after the conference. Please don't hesitate to reach out to me if you 
have any questions or concerns. Enjoy the conference!
Best,
Kim
(on behalf of the IBM z16 Day SE team)





This email was sent to 
michael.watk...@cpa.texas.gov<mailto:michael.watk...@cpa.texas.gov>
why did I get 
this?<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbemyapp.us2.list-manage.com%2Fabout%3Fu%3D7605d9f2f2cc8f3d1a43d7f54%26id%3D477abd7470%26e%3D80aa07d0d5%26c%3De9601ca60f=04%7C01%7Cmichael.watkins%40cpa.texas.gov%7C9d6b94ca7eb047887e3808da16e2cf6a%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637847460657430595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=zNFzDgHLGiChR0y6SAXE9VTA5rw3FkfjYSgcuPHZIx8%3D=0>
unsubscribe from this 
list<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbemyapp.us2.list-manage.com%2Funsubscribe%3Fu%3D7605d9f2f2cc8f3d1a43d7f54%26id%3D477abd7470%26e%3D80aa07d0d5%26c%3De9601ca60f=04%7C01%7Cmichael.watkins%40cpa.texas.gov%7C9d6b94ca7eb047887e3808da16e2cf6a%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637847460657430595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=5a9x0rUu49FYogD1APUpLRxg2Nt1hdbdO%2FVoGsFO3l4%3D=0>
update subscription 
preferences<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbemyapp.us2.list-manage.com%2Fprofile%3Fu%3D7605d9f2f2cc8f3d1a43d7f54%26id%3D477abd7470%26e%3D80aa07d0d5%26c%3De9601ca60f=04%7C01%7Cmichael.watkins%40cpa.texas.gov%7C9d6b94ca7eb047887e3808da16e2cf6a%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637847460657430595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=XP9%2BwMhz6wiGs5jFuVDaMbfdR9GXDSZmaMgtSTVL%2BKc%3D=0>
BEMYAPP * 18 Boulevard Michelet * 8E ARRONDISSEMENT * MARSEILLE 13008 * France


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

Re: Can SORTWKnn Data Sets Use More Than One Volume?

[Michael Watkins]

Nevermind.

DFSORT Application Programming Guide, P.68, "DFSORT uses only the space on the 
first volume specified for a multivolume data set. Space on the second and 
subsequent volumes is not used. Multivolume SORTWKdd data sets are, therefore, 
treated as single-volume SORTWKdd data sets."

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Thursday, March 24, 2022 2:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Can SORTWKnn Data Sets Use More Than One Volume?

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

I've always understood that SORTWKnn data sets could only reside on a single 
volume, but a co-worker coded DATACLAS=PSE on SORTWKnn DD cards and, as the 
DATACLASS dictated, 59 volumes were allocated to the SORTWKnn DD. Of course, 
simply because volumes were allocated doesn't mean they were actually written 
to. The sort step completed with RC=0, but I suspect that data was only written 
to the first volume. A quick search of the IBM documentation doesn't seem to 
provide a conclusive answer. Anyone got a clue?

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

Can SORTWKnn Data Sets Use More Than One Volume?

[Michael Watkins]

I've always understood that SORTWKnn data sets could only reside on a single 
volume, but a co-worker coded DATACLAS=PSE on SORTWKnn DD cards and, as the 
DATACLASS dictated, 59 volumes were allocated to the SORTWKnn DD. Of course, 
simply because volumes were allocated doesn't mean they were actually written 
to. The sort step completed with RC=0, but I suspect that data was only written 
to the first volume. A quick search of the IBM documentation doesn't seem to 
provide a conclusive answer. Anyone got a clue? 

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

Re: Resizing MCDS

[Michael Watkins]

I heartily agree that SMS-management and RLS is the preferred way to define all 
DFSMShsm CDSs. I made the rash assumption that Peter simply need to resize the 
MCDS in the near future instead of making a project out of it by defining the 
required coupling facility structures and making the DFSMShsm CDSs SMS-managed. 
Can the MCDS exceed the 4 GB limit without SMS-management? From the following 
discussion, it appears it can be:

See: https://www.zmainframes.com/viewtopic.php?t=2009

'Over coming the 4 GB limit of VSAM.', Mon Feb 22, 2016 6:29 pm, Robert Sample: 
 If you read the manual on DEFINE CLUSTER, you will discover that the manual 
EXPLICITLY states that DATACLASS can be used for SMS or non-SMS managed 
storage. Yes, it is part of SMS but it can also be used outside SMS.

Sat Feb 27, 2016 6:00 pm, Angel:  I have suggested to use the Extended  Format 
(VSAM EF) files. As I read about them, they allow to add an extra 32 control 
bytes to each data block. But they need to be DFSMS managed. It seems to solve 
the problem. So even if a DATACLASS is also given the restriction of 4GB 
anyways remains, right?

Sat Feb 27, 2016 7:42 pm, Robert Sample:  This is another reason you REALLY 
need to talk to your site support group. If the DATACLASS given does not 
support VSAM extended format (a DATACLASS can be used for different reasons), 
then yes the 4 GB limit still applies. Only someone working at your site can 
provide you with the site-specific information you need on how to get your VSAM 
data set to go past 4 GB; we can only say that yes it can be done.

Wed May 04, 2016 4:42 pm, Angel:  We ended up using 4 GB limit, as going beyond 
that was not recommended by the policies.

Thu May 05, 2016 1:22 am, Robert Sample:  Policies often wind up being in 
effect long after they should have been changed.  I've used a number of VSAM 
linear and KSDS data sets as large as 60 GB with no problems; a policy against 
them makes less and less sense as time passes.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Nigel Morton
Sent: Tuesday, February 22, 2022 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Resizing MCDS

I would suggest using extended addressability VSAM to avoid the 4GB limit as 
well as considering multi-cluster CDSs (for MCDS and BCDS, don't think it is 
supported for the OCDS). I'd also recommend using RLS as I've seen it speed up 
long-running HSM functions significantly.

Both extended addressability and RLS for HSM CDSs have been around for several 
years.

On Tue, 22 Feb 2022 at 15:50, Michael Watkins < 
032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote:

Yes, all DFSMShsm ASIDs in the HSMplex must be down. (All DFSMShsm ASIDs that 
share control datasets and a journal are in the same HSMplex.) I would rename 
the existing MCDS by appending the current date [either '.#22feb22' or 
'.#22053' (Julian date) for today, for example] to the index and data component 
names as well as to the cluster name. By including the date last used in the 
new dataset name, there will be less question of what the cluster is when you 
don't delete it and someone else is looking at it next year and wondering if 
they can reclaim the space.

First, After renaming the MCDS, I would then define the new (presumably larger) 
MCDS with the old name by using the MODEL parameter and changing only the CYLS 
for both the data and index components to (x 0). By using the same MCDS name, 
no JCL will have to be changed. No secondary should be allocated to any of the 
DFSMShsm control datasets when they are shared by DFSMShsm ASIDs on different 
LPARs, unless the DFSMShsm CDSs are managed with RLS (Record Level Sharing).

Second, REPRO the old '.#yyddd' MCDS into the new MCDS.

Third, restart DFSMShsm on all LPARs, one at a time. Done.

Let's assume your MCDS's characteristics are:
KEYLEN: 44 AVGLRECL: 435 BUFSPACE: 530432 CISIZE: 12288  RKP: 0 
MAXLRECL: 2040 EXCPEXIT: (NULL) CI/CA: 60 SHROPTNS(3,3)
SPEED UNIQUE NOERASE INDEXED NOWRITECHK UNORDERED 
NOREUSE NONSPANNED

If your MCDS is not SMS-managed, then I would suggest allocating the maximum 
CYLS(5825 0) for the MCDS data component, which will allow the MCDS to reach as 
close to the VSAM 4 GB limit as possible while still allocating in CYLS instead 
of TRKS. Something close to 'CYLS(30 0)'  should be sufficient for the MCDS 
index component. I would also suggest devoting an entire MOD-9 to the MCDS to 
avoid contention for the volume.

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Allan Staller
> Sent: Tuesday, February 22, 2022 7:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Resizing MCDS
>
Essentially yes. HSM must be down for the duration.

I would also rename the original to .old and the new to the original name. A 
lot of JCL would need to be changed otherwise. Of course take backups.

HTH,
>
> 

Re: Resizing MCDS

[Michael Watkins]

Yes, all DFSMShsm ASIDs in the HSMplex must be down. (All DFSMShsm ASIDs that 
share control datasets and a journal are in the same HSMplex.) I would rename 
the existing MCDS by appending the current date [either '.#22feb22' or 
'.#22053' (Julian date) for today, for example] to the index and data component 
names as well as to the cluster name. By including the date last used in the 
new dataset name, there will be less question of what the cluster is when you 
don't delete it and someone else is looking at it next year and wondering if 
they can reclaim the space.

First, I would then define the new (presumably larger) MCDS with the old name 
by using the MODEL parameter and changing only the CYLS for both the data and 
index components to (x 0). By using the same MCDS name, no JCL will have to be 
changed. No secondary should be allocated to any of the DFSMShsm control 
datasets when they are shared by DFSMShsm ASIDs on different LPARs, unless the 
DFSMShsm CDSs are managed with RLS (Record Level Sharing).

Second, REPRO the old '.#yyddd' MCDS into the new MCDS.

Third, restart DFSMShsm on all LPARs, one at a time. Done.

Let's assume your MCDS's characteristics are:

KEYLEN: 44 AVGLRECL: 435 BUFSPACE: 530432 CISIZE: 12288 RKP: 0  
   MAXLRECL: 2040 EXCPEXIT: (NULL) CI/CA: 60 SHROPTNS(3,3)
SPEED UNIQUE NOERASE INDEXED NOWRITECHK UNORDERED  
NOREUSE NONSPANNED

If your MCDS is not SMS-managed, then I would suggest allocating the maximum 
CYLS(5825 0) for the MCDS data component, which will allow the MCDS to reach as 
close to the VSAM 4 GB limit as possible while still allocating in CYLS instead 
of TRKS. Something close to 'CYLS(30 0)' should be sufficient for the MCDS 
index component. I would also suggest devoting an entire MOD-9 to the MCDS to 
avoid contention for the volume. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Tuesday, February 22, 2022 7:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Resizing MCDS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Classification: Confidential

Essentially yes. HSM must be down for the duration.

I would also rename the original to .old and the new to the original name. A 
lot of JCL would need to be changed otherwise.
Of course take backups.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Tuesday, February 22, 2022 3:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Resizing MCDS

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hello

Apologize for basic question

Whats your approach on resizing HSM MCDS ?

is it just defining MCDS, Rename, repro old to new and start HSM task ?

Peter

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

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


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

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

Re: Definition of z/OS SYSRES volume

[Michael Watkins]

Perhaps 'z/OS system installation and maintenance', P.9, is sufficient:

"The z/OS software- as supplied by IBM- is usually installed on a series of 
disk volumes known as the system residence volumes (SYSRES). Much of the 
flexibility of z/OS is built on these SYSRES sets. They make it possible to 
apply maintenance to a new set that is cloned from the production set while the 
current set is running production work. A short outage can then be taken to IPL 
from the new set--and the maintenance has been implemented! Also, the change 
can be backed out by IPLing from the old set."

See: 
https://www.ibm.com/docs/en/zosbasics/com.ibm.zos.zsysprog/zsysprog_book.pdf


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: Monday, February 14, 2022 5:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Definition of z/OS SYSRES volume

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

I think the sysres is the volume on the device address specified as the IPL 
device.
Lennie Dymoke-Bradshaw
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frsclweb.com%2Fdata=04%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C5407f52cc3cb47ffe1ff08d9f01306ba%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637804786774306549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=53Dygu9FWjdBsL5iFLIa4NY7uadHVHlc77YaG6nBmJ8%3Dreserved=0
'Dance like no one is watching. Encrypt like everyone is.'

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
PINION, RICHARD W.
Sent: 14 February 2022 21:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Definition of z/OS SYSRES volume

I did a little online searching.  But, I didn't see anything that helped.
How would you define the "SYSRES volume"?  I want to give a good definition to 
new system programmers.
Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
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: Looking for a manual on IRLM services

[Michael Watkins]

#metoo

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
esst...@juno.com
Sent: Monday, January 3, 2022 3:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for a manual on IRLM services

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

ANyone else find this URL link NOT FOUND


-- Original Message --
From: Rahim Azizarab <03f036d88eeb-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for a manual on IRLM services
Date: Mon, 3 Jan 2022 17:13:09 +

https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.redbooks.ibm.com%2Fredbooks%2Fpdfs%2Fsg246908.pdfhttp%3A%2F%2Fwww.redbooks.ibm.com%2Fredbooks%2Fpdfs%2Fsg246928.pdfhttp%3A%2F%2Fwww.redbooks.ibm.com%2Fredbooks%2Fpdfs%2Fsg246928.pdfdata=04%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7Cb2b913e5fb1949ad1d8d08d9cf040b26%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637768439274193223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=IXe%2FcUo%2BPQbzhhMqJrcqyxMWU8sVFswSBW9S9k6PTDE%3Dreserved=0
You did not say if you are using it for DB2 or IMS.



Rahim








On Monday, January 3, 2022, 12:58:38 AM CST, Binyamin Dissen 
 wrote:

 I am looking for a manual on how to call IRLM services (as well as their 
names). Does such a thing exist?

--
Binyamin Dissen 
https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dissensoftware.com%2Fdata=04%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7Cb2b913e5fb1949ad1d8d08d9cf040b26%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637768439274193223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=uOzPMCBbnjnpYwlXr8cn50QNde6mdAObUzgBJwWj0zc%3Dreserved=0

Director, Dissen Software, Bar & Grill - Israel

--
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: Redbooks Rumor

[Michael Watkins]

Yes, PDFs, not webpages.

Sometimes the network on my end is a little shaky. This might especially be the 
case in a disaster situation.

Having the documentation in PDF form and downloaded onto the C: drive of my 
laptop gives me a warm and fuzzy feeling.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Friday, November 5, 2021 9:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Redbooks Rumor

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

I used to think that Redbooks were an admission that product documentation was 
not very good.
I explained to someone; the product documentation tells you how to adjust your 
tappets.  What red books did was to say this is how you unlock the car, put the 
seat belt on (not always obvious), and tell you if it was an automatic or stick 
shift.

I find the IBM Doc site very slow (10 seconds to get into it) - not a good
advertisement for IBM servers.   (most of the time "scripting")
I hope they provide PDF's rather than just web pages.
Colin

On Fri, 5 Nov 2021 at 13:32, Michael Watkins < 
032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote:

> "if IBM is going to transition the Redbooks into something better"?
>
> It looks like IBM is transitioning to ibm.com/docs, where an isolated 
> piece of documentation is given to you without any of the surrounding 
> related information. This is hardly better. The most expensive part of 
> z/OS TOC is probably labor. If IBM increases the cost of labor by 
> failing to provide easy to access documentation, it's just another 
> blow to the z/OS platform.  I thank God that retirement is starting to look 
> feasible.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Lionel B. Dyck
> Sent: Friday, November 5, 2021 5:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Redbooks Rumor
>
> CAUTION: This email originated from outside of the Texas Comptroller's 
> email system.
> DO NOT click links or open attachments unless you expect them from the 
> sender and know the content is safe.
>
> I agree with Cheryl that Redbooks have been some of the BEST 
> documentation available from IBM. What I am curious about is if IBM is 
> going to transition the Redbooks into something better. With the web 
> there are many more opportunities to provide documentation that 
> contains the Redbook content but in more usable (and searchable) 
> formats. If that is their plan then I'm on board but if they are going 
> to do away with Redbooks, or make them marketing guides, then the IBM 
> customer community needs to take a stand and let IBM know that they 
> are making a significant mistake that
> *will* impact their future growth of the platform.
>
>
> Lionel B. Dyck <><
> Website:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> lbdsoftware.com%2Fdata=04%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%
> 7Cd63bdbe632ee4f2e0bf308d9a0651c56%7C2055feba299d4d0daa5a73b8b42fef08%
> 7C0%7C0%7C637717178405312341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=dBX
> aJrsFEfs80ICrD9ka1ZxCxltvqsCIoRhoc9%2Fy%2F1U%3Dreserved=0
> Github:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Flbdyckdata=04%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7Cd
> 63bdbe632ee4f2e0bf308d9a0651c56%7C2055feba299d4d0daa5a73b8b42fef08%7C0
> %7C0%7C637717178405312341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=t2X1hz
> bO6CvrSrgVpXUS3ABfkehHJv0Q3Rj1WtgNhCo%3Dreserved=0
>
> "Worry more about your character than your reputation. Character is what
> you are, reputation merely what others think you are."   - - - John Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Cheryl Watson
> Sent: Thursday, November 4, 2021 9:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Redbooks Rumor
>
> This is really appalling! I hope it's not true, but I have noticed 
> that the lack of books related to z/OS has been steadily declining, 
> and I find it very distressing. I've always found the Redbooks to be 
> the best documentation ever provided by IBM. Unfortunately, most of 
> the Redbooks are now simply marketing guides.
>
> The post from Bill Bitner was from a Linux blog post. Is IBM speaking 
> about Linux/Power Redbooks only? Does it also apply to z/OS Redbooks?
>
> Why isn't there more outrage on this forum? If you don't complain, IBM 
> will bury these in one more opportunity to save money while lea

Re: Redbooks Rumor

[Michael Watkins]

"if IBM is going to transition the Redbooks into something better"?

It looks like IBM is transitioning to ibm.com/docs, where an isolated piece of 
documentation is given to you without any of the surrounding related 
information. This is hardly better. The most expensive part of z/OS TOC is 
probably labor. If IBM increases the cost of labor by failing to provide easy 
to access documentation, it's just another blow to the z/OS platform.  I thank 
God that retirement is starting to look feasible.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B. Dyck
Sent: Friday, November 5, 2021 5:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Redbooks Rumor

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

I agree with Cheryl that Redbooks have been some of the BEST documentation 
available from IBM. What I am curious about is if IBM is going to transition 
the Redbooks into something better. With the web there are many more 
opportunities to provide documentation that contains the Redbook content but in 
more usable (and searchable) formats. If that is their plan then I'm on board 
but if they are going to do away with Redbooks, or make them marketing guides, 
then the IBM customer community needs to take a stand and let IBM know that 
they are making a significant mistake that *will* impact their future growth of 
the platform.


Lionel B. Dyck <><
Website: 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lbdsoftware.com%2Fdata=04%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C2e3a6dbe5e3c42ad8d0d08d9a04a716a%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637717063875460424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kQ5qQ8b69SI%2F0CyUPvczqR%2BOoKhBr31v5Mjd%2BpCMBBk%3Dreserved=0
Github: 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flbdyckdata=04%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C2e3a6dbe5e3c42ad8d0d08d9a04a716a%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637717063875460424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=bF8E7Q2nVxMUbzidS3mxL010xaQuGxC5LQsCyX5qV0I%3Dreserved=0

"Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are."   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Cheryl Watson
Sent: Thursday, November 4, 2021 9:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Redbooks Rumor

This is really appalling! I hope it's not true, but I have noticed that the 
lack of books related to z/OS has been steadily declining, and I find it very 
distressing. I've always found the Redbooks to be the best documentation ever 
provided by IBM. Unfortunately, most of the Redbooks are now simply marketing 
guides.

The post from Bill Bitner was from a Linux blog post. Is IBM speaking about 
Linux/Power Redbooks only? Does it also apply to z/OS Redbooks?

Why isn't there more outrage on this forum? If you don't complain, IBM will 
bury these in one more opportunity to save money while leaving customers 
without the excellent resources they've had in the past.

If you want z/OS Redbooks, please make your voice heard here.

Thanks,
Cheryl

==
Cheryl Watson Walker, CEO
Watson & Walker, Inc.
https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.watsonwalker.com%2Fdata=04%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C2e3a6dbe5e3c42ad8d0d08d9a04a716a%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637717063875460424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Iuq7LFu50LvfLdEt5kL0799mlZa72BAddLk5mtZpz4I%3Dreserved=0
==



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Neale Ferguson
Sent: Thursday, October 28, 2021 10:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Redbooks Rumor

I am hearing strong rumors that IBM is about to commit the type of corporate 
facepalm that is the stuff for future textbooks. Apparently Redbooks are no 
longer going to be a thing and the organization disbanded. If there's one thing 
that has differentiated IBM in the mainframe space has been the quality of its 
documentation and, in particular, the type of HOW-TO information contained 
within Redbooks and Redpieces. These documents turn a "that'd be nice to do" 
into a proof-of-concept and finally into production. In doing so, they must be 
responsible for millions or billions of dollar in revenue to IBM.

Many of the topics of Redbooks cover are complex and even intimidating. They 
provide a step-by-step approach to learning and implementing using a group of 
people actually doing what they're writing about. This is invaluable.

I hope these rumors 

Re: zEDC compression on z13 and z15

[Michael Watkins]

Just a dumb question: Did your z13 have zEDC cards installed? They were 
optional on the z13, but zEDC compression is included on the z15.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Chuck Kreiter
Sent: Thursday, July 22, 2021 3:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zEDC compression on z13 and z15

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

We went from z14 to z15's and didn't notice any difference in compression.
I would be curious to see listcat of both showing the user data size and the 
comp data size as well as the dataset DCB attributes.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of PINION, RICHARD W.
Sent: Thursday, July 22, 2021 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zEDC compression on z13 and z15

We migrated from a z13 to a z15 this past weekend.  We are running z/OS 2.2, 
z/OS 2.2 on the z13, and the same z/OS 2.2 on the z15.  z15 maintenance was 
applied to z/OS 2.2, and activated a couple of months ago.  We are using the 
same SMS configuration on the z15 as the z13, and that includes the zEDC 
compression Data Class.

I restored a dataset that was created on the z13 using zEDC compression, and 
needed to make a copy of the dataset on the z15.  I was surprised to see an 
almost 20,000 track difference between the z13 created dataset, and the z15 
created dataset.  I used the same SMS Data Class to make the z15 version of the 
dataset.


Enter "/" to select actionTracks %Used

Z13.CREATED.DATA.SET 4755099
Z15.CREATED.DATA.SET 64555  100


SMS allocation messages for the z15 created dataset follows.

IGD17070I DATA SET Z15.CREATED.DATA.SET
ALLOCATED SUCCESSFULLY WITH 1 STRIPE(S).
IGD17160I DATA SET Z15.CREATED.DATA.SET
IS ELIGIBLE FOR COMPRESSION
IGD101I SMS ALLOCATED TO DDNAME (SYSUT2  )
DSN (Z15.CREATED.DATA.SET)
STORCLAS (STANDARD) MGMTCLAS (DE180DAY) DATACLAS (COMP)
VOL SER NOS= TL0018


I have not looked into the TCB/SRB I/O numbers of the
z13 creating job to compare against the z15 job.

Anyone have an idea as to why such a dramatic difference?

Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
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: Can I define a disk as read only to z/OS?

[Michael Watkins]

You might want to explore IBM's 'SafeGuarded Copy' to see whether it meets your 
needs.

A Red Paper called 'IBM DS8000 Safeguarded Copy (Updated for DS8000 Release 
9.1)' was published in March of this year (REDP-5506-01)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Tuesday, July 13, 2021 5:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can I define a disk as read only to z/OS?

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

The IBM Dallas development system has VM volumes mounted read-only to the z/OS 
client machines. I know zero details of the CP side but I see it from the z/OS 
side. IBM has shared SYSRES-type volumes for multiple clients. Yes, z/OS 
reports I/O errors if it tries to write to them, but it all works, and 
obviously IBM knows what they are doing.

The point is Yes, a z/OS read-only disk is possible. I don't think z/OS "knows" 
it is read-only, so it tries to write and reports errors, but it survives just 
fine.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, July 13, 2021 1:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can I define a disk as read only to z/OS?

z/OS does not have the concept of a readonly disk. The z/OS mount command will 
allow the USE=PRIVATE option. But that is not readonly.  In the past, under 
z/VM, I  would use a full pack minidisk with I defined in the directory as 
readonly. This worked, but did cause I/O errors to be reported on z/ OS when it 
tried to update the date stamp in the VTOC entry for DSNs when they were OPENed.

On Linux, there is a readonly option on the mount command for a filesystem.

On Tue, Jul 13, 2021, 13:40 Colin Paice  wrote:

> I am migrating to the latest levels of ADCD ( C4* instead of A4*).  
> During the migration I would like to be able to mount the A4* volumes 
> on the C4 system, but mount them read only.
> I can change the Linux disk to be access mode 444, but if I want to 
> IPL from A4* I need to change it back again.
> The z/OS documentation mentions usingn read-only disks, but I can't 
> see how to do it.  I dont think I can do it from the HCD
> OA50068: NEW FUNCTION - PROVIDE READ-ONLY ACCESS FOR SYNCHRONOUS PPRC 
> SECONDARY DEVICES  
> 
>  Looks like it is only for PPRC.
> Do I just have to live with changing the access mods to/from 444.
> Colin
>
> --
> 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: EMC DLM over IBM VTL

[Michael Watkins]

Just curious, Carl: Is TCT implemented with DFSMShsm and DFSMSdss (and RACF) 
when using a PowerMax/DLm solution?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carl Swanson
Sent: Thursday, March 4, 2021 11:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EMC DLM over IBM VTL

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

First off, thank you for your kind words, really appreciate that.

One thing to note some recent announcements regarding DLm and PowerMax 
from Dell. Like IBM we now have Transparent Cloud Tiering (TCT), between the 
PowerMax and DLm. Like IBM we require our DASD and Virtual Tape product for 
this to work. One of the differences in this solution is that the connectivity 
between the PowerMax and DLm is we use FICON to move the data between the two 
systems.

Also, for quite awhile now the DLm has had the ability to move 
(migrate)  data from its data storage to another tier of storage (Cloud). This 
feature is referred to as Long Term Retention the DLm will move the data to and 
from the storage without any need for host cycles. Generally, we see customers 
looking at this feature for data that does not have high access patterns, 
generally like archive data or data that have not been accessed for a long 
period of time. The user can create the policy (usually last time the tape was 
mounted) that best meets their needs and the DLm will move that tape once the 
policy is meet. If the tape is needed the DLm will access the new location 
directly and the data will flow back to the mainframe. We do not recommend 
using this feature for data or tapes that have a high frequency of recall.

As to the tape management functions, we are different being a MTL. What 
will take place is a step will be added to the house keeping routine that will 
pass the daily or full scratch list to the DLm. It is that process that will 
then mark the tape as a scratch tape in the DLm.

Carl Swanson
Mobile:215.688.1459
Email: carl.swans...@verizon.net

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Thursday, March 4, 2021 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EMC DLM over IBM VTL

"Will there be a impact to mainframe backup when there is a high backup volume 
for open system  ?"

I am employed by the Texas CPA where such a solution was implemented. We never 
experienced any problems with contention. First, our z/OS mainframe necessarily 
had its own MTree file structure on the Data Domain, so there was no contention 
at the file level. The mainframe activity at this installation is characterized 
by a couple of bursts of activity each week while the open systems activity is 
more distributed through out the week, so the performance of the Data Domain 
has never been challenged.

NB: The DLm emulates a manual tape library. An IBM TS7000 is an automatic 
library.

NB: The TS7000 is capable of communicating directly with an IBM DS8000-class 
storage frame. The DLm is not.

Two caveats: (1) The TS7000 communicates with z/OS tape management software. 
The DLm does not. This complicates tape management. (2) If you are 
contemplating the achival of mainframe data on cloud storage using IBM's Cloud 
Tape Connector (CTC) solution, the DLm will not be able to do this. It will 
also complicate implementation of IBM's Transparent Cloud Tiering (TCT).

I don't believe you can find someone more knowledgeable about of Data 
Domain/DLm implementations than Carl Swanson.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carl Swanson
Sent: Thursday, March 4, 2021 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EMC DLM over IBM VTL

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

First full disclosure I work for Dell Technologies but more 
specifically in the DLm group, now with that out of the way.

Probably more than 50% of the DLm customers do share their backend 
(Data Domain) storage with the distributed world and or the IBM-I world. What 
this means is we have experiences in sizing these types of solutions. When we 
perform this sizing, we will do a study on the mainframe the distributed side 
and the IBM I if required. We then make sure that the performance 
characteristics of the back end storage array is capable of handling the peak 
workload without issue. From the DLm point of view this is the connection to 
the mainframe and we size the performance requirements based on the supplied 
RMF data .

I can provide much more detail if you like just not sure if it is 
appropriate to do so on list. Below is my non work email, but most could

Re: EMC DLM over IBM VTL

[Michael Watkins]

"Will there be a impact to mainframe backup when there is a high backup volume 
for open system  ?"

I am employed by the Texas CPA where such a solution was implemented. We never 
experienced any problems with contention. First, our z/OS mainframe necessarily 
had its own MTree file structure on the Data Domain, so there was no contention 
at the file level. The mainframe activity at this installation is characterized 
by a couple of bursts of activity each week while the open systems activity is 
more distributed through out the week, so the performance of the Data Domain 
has never been challenged.

NB: The DLm emulates a manual tape library. An IBM TS7000 is an automatic 
library.

NB: The TS7000 is capable of communicating directly with an IBM DS8000-class 
storage frame. The DLm is not.

Two caveats: (1) The TS7000 communicates with z/OS tape management software. 
The DLm does not. This complicates tape management. (2) If you are 
contemplating the achival of mainframe data on cloud storage using IBM's Cloud 
Tape Connector (CTC) solution, the DLm will not be able to do this. It will 
also complicate implementation of IBM's Transparent Cloud Tiering (TCT).

I don't believe you can find someone more knowledgeable about of Data 
Domain/DLm implementations than Carl Swanson.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carl Swanson
Sent: Thursday, March 4, 2021 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EMC DLM over IBM VTL

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

First full disclosure I work for Dell Technologies but more 
specifically in the DLm group, now with that out of the way.

Probably more than 50% of the DLm customers do share their backend 
(Data Domain) storage with the distributed world and or the IBM-I world. What 
this means is we have experiences in sizing these types of solutions. When we 
perform this sizing, we will do a study on the mainframe the distributed side 
and the IBM I if required. We then make sure that the performance 
characteristics of the back end storage array is capable of handling the peak 
workload without issue. From the DLm point of view this is the connection to 
the mainframe and we size the performance requirements based on the supplied 
RMF data .

I can provide much more detail if you like just not sure if it is 
appropriate to do so on list. Below is my non work email, but most could 
probably figure out my work email.

Final answer this is a common for DLm systems and works great the key 
is proper sizing which my group handles.

Carl Swanson
Mobile:215.688.1459
Email: carl.swans...@verizon.net

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Thursday, March 4, 2021 1:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EMC DLM over IBM VTL

Hello

We are analysing if EMC DLM would be a right fit to replace IBM VTL.


I am trying to understand about backup cycles using EMC DLM when we use single 
backup solution and single virtual tape library to backup both mainframe and 
open systems.

Is there a possibility for contention ?
Will there be a impact to mainframe backup when there is a high backup volume 
for open system  ?

These performance do effect the open system as well ?

Trying to understand these from the DLM users ? Any feedback would be 
appreciated

Jake.

--
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: RMM/OAM/SMS

[Michael Watkins]

A 'manual' tape library? Is this command being issued on the GUI for an EMC DLm?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Edgington, Jerry
Sent: Wednesday, January 27, 2021 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RMM/OAM/SMS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Best guess would be the SMS ACS routines. That would be first place I would 
look.

Jerry

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ken 
Bloom
Sent: Wednesday, January 27, 2021 1:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RMM/OAM/SMS

This message was sent from an external source outside of Western & Southern's 
network. Do not click links or open attachments unless you recognize the sender 
and know the contents are safe.


Need some advice here .  When trying to mount a scratch tape on a manual 
library, the LOAD DISPLAY command comes down the channel as a M (Storage Group 
name) rather than MSCRTCH.  Any ideas as to what is configured incorrectly in 
OAM or SMS?

Kenneth A. Bloom
CEO
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.visara.com%2Fdata=04%7C01%7Cmichael.watkins%40CPA.TEXAS.GOV%7C9be3bb253a744601e14a08d8c2ee5d8d%7C2055feba299d4d0daa5a73b8b42fef08%7C0%7C0%7C637473676345494710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KG%2Bmp07qpDpHtFYfY4Oeyfmf%2FSL8BKusXqgx5%2FjVFKA%3Dreserved=0



--
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: Simple VSAM question on sizing INDEX component

[Michael Watkins]

More efficient in terms of fewer index LEVELs as Tony Thigpen may have been 
getting at? I thought the number of LEVELs was contingent on the the size of 
the file and the number of CI  and CA splits the index component had endured 
and not the allocation of contiguous space for the index component on DASD. A 
REORG should reduce the number of LEVELs to its smallest possible number, no?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Sunday, August 30, 2020 7:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Simple VSAM question on sizing INDEX component

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

CYL(4 1) should leave one cylinder empty.  Cylinder CA will result is a more 
efficient index.

On Sun, Aug 30, 2020 at 5:12 PM Lizette Koehler  wrote:
>
> List -
>
> I have a VSAM Dataset that has grown over the years.  When it was set 
> up - the INDEX space was left to default
>
> I am wondering if it makes sense to override the Track Allocation and 
> put it in Cylinders.
>
> We are noticing a little bit of an increase in run time during reorg.  
> I was wondering if this might be due to the data set having 3.4GB now.  
>
> This file is EA/EF so it can grow
>
> Over 4500 Cylinders on the Data
>
> And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB
> During reorg we offload records to an archive then reload the current 
> data back in
>
> This may be something I cannot improve on, just thought I would see if 
> there are any insights I am missing.
>
> Process:
> Offload the data to a temp file
> Archive records older than 2 weeks
> Del/Def VSAM dataset
> Reload current records to VSAM dataset
> This runs daily
>
> Thank you
> Lizette
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Simple VSAM question on sizing INDEX component

[Michael Watkins]

Of course, buffering will probably do the most to improve VSAM REORG times.

For the sequential reads through the cluster that are typical of REORG 
activity, add the ',AMP=('BUFNI=x,BUFND=yyy')' parameter to the DD card, where 
'x' equals the number of index component LEVELS displayed in the IDCAMS 
'LISTCAT ENT() ALL' output and 'yyy' equals the number of data 
component CIs in one data CA.

This will assure that every chain of channel commands reads an entire virtual 
cylinder. When the virtual read/write heads cross a cylinder boundaries, the 
channel program will lose control, so no more than a cylinder can be read or 
written by a channel program.

To optimize the value of 'yyy' for BUFND, look at the data component of the 
'LISTC  ENT() ALL'. Find the values for 'CI/CA' and 'TRACKS/CA'. Since 
there are 15 tracks in a 3390 cylinder, you can easily calculate the number of 
data CIs in one cylinder. Add one to this value and use that for BUFND.

Why add one? Some pople say the code reserves one CI for SPLIT activity, even 
when the odds of it occuring are low. Some people say adding one for a CI 
reserved for SPLIT activity is an old-wives tale, but it seems to work.

-Original Message-
From: Michael Watkins  
Sent: Sunday, August 30, 2020 6:00 PM
To: IBM Mainframe Discussion List 
Cc: Michael Watkins 
Subject: RE: Simple VSAM question on sizing INDEX component

The index component alone is 2.4 MB? 2,400,000/56664 = 43 tracks? Sure, 
Allocate the index component as 4 or even 5 cylinders primary and a single 
cylinder secondary.


If the cluster has changed significantly over time, I might also run an IDCAMS 
EXAMINE command:

EXAMINE NAME() INDEXTEST DATATEST

And look for:

IDC01728I FOUND n EMPTY CONTROL AREAS THAT HAVE NOT BEEN RECLAIMED IDC11775I 
nnn DATA COMPONENT CIS ARE ESTIMATED TO BE UNREACHABLE 

These may indicate that you want to change the index CI size, although buffer 
specifications may also have to change if you do.


And I assume you have already activated 'CA reclaim' for all pertinent 
DATACLASes in ISMF.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lizette Koehler
Sent: Sunday, August 30, 2020 5:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Simple VSAM question on sizing INDEX component

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

List -



I have a VSAM Dataset that has grown over the years.  When it was set up - the 
INDEX space was left to default



I am wondering if it makes sense to override the Track Allocation and put it in 
Cylinders.



We are noticing a little bit of an increase in run time during reorg.  I was 
wondering if this might be due to the data set having 3.4GB now.  This file is 
EA/EF so it can grow



Over 4500 Cylinders on the Data

And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB





During reorg we offload records to an archive then reload the current data back 
in.



This may be something I cannot improve on, just thought I would see if there 
are any insights I am missing.



Process:
Offload the data to a temp file

Archive records older than 2 weeks

Del/Def VSAM dataset

Reload current records to VSAM dataset



This runs daily


Thank you



Lizette


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

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

Re: Simple VSAM question on sizing INDEX component

[Michael Watkins]

The index component alone is 2.4 MB? 2,400,000/56664 = 43 tracks? Sure, 
Allocate the index component as 4 or even 5 cylinders primary and a single 
cylinder secondary.


If the cluster has changed significantly over time, I might also run an IDCAMS 
EXAMINE command:

EXAMINE NAME() INDEXTEST DATATEST

And look for:

IDC01728I FOUND n EMPTY CONTROL AREAS THAT HAVE NOT BEEN RECLAIMED
IDC11775I nnn DATA COMPONENT CIS ARE ESTIMATED TO BE UNREACHABLE 

These may indicate that you want to change the index CI size, although buffer 
specifications may also have to change if you do.


And I assume you have already activated 'CA reclaim' for all pertinent 
DATACLASes in ISMF.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lizette Koehler
Sent: Sunday, August 30, 2020 5:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Simple VSAM question on sizing INDEX component

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

List -



I have a VSAM Dataset that has grown over the years.  When it was set up - the 
INDEX space was left to default



I am wondering if it makes sense to override the Track Allocation and put it in 
Cylinders.



We are noticing a little bit of an increase in run time during reorg.  I was 
wondering if this might be due to the data set having 3.4GB now.  This file is 
EA/EF so it can grow



Over 4500 Cylinders on the Data

And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB





During reorg we offload records to an archive then reload the current data back 
in.



This may be something I cannot improve on, just thought I would see if there 
are any insights I am missing.



Process:
Offload the data to a temp file

Archive records older than 2 weeks

Del/Def VSAM dataset

Reload current records to VSAM dataset



This runs daily


Thank you



Lizette


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

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