Re: VTOCs vs. catalogs

[Gibney, Dave]

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

[Gibney, Dave]

Also Known As

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Radoslaw Skorupka
> Sent: Saturday, April 27, 2024 3:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Netview
> 
> [EXTERNAL EMAIL]
> 
> (off-topic, but on-thread)
> "vel" is not Polish. We don't have letter "v". It is latin, so I supposed it 
> is wide
> known.
> And yes, it is "aka".
> BTW: WTF is aka??? :-)
> 
> Last, but not least: thank you for kind words about my English (I still 
> polish my
> English :-) )
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> W dniu 26.04.2024 o 18:25, Phil Smith III pisze:
> > For those who are curious like me, "vel" is Polish for "AKA". That was my
> guess, confirmed via Tha Goog.
> >
> > Not throwing shade at Radoslaw, whose English is better than that of a lot 
> > of
> folks on the list who are native speakers!
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Radoslaw Skorupka
> > Sent: Friday, April 26, 2024 7:22 AM
> > To:IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Netview
> >
> > It is not so easy.
> > Do you know IWS vel TWS vel Workload Scheduler?
> > It is still being sold by IBM, but development is out of IBM.
> > The same for SDSF (Rocket), PCOMM (HCL), Omegamon, etc. The list is
> longer.
> > And it is nothing new IMHO, as far as I remember ESCON Director was also
> third party product under IBM logo.
> >
> > Note, JES3 and z/VSE are different - in both cases products are supported
> and marketed by their current producers - that means PSI and 21CS.
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> >
> >
> > W dniu 26.04.2024 o 07:38, Bruce Hewson pisze:
> >> Hello Steve,
> >>
> >> FUD
> >>
> >> "IBM Netview for Z/OS" is still being sold and supported by IBM, and is a
> pre-req for IBM System Automation and GDPS.  No evidence that this product
> has been sold.
> >>
> >> On Wed, 24 Apr 2024 16:19:17 -0500, Steve
> Beaver  wrote:
> >>
> >>> My understanding is that IBM sold off Netview.
> >>>
> >>> Who did they sell it to?
> >>>
> >>>
> >>> Sent from my iPhone
> >>>
> >>> No one said I could type with one thumb
> >>>
> 
> --
> 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: What happens in HSM when I change a Management Class

[Gibney, Dave]

You need to run it at least twice. The 1st pass will mark for pending delete. 
2nd pass will delete

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Glenn Wilcock
> Sent: Friday, March 15, 2024 7:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What happens in HSM when I change a Management Class
> 
> [EXTERNAL EMAIL]
> 
> I should have added that EXPIREBV will run for a while if you haven't run it 
> for
> some time.  So, do it over a weekend.  Glenn
> 
> --
> 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: What happens in HSM when I change a Management Class

[Gibney, Dave]

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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> >
> 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 Days Only Backup Ver:
> >  Indicates how many days to keep the most recent backup version of a
> > deleted data set, starting from the day DFSMShsm detects it has been
> > deleted. This attribute applies only when a data set no longer exists
> > on primary (level 0) or migrated (levels 1 and 2) storage. The default
> > is 60. This field does not apply to objects. Backup copies of objects
> > are not retained when the original object is deleted.
> >
> > Retain Days Extra Backup Vers:
> >  Indicates how many days to keep backup versions other than the most
> > recent one, starting from the day backups were created. It applies
> > only when more than one backup version exists, and when a data set has
> > low activity. This attribute applies whether the data set has been
> > deleted or not. The default is 30. The number of extra versions is the
> > number of backup versions minus one. If you specify 1 for Number of
> > Backup Vers, there are no extra versions. For example, if you specify
> > 3 for Number of Backup Vers (Data Set Deleted), the number of "extra"
> > versions for deleted data sets is 2. These 2 versions are managed
> > according to the Retain Days Extra Backup Vers attribute. Any other
> > versions that may have existed when the data set was deleted will be deleted
> the next 

Understanding, Language and Comminication

[Gibney, Dave]

I believe it was explicitly stated some years ago, but it is clear that English 
is not Mr. Reichman's native language. He doesn't catch many nuances. I suspect 
there may also be some issues that are sometimes described as location on the 
spectrum.

I also think it unfortunate (but understandable) that legal concerns keep the 
very helpful IBM people like Peter from directly looking at CBT files, forcing 
them to derive context from incomplete questions like this and other threads. 

> > Thanks and I apologize if sone of my posts made it seem like I wasn’t
> > listening to what you were telling me
> 
> Joseph, you missed Peter's point. Clearly you don't understand this is not
> about "seems like". By ignoring several clarification requests, you caused 
> lots
> of confusing posts because you forced false speculation that would have been
> avoided by the clarifications. Everyone is wasting their time reading 
> irrelevant
> posts (not just the poster) because you couldn't be bothered to respond. Do
> you not consider this rude?
> 


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

Re: [Very much off-topic] Re: AI is the real deal.

[Gibney, Dave]

To be honest, I have no idea. I would guess the multi-function options

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Seymour J Metz
> Sent: Thursday, February 22, 2024 6:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [Very much off-topic] Re: AI is the real deal.
> 
> [EXTERNAL EMAIL]
> 
> Dedicated fax machines, combo printer/scanner/fax or wokstations with fax
> modems?
> 
> --
> Shmuel (Seymour J.) Metz
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__http%3A%2F%2Fmason.gmu.edu%2F*smetz3__%3
> Bfg!!JmPEgBY0HMszNaDT!vtEIyO7q3_40wDYVUmS8Oxv-
> 9SE_HXWFBQARve4T98ajMlwwnavpy1WKQnIPd9DNKjONNwxpVjHLnA%24
> =05%7C02%7CGIBNEY%40WSU.EDU%7C32f0263c4f6a4b23380e08dc
> 34141fad%7Cb52be471f7f147b4a8790c799bb53db5%7C0%7C0%7C63844
> 2508281868496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C
> ata=jFC%2FHrP8BsuorMyG5WqE5QoCzORFa2Fg5reP%2FibT8UQ%3D
> ed=0
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
> 
> ________
> From: IBM Mainframe Discussion List  on
> behalf of Gibney, Dave <03b5261cfd78-dmarc-
> requ...@listserv.ua.edu>
> Sent: Thursday, February 22, 2024 7:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [Very much off-topic] Re: AI is the real deal.
> 
> Fax machines are still heavily used un medical and legal areas
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of zMan
> > Sent: Thursday, February 22, 2024 4:06 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [Very much off-topic] Re: AI is the real deal.
> >
> > [EXTERNAL EMAIL]
> >
> > The FAX machine's impact wasn't exactly tiny. Short-lived, yes.
> >
> > On Thu, Feb 22, 2024 at 7:04 PM Dave Beagle < 0525eaef6620-dmarc-
> > requ...@listserv.ua.edu> wrote:
> >
> > > Picking on Krugman is typical of the right. But, that’s not exactly
> > > what he said. Here’s the context.
> > >
> > >
> > >
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> > efense.com%2Fv3%2F__https%3A%2F%2Fsecure-
> web.cisco.com%2F1CieSMPaZwvAT
> > Ho3u6SeKwdTSLYWjrgzgHMj5G0cgeCU6OwRX-
> tYZ0dZywGFgIYxZ06npUpn5PdldAbPxon
> > dPyUXiudafJL2BDmpgDe6rIweSl28zsyyk2d3NIj-xPIx6hsP1J7Opb2qapLGK-
> iUSprkR
> > mplH8sgKkH2Fa_GDPo3s5-6nMxBfty_xI1VeBOk3eZA2jCA0T-
> lEW75Uwsp9gT2BVKTGHZ
> >
> Rysd2x6abN4KAFeZTovDz9zsB5F5HQrDt9snuZo7CYjPBb6oBbE3fHDt6B9Abf
> d4xRxhiX
> > U5O_bnWnTmtJPekKqEj5EtxQBmN-0SFI7HoHDQAVGFH-
> ZEfBvmvGMg6Y97kUewFyxBcTIy
> > 8QDI833P3l0MKy3q3xE1_tkY9JoCGfDvLIb0ULhWAPS-s9z2pDcGcO2WS-
> 9Q6JrVg%2Fht
> >
> tps*3A*2F*2Fnam12.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*2
> 5
> >
> 3A*252F*252Furld__%3BJSUlJSUlJSUl!!JmPEgBY0HMszNaDT!vtEIyO7q3_40
> wDYVUm
> > S8Oxv-
> 9SE_HXWFBQARve4T98ajMlwwnavpy1WKQnIPd9DNKjONNwyRlsIiJg%24
> ata=0
> >
> 5%7C02%7CGIBNEY%40WSU.EDU%7C32f0263c4f6a4b23380e08dc34141fa
> d%7Cb52be47
> >
> 1f7f147b4a8790c799bb53db5%7C0%7C0%7C638442508281876390%7CU
> nknown%7CTWF
> >
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6M
> >
> n0%3D%7C0%7C%7C%7C=bPcy1uJlMKIOoeS46gqFzOhpDwlK8Ha8zg
> ghsk%2BRMks
> > %3D=0
> > >
> >
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.businessinsider.com%2Fpau
> > l-krugm
> > > an-responds-to-internet-quote-2013-
> > 12%3Famp__%3B!!JmPEgBY0HMszNaDT!pUV
> > >
> >
> U8USJPSqXuREx80y0bQ5MR7v2G271msUDJVyimwcA0x0oiPePyvVMbEFmX
> > vp0KkVgyslQg
> > >
> >
> BkUcCIgOietLWEjpfoWVvXo%24=05%7C02%7CGIBNEY%40WSU.EDU%
> > 7Ce292b02ec
> > >
> >
> ab547644c8d08dc34034e72%7Cb52be471f7f147b4a8790c799bb53db5%7
> > C0%7C0%7C6
> > >
> >
> 38442436003405898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> > MDAiLCJQIjoi
> > >
> >
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=rkxa
> > e42Xnjdr
> > > ZsbYsztE%2FeQftM45pYXwoSisSXM3MvA%3D=0
> > >
> > >
> > >
> > >
> > >
> > > Sent from Yahoo Mail for iPhone
> > >
> > >
> > > On Thursday, February 22, 2024, 5:12 PM, Bob Bridges <
> > > 0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > > Speaking of old predictions:  /* By 2005 or so, it will be clear
> > > that the Internet's impact on the economy has been no greater than
> > > the fax machine's.  -Paul Krugman, Nobel-prize-winning economist in
>

Re: [Very much off-topic] Re: AI is the real deal.

[Gibney, Dave]

Fax machines are still heavily used un medical and legal areas

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of zMan
> Sent: Thursday, February 22, 2024 4:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [Very much off-topic] Re: AI is the real deal.
> 
> [EXTERNAL EMAIL]
> 
> The FAX machine's impact wasn't exactly tiny. Short-lived, yes.
> 
> On Thu, Feb 22, 2024 at 7:04 PM Dave Beagle < 0525eaef6620-dmarc-
> requ...@listserv.ua.edu> wrote:
> 
> > Picking on Krugman is typical of the right. But, that’s not exactly
> > what he said. Here’s the context.
> >
> >
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> >
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.businessinsider.com%2Fpau
> l-krugm
> > an-responds-to-internet-quote-2013-
> 12%3Famp__%3B!!JmPEgBY0HMszNaDT!pUV
> >
> U8USJPSqXuREx80y0bQ5MR7v2G271msUDJVyimwcA0x0oiPePyvVMbEFmX
> vp0KkVgyslQg
> >
> BkUcCIgOietLWEjpfoWVvXo%24=05%7C02%7CGIBNEY%40WSU.EDU%
> 7Ce292b02ec
> >
> ab547644c8d08dc34034e72%7Cb52be471f7f147b4a8790c799bb53db5%7
> C0%7C0%7C6
> >
> 38442436003405898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoi
> >
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=rkxa
> e42Xnjdr
> > ZsbYsztE%2FeQftM45pYXwoSisSXM3MvA%3D=0
> >
> >
> >
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Thursday, February 22, 2024, 5:12 PM, Bob Bridges <
> > 0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Speaking of old predictions:  /* By 2005 or so, it will be clear that
> > the Internet's impact on the economy has been no greater than the fax
> > machine's.  -Paul Krugman, Nobel-prize-winning economist in 1998 */
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Lennie Dymoke-Bradshaw
> > Sent: Thursday, February 22, 2024 16:58
> >
> > Sorry, the date has been truncated on the left.
> > That should be 11994.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Allan Staller
> > Sent: 22 February 2024 19:42
> >
> > The last mainframe will be turned off in 1994 - Gartner Group
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Seymour J Metz
> > Sent: Thursday, February 22, 2024 11:11 AM
> >
> > A 5-year prediction is generally safe, because in 5 years people will
> > have forgotten the predictions. Who remembers the failed 5-year
> > predictions for, e.g., controlled fusion, human level machine translation?
> >
> > I expect it to eventually happen, but as for when, Hypotheses non
> > fingo <
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHypo
> theses_non_fingo__%3B!!JmPEgBY0HMszNaDT!pUVU8USJPSqXuREx80y0bQ
> 5MR7v2G271msUDJVyimwcA0x0oiPePyvVMbEFmXvp0KkVgyslQgBkUcCIgOi
> etLWEjpRKs5ifv%24=05%7C02%7CGIBNEY%40WSU.EDU%7Ce292b02
> ecab547644c8d08dc34034e72%7Cb52be471f7f147b4a8790c799bb53db5
> %7C0%7C0%7C638442436003413344%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C0%7C%7C%7C=I69SwWniPcqnRRWi98MnELuNXk1a6kYh%2B1kY
> H9wRX2g%3D=0 >.
> >
> > On the flip side, hand optimization for pipelined machines is labor
> > intensive and fragile; a compiler with an ARCHLVL parameter is better
> > suited for the job.
> >
> > --
> > 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
> >
> 
> 
> --
> zMan -- "I've got a mainframe and I'm not afraid to use it"
> 
> --
> 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: Something keeps releasing space on a large (annual) DS

[Gibney, Dave]

At some point in the past, and maybe for  greater than n? extents, HSM 
accomplished partial release by a migrate/recall under the covers. The may also 
be an additional SETSYS needed to enable extent reduction

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Ed Jaffe
> Sent: Wednesday, February 21, 2024 1:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Something keeps releasing space on a large (annual) DS
> 
> [EXTERNAL EMAIL]
> 
> On 2/21/2024 12:52 PM, Gibney, Dave wrote:
> > However, HSM Partial Release should consolidate extents...
> 
> Not in my experience. It removes "extraneous" extents (if any), but doesn't
> actually do any sort of consolidation of occupied extents.
> 
> That said, I believe if you migrate and then later recall a data set, a
> consolidation does occur.
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.phoenixsoftware.com%2F__
> %3B!!JmPEgBY0HMszNaDT!v19RPyz3qPLVbvxhsix3B5bt02NriXaW69j3ZFop
> m3wyEcoykkW9OjkXgCYvsKFGT1LZCYk7Yzlh1Pjwm0kgfYr-
> M8m5TqZg%24=05%7C02%7CGIBNEY%40WSU.EDU%7C64fa6b8b02a
> f404c10a908dc3324b77f%7Cb52be471f7f147b4a8790c799bb53db5%7C0
> %7C0%7C638441479982068087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> %7C%7C%7C=eun2fYIkexK6nTob2BBNvsRaMZQ3SWbAxumeMiUENB
> g%3D=0
> 
> 
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended 
> recipient(s).
> If you are not an intended recipient or have otherwise received this email
> message in error, any use, dissemination, distribution, review, storage or
> copying of this e-mail message and the information contained therein is 
> strictly
> prohibited. If you are not an intended recipient, please contact the sender by
> reply e-mail and destroy all copies of this email message and do not otherwise
> utilize or retain this email message or any or all of the information 
> contained
> therein. Although this email message and any attachments or appended
> messages are believed to be free of any virus or other defect that might 
> affect
> any computer system into which it is received and opened, it is the
> responsibility of the recipient to ensure that it is virus free and no
> responsibility is accepted by the sender for any loss or damage arising in any
> way from its opening or use.
> 
> --
> 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: Something keeps releasing space on a large (annual) DS

[Gibney, Dave]

However, HSM Partial Release should consolidate extents, so a properly sized 
(big) secondary should keep the abends at bay

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Feller
> Sent: Wednesday, February 21, 2024 12:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Something keeps releasing space on a large (annual) DS
> 
> [EXTERNAL EMAIL]
> 
> Bob as Steve said you might want to talk to your storge management team.
> What I think is happening is your dataset is getting a management class that
> has Partial Release set and then HSM is doing space management and releasing
> any unused space.  I've seen this happen before and it has happened to me.
> 
> Good luck.
> 
> Paul
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Steve Thompson
> Sent: Wednesday, February 21, 2024 1:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Something keeps releasing space on a large (annual) DS
> 
> Ask the storage guys about the preferred method to allocate a file that will 
> get
> very large during production runs. And you don't want production to fail with
> a storage ABEND. And let them know about the current behavior. They may
> have made a change that is the cause of your problem.
> 
> Then you can modify the REXX code to include the class info they give you.
> 
> Also, I suggest you allocate in CYLS not TRKS in the case they are doing
> compression of space on data sets allocated in tracks...
> 
> I've seen various odd things done to recover space for files that can't be on 
> the
> tracks after 65xxx (forgot the last track accessible by the old NOTE/POINT 
> that
> causes products like Panvalet to break).
> 
> And if I remember correctly, compression/decompression is done by the
> access method. Double check to make sure this isn't a VSAM thing.
> 
> I've not had to deal with these features for a few years So things slip 
> from
> one's mind.
> 
> Steve Thompson
> 
> On 2/21/2024 2:33 PM, Bob Bridges wrote:
> > Ooh, now that's interesting!  The content of this file would lend
> > itself well to compression - all alphanumeric with a few parens,
> > colons and the like.  But what happens when someone needs to view it?
> > Does it compress automatically or is another step required?
> >
> > It's not something I can bring up now, because everyone's busy with a
> > z/OS upgrade.  But next month...
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* For Sale: Parachute.  Only used once, never opened, small stain. */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Michael Oujesky
> > Sent: Wednesday, February 21, 2024 13:49
> >
> > You might consider SMS compression to reduce the physical size of the file.
> > If you do, change the BLKSIZE to 32760 as SMS compression writes full
> > tracks and the BLKSIZE becomes logical (the size of the buffer used in
> > passing date to/from the application).
> >
> > --- At 11:44 AM 2/21/2024, Bob Bridges 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 

Re: z/OS hosting

[Gibney, Dave]

I did a lift'n'shift to FNTS in Omaha several years ago, It was very 
successful. Ran there 5 years and then did shutdown z/OS

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gadi Ben-Avi
> Sent: Thursday, February 15, 2024 2:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: z/OS hosting
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> I was asked to investigate z/OS hosting.
> Can any one point me to companies that provides this type of service?
> If you've move from on premis to a hosted environment, and would like to
> share your experience, I would like to hear it.
> 
> Thanks
> 
> Gadi
> 
> --
> 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: HLQ of Page Dataset Names

[Gibney, Dave]

Even when not sharing master catalogs, using PAGE. Allows you to define them on 
a system different from the ultimate using system. I doubt any modern systems 
will ever reach the point where all PAGE space is exhausted and define from 
different system and add to stalled system would help, but such things did 
happen in the past

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Mark Jacobs
> Sent: Friday, February 9, 2024 10:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: HLQ of Page Dataset Names
> 
> [EXTERNAL EMAIL]
> 
> For historical reasons most of our systems don't share MCATS. So I
> misremembered and there's nothing really special about specific HLQs for page
> dataset names, correct?
> 
> Mark Jacobs
> 
> Sent from ProtonMail, Swiss-based encrypted email.
> 
> GPG Public Key -
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flook
> up%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!!JmP
> EgBY0HMszNaDT!pAWO1c7mmDn_QwSQvW47zNtqLZjxXFmAjQSiQbQ3RDt1
> C5cK5ibODjyit4YTrG-
> 8oe1bcIP7jvYVdte7lA468xSU5bS2yHTD%24=05%7C02%7CGIBNEY%40
> WSU.EDU%7C4f71da5c5bef4c7bc66808dc299a7403%7Cb52be471f7f147b
> 4a8790c799bb53db5%7C0%7C0%7C638430990552642856%7CUnknown
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=SMKdbO8kleP4gFxXmiDfO
> K80KFMCb6duVno3%2FCuj3Sw%3D=0
> 
> 
> On Friday, February 9th, 2024 at 1:02 PM, Gibney, Dave
> <03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > You would be better served with PAGE. because you can have
> > them cataloged in multiple catalogs
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> > > Behalf Of Mark Jacobs
> > > Sent: Friday, February 9, 2024 8:54 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: HLQ of Page Dataset Names
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > Yes, we're currently using the value of  as the HLQ for the
> > > page datasets. I was wondering if there's any special powers
> > > available for the HLQ of
> > > SYS1 or PAGE.
> > >
> > > Mark Jacobs
> > >
> > > Sent from ProtonMail, Swiss-based encrypted email.
> > >
> > > GPG Public Key -
> > >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur
> > >
> ldefense.com%2Fv3%2F__https%3A%2F%2Fnam12.safelinks.protection.outl
> o
> > >
> ok.com%2F%3Furl%3Dhttps*3A*2F*2Furld__%3BJSUl!!JmPEgBY0HMszNaDT
> !pAWO
> > > 1c7mmDn_QwSQvW47zNtqLZjxXFmAjQSiQbQ3RDt1C5cK5ibODjyit4YTrG-
> 8oe1bcIP7
> > >
> jvYVdte7lA468xSU5SnIrJ2R%24=05%7C02%7CGIBNEY%40WSU.EDU%
> 7C4f71da
> > >
> 5c5bef4c7bc66808dc299a7403%7Cb52be471f7f147b4a8790c799bb53db5
> %7C0%7C
> > >
> 0%7C638430990552652888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiL
> > >
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C
> a=Ax%
> > >
> 2BhKaz6VuuTKnu%2BQzH9%2BNDg7prLVepqimhgyKCLBfk%3D=0
> > >
> efense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flook
> > >
> up%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!!JmP
> > > EgBY0HMszNaDT!t2r_0zpttnfKKQdF472QCXfSkUBWgKXVU3L-a-
> > > 1YJwiUy65DMx3HtormAYh2EY3aX0F9VcNH16OYsxw3H3kVU0hI-
> > >
> iiAPmFq%24=05%7C02%7CGIBNEY%40WSU.EDU%7Cffd88af4468a48
> > >
> 1ba7ea08dc298fd340%7Cb52be471f7f147b4a8790c799bb53db5%7C0%7C
> > >
> 0%7C638430944905529551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > >
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> > >
> %7C%7C=hZw%2FWdCJeYltXnhh6UHn51SVT%2BarWsgBUwFYZu2vZv
> > > Y%3D=0
> > >
> > > On Friday, February 9th, 2024 at 10:16 AM, David Elliot
> > > 05829bddcbe4-dmarc-requ...@listserv.ua.edu wrote:
> > >
> > > > Are you talking about choosing your own HLQ for page datasets?
> > > >
> > > > On Fri, Feb 9, 2024, 2:54 PM Mark Jacobs <
> > > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> > > >
> > > > > I seem to recall, but can't find anything that confirms my
> > > > > recollection that certain HLQs such as SYS1 and PAGE have
> > > > > special powers as relating to systems programmer type management
> activities.
> > > > > Can anyone point me to the documentation if true, or tell me I'm
> > > > > incorrect if I am? Thanks.
> > > > >
> > &g

Re: HLQ of Page Dataset Names

[Gibney, Dave]

You would be better served with PAGE. because you can have them 
cataloged in multiple catalogs

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Mark Jacobs
> Sent: Friday, February 9, 2024 8:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: HLQ of Page Dataset Names
> 
> [EXTERNAL EMAIL]
> 
> Yes, we're currently using the value of  as the HLQ for the page
> datasets. I was wondering if there's any special powers available for the HLQ 
> of
> SYS1 or PAGE.
> 
> Mark Jacobs
> 
> Sent from ProtonMail, Swiss-based encrypted email.
> 
> GPG Public Key -
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flook
> up%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!!JmP
> EgBY0HMszNaDT!t2r_0zpttnfKKQdF472QCXfSkUBWgKXVU3L-a-
> 1YJwiUy65DMx3HtormAYh2EY3aX0F9VcNH16OYsxw3H3kVU0hI-
> iiAPmFq%24=05%7C02%7CGIBNEY%40WSU.EDU%7Cffd88af4468a48
> 1ba7ea08dc298fd340%7Cb52be471f7f147b4a8790c799bb53db5%7C0%7C
> 0%7C638430944905529551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> %7C%7C=hZw%2FWdCJeYltXnhh6UHn51SVT%2BarWsgBUwFYZu2vZv
> Y%3D=0
> 
> 
> On Friday, February 9th, 2024 at 10:16 AM, David Elliot
> <05829bddcbe4-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > Are you talking about choosing your own HLQ for page datasets?
> >
> >
> >
> > On Fri, Feb 9, 2024, 2:54 PM Mark Jacobs <
> > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > I seem to recall, but can't find anything that confirms my
> > > recollection that certain HLQs such as SYS1 and PAGE have special
> > > powers as relating to systems programmer type management activities.
> > > Can anyone point me to the documentation if true, or tell me I'm incorrect
> if I am? Thanks.
> > >
> > > Mark Jacobs
> > >
> > > Sent from ProtonMail, Swiss-based encrypted email.
> > >
> > > GPG Public Key -
> > >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur
> > >
> ldefense.com%2Fv3%2F__https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flo
> okup
> > >
> %3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com__%3B!!JmPEg
> BY0HMs
> > > zNaDT!t2r_0zpttnfKKQdF472QCXfSkUBWgKXVU3L-a-
> 1YJwiUy65DMx3HtormAYh2EY
> > > 3aX0F9VcNH16OYsxw3H3kVU0hI-
> iiAPmFq%24=05%7C02%7CGIBNEY%40WSU.ED
> > >
> U%7Cffd88af4468a481ba7ea08dc298fd340%7Cb52be471f7f147b4a8790c
> 799bb53
> > >
> db5%7C0%7C0%7C638430944905538872%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4
> > >
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C
> %7C%7C
> > >
> =nlRtWaCJo9V0CfJfEJcZ%2FpEQaZC8ilrBH0p4ZQZNoKY%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
> 
> --
> 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: JES2 JOBDEF DUPL_JOB=NODELAY - Any gotchas?

[Gibney, Dave]

There is no guarantee that jobs with the same name will execute in the order 
submitted. They do appear to run in the order that conversion completes.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Frank Swarbrick
> Sent: Friday, February 2, 2024 11:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 JOBDEF DUPL_JOB=NODELAY - Any gotchas?
> 
> [EXTERNAL EMAIL]
> 
> I tried this once for a single class in our dev region and it screwed up some 
> jobs
> that depend on DELAY for sequencing.  
> Of course something could be done about that, but I didn't feel like dealing
> with it at the time.
> 
> From: IBM Mainframe Discussion List  on
> behalf of Charles Mills 
> Sent: Thursday, February 1, 2024 10:15 AM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: JES2 JOBDEF DUPL_JOB=NODELAY - Any gotchas?
> 
> I am not a sysprog but I occasionally play one in my spare time. I am thinking
> of changing a system that I control to DUPL_JOB=NODELAY. Any gotchas?
> Anything I need to consider before I do this? Do most/many of you run with
> NO_DELAY?
> 
> I am trying to solve a problem where I have jobs delayed because the names
> are duplicates. I can't easily change the jobnames.
> 
> I can't think of any issues. We don't have any significant automation. I can't
> think of anything where jobs are referenced by name rather than Job ID.
> 
> What should I be considering?
> 
> Thanks,
> Charles
> 
> --
> 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: GTF trace for a JCL error?

[Gibney, Dave]

Have (or create from sandbox) a simple/failsafe version of the VTAN proc.
Export the spool files and import into sandbox or other lpar.
I suspect there are sufficwnt breadcrumbs in a standalone dump.

Test changes to VTAM proc by running it via a job before you shutdown.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Peter Ten Eyck
> Sent: Tuesday, January 30, 2024 10:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: GTF trace for a JCL error?
> 
> [EXTERNAL EMAIL]
> 
> Dave,
> 
> It was VTAM that would not come up due to a JCL error. We could not sign on
> to that LPAR and access JES. I was researching if I could see the JCL error 
> via a
> GTF trace. Sounding like I will not be able to do that.
> 
> In this case, starting the VTAM STC again with S , SUB=MSTR would
> write the JCL error to the console.
> 
> The issue has been resolved, just researching what other methods I could have
> used…
> 
> --
> 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: GTF trace for a JCL error?

[Gibney, Dave]

Run a job with //STEP EXEC procname

Presumably it will experience the same JCL error

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Peter Ten Eyck
> Sent: Tuesday, January 30, 2024 6:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: GTF trace for a JCL error?
> 
> [EXTERNAL EMAIL]
> 
> Under z/OS 2.4.
> 
> I have a STC when started, fails with the following error in the SYSLOG:
> 
> IEE132I START COMMAND DEVICE ALLOCATION ERROR
> 
> Looking at the STC output in JES, there is a JCL error in the proc (dataset 
> not
> found).
> 
> Is there a way to "see" the JCL error without looking at the JES output?
> 
> I have been researching and running a GTF trace with no success "seeing" the
> JCL error, not sure what GTF trace options to turn on or if it is possible to 
> see
> that JCL error via a GTF trace.
> 
> Is it possible to see that JCL error in a GTF trace, if so, what options 
> (parms) do
> I need to run with?
> 
> 
> 
> Note: We had an issue with VTAM not coming up on a LPAR and we were
> unable to access JES to see the JCL error.
> 
> --
> 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: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Gibney, Dave]

It should be obvious, but as a practical matter, you can't encrypt the modules 
that do the decryption and it also follows that you can't encrypt the modules 
that provide the execution environment (z/OS) for these modules.

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

Re: allowed characters in member name

[Gibney, Dave]

Before LIKE, you needed IDCAMS to create VSAM files, after LIKE you could do 
this with just JCL

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Sunday, January 7, 2024 4:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: allowed characters in member name
> 
> [EXTERNAL EMAIL]
> 
> On Sun, 7 Jan 2024 23:42:41 +, Seymour J Metz wrote:
> 
> >Long ago (in OS/390?) IBM introduced a bunch of keywords equivalent to
> subparameters of DCB, e.g., LRECL= is equivalent to DCB=LRECL=. I believe that
> LIKE= was part of that.
> >
> Did LIKE add any expressive power that DCB lacks?
> 
> I believe neither DCB nor LIKE can be used in nor refer to DD PATH=
> 
> The alternative might be to use JCL symbols for common attribute strings.
> 
> Combining brevity and mnemonic value:
> Q = "'"
> QQ = '"'
> 
> Don't forget to mention them in PROCEDURE EXPOSE.
> SIGNAL ON NOVALUE would remind you, if you chose to use it.
> 
> --
> gil
> 
> --
> 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: allowed characters in member name

[Gibney, Dave]

DCB for the subparameters as been depreciated and, in my opinion, bad form for 
most of the 40 years I worked on mainframes. The DCB=modeldscb form used for 
new GDS allocations hasn't been needed since SMS came along. Early 90s'? 
I may recall wrong, but I think LIKE was new with SMS.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Sunday, January 7, 2024 12:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: allowed characters in member name
> 
> [EXTERNAL EMAIL]
> 
> On Sun, 7 Jan 2024 21:04:48 +0100, Radoslaw Skorupka wrote:
> >...
> >I have to admit: I almost never used DCB keyword in JCL and (AFAIR)
> >absolutely never DCB=HLQ.DATASET.NAME.
> >When teaching JCL I explain it, but also advice to not using that.
> >BTW: LIKE=HLQ.FOO-BAR works like a charm.
> >
> in
>  defense.com%2Fv3%2F__https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%
> 2Fzos%2F3.1.0%3Ftopic%3Ddp-syntax-
> 2__%3B!!JmPEgBY0HMszNaDT!t9cNADlF8YggV3ftQnDqq6_pEAAjAFaVbaK2k
> fJgOesh1r7d9dqid5L-
> WIIW1zb5mpfhGtk7tLl2BCULYpCb41cuw0K2G4c3%24=05%7C02%7C
> GIBNEY%40WSU.EDU%7C67f73d32256d4c107e3608dc0fc30cd4%7Cb52be
> 471f7f147b4a8790c799bb53db5%7C0%7C0%7C638402577608244597%7
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=5avD4PTklj
> wHUQOVSoHwar90iho8VQVuCtgOLxfh5gM%3D=0 >:
> [ DCB= ( {dsname   }[,subparameter]...) ]
> 
> Is it possible likewise to override selected subparameters of LIKE?  Was it so
> even before the subparameters were allowed as separare parameters?  (Old
> habits diehard.)
> 
> --
> gil
> 
> --
> 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: ISPF to Panvalet interface

[Gibney, Dave]

Any site that runs z/OS today needs zOSMF and therefore pretty much needs a 
zIIP. 
I think needing zOSMF was at least on the horizon when z13s became available. 
Seems IBM was inaccurate : (

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Brian Westerman
> Sent: Friday, December 22, 2023 9:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ISPF to Panvalet interface
> 
> [EXTERNAL EMAIL]
> 
> When they bought the machine they were moving from a z/800 and were told
> by IBM that they didn't "need" the specialty processor.  In any case, it is 
> what
> it is.  Trying to get zIIP dollars from a site that doesn't have one, 
> especially
> when their product doesn't support a zIIP would be kind of odd.  They have
> other products that do run on a zIIP, but that's not the case here.  I think 
> it
> could really just a matter of greed.  It's not like they are going to come 
> forward
> and say so.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Rexx to clone users in RACF

[Gibney, Dave]

I had a Rexx that matched user (well any string actually) and extracted the 
records from an unload. Then fed them to DBSYNC with an empty compare file. The 
generated commands were usually close to what I wanted.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Peter
> Sent: Tuesday, November 21, 2023 12:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Rexx to clone users in RACF
> 
> [EXTERNAL EMAIL]
> 
> Cloning  and creating one user is easy but
> 
> I want to clone and create 10 userid at once .
> 
> Is it possible to achieve it through DBSNC.?
> 
> On Fri, Nov 17, 2023, 11:20 PM Walt Farrell  wrote:
> 
> > IBM used to, and may still, supply an unofficial REXX exec that I
> > wrote named DBSYNC. One of its operational modes allows cloning a
> > user, though I don't recall if that is described in the documentation
> > or only anecdotally on RACF-L. And I have no idea where such tools &
> > toys are distributed today, but someone on RACF-L could probably provide
> more information.
> >
> > (And, arguably, RACF-L is a better place for a discussion about
> > cloning RACF users than ibm-main, in my opinion :) )
> >
> > --
> > Walt
> >
> > --
> > 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: SAS for ZOS 9.4.8 Install/Upgrade Experiences?

[Gibney, Dave]

At one time there was a SAS-L. Don't know if it still exists. It was very 
active.
Also, the people at mxg.com might be able to help.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Steve Estle
> Sent: Saturday, September 23, 2023 5:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SAS for ZOS 9.4.8 Install/Upgrade Experiences?
> 
> [EXTERNAL EMAIL]
> 
> Everyone,
> 
> I support a secure government environment that has limited ability to connect
> directly to vendor software download sites and am embarking on effort to
> upgrade our SAS for ZOS from 9.4.7 to 9.4.8 - you would think simple / simon
> but is my first time with this software package install/upgrade and am
> struggling with the process SAS dictates to get software from there sites.  
> They
> use a tool called SAS download manager - one for ZOS, Windows, Linux, etc.
> Curious for those sites that have SAS for ZOS, how are you getting software
> from SAS site to your ZOS system(s)?  SAS does not offer any sort of FTP like
> functionality and forces you to use download manager which unfortunately is
> not so simple to use - at least not on ZOS.  SAS packaging for ZOS relies very
> heavily on Unix System Services for the packaging, install, maintenance, and
> deployments/customization.
> 
> One other item, if you have engaged SAS support on regular basis, how would
> you rate your SAS support experience?  Mine to say the least is challenging -
> one of the issues we've run into under SAS 9.4.7 is interfacing SAS 9.4.7 with
> CICS web services and ATTLS - they seem to not be too savvy in this space -
> found out they do not have / nor test CICS in there ZOS / lab test environment
> at all and we have programmer who has written code for SAS to talk to CICS
> web services to extract information.  This is one of the reasons we are moving
> to SAS 9.4.8 as they repackage the OpenSSL such that it now relies on system
> SSL libraries / encryption routines vs. packing there own.
> 
> Anyways if interested in talking further / sharing experiences / or maybe have
> some good contacts relative to SAS, please let me know.  Appreciate any/all
> ideas.
> 
> Thanks in advance,
> 
> Steve Estle
> sest...@gmail.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: Bill Johnson

[Gibney, Dave]

FWIW, discussions of Bill and thanking Darren are technically not about IBM 
Mainframes 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tom Marchant
> Sent: Monday, September 18, 2023 1:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Bill Johnson
> 
> [EXTERNAL EMAIL]
> 
> Thank you Darren.
> 
> Bill was primarily disruptive and contributed very little to the list.
> It would be a shame if his disruptive tactics resulted in the list being shut
> down.
> 
> --
> Tom Marchant
> 
> On Mon, 18 Sep 2023 19:24:23 +, Darren Evans-Young
>  wrote:
> 
> >I have removed Bill Johnson from the IBM-MAIN list and you all know why.
> >
> >He has now officially lodged a complaint against me accusing me of
> discrimination
> >and violating his 1st Amendment rights.  This complaint was sent to the
> President and
> >the Chief Administrative Officer at The University of Alabama.
> >
> >Worst case, I'll have to dissolve IBM-MAIN. If you are at a university that
> hosts
> >listserv lists, and would be able to host IBM-MAIN in the event I'm told to
> take
> >the list down, please contact me off-list
> (dar...@ua.edu).
> >
> >Darren
> >
> >P.S. - Please do not contact Bill Johnson. It will only make things worse.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: EXTERNAL EMAIL: Re: On-Prem to Cloud Mainframe Migration Experiences

[Gibney, Dave]

When we moved our LPARs to a hosting service, we were able to set-up a VPN 
(Palo Alto FW) from our f5 load balancer to 10. Addresses at the service OSA 
and from our customer's point of view, keep all of our local ip addresses

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jerry Whitteridge
> Sent: Thursday, August 31, 2023 2:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: EXTERNAL EMAIL: Re: On-Prem to Cloud Mainframe Migration
> Experiences
> 
> [EXTERNAL EMAIL]
> 
> OK - so you are planning DB2 z to DB2 z that makes  it simpler.  Are you
> running on your own systems or are you planning to move to a hosted
> operating system (in other words are you just migrating DB2 or would you be
> migrating your OS as well).
> 
> We recently moved all our mainframe work to the zCloud and I'd be happy to
> answer any questions you may have. Some might need to be in a private
> conversation but I will say the most critical piece of the move will be your
> network and network addresses.
> 
> 
> Jerry Whitteridge
> Sr Manager Managed Services
> jerry.whitteri...@albertsons.com
> 480 578 7889
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Lance D. Jackson
> Sent: Thursday, August 31, 2023 11:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: EXTERNAL EMAIL: Re: On-Prem to Cloud Mainframe Migration
> Experiences
> 
> Sorry Jerry, I missed it.
> 
> What's being considered (among other things) is Db2 Z on-prem to Db2 Z
> cloud.  I was just trying to see if anyone in the community had any 
> experiences
> to share.  Thanks.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jerry Whitteridge
> Sent: Thursday, August 31, 2023 13:04
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: EXTERNAL EMAIL: Re: On-Prem to Cloud Mainframe Migration
> Experiences
> 
> Lance - I responded to your query asking for clarification on your question. 
> Are
> you asking about moving Mainframe DB2 to UDB in the cloud or Mainframe
> DB2 to Mainframe DB2 (hosted on z/OS still) ?
> 
> J
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Lance D. Jackson
> Sent: Wednesday, August 30, 2023 5:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: EXTERNAL EMAIL: Re: On-Prem to Cloud Mainframe Migration
> Experiences
> 
> David,
> 
> Actually, yours is the FIRST response to my query.  I was primarily curious if
> anyone has had experience with this (not advocating for it).  My client is
> exploring the possibilities, and I wanted to see if anyone has made the leap.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of David Elliot
> Sent: Tuesday, August 29, 2023 18:29
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: On-Prem to Cloud Mainframe Migration Experiences
> 
> Not seeing much in the way of responses to your question, Lance. Could be
> you are asking an impossible question. like ' Is there a god?' or 'is global
> warming real?' Were you expecting an outpouring of enthusiasm for this
> nebulous technology? What were your experiences? Did you get what you
> were promised or what you deserved?
> 
> 
> 
> 
> On Mon, Aug 21, 2023 at 11:23 AM Lance D. Jackson <
> ljack...@pandrueassociates.com> wrote:
> 
> > List,
> >
> > Has anyone had experience (good or bad) with migrating their mainframe
> > Db2 workload from on-prem to the cloud?
> >
> > --
> > 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
> 
>  Warning: All e-mail sent to this address will be received by the corporate e-
> mail system, and is subject to archival and review by someone other than the
> recipient. This e-mail may contain proprietary information and is intended 
> only
> for the use of the intended recipient(s). If the reader of this message is 
> not the
> intended recipient(s), you are notified that you have received this message in
> error and that any review, dissemination, distribution or copying of this
> message is strictly prohibited. If you have received this message in error,
> please notify the sender immediately.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Gibney, Dave]

EasyProclib did DD concatenations. IBM did a new //name JCLLIB 
ORDER=(dsn,dsn,,) JCL statement. I am only guessing that this was so that it 
was sufficiently different from the existing ISV product

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tom Brennan
> Sent: Thursday, August 31, 2023 10:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: Is SMP/E needed for installs?
> 
> [EXTERNAL EMAIL]
> 
> I remember that product!  But I thought it worked with a DD, something
> like:  //PROCLIB DD DSN=TED013.PROCLIB,DISP=SHR
> 
> When JCLLIB came out, we dropped the product and wrote some code in JES2
> exit 4 to convert PROCLIB to JCLLIB so users didn't have to change their
> JCL.
> 
> I thought ORDER= was done because you can code more than one dataset.
> 
> On 8/31/2023 10:27 AM, Gibney, Dave wrote:
> > In part because that was how the EasyProclib (owned by CA at the
> time)product worked.
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of Pommier, Rex
> >> Sent: Thursday, August 31, 2023 10:20 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: [EXTERNAL] Re: Is SMP/E needed for installs?
> >>
> >> [EXTERNAL EMAIL]
> >>
> >> Yeah, I don't understand why IBM didn't just use DD card syntax instead of
> >> coming up with this.
> >>
> >> Rex
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of Phil Smith III
> >> Sent: Thursday, August 31, 2023 12:01 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: [EXTERNAL] Re: Is SMP/E needed for installs?
> >>
> >> Billy Ashton wrote:
> >>
> >>> If you want to INCLUDE a member, this is like a PROC, so you need to
> >>
> >>> have SETS in a system-defined proclib or you have to add something like
> >>
> >>> //JCLLIB ORDER=PHS.PDS.JCL840
> >>
> >>
> >>
> >> You've got me to spot what I'd just stupidly missed: I had taken the JCLLIB
> to
> >> be a DD, and it's not: it's a whole new statement. If I change it to:
> >>
> >> // JCLLIB   ORDER=PHS.PDS.JCL840
> >>
> >>
> >>
> >> It works. Well, it fails later, but the JCL works! Thanks. I knew it was
> something
> >> dumb.
> >>
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to
> >> lists...@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 intended recipient, you are hereby notified that any
> disclosure,
> >> distribution, copying, or any action taken or action omitted in reliance 
> >> on it,
> is
> >> strictly prohibited and may be unlawful. If you have received this
> >> communication in error, please notify us immediately by replying to this
> >> message and destroy the material in its entirety, whether in electronic or
> hard
> >> copy format. Thank you.
> >>
> >> --
> >> 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: [EXTERNAL] Re: Is SMP/E needed for installs?

[Gibney, Dave]

In part because that was how the EasyProclib (owned by CA at the time)product 
worked.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Pommier, Rex
> Sent: Thursday, August 31, 2023 10:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: Is SMP/E needed for installs?
> 
> [EXTERNAL EMAIL]
> 
> Yeah, I don't understand why IBM didn't just use DD card syntax instead of
> coming up with this.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Phil Smith III
> Sent: Thursday, August 31, 2023 12:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: Is SMP/E needed for installs?
> 
> Billy Ashton wrote:
> 
> >If you want to INCLUDE a member, this is like a PROC, so you need to
> 
> >have SETS in a system-defined proclib or you have to add something like
> 
> >//JCLLIB ORDER=PHS.PDS.JCL840
> 
> 
> 
> You've got me to spot what I'd just stupidly missed: I had taken the JCLLIB to
> be a DD, and it's not: it's a whole new statement. If I change it to:
> 
> // JCLLIB   ORDER=PHS.PDS.JCL840
> 
> 
> 
> It works. Well, it fails later, but the JCL works! Thanks. I knew it was 
> something
> dumb.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@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 intended recipient, you are hereby notified that any 
> disclosure,
> distribution, copying, or any action taken or action omitted in reliance on 
> it, is
> strictly prohibited and may be unlawful. If you have received this
> communication in error, please notify us immediately by replying to this
> message and destroy the material in its entirety, whether in electronic or 
> hard
> copy format. Thank you.
> 
> --
> 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

Uptime?

[Gibney, Dave]

  Yes, IBM z hardware and z/OS properly sysplexed can achieve many 9s of 
reliability.  I don't think this is in dispute. 
But, computers are tools that perform useful things for people. It should be 
clear that actual availability of application function at the outside endpoints 
is not nearly as many 9s.
   It's fairly clear that even IBM support sites don't run solely on Sysplexed 
zHardware under z/OS achieving lot's of 9s.

  I suspect a few LPARs in Sysplex over a couple CECs running nothing but z/OS 
would never need to come fully down. An expensive POC, but also pretty useless.

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

Re: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server

[Gibney, Dave]

There's a free "wireshark" for z/OS. Something like 
NBOS for z/OS

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jerry Whitteridge
> Sent: Saturday, August 26, 2023 10:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server
> 
> [EXTERNAL EMAIL]
> 
> Thanks Charles I was just starting to look at if curl would do it.
> 
> This is a TN3270 server on z/OS that I want to check what cert it is 
> presenting
> to the user for a TLS connection.
> 
> J
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Charles Mills
> Sent: Saturday, August 26, 2023 10:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server
> 
> Well, I wrote a product that does exactly that in a beautiful graphic fashion 
> and
> is part of NewEra's ICEDirect suite.
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.newera.com%2FINFO%2FIC
> EDirect.pdf__%3B!!JmPEgBY0HMszNaDT!p7XN4J09CBWP5eaGgpdT2VAVnTc
> gOHI66aUmtmicKPvG-
> 4oXEGRcKDnH9yb_2KRZQg0s99_3guSOoyqqicnIdvXILxNY%24=05%7C
> 01%7CGIBNEY%40WSU.EDU%7C0436f4fd6f0d41e45b3608dba65c7453%7C
> b52be471f7f147b4a8790c799bb53db5%7C0%7C0%7C638286688235202
> 429%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=4NW
> Vk9ZbssYTQSffyGgNsMixH22r32oxKNNzbLUJgCA%3D=0
> 
> Does that count? 
> 
> For free tools
> 
> 1. Is it a Web server? If so most browsers will display the server 
> certificate and
> the entire chain of trust. Click on the padlock icon next to the URL and take 
> it
> from there.
> 
> 2. Perhaps you can do this with OpenSSL?  I think so but don't know the
> details.
> 
> 3. Can you do this with curl? Seems likely but I am not a curl expert.
> 
> Charles
> 
> On Sat, 26 Aug 2023 16:52:46 +, Jerry Whitteridge
>  wrote:
> 
> >I used to use a java command to check on my certs on the mainframe
> >
> >keytool -printcert -sslserver :port
> >
> >but now all I get is a message
> >
> >XXX:/u/xxx:>keytool -printcert -V -sslserver .yyy.com
> >keytool error: java.lang.Exception: No certificate from the SSL server
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
>  Warning: All e-mail sent to this address will be received by the corporate e-
> mail system, and is subject to archival and review by someone other than the
> recipient. This e-mail may contain proprietary information and is intended 
> only
> for the use of the intended recipient(s). If the reader of this message is 
> not the
> intended recipient(s), you are notified that you have received this message in
> error and that any review, dissemination, distribution or copying of this
> message is strictly prohibited. If you have received this message in error,
> please notify the sender immediately.
> 
> 
> --
> 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: vi

[Gibney, Dave]

Pretty sure it was 16 bits. The assembler I was learning used octal notation.
The next semester class was 370 assembler using the Struble book. 
In many ways, I owe my entire career too that class.

> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Paul Gilmartin
> Sent: Friday, August 18, 2023 2:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: vi
> 
> [EXTERNAL EMAIL]
> 
> On Fri, 18 Aug 2023 20:37:35 +, Seymour J Metz wrote:
> 
> >> The early 1970s PDP-10 (and PDP-8) were the Digital Equipment forerunners
> of the later DECSYSTEM and VAX computers.
> >
> >No; the PDP-6 and PDP-10 were 36-bit machines. The PDP-5 and PDP-8 were 12
> bit machines unrelated to the DECSYSTEM-10 and -20 and the VAX-11. The
> forerunner of the VAX was the 16-bit PDP-11.
> >
>  se.com%2Fv3%2F__https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProgrammed_
> Data_Processor__%3B!!JmPEgBY0HMszNaDT!vHVtpLbj7su56m0olLJcdNrJAkUZRi
> 5YoOE6zpPKiI6MZ05n8vnGCe8_rdYeQAkdTZ_6QziItBQuvYvBZUs-
> ksLI7BIn7f8t%24=05%7C01%7CGIBNEY%40WSU.EDU%7C43d886a21d2d4
> e21a8b208dba02e0cb8%7Cb52be471f7f147b4a8790c799bb53db5%7C0%7C0%7
> C638279891870712574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> data=I0%2Fs09Uk10VARlTvajwZO308WP9D1jVhRyT%2BegLbrrM%3D=
> 0 >
> 
> --
> gil
> 
> --
> 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: vi

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Paul Gilmartin
> Sent: Friday, August 18, 2023 10:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: vi
> On Fri, 18 Aug 2023 17:08:09 +, Gibney, Dave wrote:
> 
> >In 1978, the class in PDP assembler used ed. Didn't mention vi.
> >Discovering vi was quite helpful to my progress in the class.
> >
> Mavens have cautioned me that I should master ed lest I am ever
> confined to a terminal lacking the capabilities needed by vi.
> I've ignored them, so far.
> 
> 3278?
> 
> But ed : vi :: TSO EDIT : ISPF.
> 
> PDP?  ed, not TECO?

Using Fox terminals. I remember it as a PDP 11/60
> 
> --
> gil
> 
> --
> 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

vi

[Gibney, Dave]

In 1978, the class in PDP assembler used ed. Didn't mention vi. 
Discovering vi was quite helpful to my progress in the class.

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

Re: ISPF in batch, And then there is The Naviquest part of DFSMS

[Gibney, Dave]

Naviquest is a part of the ISMF panels/application. It includes a bunch of 
batch ISPF.

It doesn't run fast, but it does work.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Thursday, August 10, 2023 3:09 PM
> ISPF 3.4 is interactive, probably of little use in batch.
> 
> Wouldn't it be nice if(?) there were a catalogued PROC with the needed
> allocations as replaceable parameters?
> 
> --
> gil
> 
> --
> 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: RSU Maintenance: Asking For a Friend

[Gibney, Dave]

I didn't have a policy of regular RSU. But, I would usually bring maintenance 
up to current RSU plus HIPER, IBM , etc. midway between upgrades, usually every 
other Z/OS release. And, I would always bring my running system as close to 
current as was available before starting any upgrade. 

Only once did I try to upgrade without fallback and co-existence fixes on my 
running system. This was long ago, my 1st time and was not a pleasant 
experience.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Michael Watkins
> Sent: Monday, July 17, 2023 3:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RSU Maintenance: Asking For a Friend
> 
> [EXTERNAL EMAIL]
> 
> 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

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

Re: "National" characters

[Gibney, Dave]

US/Europe centered attitude
$ Currency - Dollar 
# Weight - Pound
@ per item - at

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bob Bridges
> Sent: Tuesday, July 11, 2023 6:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "National" characters
> 
> It was never clear to me why the term "national" was picked in the first 
> place.
> Although I worked for Volvo 14 years (jag Verkade på Volvo Lastvagnar fyrtio
> år) and on the Swedish side those keys produced characters in the Swedish
> alphabet - I don't remember which ones exactly, but probably something like
> Ä, Å and Ö.
> 
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> 
> /* Vegetables aren't food.  Vegetables are what food eats.  -from Shoe,
> 1999-10-08 */
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Peter Relson
> Sent: Tuesday, July 11, 2023 08:05
> 
> The ID (now CDD) folks had years ago made us refer to @,$,# as "special
> characters" rather than as "national characters".
> 
> It is disappointing that they did not change the publications to be consistent
> with that directive. By all means point out the discrepancies that you spot.
> 
> I'll bet that any change would be from "national" to "special" (not the other
> way around).  I have no idea what term they will decide to use for the JCL
> characters that they currently call special.
> 
> --
> 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: SORTWK space usage

[Gibney, Dave]

There may be some odd edge case, but it is my opinion control statements, 
parameters, are always preferable to hardcoded JCL SORTWK. If only for the sake 
of conciseness.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Billy Ashton
> Sent: Monday, July 3, 2023 1:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SORTWK space usage
> 
> [EXTERNAL EMAIL]
> 
> It is on disk, Doug. Thanks for the caveat!
> 
> Thank you and best regards,
> Billy Ashton
> 
> 
> -- Original Message --
> From "Doug Shupe"  To IBM-MAIN@listserv.ua.edu
> Date 7/3/2023 4:07:05 PM Subject Re: SORTWK space usage
> 
> >Billy,
> >Am only trying to present a possible option. The number of volumes and
> available space is shop dependent. Best to grab a sort manual and go through
> the possible option then test.
> >The expert, Sri Kolusu many have thoughts on best practice.
> >Is the input disk or tape ? It makes a difference..
> >Doug
> >
> >Stay Safe
> >
> >>  On Jul 3, 2023, at 15:48, Billy Ashton  wrote:
> >>
> >>  Doug, this raises a good point. If I have a COBOL program doing a SORT in
> the middle of the program (I am not sure if the big file is doing this, too or
> not), is using this DFSPARM the best way to force the use of 15 Dynalloc
> SORTWK files, so I would not have to code SORTWK DD statements?
> >>
> >>  Thank you and best regards,
> >>  Billy Ashton
> >>
> >>
> >>  -- Original Message --
> >>  From "Doug" 
> >>  To IBM-MAIN@listserv.ua.edu
> >>  Date 7/3/2023 2:45:28 PM
> >>  Subject Re: SORTWK space usage
> >>
> >>>  Try adding this instead off sorted dd.
> >>>  //DFSPARM  DD   *
> >>>   OPTION DYNALLOC=(SYSDA,15),DYNSPC=768
> >>>  /*
> >>>
> >>>  You can add other options too.
> >>>  Regards, Doug
> >>>
>   On Jul 3, 2023, at 14:34, Michael Oujesky 
> wrote:
> 
>   Just a warning, but the SORTWK specification decision depends on how
> SORT is provided the input data.  If via SORTIN, then allowing SORT to make
> the determination should be fine.  But when the incoming records are
> provided SORT one records at a time (piping, E15 exit, etc,) then nudging
> SORT's SORTWK decision by providing some SORTWK areas would probably be
> a better approach.
> 
>   At 01:13 PM 7/3/2023, Billy Ashton wrote:
> 
>   Thanks everyone - these are good recommendations.
> 
>   However, the guy who came to me first has a job that sorts 450 million
> records of 110 bytes, and I can't see how I could run SORT without specifying
> SORTWK DD statements. Are there special configuration options I can verify
> that we have in place to help my comfort level that I could eliminate SORTWK
> DD?
> 
>   If the programming team are not convinced, does this look right, based
> on the discussion - and based on a 100% Disk sort, which is not likely?
>   450mill * 110 * 1.5 = 7425000 = 69GB  so maybe SORTWK01 -
>  SORTWK10
>   //SORTWK01  DD
> UNIT=WORK,DSNTYPE=LARGE,SPACE=(CYL,(4000,1000))
>   to
>   //SORTWK10  DD
> UNIT=WORK,DSNTYPE=LARGE,SPACE=(CYL,(4000,1000))
> 
>   and this will give me 4000 + (15*1000) on each, or 4c primary
>  + (up to 150 * 1000) secondary
> 
>   While we have been talking here, I have looked, and found some
>  jobs with
>   //SORTWK01 DD UNIT=(WORK,5)...
>   and this will not work, is that right, Sri Kolusu? I would only get the 
>  first
> volume anyway?
> 
>   Thank you and best regards,
>   Billy Ashton
> 
> 
>   -- Original Message --
>   From "Farley, Peter"
>  <031df298a9da-dmarc-requ...@listserv.ua.edu>
>   To IBM-MAIN@listserv.ua.edu
>   Date 7/3/2023 12:44:43 PM
>   Subject Re: SORTWK space usage
> 
> >  I will add on to Sri's excellent answer with my very STRONG
> recommendation NOT to use hard-coded SORTWK's in your JCL.  Both of the
> major SORT vendors (IBM and Syncsort) do a far, far better job of estimating
> necessary SORTWK space and memory utilization than any human could hope
> to do.
> >
> >  I also STRONGLY recommend that you give your JCL and program-
> controlled SORT steps as much memory in the REGION parameter as your
> installation allows for production and test jobs.  Both of the major SORT
> programs will figure out how much of that memory to use, whether and how
> much of it to use in the current WLM environment, and will make VERY
> effective use of as much of it as they can to cut down on SORT execution and
> elapsed time.  Memory is (relatively) cheap, don't be afraid to use all you've
> got available to shorten your SORT times.
> >
> >  My basic advice is don't try to second-guess these very intelligent
> programs - they each have more than half a century of practice and experience
> that none of us can match, even those of us who have been around that long.
> >
> >  Peter
> >
> >  -Original Message-
> >  From: IBM Mainframe 

Re: REXXLIB execs naming

[Gibney, Dave]

I would still keep it in an additional library in the concatenation. Not the 
one that IBM maintains via SMP/E

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of jgmauta...@yahoo.com.ar
> Sent: Thursday, June 29, 2023 9:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: REXXLIB execs naming
> 
> [EXTERNAL EMAIL]
> 
> Hi:
> From IBM documentation, regarding System REXX configuration:
>  a set (concatenation) of data sets from which SYSREXX attempts to fetch
> execs. This set of data sets is referred to as the REXXLIB concatenation.
> SYS1.SAXREXEC contains execs that IBM provides and in general should not be
> modified. When SYS1.SAXREXEC is not specified in the REXXLIB concatenation,
> it is appended to the end. For details about AXRnn processing, see z/OS MVS
> Initialization and Tuning Reference. Any execs that are added to the
> concatenation cannot start with the letters A through I that are reserved for
> IBM execs. I wonder about LAST phrase of the paragraph...
> We have added a library to REXXLIB concatenation, and a REXX exec starting
> with I (it is indeed a REXX called IRRPWREX, programmed by Bruce Wells from
> IBM, but not officially supported by IBM). Everything is working fine. Do we
> have to understand the phrase just as a recommendation, in order to not
> interfere with REXX execs that IBM ships in SYS1.SAXREXEC?
> Thanks in advance for your help,
> Juan Mautalen
> 
> 
> 
> --
> 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: Does the term USE CASE apply to system software upgrades

[Gibney, Dave]

Is you have business or regulatory incentives to remain supported, then the 
case seems made.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Lizette Koehler
> Sent: Tuesday, June 27, 2023 1:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Does the term USE CASE apply to system software upgrades
> 
> [EXTERNAL EMAIL]
> 
> So if I am planning to update my tape management system, would I be able to
> create a use case?  The software is from a vendor.  The process is invoked
> whenever a tape mount request is made.
> 
> So I am not sure how w Use Case would apply
> 
> 
> Thank  you
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Kevin Mckenzie
> Sent: Tuesday, June 27, 2023 12:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Does the term USE CASE apply to system software upgrades
> 
> I would suggest choosing a function or two that you're planning on exploiting
> on the new release, and have those be the use cases.
> 
> --
> Kevin McKenzie
> 
> External Phone: 845-435-8282, Tie-line: 8-295-8282 z/OS Test Services - Test
> Architect, Provisioning z/OS Hardware/Software Interlock
> 
> 
> From: IBM Mainframe Discussion List  on
> behalf of Lizette Koehler 
> Date: Tuesday, June 27, 2023 at 3:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: [EXTERNAL] Does the term USE CASE apply to system software
> upgrades List -
> 
> 
> 
> I am being aske to create USE CASES for system software.  My brain is not able
> to coordinate USE CASE with system software updates
> 
> 
> 
> It seems the phrase USE CASE applies more to SYSTEM Software development
> than a System Software Upgrade
> 
> 
> 
> For Example, If I am upgrading from z/OS V2.4 to V2.5 - I am asked to supply a
> use case.
> 
> 
> 
> 
> 
> Any guidance on how to do this?
> 
> 
> 
> 
> 
> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: [EXTERNAL] Re: z/OSMF

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bill Johnson
> Sent: Tuesday, June 27, 2023 7:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: z/OSMF
> 
> Why would anyone think IBM wants to sell a mainframe to everyone? Any
> more than Tesla wants to sell to people who buy 15-20k autos. Someone
> needing 20 MSUs would be a perfect candidate for outsourcing to someone
> who outsources mainframe capacity.
> 
Which is what we did. And shut the system down at the end of the 5 year contract
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Tuesday, June 27, 2023, 9:36 AM, Pommier, Rex
>  wrote:
> 
> If a company is using a 20 MSU system and is forced to buy a 200 MSU system
> because that's the smallest available, unless something drastic happens to
> hardware AND software pricing, the company isn't going to be looking for
> "what else can I put on this expensive and woefully underutilized machine",
> they're going to be looking at "where can I move my 20 MSUs worth of
> processing to get rid of this expensive machine".
> 
> We're running a 2-way, 316 MSU machine and my business customers would
> squawk loudly if I had to move our workload to a 4 way with no more
> horsepower.  We have several single-threaded processes that run that would
> be woefully impacted if the per-engine thruput was halved.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Andrew Rowley
> Sent: Tuesday, June 27, 2023 5:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: z/OSMF
> 
> On 27/06/2023 5:40 pm, Gibney, Dave wrote:
> > 200 MSU was much more than we needed. Maybe 20 or so at our peaks.
> And the z/OS and ISV charges at 200 levels would have been intolerable.
> 
> That's why I keep qualifying it with ISVs would have to adjust their pricing.
> While the smallest system is 13 MSU they have no reason to do that, but if the
> smallest available system was 200 MSU I think they would be forced to adjust.
> 
> If you are using 100% of a 20 MSU system, z/OS is just an expensive system
> that can't do much more than run the stuff still around from the 90s.
> 
> If you are using 20 MSU of a 200 MSU system, it's an expensive system hugely
> underutilized, and maybe people start asking what work can be moved there,
> how to make better use of the data it contains etc?
> 
> --
> Andrew Rowley
> Black Hill Software
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@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 intended recipient, you are hereby notified that any 
> disclosure,
> distribution, copying, or any action taken or action omitted in reliance on 
> it, is
> strictly prohibited and may be unlawful. If you have received this
> communication in error, please notify us immediately by replying to this
> message and destroy the material in its entirety, whether in electronic or 
> hard
> copy format. Thank you.
> 
> 
> --
> 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: z/OSMF

[Gibney, Dave]

200 MSU was much more than we needed. Maybe 20 or so at our peaks. And the z/OS 
and ISV charges at 200 levels would have been intolerable.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Timothy Sipples
> Sent: Monday, June 26, 2023 10:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OSMF
> 
> [EXTERNAL EMAIL]
> 
> Andrew Rowley wrote:
> >I've said it before but I'll say it again - to avoid embarrassment
> >alongside 5 year old laptops or perhaps even a Raspberry Pi, IBM needs
> >to figure out how to bring the smallest z/OS systems up to a modern
> >configuration - I would suggest minimum 4 processors and 200 MSU.
> 
> IBM doesn't require anyone to order/configure less than 200 MSUs (PCIs) of
> general purpose processor capacity. If you want to order a configuration like
> that go for it!
> 
> Bearing in mind that VSEn is important and also exists, and IBM really ought 
> to
> be building machines that also cater to VSEn customers, here's the current
> minimum orderable machine configuration (latest model) for z/OS and VSEn:
> 
> * IBM z16 A02 (or AGZ for rack mount)
> * Capacity Model A01
> * Base CP capacity: 105 PCIs (13 MSUs)
> * z/OS System Recovery Boosted capacity (standard/no additional charge):
> 1,982 PCIs
> * 64GB of usable memory (plus HSA)
> 
> Add just 1 zIIP and you get ~1,900 PCIs of full-time zIIP capacity with 2
> processor threads (SMT2). You can add as many zIIPs as you wish up to the
> physical capacity of the machine.
> 
> Capacity Model A01 continues to be zELC eligible on the full capacity. Even
> though it has 105 PCIs (plus System Recovery Boost, plus more and far better
> on chip accelerators, plus optional zIIPs) it still qualifies for the same 
> software
> licensing tier that the ~26 PCIs IBM z890 Model 110 did 19 years ago.
> 
> I don't see any problem here. If 105 PCIs/13 MSUs (plus a zIIP I suggest) is 
> all
> you need for your z/OS computing, well OK then! That model is available, and
> (in most countries) you can get a nifty rack mounted form factor if you'd 
> like. If
> you need more, OK, that's available too.
> 
> Here's the recent history of minimum orderable/configurable CP capacity (all
> Capacity Models A01):
> 
> IBM z16 A02/AGZ: 105 PCIs*
> IBM z15 T02: 98 PCIs**
> IBM z14 ZR1: 88 PCIs
> IBM z13s: 80 PCIs
> IBM zBC12: 50 PCIs
> IBM z114: 26 PCIs
> 
> * System Recovery Boost capacity: 1,982 PCIs
> ** System Recovery Boost capacity: 1,761 PCIs
> 
> The z114 was announced in 2011 and the z16 A02/AGZ in 2023. Over that
> period IBM increased the minimum orderable CP capacity by ~12.4% per year
> (compounded), plus SRB.
> 
> -
> Timothy Sipples
> Senior Architect
> Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/LinuxONE,
> Asia-Pacific sipp...@sg.ibm.com
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: GRS setup for MONOPLEX to SYSPLEX

[Gibney, Dave]

Even PDSE can be safely shared. If updates only occur from one LPAR and 
read-only everywhere else. And, said updates may not be reflected immediately 
(or until next IPL) in the other read-only LPARs

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Monday, June 19, 2023 1:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GRS setup for MONOPLEX to SYSPLEX

Yes, PDSE do require SYSPLEX. Not GRS-plex, not CA-MIM (or MII), but SYSPLEX.
Reason: PDSE use sysplex communication, not GRS facilities.

Regarding to the topic: in order to share datasets you need ...nothing.
No parallel sysplex
No base sysplex
Not even GRSplex
No SMSplex
Simply nothing except DASD available from several systems.
Of course, the more mentioned facilities you have the better sharing is.
And yes, in order to share PDSEs (properly) you still have sysplex.
However you can share ICF BCSes (catalogs), VSAM, PS, PDS, etc.
Note: there are various flavours of sharing. Shared DASD as a data transport 
method, shared PDSes with jobs, REXX tools, etc. - it can be shared easily, 
because it is not heavily used. Batch datasets - assuming proper batch windows 
it is also can be shared easily.
For frequent sharing it is good to think about ICF ECS or RLS, etc.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 19.06.2023 o 17:03, Michael Babcock pisze:
> Beware of PDSEs.  I’m not 100% sure but I think the sandbox needs to 
> be in the plex to share them.  Updating a PDSE outside of the plex can 
> cause corruption.
>
> We have our sandbox in the plex just to avoid issues.
>
> On Mon, Jun 19, 2023 at 9:25 AM Paul Gorlinsky  wrote:
>
>> We have a sandbox system that references TSO user and ISV catalogs 
>> and datasets. The sandbox has a unique master catalog but shares 
>> virtually everything else.
>>
>> It does have access to the couple facility that the Sysplex is using ...
>> But it is not a member of the Sysplex.
>>
>> Is it possible for a monoplex z/OS system to share DASD, user cats, 
>> etc., with a SYSPLEX via GRS management and coupling facility?

--
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: Best practice for /etc and /var when upgrading

[Gibney, Dave]

On occasion, I tried the USS diff to evaluate my running /etc against a new 
serverpac version. And sometimes to compare the previous serverpac version with 
 the new one.

The utility of this exercise varied. 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of kekronbekron
> Sent: Tuesday, June 6, 2023 7:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Best practice for /etc and /var when upgrading
> 
> Integrating git is not something we as customers need to take on ourselves
> (for system upgrade workflows like this).
> It's something best given in a polished manner by IBM, as a part of zOSMF.
> And again, getting git ourself is another thing; so the suggestion on IBM
> establishing a dependency on git (ex: for zOSMF's use) and working backwards
> up to what is required.
> Of course, they can choose IBM zOS Change tracker, but it's not free, and is 
> yet
> another thing to learn.
> As long as there's a solution that hides the complexities and delivers the
> niceness in an interface, that'll be the way to go.
> 
> CA's Mainframe/Chorus Software Manager was ahead of its time.
> It or zOSMF needs to be far, far better today than CSM was years ago.
> 
> - KB
> 
> --- Original Message ---
> On Wednesday, June 7th, 2023 at 7:56 AM, Mark Zelden
>  wrote:
> 
> 
> > I don't know git so I can't really comment. I did google gif diff and see 
> > what
> you mean
> > now by a patch.
> >
> > For one, it seems like overkill. Two, I don't have git diff on z/OS so 
> > somehow
> I'd have to
> > get all my existing /etc (and /var) out there to compare what IBM would put
> out there
> > that matches the /etc (and /var) you get with a new OS?
> >
> > To go back to my parmlib example, why would I need to compare
> IPO1.PARMLIB sample
> > members to my running parmlib members from a system I'm about to
> upprade.
> > The LNKLST, APF, SVCs, etc are are locally customized for my running system.
> However, if
> > a new sample member was introduced that could be used if I implemented
> some new
> > feature, then it may be nice to have that sample in my running parmlib with
> the
> > "merge" process or "IEBCOPY, no replace" if you will. :)
> >
> > Not really a good comparison because in this scenario the new parmlib
> member would be put
> > in the SMP/E target IBM.PARMLIB or in SAMPLIB, but it is the best I could
> come up with
> > right now.
> >
> > BTW, A better approach to what the OP said happened in his upgrade (done
> by some
> > 3rd party) is to not touch it at all and just use your existing /etc and 
> > /var for
> your OS
> > upgrade or a copy of it with documented required changes from the upgrade
> workflow,
> > just like you would handle required parmlib changes.
> >
> > 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__http%3A%2F%2Fwww.mzelden.com%2Fmvsutil.ht
> ml__%3B!!JmPEgBY0HMszNaDT!pk5HXJWpgjdGm1ZKxIR0jXpfieiYVx5kXcbXxI
> juUxrbI5Q96ZNuTbnMoBubxwv4x6Hh483-
> uHawPpVeYyZWlAbrCog_VLTF%24=05%7C01%7CGIBNEY%40WSU.ED
> U%7C503456fbfcbe4365386708db67000c1a%7Cb52be471f7f147b4a8790
> c799bb53db5%7C0%7C0%7C638217022129812477%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C3000%7C%7C%7C=u1zF6wTztHDEhj1jeBW4YCupjk
> 1DpKQjwtgLZgrRxFI%3D=0
> >
> >
> > On Wed, 7 Jun 2023 01:53:40 +, kekronbekron
> kekronbek...@protonmail.com wrote:
> >
> > > Consider, for example, you upgrade from Ubuntu 20.04 to 22.04, and
> have updated the sudoers file.
> > > When upgrading, you get a prompt showing a diff between the new
> version and your customized version.
> > >
> > > And quoting a bit from your reply...
> > >
> > > > compare the distributed /etc to what you already have to see if possible
> other changes
> > > > may be desired.
> > >
> > > "compare the..."
> > >
> > > Normal diff, git diff...
> > >
> > > /untouched/etc/
> > > /custom/etc
> > >
> > > (git) diff against both to see what we customized.
> > > create a patch
> > >
> > > /new-untouched/etc/
> > > /new-custom/etc/
> > >
> > > Here, I'm saying /new-custom/etc/ can be created by doing a git apply of
> the patch from earlier.
> > >
> > > I mean... creating patches is quite common to keep just the delta, on a
> version-controlled repository.
> > >
> > > If it still doesn't make sense, it would be good to correct my
> understanding... without being pointed to the git website :)
> > >
> > > - KB
> > >
> > > --- Original Message ---
> > > On Tuesday, June 6th, 2023 at 9:29 PM, Mark Zelden
> m...@mzelden.com wrote:
> > >
> > > > On Tue, 6 Jun 2023 03:15:46 +, kekronbekron
> kekronbek...@protonmail.com wrote:
> > > >
> > > > > I do wonder... with git now available, and this being normal USS, 
> > > > > maybe
> zOSMF can start formally 

Re: Best practice for /etc and /var when upgrading

[Gibney, Dave]

No

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Pew, Curtis G
> Sent: Monday, June 5, 2023 11:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Best practice for /etc and /var when upgrading
> 
> [EXTERNAL EMAIL]
> 
> How do people handle /SYSTEM/etc and /SYSTEM/var when upgrading z/OS?
> In the past we’ve had these filesystems on an auxiliary volume, so that they
> remained the same during any upgrades unless we deliberately changed
> something. For our last upgrade (this past weekend) our management
> outsourced the upgrade to a 3rd party service provider, and the sysprog doing
> it configured completely new filesystems for these that were the generic IBM-
> provided versions, without any of our customizations. He claims this is a best
> practice. What say ye?
> 
> 
> --
> Curtis Pew
> ITS Campus Solutions
> curtis@austin.utexas.edu
> 
> 
> 
> 
> --
> 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: Are Banks Breaking Up With Mainframes? | Forbes

[Gibney, Dave]

Maybe my smiley should have been a sad face ! :(

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of zMan
> Sent: Saturday, May 20, 2023 4:04 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Are Banks Breaking Up With Mainframes? | Forbes
> 
> 
> P.S. Sorry, Dave, zOSMF doesn't count. It's a tool. Nobody is installing a
> mainframe so they can run it. We don't buy computers to run tools or
> operating systems: we buy them to run applications. Big difference.
> 


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

Re: Are Banks Breaking Up With Mainframes? | Forbes

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of zMan
> Sent: Saturday, May 20, 2023 10:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Are Banks Breaking Up With Mainframes? | Forbes
> All valid points but not addressing:
> When was the last time a new mainframe customer joined this list?
> Why are the parking lot and floor in POK empty all the time?
> And when was the last time you heard about a new, strategic mainframe
> application? (Hint: Not even within IBM.)

zOSMF :)  ?

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

Re: What is BPXAS and how do I make them stop piling up?

[Gibney, Dave]

Actually, you can have a 
Job card in the PROC in PROCLIB but it's not as flexible as using IEFJOBS. 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Ed Jaffe
> Sent: Monday, April 10, 2023 6:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What is BPXAS and how do I make them stop piling up?
> 
> [EXTERNAL EMAIL]
> 
> On 4/10/2023 4:58 PM, Charles Mills wrote:
> > Why would I want to do that? How would that solve my problem?
> 
> If you wish to specify a job card for a started task, you need IEFJOBs.
> Simple as that.
> 
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.phoenixsoftware.com%2F_
> _%3B!!JmPEgBY0HMszNaDT!uVXUTEVqFELxS18EuI8cEYf9z2bCUEvilFx2cDwG
> _24-
> _NGPkMr9H77Y61maDYF63bpojmZGHHbbiec_PEAYZQ%24=05%7C01%
> 7CGIBNEY%40WSU.EDU%7C9ceaf63920134b935b4108db3a2b747f%7Cb52be4
> 71f7f147b4a8790c799bb53db5%7C0%7C0%7C638167730530755081%7CUnkno
> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=VHHoJeVYOu06ewsR
> Rxbuvej%2Fbk2In7OkL947ORBtrTw%3D=0
> 
> 
> 
> This e-mail message, including any attachments, appended messages and
> the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to
> be
> free of any virus or other defect that might affect any computer system into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
> 
> --
> 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: Just PDSE

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Friday, April 7, 2023 9:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Just PDSE
> 
> On Fri, 7 Apr 2023 16:17:04 +, Gibney, Dave wrote:
> 
> >The issue with this has always been and still is the fact that you cannot
> safely share PDES without SYSPLEX (perhaps not full SYSPLEX) ...
> >
> Do program objects in a z/FS directory satisfy (some) requirements for PDSE?


Maybe, but you still cant share without SYSPLEX

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

Just PDSE

[Gibney, Dave]

The issue with this has always been and still is the fact that you cannot 
safely share PDES without SYSPLEX (perhaps not full SYSPLEX) but still more 
than our small couple LPAR shop needed, And since our development to production 
path was from Development LPAR to Production LPAR via libraries on a shared 
disk, somewhat of a non-starter.

We got burnt a long time ago with an ISV that distributed their parmlib in a 
PDSE, which we unknowingly at the time shared.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Seymour J Metz
> Sent: Friday, April 7, 2023 5:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LE runtime

> I would be tempted to just switch to PDSE and be done with it. Of course,
> that doesn't help with the C++ issue, but it's still one less thing to worry
> about.
> 

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

Re: JCL EXEC PARM= default?

[Gibney, Dave]

I agree that it's a fullword of zeros. But, this demonstration is not JCL

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Peter Sylvester
> Sent: Wednesday, April 5, 2023 10:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL EXEC PARM= default?
> 
> [EXTERNAL EMAIL]
> 
> test 'sys1.linklib(iefbr14)'
> TEST
> l 1R
>   1R  0002AF60
> TEST
> l 1r%
> 0002AF60.  8002AF64
> TEST
> l 1r%%
> 0002AF64.  
> TEST
> 
> 
> 
> 
> On 05/04/2023 18:07, Seymour J Metz wrote:
> >   DCH'0'
> >
> > ____
> > From: IBM Mainframe Discussion List  on
> behalf of Gibney, Dave <03b5261cfd78-dmarc-
> requ...@listserv.ua.edu>
> > Sent: Wednesday, April 5, 2023 11:52 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: JCL EXEC PARM= default?
> >
> > So, R1 in
> > //R EXEC PGM=IEFBR14
> > points to ???
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of Paul Gilmartin
> >> Sent: Wednesday, April 5, 2023 8:47 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: JCL EXEC PARM= default?
> >>
> >> [EXTERNAL EMAIL]
> >>
> >> On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote:
> >>
> >>> For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the
> >> default is an empty string.
> >>>
> >> That was my guess.  Where did you find that documented?
> >>
> >>> 
> >>> From:  Paul Gilmartin
> >>> Sent: Wednesday, April 5, 2023 11:17 AM
> >>>
> >>> What's the default value for the optional PARM= on the JCL EXEC
> >> statement?
> >>> It doesn't appear in the JCL Ref.  (haven't checked the cited "Assembler
> >> Services Guide.")
> >>
> >> --
> >> gil
> >>
> >> --
> >> 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: JCL EXEC PARM= default?

[Gibney, Dave]

So, R1 in 
//R EXEC PGM=IEFBR14 
points to ???

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, April 5, 2023 8:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL EXEC PARM= default?
> 
> [EXTERNAL EMAIL]
> 
> On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote:
> 
> >For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the
> default is an empty string.
> >
> >
> That was my guess.  Where did you find that documented?
> 
> >
> >From:  Paul Gilmartin
> >Sent: Wednesday, April 5, 2023 11:17 AM
> >
> >What's the default value for the optional PARM= on the JCL EXEC
> statement?
> >It doesn't appear in the JCL Ref.  (haven't checked the cited "Assembler
> Services Guide.")
> 
> --
> gil
> 
> --
> 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

CASE constructs

[Gibney, Dave]

In the CASE of Software AG's language, Natural, it is WHEN ANY and WHEN NONE. 
ANY would execute after the code of the successful WHEN condition. Once in a 
while, I would wish it would execute before rather than after.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bob Bridges
> Sent: Thursday, March 30, 2023 1:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value]
> 
> [EXTERNAL EMAIL]
> 
> Ok, I'll bite:  What's the difference between the ANY and OTHER conditions?
> 
> Oh, wait, cool!  Does the ANY condition execute even any of the above
> conditions evaluate as true?
> 
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> 
> /* It is a serious thing to live in a society of possible gods and goddesses, 
> to
> remember that the dullest and most uninteresting person you talk to may
> one day be a creature which, if you saw it now, you would be strongly
> tempted to worship, or else a horror and a corruption such as you now meet,
> if at all, only in a nightmare.  All day long we are, in some degree, helping
> each other to one of these destinations.  -C S Lewis, quoted in "In His Image"
> by Dr Paul Brand and Phillip Yancey */
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Wayne Bickerdike
> Sent: Wednesday, March 29, 2023 23:40
> 
> I also like CA-IDEAL. A little bit PL/I like with a nice SELECT statement:
> 
>   SELECT TRANS_CODE
> WHEN 'A'
>   DO ADD_RECORD_PROC
> WHEN 'D'
>   DO DEL_RECORD_PROC
> WHEN 'P'
>   DO PURCHASE_PROC
> WHEN 'R'
>   DO RECEIPT_PROC
> WHEN ANY
>   DO LOG_TRANS
> WHEN OTHER
>   DO INVALID_CODE
> ENDSEL
> 
> --
> 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: DLM Tape reading

[Gibney, Dave]

RESTORE from it with PARM=NORUN

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jake Anderson
> Sent: Monday, March 20, 2023 9:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DLM Tape reading
> 
> [EXTERNAL EMAIL]
> 
> Mike
> 
> We ran a monthly volume level of backup to a tape dataset
> 
> So I just wanted the list of dataset that was copied or backed up to the
> tape dataset.
> 
> 
> 
> On Tue, Mar 21, 2023, 7:54 AM Michael Watkins <
> 032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > '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://urldefense.com/v3/__https://gcc02.safelinks.protection.outlook.co
> 

Re: Scheduling a job to run after a delay

[Gibney, Dave]

Sorry to double ply. One of the things I was waiting on was OMVS. BPXBATCH 
Sleep doesn't sleep if OMVS isn't there.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Sunday, March 19, 2023 7:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Scheduling a job to run after a delay
> 
> [EXTERNAL EMAIL]
> 
> On Mon, 20 Mar 2023 02:39:51 +, Gibney, Dave  wrote:
> 
> >A different approach is to add a additional step at or near the top that 
> >waits.
> I had a very short assembler program that called STIMER based on parm
> input.
> >
> Ah!  the old way.  Nowadays, BPXBATCH  sleep.
> 
> In those days, it was considered discourteous to bogart an initiator; thus
> "sleep" commands were rare.
> 
> --
> gil
> 
> --
> 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: Scheduling a job to run after a delay

[Gibney, Dave]

My primary use was to pause a few things at IPL so that needed services had a 
chance to start.

In this case, the OP seemed to have a system where holding an init wouldn't 
hurt much

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Sunday, March 19, 2023 7:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Scheduling a job to run after a delay
> 
> [EXTERNAL EMAIL]
> 
> On Mon, 20 Mar 2023 02:39:51 +, Gibney, Dave  wrote:
> 
> >A different approach is to add a additional step at or near the top that 
> >waits.
> I had a very short assembler program that called STIMER based on parm
> input.
> >
> Ah!  the old way.  Nowadays, BPXBATCH  sleep.
> 
> In those days, it was considered discourteous to bogart an initiator; thus
> "sleep" commands were rare.
> 
> --
> gil
> 
> --
> 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: Scheduling a job to run after a delay

[Gibney, Dave]

True

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jeremy Nicoll
> Sent: Sunday, March 19, 2023 7:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Scheduling a job to run after a delay
> 
> [EXTERNAL EMAIL]
> 
> On Mon, 20 Mar 2023, at 02:39, Gibney, Dave wrote:
> > A different approach is to add a additional step at or near the top
> > that waits. I had a very short assembler program that called STIMER
> > based on parm input.
> 
> Does that not mean holding up an initiator for an hour, doing nothing?
> 
> It's not a technique you'd want everyone to start using!
> 
> --
> Jeremy Nicoll - my opinions are my own.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Scheduling a job to run after a delay

[Gibney, Dave]

A different approach is to add a additional step at or near the top that waits. 
I had a very short assembler program that called STIMER based on parm input.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Charles Mills
> Sent: Sunday, March 19, 2023 5:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Scheduling a job to run after a delay
> 
> I am not a sysprog, but there is a system where I play sysprog. It is a very
> specialized z/OS LPAR and has no third-party scheduling software (and I don't
> think I really want to get into supporting a CBT freebie).
> 
> I do some very rudimentary scheduling -- running a couple of jobs once a day
> each -- using
> 
> $TAMTIC,T=08.00,I=86400,'$VS,''S RDR,DSN=etc.
> 
> For one of those jobs, if and only if it fails (RC > 0) then I would like to
> schedule it to run again in one hour.
> 
> I can // IF ( stepname.RC > 0 ) THEN submit the job via INTRDR, but if I do 
> that
> it will run right away. Can I somehow conditionally submit a JES2 command to
> run the job in an hour? What would that JES2 command be?
> 
> (Yes, I foresee that if the job failed repeatedly today and also again
> tomorrow I would have two submission loops running. I can deal with that.)
> 
> JES2, z/OS V2R3
> 
> Thanks!
> Charles
> 
> --
> 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: location of JCL for started task

[Gibney, Dave]

The job cards from MSTJCL IEFJOBS Dd is newer that started tasks. Sounds to me 
like your STC is started by
S procname and any JOB card is system generated. If started before JESx, then 
it's from the proclib concatenation in MSTJCL
If after, and your JES proclib concatenation is different, then maybe from 
there. 

You state you can find the proc. That's probably where it is being started from

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bill Giannelli
> Sent: Saturday, March 18, 2023 10:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: location of JCL for started task
> 
> [EXTERNAL EMAIL]
> 
> we have a PDS for job cards for started tasks, which reference our system
> proclib.
> I have a started task that is executing, yet I can not find the actual JCL
> (Jobcard, etc). I can find the proc.
> How can I find where the JCL is being read from?
> thanks
> Bill
> 
> --
> 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: WLM Couple dataset?

[Gibney, Dave]

Do they give a reason? Or explanation?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bill Giannelli
> Sent: Thursday, March 9, 2023 1:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: WLM Couple dataset?
> > 
> we are being told by our managed service vendor they have to manually
> update the DR WLM Couple datasets. that they cant be mirrored..
> 
> --
> 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 Beta Clients

[Gibney, Dave]

We had TCP/IP connectivity with OS/390 2.10. I think we were still using a 
channel attached box from Bustech?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of rpinion865
> Sent: Wednesday, March 8, 2023 2:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Looking for Beta Clients
> 
> I know of a client that does not have a TCP/IP stack, and won't consider one
> (OS/390 2.10, yeah you read that right), that needs something more reliable
> than IND$FILE.  We have a need to transfer large binary datasets, and
> IND$FILE is way too slow, and it often dies in the middle of a large transfer.
> 
> I remember LU 6.2 transfer programs.  But, I couldn't find anything
> still available.
> 
> Sorry for tagging on to another thread.
> 
> 
> 
> 
> Sent with Proton Mail secure email.
> 
> --- Original Message ---
> On Wednesday, March 8th, 2023 at 5:19 PM, Tom Brennan
>  wrote:
> 
> 
> > Looks interesting!
> >
> > Since you didn't mention things like SFTP/FTP/TSO/CICS as requirements,
> > and the doc mentioned port 443, can I assume the product requires a
> > started task listening on the mainframe side? Just asking because
> > that's probably the way I would do it in order to bypass all the hassles
> > of those other services.
> >
> > On 3/8/2023 1:36 PM, Tony Tancredi wrote:
> >
> > > Hi Everyone,
> > >
> > > I apologize if this isn't within group protocol, but I need help.
> > >
> > > I have created a TLS enabled, TCP/IP file transfer program that performs
> transfers 156 times faster than IND$FILE. It supports files, PDS, VSAM,
> SYSOUT, can submit jobs, print to mainframe printers, and be automated. As
> a beta client, I'm offering 1 free year if you choose to keep it. All I ask 
> for is
> some of your time and feedback. I will provide constant support during your
> effort.
> > >
> > > The requirements are:
> > > - z/OS 2.3 and above
> > > - TCP/IP enabled
> > > - AT-TLS (instructions to setup are in our documentation)
> > > - Windows 10 or above for the client
> > >
> > > Please visit
> https://urldefense.com/v3/__https://entegriasystems.com__;!!JmPEgBY0H
> MszNaDT!rE3zsPHgH--
> 6SawFWiebGU0gRUM64VciqSIARhRbgVw70nFE6KZbcUFs9VdMxdAJFte_KH
> wZPGLv2vwRCWbNRGx6pu8F9Bsr$  and
> https://urldefense.com/v3/__https://fastssr.net__;!!JmPEgBY0HMszNaDT!r
> E3zsPHgH--
> 6SawFWiebGU0gRUM64VciqSIARhRbgVw70nFE6KZbcUFs9VdMxdAJFte_KH
> wZPGLv2vwRCWbNRGx6pstXq1JA$  (click the Documentation link on the left
> side) to view details of FastSSR.
> > >
> > > I greatly appreciate your consideration.
> > >
> > > Thanks,
> > > Tony Tancredi
> > > 856-316-0017
> > >
> > > --
> > > 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: NTS

[Gibney, Dave]

Extend/Make it multi-volume. Or MOD54

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Steve Beaver
> Sent: Tuesday, March 7, 2023 10:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: NTS
> 
> [EXTERNAL EMAIL]
> 
> I have run into a problem that I have never seen.  My NTS is a complete
> 
> MOD27.  But I'm told EDC5133I No space left on device.
> 
> 
> 
> Any easy ideas?
> 
> 
> 
> 
> 
> GIM66400ITHE TRANSFER IS COMPLETE FOR FILE
> 
>  /u/smpe/smpnts/U02418528/GIMPAF.XML.
> 
> GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVGET -
> java.io.IOException:
> 
>  EDC5133I No space left on device.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> /*+
> */
> 
> /*SMPe - SERVICE   */
> 
> /*+
> */
> 
> MOUNT FILESYSTEM('SMPE.OMVS.SMPE.NTS.ZFS')
> 
>   MOUNTPOINT('/u/smpnts')
> 
>   TYPE(ZFS) MODE(RDWR) PARM('AGGRGROW')
> 
> 
> 
> GIM20501ISET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE
> WAS 00.
> 
> 
> 
> 
> 
>   RECEIVE
> 0069
> 
> FROMNETWORK(
> 0070
> 
>   SERVER(SERVINFO)
> 0071
> 
>  /*   TRANSFERONLY   <=== NOTE 5 */
> 0072
> 
>   CLIENT(CLNTINFO)
> 0073
> 
>   )
> 0074
> 
>.
> 0075
> 
> 
> 
> GIM66400ITHE TRANSFER IS COMPLETE FOR FILE
> 
>  /u/smpe/smpnts/U02418528/GIMPAF.XML.
> 
> GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVGET -
> java.io.IOException:
> 
>  EDC5133I No space left on device.
> 
> GIM47601IPACKAGE U02418528 WAS PARTIALLY STAGED TO THE SMPNTS.
> 
> GIM20501IRECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE
> WAS 12.
> 
> 
> 
> 
> --
> 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: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?

[Gibney, Dave]

Does an OOS z13 support ICF thin provisioning with nterrupts?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Mike Schwab
> Sent: Monday, March 6, 2023 1:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Running a Coupling Facility using a CP for a test Parallel 
> Sysplex 0
> anyh gotcha's?
> 
> And this was long before Thin ICF provisioning on a CP with interrupts.
> 
> On Mon, Mar 6, 2023 at 3:07 PM Attila Fogarasi  wrote:
> >
> > Perhaps your outsourcer will accept recommendations by IBM in an official
> > apar, see
> https://urldefense.com/v3/__https://www.ibm.com/support/pages/apar/II
> 09294__;!!JmPEgBY0HMszNaDT!pc-N5jQe_vQoNsN9-04ykQN3SVPA3--
> zfrRMvdLg48EaghVAdve13YxtLv7URiG7JmKVX-gL1XSkd75g6Li7Hg$
> > This says in part "If you can accept slower response times or occasional
> > slower
> >
> >   response times and the load is not too great, CFs in shared
> >   LPs may be a viable alternative to running CFs with DEDICATED
> >   CP resources."
> >
> >
> > On Tue, Mar 7, 2023 at 12:04 AM Allan Staller <
> > 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Classification: Confidential
> > >
> > > The "spare" ICF engine on the "A" box could be shared between *your*
> > > test/production sysplexes.
> > >
> > > HTH
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List 
> On Behalf
> > > Of Laurence Chiu
> > > Sent: Friday, March 3, 2023 9:34 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Running a Coupling Facility using a CP for a test Parallel
> > > Sysplex 0 anyh gotcha's?
> > >
> > > [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.]
> > >
> > > The situation.
> > >
> > > We share a couple of Z13's with another (larger client). Z13 B is where we
> > > run our development LPARs and Z13 A is production.
> > >
> > > For critical business reasons an online application on our production LPAR
> > > needs to be highly available and that means in a parallel sysplex.  But 
> > > our
> > > outsourcer has told us it cannot be done for the following reasons
> because
> > > there are no spare ICF engines on the host B - all are being used by other
> > > CF instances, either to support production Sysplexes or development
> ones
> > > (not ours).
> > >
> > > Host A does potentially have a spare ICF engine we could use to support a
> > > production parallel Sysplex but good practice does recommend you
> create a
> > > test one first of course.
> > >
> > > I then asked the question, if host A has a spare ICF engine, can't it be
> > > used to support a CF to be used by the test Sysplex on B. I was advised
> > > this was not possible since there are no spare connections between host
> A
> > > and Host B (Infiniband possibly) so the Sysplex on B could not actually
> > > communicate with the CF on A.
> > >
> > > Our requirement for the Sysplex is primarily to be able to share a VSAM
> > > dataset which is hit every time a transaction comes in with a peak of
> about
> > > 99tps. So we would need VSAM RLS to share the dataset records
> between the
> > > two application instances. There is no DB2, CICS or IMS so I think the 
> > > only
> > > structures in the CF are those to support VSAM RLS, maybe some XCF
> > > structures and core systems.
> > >
> > > Knowing that we would only bring up the test sysplex to make sure
> > > transactions routed correctly across the two LPARs and most of the time
> we
> > > would have one member of the Sysplex off, I suggested that the test CF
> > > could be built using a CP.  To this suggestion I received the following
> > > (anti) advice
> > > - there would be MSU costs (we don't care since we think the MIPS load
> on
> > > the CF would be low). Plus we would ask that the CF be defined with
> Dynamic
> > > Coupling Facility Dispatch and set DYNDISP=THIN. Since that CF is going to
> > > be idling most of the time, MSU consumption is not going to be a major
> cost.
> > > - it's strongly recommended not to do this by IBM. Yet when I read this
> > > document
> > >
> > >
> > >
> https://urldefense.com/v3/__https://apc01.safelinks.protection.outlook.co
> m/?url=https*3A*2F*2Fwww.ibm.com*2Fdownloads*2Fcas*2FJZB2E38Q
> ata=05*7C01*7Callan.staller*40HCL.COM*7C1962ff1c13d7410924a708db1c61
> 7020*7C189de737c93a4f5a8b686f4ca9941912*7C0*7C0*7C6381349770666599
> 42*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C=78DxD9grm
> MmrALQNItds2OaQ6Eyuv43mGVh5*2BoeqQnk*3D=0__;JSUlJSUlJ
> SUlJSUlJSUlJSUlJSUlJSU!!JmPEgBY0HMszNaDT!pc-N5jQe_vQoNsN9-
> 04ykQN3SVPA3--zfrRMvdLg48EaghVAdve13YxtLv7URiG7JmKVX-
> gL1XSkd74tramVcA$
> > > the option is discussed in great detail and the only negatives are the
> > > incurring of MSU costs and some performance degradation if both a z/OS
> and
> > > CF 

Re: zOSMF and zOWE for non-mainframers

[Gibney, Dave]

LIKE=a good representative existing library.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of David Crayford
> Sent: Monday, February 27, 2023 9:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: zOSMF and zOWE for non-mainframers
> 
> [EXTERNAL EMAIL]
> 
> On 28/2/23 13:41, Gibney, Dave wrote:
> > How many decades have we had System Determined Blocksize, and other
> artifacts of SMS. These details are surely not anything than new folks need to
> deal with at the outset.
> 
> If a young programmer came to you and asked "what is the best DCB for a
> C++ source data set?" what would you suggest?
> 
> 
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of David Crayford
> >> Sent: Monday, February 27, 2023 9:27 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: zOSMF and zOWE for non-mainframers
> >>
> >> On 27/2/23 06:46, Andrew Rowley wrote:
> >>> On 25/02/2023 8:03 am, Bob Bridges wrote:
> >>>> Oh, I was going to mention that surely allocating datasets, either in
> >>>> batch or TSO, has got to seem like one of the dumbest and most
> >>>> incomprehensible things we do on the mainframe, to a foreigner.
> >>> Allocating datasets shouldn't be that hard to grasp. "Dataset" is
> >>> actually a pretty common term and generally implies a collection of
> >>> data with more structure than just a file.
> >>   From what I've seen while working with younger individuals, they tend
> >> to find the MVS file system quite perplexing. In order to navigate it,
> >> one must first grasp the archaic concept of CKD disk geometry, including
> >> blocks, cylinders, blocking factors, and record formats, among other
> >> things. And that's all before even introducing them to the intricacies
> >> of VTOCs, catalogs, interblock gaps, spanned record formats etc.
> >>
> >>> If people have worked with databases, presumably they have
> encountered
> >>> the concept of defining the schema.
> >>>
> >>> A dataset is simply a collections of records (similar to a database
> >>> table) where each record has a fixed length or limited variable length
> >>> and the total collection has a size limit. Any structure within the
> >>> records is up to the application. This is not an unusual construct.
> >>>
> >>> What is unusual is that z/OS uses such a structured format for almost
> >>> everything, not that it exists.
> >>>
> >> --
> >> 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: zOSMF and zOWE for non-mainframers

[Gibney, Dave]

How many decades have we had System Determined Blocksize, and other artifacts 
of SMS. These details are surely not anything than new folks need to deal with 
at the outset.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of David Crayford
> Sent: Monday, February 27, 2023 9:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: zOSMF and zOWE for non-mainframers
> 
> On 27/2/23 06:46, Andrew Rowley wrote:
> > On 25/02/2023 8:03 am, Bob Bridges wrote:
> >> Oh, I was going to mention that surely allocating datasets, either in
> >> batch or TSO, has got to seem like one of the dumbest and most
> >> incomprehensible things we do on the mainframe, to a foreigner.
> >
> > Allocating datasets shouldn't be that hard to grasp. "Dataset" is
> > actually a pretty common term and generally implies a collection of
> > data with more structure than just a file.
> 
>  From what I've seen while working with younger individuals, they tend
> to find the MVS file system quite perplexing. In order to navigate it,
> one must first grasp the archaic concept of CKD disk geometry, including
> blocks, cylinders, blocking factors, and record formats, among other
> things. And that's all before even introducing them to the intricacies
> of VTOCs, catalogs, interblock gaps, spanned record formats etc.
> 
> >
> > If people have worked with databases, presumably they have encountered
> > the concept of defining the schema.
> >
> > A dataset is simply a collections of records (similar to a database
> > table) where each record has a fixed length or limited variable length
> > and the total collection has a size limit. Any structure within the
> > records is up to the application. This is not an unusual construct.
> >
> > What is unusual is that z/OS uses such a structured format for almost
> > everything, not that it exists.
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: [EXTERNAL] Re: SCRT and not operating LPAR

[Gibney, Dave]

If I remember correctly Z EOD doesn't stop the system, it just stops recording 
and flushes the records. Unless you follow with a QUIESCE (or deactivate), the 
system continues to idle along

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Radoslaw Skorupka
> Sent: Friday, February 24, 2023 4:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: SCRT and not operating LPAR
> 
> [EXTERNAL EMAIL]
> 
> Gentlemen,
> 
> First, thank you for the discussion. That also helps.
> 
> Ad rem:
> 1. The is no big reason to keep LPAR Activated, Not operating, except
> short time between activation and IPL or re-IPL, etc. And SCRT is IMHO
> not the most important reason for that. Good reasons were presented by
> Martin.
> 2. I asked mostly out of my curiosity. But it is not senseless at all,
> it is good to know *severity* of results of mistaken scenario. Not to
> say, the curiosity is good :-)
> 3. I did some tests.
> Test 1. I activated an LPAR and deactivated it few hours later. Result -
> the LPAR is not visible in SCRT report. No "required" statement for the
> LPAR. Same as for other deactivated LPARs.
> Test 2. I shut down the system, but the LPAR remained Activated. 8 hours
> later I IPLed another z/OS image in the LPAR. Result - SCRT report
> claims there is  8-hour hole in the SMF reporting.
> 
> I have some other ideas to test, but this is real customer production,
> SCRT report is real, so I come off it.
> 
> 
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> W dniu 23.02.2023 o 23:31, Pommier, Rex pisze:
> > Ignore my last question - you just answered it.
> >
> > Rex
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of Pommier, Rex
> > Sent: Thursday, February 23, 2023 4:30 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [EXTERNAL] Re: SCRT and not operating LPAR
> >
> > Hi Radoslaw,
> >
> > I'm not denying your experience.  You got me questioning my own so I had
> to go back and make sure it was working like I had expected it to.  :-)  I did
> also misspeak.  You are correct, it was an e-mail with the CSV sent as an
> attachment.  This was the mechanism IBM took away and they're in essence
> forcing us to submit the CSV manually thru the web site.  We (as I'm sure
> most every company submitting SCRT) had the e-mail completely automated
> (except when we had to insert comments) and then they took that away.
> >
> > Is there a reason you have these LPARs active but not IPLed?  Just curiosity
> and if I'm getting nosy tell me.  :-)  Wouldn't deactivating them stop SCRT
> from reporting on them?
> >
> > Rex
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of Radoslaw Skorupka
> > Sent: Thursday, February 23, 2023 4:21 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [EXTERNAL] Re: SCRT and not operating LPAR
> >
> > As I noted things may have changed. I really tried to do it, but it was
> > 10+ years ago. After that I did not come back to try it again and again.
> > BTW: I was very first user of SCRT in Poland, it was January 2006, AFAIR.
> >
> > Actually I don't understand the way you submit reports. In the past few
> ways were possible, one of them was webpage, another one was mail
> attachment. Then mail was closed.
> > LMS webpage analyze CSV content and (see above) reject amended file. I
> cannot say for today, because I did not submit SCRT report personally for
> several years.
> > And in fact I don't care - for me there is no difference to put some
> explanation in the file or on the webpage directly. I can imagine the
> checksum now does cover only relevant fields, not whole file. It would make
> sense.
> >
> > My current problem is Activated but not IPLed LPAR. I had discussion with
> my coworker and that's why I'm asking about it.
> >
> > Regards
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> >
> >
> > W dniu 23.02.2023 o 23:09, Pommier, Rex pisze:
> >> With all due respect, I have to disagree.  Granted I haven't had to
> >> make any explanations to LMS since IBM took away the FTP transmission
> >> and required us to go through the web site for transmissions, but
> >> before that I would add my comments to the mainframe version of the
> >> CSV and then directly FTP it from the mainframe to LMS, all without
> >> any issues.  I have the prior 12 months' worth of SCRT reports on the
> >> mainframe and I found where I had commented in at least 3 of these
> >> reports and didn't have IBM reject any of them.  Unless, of course,
> >> IBM was silently rejecting them
> >>
> >> Rex
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of Radoslaw Skorupka
> >> Sent: Thursday, February 23, 2023 3:58 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: [EXTERNAL] Re: SCRT and not operating LPAR
> >>
> >> You cannot update CSV file. There is a checksum at the bottom. Any
> update, including such comment causes the file 

Re: How long for an experiened z/OS sysprog to come up to speed on a new environment?

[Gibney, Dave]

With all due respect, and I do have great respect for you Brian, you do have a 
great deal of experience in this kind of work. So, a day or so after you get 
access (and I assume you've acquired a number of tools) it is entirely possible 
that you would be up to speed.
I do agree with you that the first hurdle would how rapidly the new guy gets 
and what level of access they are allowed.

I think there are several other variables as to how rapidly a given newly hired 
yet experienced sysprog learns the ropes at a new site. From what I have 
observed here on the list, sites vary quite a bit. 

Personally, I would need a little longer. But, I've only worked at the one 
site, even if it was for 40 years. The thing is, I've forgotten more than I 
know at any given time. Almost always had to move to the next issue before any 
true expertise settled in. It was usually easier the next time a task or need 
rolled around, but since it was my site, I knew where I’d last left the tools 
and bread crumbs

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Brian Westerman
> Sent: Thursday, February 16, 2023 9:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How long for an experiened z/OS sysprog to come up to speed
> on a new environment?
> 
> [EXTERNAL EMAIL]
> 
> I completely agree with one day.  You should be productive by then, as for
> learning all of the sites naming conventions, procedures and standards, you
> would pick them up as you go.  I have found that by the end of the first
> week, I typically know more about how things are "supposed" to be
> managed than the people that are currently employed there. :)
> 
> That assumes that everyone knows you are coming in and is prepared for
> you to be there.  Things like getting an ID and a place to sit and 
> instructions
> for VPN's and connections.  Those things typically should be done before
> your first day at the site, but unfortunately it rarely happens that way.  So 
> I
> should say that it's about a day after you can actually log onto the system.
> 
> Brian
> 
> --
> 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: how to read SMF data?

[Gibney, Dave]

MXG is a source available product. And, just about all the documentation in 
that source lib. It's a bit massive and perhaps overwhelming. SRCHFOR helps

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bill Giannelli
> Sent: Tuesday, February 14, 2023 7:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: how to read SMF data?
> 
> [EXTERNAL EMAIL]
> 
> thank you for your responses!
> I just found out we have MXG!
> doing google searches.
> might you point me to a link and or manual on how to use MXG?
> thanks
> Bill
> 
> --
> 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: JCL Procedure help

[Gibney, Dave]

Add a new first step. Which reads the SYSIN and passes it to the function (now 
3rd) step

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gadi Ben-Avi
> Sent: Wednesday, February 8, 2023 4:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JCL Procedure help
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> I was asked to modify a procedure.
> Currently, the procedure has one step.
> This step receives input from SYSIN DD *
> 
> I was asked to add a step that would check that the JOB is running on the
> correct LPAR.
> I wrote a small REXX program that check the LPAR, and returns condition code
> 8 if it's not running on the correct LPAR.
> I then added an if statement that will run the original step if the previous
> condition code is 0, and if not will issue a message.
> 
> The problem is that now the SYSIN DD is allocated to the first step.
> I know I can code STEP.SYSIN to associate the SYSIN with correct step, but was
> wondering if there a way to code the procedure in a way so that I won't
> require changing the way the procedure is used.
> 
> We are running z/OS v2.3
> 
> Gadi
> 
> 
> --
> 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: The Local death of DB2 z/OS --- what is the best way to preserve the data once the mainframe is gone

[Gibney, Dave]

I recently shutdown our mainframe. We used various means to preserve the data. 
Most was exported using a SAG tool that we already had. Connx.
Don't forget your source code : ) We ftped to Windows files. For reference only
As a final, break glass in an emergency, we shipped some files to Windows via 
binary ftp. There are tools that can read EBCDIC : )

Our people even created OBIEE reports to access the exported data that 
resembled the previous green query screens.


> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tom Longfellow
> Sent: Wednesday, February 8, 2023 11:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: The Local death of DB2 z/OS --- what is the best way to preserve
> the data once the mainframe is gone
> 
> [EXTERNAL EMAIL]
> 
> Thanks, but we are familiar enough with those tools and should not need a
> sample.
> 
> I am starting to believe that no matter how I create the "Flat File Swamp"  it
> will no longer be able to serve its original purpose ever again.
> 
> --
> 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: The Local death of DB2 z/OS --- what is the best way to preserve the data once the mainframe is gone

[Gibney, Dave]

Print it and be done :)

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tom Longfellow
> Sent: Wednesday, February 8, 2023 11:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: The Local death of DB2 z/OS --- what is the best way to preserve
> the data once the mainframe is gone
> 
> [EXTERNAL EMAIL]
> 
> Not dumb at all.I am between a rock and a hard place.
> 
> NO resources on any servers anywhere will be committed to the preservation
> of data.
> The Mainframe will be powered off 6 months after the last primary application
> has left the building.
> 
> Usability of the exported data is not managements concern.  User requests are
> not important.   ALL DATA MUST GO
> 
> --
> 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

[Gibney, Dave]

It's been a long time since I keypunched. Never had to for work. 
I was going to write S370, but as I seemingly often do, I held the shift and 
did S#&)

Digressing from my statement that COBOL was not hard to learn. And as has been 
also stated, modern Cobol is capable of many things that used to be tricky to 
do, but were possible even then. (1980s)

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Monday, February 06, 2023 1:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: I want to cry
> 
> [EXTERNAL EMAIL]
> 
> On Mon, 6 Feb 2023 21:11:34 +, Gibney, Dave  wrote:
> 
> >370 assembler . Sticky shift finger
> >
> Keypunch?
> 
> --
> gil
> 
> --
> 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

[Gibney, Dave]

370 assembler . Sticky shift finger

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gibney, Dave
> Sent: Monday, February 06, 2023 1:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: I want to cry
> 
> [EXTERNAL EMAIL]
> 
> COBOL was almost trivial to learn, after a semester of #&) Assemble out of
> Struble. But, I guess by then it was at least my 4th or 5th language.
> 
> I came up from application programming, then supporting a few (CA)
> products to sysprog about the time of ESA
> 
> --
> 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

[Gibney, Dave]

COBOL was almost trivial to learn, after a semester of #&) Assemble out of 
Struble. But, I guess by then it was at least my 4th or 5th language.

I came up from application programming, then supporting a few (CA) products to 
sysprog about the time of ESA

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

Re: Virtual tape usage

[Gibney, Dave]

Tape management system?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jake Anderson
> Sent: Sunday, February 05, 2023 7:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Virtual tape usage
> 
> [EXTERNAL EMAIL]
> 
> Hello
> 
> We are using DELL DLM8500. Is it possible to know from the z/OS perspective
> on how many tapes being consumed on a monthly basis ? Is there any report
> within SMF or any facility within DLM can help me to know usage of virtual
> tapes ?
> 
> Regards
> 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

Re: I want to cry

[Gibney, Dave]

Part of the tears could be that a SLIP trap is not a terribly useful answer to 
S047 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Retired Mainframer
> Sent: Thursday, February 02, 2023 8:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: I want to cry
> 
> [EXTERNAL EMAIL]
> 
> Look in the System Codes manual.  047 means a program that is not running
> "authorized" requested a service that only one that is running "authorized"
> can access.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of
> Hank Oerlemans
> Sent: Thursday, February 2, 2023 7:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: I want to cry
> 
> Customer : Could you please have a look and help us to fix the issue .
> Customer log :  IEA992I SLIP TRAP ID=S047 MATCHED.
> 
> ME :
> 1. Hire a sysprog
> 2. RTFM
> 3. Google Play and hit update
> 4. Apple store and hit update
> 5. Check calendar and mortgage and see when I can retire
> 6. Tears welling up realising I can't actually say any of 1-4.
> 
> --
> 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: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

[Gibney, Dave]

1st guess would be that the named BMC module isn't 2.5 ready and shouldn't be 
located where SDSF  can try to use it.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Ross Vaughn
> Sent: Thursday, February 02, 2023 8:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Missing Values For The 'SDSF DA' Panels - z/OS 2.5
> 
> [EXTERNAL EMAIL]
> 
> We are currently in the process of rolling out z/OS 2.5 and have hit an issue
> on a test LPAR that is not displaying any information in the SDSF DA panels.
> There are no messages in the syslog out of the IPL that would lead us in a
> certain direction.  We think we may have an issue with CMF but can’t
> confirm.  We are occasionally seeing error messages out of SDSFAUX as well.
> 
> It looks like beginning with z/OS 2.4 the ’SDSF DA’ information is obtained by
> the SDSFAUX address space calling the BMC AMI Ops Monitor for CMF.  We
> have verified we have the CX10GVID module in our linklist library that CMF
> uses to obtain the SDSF DA values.
> We have a ticket open with support as well, but curious if anyone has seen
> similar issues when rolling out z/OS 2.5?   Same LPAR on z/OS 2.4 does not
> have the same issue.
> 
> Thanks,
> Ross
> 
> 
> 
> 
> 
> 
> 
> --
> 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: How to determine if Enhanced HOLDDATA received?

[Gibney, Dave]

Is it possible for a PTF to have no hold except the SECINT? That is to ask, is 
it likely that a PTF introducing a security issue could be applied because 
there is no HOLD(ERROR) or even a HOLD(ACTION) which could inform that there is 
a SECINT for the PFT?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Kurt J. Quackenbush
> Sent: Wednesday, January 18, 2023 11:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How to determine if Enhanced HOLDDATA received?
> 
> [EXTERNAL EMAIL]
> 
> HOLDDATA with CLASS(SECINT) is only available on the IBM Z Security Portal.
> 
> Who can and cannot obtain access to the IBM Z Security Portal is
> documented in this FAQ:
> https://urldefense.com/v3/__https://ibm.biz/security-portal-
> faq__;!!JmPEgBY0HMszNaDT!udnBZoAidHBU-
> nmJaQ0x_rAqjr3sKY3itcxgjYC4xq2ba2WcWInaZ1FXSydmPoc_MhkB6e-
> IHCxU$ .
> 
> In short, from the FAQ, "the Security Portal is for IBM clients that have a
> licensed IBM Z or LinuxONE mainframe.  It is not intended for users of
> emulators, such as zPDT, zRD, etc. using the z/OS ADCD or z/VM ADCD."
> So, a vendor that also has a license can obtain access.  No license?  No 
> access.
> And I am only a messenger on this topic.
> 
> Kurt Quackenbush
> IBM  |  z/OS SMP/E and z/OSMF Software Management
> |  ku...@us.ibm.com
> 
> Chuck Norris never uses CHECK when he applies PTFs.
> 
> >> Do you have access to security portal? the information I am looking
> >> for are only available there. I was told by IBM that as a vendor, I
> >> can't get access to it. See below for details about the cvss info:
> >> The HOLDDATA available from the IBM Z and LinuxONE Security Portal
> >> adds a new HOLD CLASS, SECINT, and the HOLD SYMPTOMS contains the
> CVSS
> >> Base and Temporal scores.
> 
> > I am surprised to hear IBM would take a position like that. It seems almost
> inconceivable that large vendors like BMC and Broadcom are locked out of
> the Secure Portal.
> 
> > My experience has been that an individual working for an IBM Z customer,
> with a manager or CISO that will vouch for them, can get access.
> 
> 
> 
> --
> 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: How to determine if Enhanced HOLDDATA received?

[Gibney, Dave]

Is there still such a thing as not-enhanced holddata?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Ed Jaffe
> Sent: Tuesday, January 17, 2023 11:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How to determine if Enhanced HOLDDATA received?
> 
> [EXTERNAL EMAIL]
> 
> On 1/17/2023 11:12 AM, Itschak Mugzach wrote:
> > I am not confused. As a vendor, we don;t have access to enhanced
> holddata.
> 
> Everyone has access to enhanced HOLDDATA. Just download it using FTP.
> For example:
> 
> //GETHOLDD JOB 1,JAFFE,CLASS=A,MSGCLASS=T,NOTIFY=
> // EXEC PGM=FTP,REGION=64M
> //SYSPRINT DD SYSOUT=*
> //SYSINDD *
>   service.boulder.ibm.com
>   anonymous
>   edja...@phoenixsoftware.com
>   cd s390/holddata
>   locsite recfm=fb lrecl=80
>   locsite primary=1 secondary=1 cylinders
>   get full.txt holddata.full.txt (REPLACE
>   quit
> //
> 
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!JmP
> EgBY0HMszNaDT!qSpVphFjV91HcWaf1rh2eLmIh7dOpJnrf_77wlB8IvJSH9nEI3
> p_IEdX1JyCgQbJX3wX4tI76uD1aXmkHOrqSA$
> 
> 
> 
> This e-mail message, including any attachments, appended messages and
> the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to
> be
> free of any virus or other defect that might affect any computer system into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: [EXTERNAL] ICKDSF

[Gibney, Dave]

I think it clear that Steve always meant OSVTOC and not CVOL. 

What I am not sure I agree with is the assertion that using ISKDSF to turn off 
the index and then turn it back on does not delete and rebuild the index?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Pommier, Rex
> Sent: Tuesday, January 03, 2023 3:05 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] ICKDSF
> 
> Hi Tony,
> 
> I never had to deal with CVOLs or for that matter, VSAM catalogs.  I cut my
> teeth in the early XA days when ICF catalogs were still green.  That said, I'm
> trying to figure out what Steve means when he says he needs to convert the
> indexed VTOC into a CVOL.  As you concurred, the VTOC has nothing to do
> with a CVOL (or VSAM catalog or ICF catalog).
> 
> Steve is getting errors trying to use LSPACE.  IDK if he posted the return
> codes or errors he is receiving.  If the LSPACE errors are related to the VTOC
> index, I would think he should be able to run an ICKDSF BUILDIX OSVTOC
> PURGE to (like Anthony alluded to), to shut off the VTOC index and the
> PURGE is supposed to actually delete the VTOCIX dataset.  Then running a
> BUILDIX IXVTOC should put a new, pristine VTOC index back on the volume.
> If he's getting an LSPACE on the actual VTOC, that's another matter.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tony Harminc
> Sent: Tuesday, January 3, 2023 3:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] ICKDSF
> 
> On Tue, 3 Jan 2023 at 15:16, Pommier, Rex 
> wrote:
> 
> > Steve,
> >
> > Don't you simply mean converting the IXVTOC to an OSVTOC - ie an
> > unindexed VTOC?  If my old memory cells are recalling correctly, a
> > CVOL was an ancient version of a VSAM catalog from before the ICF
> catalogs existed.
> >
> 
> CVOL is a non-VSAM catalog (that is, it is not itself a VSAM dataset, and it
> cannot point to VSAM datasets). It was the only kind of catalog prior to
> OS/VS back in the 1970s, and it continued in common use well into the 1990s.
> Perhaps more strictly, it is the *volume* that contains such a catalogue that 
> is
> the CVOL (Control Volume). The catalog is a CVOL Catalog.
> 
> That ancient *VSAM* catalog was the only kind of VSAM catalog in the early
> days, and was a design disaster for a bunch of reasons. It was replaced long
> ago by the ICF (Integrated Catalog Facility?) catalog, which with some tweaks
> is pretty much what we have today.
> 
> Regardless, these various catalogs have nothing at all to do with VTOCs,
> indexed or not.
> 
> Tony H.
> 
> -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Steve Beaver
> > Sent: Tuesday, January 3, 2023 2:06 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [EXTERNAL] ICKDSF
> >
> > What I have is a couple VOLUMES that are getting LSPACE errors
> >
> > Basically all the VOLUMES have indexed VTOCS that need to be Converted
> > to a CVOL and returned to a indexed VTOC
> >
> > That the easy part.  The painful part is I will have to the RO
> > *ALL,UCB Offline
> >
> > Run  the job
> >
> > RO *ALL,UCB Online
> >
> > Before anyon is the wiser
> >
> >
> >
> > --
> > --
> > 
> >
> > This electronic mail (including any attachments) may contain
> > information that is privileged, confidential, and/or otherwise
> > protected from disclosure to anyone other than its intended
> > recipient(s). Any dissemination or use of this electronic email or its
> > contents (including any attachments) by persons other than the
> > intended recipient(s) is strictly prohibited. If you have received
> > this message in error, please notify us immediately by reply email so
> > that we may correct our internal records. Please then delete the
> > original message (including any
> > attachments) in its entirety. Thank you
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> > On Behalf Of Pommier, Rex
> > Sent: Tuesday, January 3, 2023 1:54 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [EXTERNAL] ICKDSF
> >
> > The PURGE parameter deletes the VTOCIX dataset so using the BUILDIX
> > will build a new one and not reuse the old, corrupt dataset.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Seymour J Metz
> > Sent: Thursday, December 22, 2022 1:53 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [EXTERNAL] ICKDSF
> >
> > That will work fine if the existing IXVTOC is good, but what if it is
> > corrupted?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> >
> >
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!KjMRP
> 1I
> > xj6eLE
> > 0Fj
> >
>  P1
> > Ixj6eLE0Fj>
> > !rQsxPmTo-
> 3kSqLu15go6sNEUX8nn6PcuIZao7aZKuZ2xEN9BCZkpYpOn1HKVI96FWQXJ_
> > -p4
> > F3GGnpKkUQ$
> >
> 

Re: ZFS Address Space, shared ENQ but filesystem isn't mounted

[Gibney, Dave]

Had it not been enqueued, what did you wish to do? Perhaps one of the BYPASSNQ 
CBT utilities would allow you to do it anyway.

Or, perhaps there is an internal (or abended)  subtask in ZFS which is 
retaining (or waiting) the problem enqueue

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Mark Jacobs
> Sent: Thursday, December 29, 2022 12:15 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ZFS Address Space, shared ENQ but filesystem isn't mounted
> 
> [EXTERNAL EMAIL]
> 
> Tried that. Didn't work. Told me that the file system that was contained in 
> the
> ZFS dataset was mounted somewhere. OMVS disagrees.
> 
> Mark Jacobs
> 
> Sent from ProtonMail, Swiss-based encrypted email.
> 
> GPG Public Key -
> https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get
> =markjacobs@protonmail.com__;!!JmPEgBY0HMszNaDT!qrhVnMjbi
> aUp7SxqtXPV8dAsiy0-
> UIkAniFKp_N1zIfz2XRM3bo1ILrHpGkfBpV8VnOZSMYRU5jBynjHid_BTtpsyjs9r
> o2I$
> 
> 
> --- Original Message ---
> On Thursday, December 29th, 2022 at 1:37 PM, Patrick Loftus
>  wrote:
> 
> 
> > Consider the following command in that case:
> >
> https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.4.0?top
> ic=commands-zfsadm-
> detach__;!!JmPEgBY0HMszNaDT!qrhVnMjbiaUp7SxqtXPV8dAsiy0-
> UIkAniFKp_N1zIfz2XRM3bo1ILrHpGkfBpV8VnOZSMYRU5jBynjHid_BTtpsymF
> 7NBU7$
> > And have a look at the other zfsadm commands in that manual whilst
> you're there in case anything useful jumps out at you.
> >
> > Regards
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> Behalf Of Mark Jacobs
> >
> > Sent: 29 December 2022 18:33
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: ZFS Address Space, shared ENQ but filesystem isn't mounted
> >
> > It does, yes.
> >
> > Mark Jacobs
> >
> > Sent from ProtonMail, Swiss-based encrypted email.
> >
> > GPG Public Key -
> https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get
> =markjacobs@protonmail.com__;!!JmPEgBY0HMszNaDT!qrhVnMjbi
> aUp7SxqtXPV8dAsiy0-
> UIkAniFKp_N1zIfz2XRM3bo1ILrHpGkfBpV8VnOZSMYRU5jBynjHid_BTtpsyjs9r
> o2I$
> >
> >
> >
> >
> > --- Original Message ---
> > On Thursday, December 29th, 2022 at 1:20 PM, Patrick Loftus
> patricklof...@pmlnet.co.uk wrote:
> >
> >
> >
> > > Does Unix command "zfsadm aggrinfo -system sysname" list the
> filesystem concerned, where sysname is the sysname of the one showing
> the enqueue by ZFS?
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> Behalf
> > > Of Mark Jacobs
> > >
> > > Sent: 29 December 2022 15:06
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: ZFS Address Space, shared ENQ but filesystem isn't
> > > mounted
> > >
> > > OMVS doesn't have that file system in its list of mounted file systems, so
> the OMVS unmount command fails just like the TSO umount command does.
> > >
> > > Mark Jacobs
> > >
> > > Sent from ProtonMail, Swiss-based encrypted email.
> > >
> > > GPG Public Key -
> > >
> https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get
> =markjacobs@protonma__;!!JmPEgBY0HMszNaDT!qrhVnMjbiaUp7S
> xqtXPV8dAsiy0-
> UIkAniFKp_N1zIfz2XRM3bo1ILrHpGkfBpV8VnOZSMYRU5jBynjHid_BTtpsysZb
> VZH_$
> > > il.com
> > >
> > > --- Original Message ---
> > > On Thursday, December 29th, 2022 at 9:46 AM, Shelia Chalk
> 03d9384cc8f1-dmarc-requ...@listserv.ua.edu wrote:
> > >
> > > > Mark,
> > > >
> > > > I also have a batch job if you need that also.
> > > >
> > > > //INSTALL EXEC PGM=BPXBATCH,REGION=0M //STDPARM DD * SH
> > > > /usr/xxx/unmount -f OMVS.xxx.xxx.ZFS
> > > > /*
> > > > //SYSMDUMP DD SYSOUT=*
> > > > //STDOUT DD SYSOUT=*
> > > > //STDERR DD SYSOUT=*
> > > >
> > > > Or
> > > > //STDPARM DD *
> > > > SH
> > > > /usr/xxx/unmount -f OMVS..xxx.ZFS immediate;
> > > > /*
> > > >
> > > > Thanks
> > > > Shelia C
> > > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> Behalf
> > > > Of Shelia Chalk
> > > >
> > > > Sent: Thursday, December 29, 2022 8:39 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: ZFS Address Space, shared ENQ but filesystem isn't
> > > > mounted
> > > >
> > > > Have you tried this command from omvs
> > > > /usr/xxxn/t -f OMVS...S.ZFS immediate
> > > >
> > > > Shelia C
> > > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> Behalf
> > > > Of Mark Jacobs
> > > >
> > > > Sent: Thursday, December 29, 2022 7:14 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: ZFS Address Space, shared ENQ but filesystem isn't
> > > > mounted
> > > >
> > > > That would likely be externalized as a different error.
> > > >
> > > > Mark Jacobs
> > > >
> > > > Sent from ProtonMail, Swiss-based encrypted email.
> > > >
> > > > GPG Public Key -
> > > >
> 

Re: Markup languages

[Gibney, Dave]

It may be heresy, but $99/year for Office365 isn't a large expense and can be 
installed on 5 PCs plus mobile devices. 
But, I am still running Visio from a 2013 license

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bob Bridges
> Sent: Thursday, December 22, 2022 12:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Markup languages
> 

> ...But maybe I will anyway, to this extent:  With each new PC I shell out
> real money for a copy of the real MS Office, including Access.  But long ago
> I took up the habit of teaching each new PC to default to WordPad for .rtf
> documents, and that's what I use to write one- or two-page documentation
> on
> simple commands and utilities.  I've been saving Word for the more
> ambitious
> stuff, especially if it involves chapter headings and cross-references.
> 
> Now that I think I'm giving up on that, I guess Word is relegated to reading
> MS .docx documents that others send me.  I can't think of anything else I'd
> want it for.
> 
> I really miss WordPerfect.
> 
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> 
> /* A general dissolution of the principles and manners will more surely
> overthrow the liberties of America than the whole force of the common
> enemy.
> -Samuel Adams */
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of
> Seymour J Metz
> Sent: Thursday, December 22, 2022 14:49
> 
> Oddly enough, one of the reasons that I use markup languages is that the
> documents are easy to maintain; adding text doesn't break formatting.
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of
> Matt Hogstrom [m...@hogstrom.org]
> Sent: Thursday, December 22, 2022 9:51 AM
> 
> In my travels I've not seen anyone use Libre Office or LaTeX; I'm not
> knocking them but if they are not widely used who will maintain the doc
> later when we all retire?   When considering authoring docs like programs we
> need to consider the downstream consumers / maintainers so I'd go with the
> popular tools of today.
> 
> --
> 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: RLSE - A question about releasing unused tracks in a DASD dataset

[Gibney, Dave]

The F line command from ISPF 3.4

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of David Cole
> Sent: Wednesday, December 21, 2022 1:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RLSE - A question about releasing unused tracks in a DASD dataset
> 
> [EXTERNAL EMAIL]
> 
> Is there a way to release unused tracks in a classic z/OS PDS but
> without having to open and close it?
> 
> Or if opening/closing is required, is there a way to do that for a
> PDS without knowing (or discovering) what members are in it, and
> without creating a new member?
> 
> Obviously, I could write something, but I don't want to.
> And I cannot rely on the presence of any program or TSO command that
> does not come standard on a z/OS system?
> 
> I don't think there is a way to do this, but I'd love for someone to
> prove me wrong.
> 
> 
> David Cole
> dbc...@gmail.com (personal)
> dbc...@colesoft.com (business)
> 540-456-6518 (cell)
> 
> --
> 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: Why email from z/OS SMTP rejected by Gmail?

[Gibney, Dave]

I'm at the bottom, but as I read the article, it seems that you are claiming to 
be @mcn.org and that the DNS  data for whatever your first hop out of z/OS is, 
needs to have SPF entries stating that it is ok for it to be sending for 
mcn.org.

Perhaps there is a better SMTP server you can use for that first hop

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Charles Mills
> Sent: Sunday, December 11, 2022 1:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Why email from z/OS SMTP rejected by Gmail?
> 
> Thanks all! Let's see if I can do one big reply.
> 
> > Difficult to avoid HTML
> Yeah, with some re-programming (see next answer) I could go to HTML Not
> the best use of my time, but I can do that.
> 
> > Did I try the HTML?
> Yes, If I add the following to the e-mail then GMail accepts it.
> 
> "Mime-Version: 1.0;"
> 'Content-Type: text/html; charset="ISO-8859-1";'
> "Content-Transfer-Encoding: 7bit;"
> " "/* Watch out -- null lines kill EXECIO */
> 
> But that screws up the formatting of the email because it becomes flow-
> together HTML rather than individual monospaced lines. (Does what I am
> saying make sense?)
> 
> > Service bureau ...
> 
> It is an LPAR on a service bureau machine. I have complete control over the
> LPAR, but it is talking to some SMTP gateway that I do not control. I am not 
> an
> SMTP expert ...
> 
> > @Phil ...
> 
> Thanks for the link. Duh. I did not think to Google the error. But lots of
> complainers there; no resolution that i saw.
> 
> > I would suspect a need to further configure due to some newer gmail
> requirements
> 
> Me too, but what?
> 
> Charles
> 
> --
> 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: Why email from z/OS SMTP rejected by Gmail?

[Gibney, Dave]

What level z/OS? SMPT or CSSMPT? I would suspect a need to further configure 
due to some newer gmail requirements. Probably only available using CSSMPT

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Charles Mills
> Sent: Sunday, December 11, 2022 10:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Why email from z/OS SMTP rejected by Gmail?
> 
> [EXTERNAL EMAIL]
> 
> Has anyone else seen this? I have a couple of z/OS applications that send
> status emails. The emails go to several addresses without error. Some of the
> emails are plain text format, and some are HTML.
> 
> I recently added an @Gmail address to the emails and the plain text email
> *only* is being rejected by Gmail with the following error:
> 
> host gmail-smtp-in.l.google.com[142.251.15.26] said:
> 550-5.7.1 [66.180.7.182] Messages missing a valid messageId header are
> not
> 550 5.7.1 accepted. 4-
> 20020a25040400b006de730f5057si5474769ybe.296 -
> gsmtp (in reply to end of DATA command)
> 
> Here is an example – pretty much straight out of the IP User’s Guide – that
> duplicates the problem. The @mcn address works but the @gmail address
> bounces. Has anyone else seen this? Any ideas?
> 
> //IEBGENER EXEC PGM=IEBGENER
> //SYSIN DD DUMMY
> //SYSUT1 DD *
> HELO server
> MAIL FROM:
> RCPT TO:
> RCPT TO:
> DATA
> Importance: high
> From: LPAR
> To: 
> To: 
> Subject: Please tell me if you get this email!!!
> 
> Mike: Cindy stubbed her toe. Bobby went to
> baseball camp. Marsha made the cheerleading team.
> Jan got glasses. Peter has an identity crisis.
> Greg made dates with 3 girls and couldn't
> remember their names.
> .
> QUIT
> /*
> //SYSUT2 DD SYSOUT=(B,SMTP)
> //SYSPRINT DD SYSOUT=*
> 
> Thanks,
> Charles
> 
> --
> 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: To share or not to share DASD

[Gibney, Dave]

Different RACF and fully shared DASD is a recipe for security problems and 
inconsistencies. I suppose RRSF could help. GRS ring is reported to be abysmal 
and nodes > 2
Same issues in trying to keep the catalogs in sync, which is required to SMS to 
be reliable. As will as trying to keep the SMS xCDS (and DFHSM) in sync.

I had 4 LPARS, all monoplex, perhaps a dozen, carefully shared volumes. 
Including the SYSRES. I did have separate Unix system filesystems for each.
All volumes were potentially shareable, but I varied most of them offline at 
IPL from the 3 LPARs they were a part of. 

I had separate SMS pools for the application data in each LPAR.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gord Neill
> Sent: Thursday, November 24, 2022 1:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: To share or not to share DASD
> 
> [EXTERNAL EMAIL]
> 
> Dave,
> Each LPAR has its own RACF and Catalogs, and they are using SMS.  This shop
> is currently running z/OS 1.9 on very old hardware, in the process of
> upgrading to current H/W and S/W.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gibney, Dave
> Sent: November 24, 2022 4:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: To share or not to share DASD
> 
> You can't share PDSE in such an environment. You can "get away"  with only
> and rarely updating from one LPAR, and reading in the others.
> 
> Multiple RACF databases?  Are the Catalogs the same and shared between all
> 3 LPARS?
> 
> Is the site using SMS?
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Gord Neill
> > Sent: Thursday, November 24, 2022 12:55 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: To share or not to share DASD
> >
> > [EXTERNAL EMAIL]
> >
> > G'day all,
> > I've been having discussions with a small shop (single mainframe, 3
> > separate LPARs, no Sysplex) regarding best practices for DASD sharing.
> > Their view is to share all DASD volumes across their 3 LPARs
> > (Prod/Dev/Test) so their developers/sysprogs can get access to current
> > datasets, but in order to do that, they'll need to use GRS Ring or MIM
> > with the associated overhead.  I don't know of any other serialization
> > products, and since this is not a Sysplex environment, they can't use
> > GRS Star.  I suggested the idea of no GRS, keeping most DASD volumes
> isolated to each LPAR, with a "shared string"
> > available to all LPARs for copying datasets, but it was not well received.
> >
> > Just curious as to how other shops are handling this.  TIA!
> >
> >
> > Gord Neill | Senior I/T Consultant | GlassHouse Systems
> >
> >
> >
> >
> > --
> > 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: To share or not to share DASD

[Gibney, Dave]

You can't share PDSE in such an environment. You can "get away"  with only and 
rarely updating from one LPAR, and reading in the others.

Multiple RACF databases?  Are the Catalogs the same and shared between all 3 
LPARS?

Is the site using SMS?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gord Neill
> Sent: Thursday, November 24, 2022 12:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: To share or not to share DASD
> 
> [EXTERNAL EMAIL]
> 
> G'day all,
> I've been having discussions with a small shop (single mainframe, 3 separate
> LPARs, no Sysplex) regarding best practices for DASD sharing.  Their view is 
> to
> share all DASD volumes across their 3 LPARs (Prod/Dev/Test) so their
> developers/sysprogs can get access to current datasets, but in order to do
> that, they'll need to use GRS Ring or MIM with the associated overhead.  I
> don't know of any other serialization products, and since this is not a 
> Sysplex
> environment, they can't use GRS Star.  I suggested the idea of no GRS,
> keeping most DASD volumes isolated to each LPAR, with a "shared string"
> available to all LPARs for copying datasets, but it was not well received.
> 
> Just curious as to how other shops are handling this.  TIA!
> 
> 
> Gord Neill | Senior I/T Consultant | GlassHouse Systems
> 
> 
> 
> 
> --
> 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: Limiting quantity of tape drives used by user

[Gibney, Dave]

Maybe it was FILE500

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gibney, Dave
> Sent: Monday, November 07, 2022 3:42 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Limiting quantity of tape drives used by user
> 
> As I removed automation from my just recently shutdown system, I installed
> a MPF exit from the
> CBT ( I  think maybe file 882). This MPF2REXX just did a F AXR,msgid for the
> messages it was active for.
> 
> I suspect I could have extended this to notice tape mount (requests, mounts,
> and releases) to monitor drive allocation and react to a high water limit.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Mark Jacobs
> > Sent: Monday, November 07, 2022 3:22 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Limiting quantity of tape drives used by user


> > A very long time ago at $previousjob-1 we used an MPF exit for messages
> > such as TMS001, IEC101A, IEC501A, IEC501E, IEF233A and IEF233D. This exit
> > looked at the tape UCBs for the job name of the newly allocated drive and
> if
> > the job exceeded a defined limit the exit canceled the job.
> >
> > I do have the source code available if someone wants to read some real
> ugly
> > code.
> >
> > Mark Jacobs
> >
> > Sent from ProtonMail, Swiss-based encrypted email.
> >
> > GPG Public Key -
> >
> https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get
> >
> =markjacobs@protonmail.com__;!!JmPEgBY0HMszNaDT!unG2wgFb
> > C9Q5AhE5o2JCM5Z8nrV7xUpk8BGtU87QxduUT5LIj-
> > gix4ZtTaFtD31RcbIJUy_VEaesvd8bjWKG0Nyp1MITpLkA$
> >
> >
> > --- Original Message ---
> > On Monday, November 7th, 2022 at 6:06 PM, Glenn Miller
> >  wrote:
> >
> >
> > > We encountered the exact same problem recently. In our situation, a
> batch
> > job using the IBM DB2 DSNUTILB attempting to perform a DB2 Reorg of a
> > partitioned DB2 Table with 500 partitions. The batch job was submitted by a
> > TSO User, not our TWS job scheduler. The job slowly allocated about 470
> > virtual tape drives in about 90 minutes until it received IEF877E followed 
> > by
> > IEF238D. Unfortunately, our automation replied WAIT to the IEF238D and
> > replied NOHOLD to the subsequent IDF433D. That caused Operations to be
> > unaware of the 'problem' until nearly an hour later when HSM need a
> virtual
> > tape drive.
> > > A cancel of that 'mis behaving' batch job cleared up the problem,
> however
> > we have be struggling with finding a way to prevent the problem or alerting
> > our Operations folks in real time that a 'not good' situation may be
> occurring.
> > As of today, we don't have a good answer for either part.
> > > Glenn Miller
> > >
> > > --
> > > 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: Limiting quantity of tape drives used by user

[Gibney, Dave]

As I removed automation from my just recently shutdown system, I installed a 
MPF exit from the 
CBT ( I  think maybe file 882). This MPF2REXX just did a F AXR,msgid for the 
messages it was active for.

I suspect I could have extended this to notice tape mount (requests, mounts, 
and releases) to monitor drive allocation and react to a high water limit. 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Mark Jacobs
> Sent: Monday, November 07, 2022 3:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Limiting quantity of tape drives used by user
> 
> [EXTERNAL EMAIL]
> 
> A very long time ago at $previousjob-1 we used an MPF exit for messages
> such as TMS001, IEC101A, IEC501A, IEC501E, IEF233A and IEF233D. This exit
> looked at the tape UCBs for the job name of the newly allocated drive and if
> the job exceeded a defined limit the exit canceled the job.
> 
> I do have the source code available if someone wants to read some real ugly
> code.
> 
> Mark Jacobs
> 
> Sent from ProtonMail, Swiss-based encrypted email.
> 
> GPG Public Key -
> https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get
> =markjacobs@protonmail.com__;!!JmPEgBY0HMszNaDT!unG2wgFb
> C9Q5AhE5o2JCM5Z8nrV7xUpk8BGtU87QxduUT5LIj-
> gix4ZtTaFtD31RcbIJUy_VEaesvd8bjWKG0Nyp1MITpLkA$
> 
> 
> --- Original Message ---
> On Monday, November 7th, 2022 at 6:06 PM, Glenn Miller
>  wrote:
> 
> 
> > We encountered the exact same problem recently. In our situation, a batch
> job using the IBM DB2 DSNUTILB attempting to perform a DB2 Reorg of a
> partitioned DB2 Table with 500 partitions. The batch job was submitted by a
> TSO User, not our TWS job scheduler. The job slowly allocated about 470
> virtual tape drives in about 90 minutes until it received IEF877E followed by
> IEF238D. Unfortunately, our automation replied WAIT to the IEF238D and
> replied NOHOLD to the subsequent IDF433D. That caused Operations to be
> unaware of the 'problem' until nearly an hour later when HSM need a virtual
> tape drive.
> > A cancel of that 'mis behaving' batch job cleared up the problem, however
> we have be struggling with finding a way to prevent the problem or alerting
> our Operations folks in real time that a 'not good' situation may be 
> occurring.
> As of today, we don't have a good answer for either part.
> > Glenn Miller
> >
> > --
> > 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: SYSTEM REXX use

[Gibney, Dave]

SYSLOG, There's a msg id I could give you, if I had a system

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Seymour J Metz
> Sent: Tuesday, November 01, 2022 11:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSTEM REXX use
> 
> 
> Where does the output of say go?
> 
> Thanks.
> 
> 
> 
> From: IBM Mainframe Discussion List  on
> behalf of ITschak Mugzach 
> Sent: Tuesday, November 1, 2022 2:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSTEM REXX use
> 
> Seymour,
> 
> TSO is supported by SystemRexx, including OMVS. The modify command will
> always route the exec to run under axr stc having TSO=YES.
> 
> Best
> ITschak
> 
> Sa
> בתאריך יום ג׳, 1 בנוב׳ 2022 ב-18:16 מאת Seymour J Metz :
> 
> > You can submit a MODIFY AXR command from TSO, but the code doesn't
> run in
> > the TSO address space and doesn't have access to TSO services.
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf
> > of Kenneth J. Kripke <046fa3a8ef80-dmarc-
> requ...@listserv.ua.edu>
> > Sent: Monday, October 31, 2022 9:36 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: SYSTEM REXX use
> >
> > Hello;
> >
> >  I am looking at the capabilities of SYSTEM REXX on a Z/OS system.  I
> > am
> > not familiar with how to invoke it and so forth.
> >
> > Can functions be called from a TSO REXX environment, and, if so, how do I
> > establish a connection to AXR?
> >
> >
> >
> > 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
> >
> 
> --
> 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

End of several eras

[Gibney, Dave]

I just shutdown our z/OS 2.3 system(s) for the last time.
When I came to school in 1976, the computer was described as  "loosely coupled 
370s". My exposure was via remote cardreader/printer.
When I started working here in 1981, there were still folks that had rewired 
boards for what they had before that.
End of 2019, we moved from a 10 year old z9 to MFaaS with FNTS in Omaha.

Dave Gibney
Information Technology Services
Washington State University


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

Re: SYSTEM REXX use

[Gibney, Dave]

System Rexx is quite useful. I used it to replace CA-7 and CA-OPS when we 
dropped our CA licenses last year.
Granted, we where on the path towards today's final shutdown and our automation 
needs where diminishing.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Farley, Peter
> Sent: Monday, October 31, 2022 9:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSTEM REXX use
> 
> [EXTERNAL EMAIL]
> 
> System Rexx runs Rexx programs in an isolated, **APF authorized**
> environment, so the only way to run a Rexx program under the AXR task is to
> use an operator MODIFY command to the AXR service to tell it to run your
> Rexx in that address space.
> 
> This reference explains what System Rexx really is:
> 
> https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.5.0?top
> ic=guide-system-rexx__;!!JmPEgBY0HMszNaDT!sGzD1kTF-
> VRnIRQ9cQWgiVsChCNgXa5aqSM35jEcXyTIhvt-
> 0GU9U3mQVO9WSx9RBTblYqJQzo8gd4XKb9kS5TGZRlAytfYQ$
> 
> Basically, you can't run your Rexx from plain JCL or normal TSO, you have to
> have authorization to use the operator MODIFY command and your Rexx
> must be accessible to the AXR STC in a library to which the STC has access.
> 
> Not intended for "normal" Rexx applications, and probably only useful to
> system programmers and other authority-privileged teams.
> 
> HTH
> 
> Peter
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Kenneth J. Kripke
> Sent: Monday, October 31, 2022 9:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SYSTEM REXX use
> 
> Hello;
> 
>  I am looking at the capabilities of SYSTEM REXX on a Z/OS system.  I am
> not familiar with how to invoke it and so forth.
> 
> Can functions be called from a TSO REXX environment, and, if so, how do I
> establish a connection to AXR?
> 
> 
> 
> Kenneth J. Kripke
> --
> 
> 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: ICHEINTY - RACF interface

[Gibney, Dave]

I actually know very little about ICHENITY. I have, however, always understood 
it to be a dangerous, use at last resort tool. Requiring rather detailed 
knowledge of the RACF database structure. Or, maybe I am thinking of the direct 
block update utility 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Pierre Fichaud
> Sent: Wednesday, October 05, 2022 11:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ICHEINTY - RACF interface
> 
> [EXTERNAL EMAIL]
> 
> I have an update.
> After an hour or so of juggling the various parameters for ICHEINTY, I got 
> this
> :
> 
> 20.26.08 JOB04490 *IRR401I 0C4 ABEND DURING RACF PROCESSING OF  236
>236   ALTER REQUEST FOR ENTRY T22TST1
> 20.26.08 JOB04490  IRR401I 0C4 ABEND DURING RACF PROCESSING
> 
>  I couldn't get the macro to work with DATAMAP=NEW and RELEASE 1.8.
>  I let it default to 1.7 and played with the parameters.
> 
> Now I have an abend but I got no SYSMDUMP nor a SYSUDUMP.
> 
> My next step is to set a SLIP trap but I'm waiting to be APF-authorized 
> to do
> this.
> 
> 1) Why is it a guessing game as to which parameters apply ?
> 
> 2) The examples are always coded in non-rent assembler programs.
>  I code exclusively re-entrant, AMODE 31 and RMODE ANY.
>  I rarely see IBM examples where the code is re-entrant.
>  And I never see the flavor that I am using, in this case ICHEINTY 
> ALTER,
> TYPE='USR'.
>  Couldn't IBM use examples that work in 31-bit and are re-entrant ?
> 
> 3) There is probably something in the generated parameter list that is
> wrong or missing.
>  Unfortunately, there is no mapping for the ICHEINTY parameter list.
>  Can IBM supply a mapping if it exists.
>  The doc refers to fields at various offsets.
>  I have no idea what to do to fix this problem.
>  It's a guessing game - back to #1.
> Regards, Pierre.
> 
> --
> 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 Roadmap

[Gibney, Dave]

I converted sometime last year. The Redbook wasn't really helpful, as RMM has 
several newer features that help match CA-1 behavior. RMM support was very 
helpful. I believe I asked some questions here on IBM-MAIN and they reached 
back out to me.

I did find that my retention processing became a problem because RMM does honor 
MGMTCLAS rules even if it is not an explicitly SMS managed tape library 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Doug
> Sent: Tuesday, October 04, 2022 8:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RMM Roadmap
> 
> [EXTERNAL EMAIL]
> 
> Redbook still works. You need SYS1.SAMPLIB and SYS1.LINKLIB from a z/OS
> 1.13 system.
> 
> Modules might be still there at z/OS 2.2 but I don't think so, but there
> was some discussion regarding.
> 
> Doug Fuerst
> d...@bkassociates.net
> 
> -- Original Message --
> From: "Steve Beaver" 
> To: IBM-MAIN@listserv.ua.edu
> Sent: 04-Oct-22 10:47:08
> Subject: RMM Roadmap
> 
> >Has anyone converted from CA-1 to RMM since Broadcom bought CA.
> >
> >
> >
> >The Redbook is WAY out of date and basically useless
> >
> >
> >
> >
> >
> >
> >--
> >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: COBOL - z/OS 2.1 vs 2.4

[Gibney, Dave]

Level of CIS would be in play.   This is likely one of the changes in how and 
where memory gets allocated and initialized in 2.2 or 2.3 on.  There are some 
compatibility DIAGxx parms

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Crusty Old Guy
> Sent: Monday, October 03, 2022 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL - z/OS 2.1 vs 2.4
> 
> [EXTERNAL EMAIL]
> 
> I have further information from the programmers.
> 
> These are CICS programs. The programs do not initialize their working
> storage.  I'm told everything is fine under z/OS 2.1.
> 
> Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to
> know why it runs OK under 2.1.
> I have not found an answer for them in the migration guide.  Can anyone
> help?
> 
> COG
> 
> --
> 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: Assembler courses

[Gibney, Dave]

I wrote a analyzer of DFHSM messages. Here, the most convient language is 
Natural. Which allowed me to generate the subroutine name base on the  error 
message id. With an error handler to catch subroutines not yet written.

So, I could write the code to handle messages I cared about and let the error 
handler tell me about messages I hadn't written yet.  

In this case, there was no confusion about where the programmatically derived 
names where call, as they were all called from the same gateway routine

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bernd Oppolzer
> Sent: Saturday, September 24, 2022 10:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler courses
> 
> [EXTERNAL EMAIL]
> 
> Sorry for this topic drift, but this is interesting, anyway.
> 
> IMO, there are some really interesting use cases for such techniques,
> for example
> 
> - sort routines where the comparison functions is generic, that is, a
> function pointer
> - same for search routines
> - same for dynamic arrays of structs, indexed by key structs (I
> implemented one, using AVL trees)
> - a function package which prints or plots other functions
> 
> and so on.
> 
> In C, I did this using function pointers.
> In Pascal, I can pass procedures or functions to procedure parameters
> (procedures passed as
> parameters to other procedures), which is virtually the same as function
> pointers, but IMO
> looks nicer. This is from the 1960s. I never considered this as being
> OO, but in fact,
> all the above things, although implemented in procedural languages like
> C and Pascal,
> are TEMPLATES.
> 
> If I really feel the need for such solutions (which I do sometimes), I
> anyway like to stick
> with procedural languages like, see above, Pascal and C, and I don't use
> C++;
> all the OO overhead makes me feel bad.
> 
> See this video:
> 
> Object-Oriented Programming is Embarrassing: 4 Short Examples - YouTube
>  AqPw__;!!JmPEgBY0HMszNaDT!s9tTUn_a7tgU7l_UQjPBgdsIbevvPpNynzvhic
> 9sFjG3dkRDKnfRJXug7RowAIc4HD4Pxc0R1AZTDDBeXLllf-GwHYU$  >
> 
> Kind regards
> 
> Bernd
> 
> 
> Am 24.09.2022 um 18:51 schrieb Tony Harminc:
> > On Fri, 23 Sept 2022 at 19:10, Paul Gilmartin <
> > 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Far worse is the attempt to use OO techniques in non-OO languages.
> >> "Where is this function called?"
> >> "A pointer to it is saved in a struct."
> >> After that, it's anyone's guess.
> >>
> > Years ago I inherited a good size (~200 kLOC) assembler program that had a
> > lot of old-fashioned techniques. But at the same time it had a structured
> > macro scheme that was quite advanced, and included an internal
> subroutine
> > call/stack mechanism. I updated the macros to generate symbols for the
> > assembler xref/ADATA about what was being called and from where, and
> only
> > then discovered that the subcall macro had the option to load the "function
> > pointer" (address) from a field in a "struct" (DSECT), thus making a
> > complete static xref of calls impossible. The best that could be done
> > (other than a complete control/data flow analysis) was to also log what
> > updated those pointers in the struct, but correlating them was almost
> > impossible.
> >
> > Bad code can be written using just about any programming paradigm in any
> > language.
> >
> > Tony H.
> >
> > --
> > 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 to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: z/OSMF PSWI

[Gibney, Dave]

Maybe, somewhere in the middle, IEBCOPY is relocated...

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Mark Zelden
> Sent: Friday, September 23, 2022 2:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OSMF PSWI
> 
> [EXTERNAL EMAIL]
> 
> On Fri, 23 Sep 2022 07:33:37 -0500, Carmen Vitullo 
> wrote:
> 
> >yes I read it, and that would be great if every single client, every
> >single site had the same wisdom as you, I've worked at sites where I was
> >not the lead z/os or mvs guy, I had no control over what anyone else
> >did, and we all paid the consequences updating a live system, acceptable
> >or not, I change the allocation to not allocate secondary space period.
> 
> A point I was trying to convey was that secondary space or not if you update
> the live system without knowing what you are doing you're going to have
> unexpected results.   Instead of the secondary (which can happen)
> you would have just run into an x37 instead and maybe half your
> change was copied in (assuming it was more than one LMOD). Or
> maybe one of those less experienced people doesn't know to do an
> LLA update or refresh. Or maybe they forget the sysres is shares
> on other systems and forget to do the LLA update or refresh there. Maybe
> the maintenance process is done from a system outside the sysplex and
> they break a PDSE (all things I have run into at shops I've consulted
> at).
> 
> So to me, I really don't care about the secondary for some libraries
> because no matter what if someone needs to update the live sysres
> for an emergency, there is more than just "what happens if this library
> takes an additional extent" consideration.In your scenario of "no
> control of what anyone else does" they can break the system just
> as easily regardless of no secondary defined in any number of ways.
> That is my point.
> 
> BTW, if a secondary is taken, a compress will put everything back into the
> first extent (assuming this is being done as a "fix" and not really adding
> additional modules / some individual module that is much bigger) and doing
> an LLA UPDATE of the library will fix it all after the compress.  An
> LLA update of the modules or library has to be done anyway.
> 
> In an emergency, the better way to do it would be to have the 'fix' in a
> separate library anyway and do a dynamic LNKLST update with the
> new library concatenated ahead of the original.
> 
> >
> >my main issue was how the space was defined initially using the
> >serverpac dialog, been burnt a couple times during the SP install, so I
> >update the space requirements then.
> >
> 
> Again, the history of that I think was to facilitate applying maintenance and
> maybe
> to help accommodate poor "JCL" / allocations in Serverpac also.  But as you
> indicated, at least there was a way to update it at install time if that is
> what you wanted to do.
> 
> >that is for MY site, and my MY way of installing  and maintaining a
> >site  IMHO I've seen it done wrong, and things gone bad, and seen it
> >done a way that's safe and makes sense, that methodology I adopt.
> >
> 
> Exactly.  But not everyone does it the same or has the same considerations,
> so IBM made it a choice.  I don't consider it "wrong",  it is an option that
> I happen to like to facilitate maintenance.   Maybe the better ServerPac
> default
> would have been no secondary to begin with.  Can't please everyone
> though...
> 
> This reminds me...  back in the older days (pre DFSMS/MVS 1.3) at
> a shop I was at we ran a post clone process with FDRCPK to combine
> extents to avoid the LNKLST limitations.  Still had the secondaries
> though to facilitate maintenance.I wrote an exec (LNKVER) still on my
> web site to help manage it..  The doc has the old rules:
> 
>  (32) + (16n) + (k-1)
> n = the number of DASD extents (PDSE counts as 1)
> k = the number of data set in the link list
> 
> The result of the algorithm cannot exceed 2040.
> 
> 
> 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://urldefense.com/v3/__http://www.mzelden.com/mvsutil.html__;!!J
> mPEgBY0HMszNaDT!o5Z075cMrDIbOCIYk0ebADpYeQRA1NUQq2ZoKoVpOvr
> xa6AUxjn7-X9smRfTE32YEX1-waVjw7Uy$
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: z/OSMF PSWI

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Carmen Vitullo
> Sent: Thursday, September 22, 2022 1:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OSMF PSWI
> 
> [EXTERNAL EMAIL]
> 
> 'A'  secondary extends is supported as long as it is part of the initial
> primary allocation, or an extent is taken or required to satisfy the
> primary space allocation -
> 
> I'm talking space allocation that provides for secondary space
> allocation in the allocate in the dialog, not what SMS or dfp does to
> satisfy the primary space allocation
> 
> why is the Health checker issuing a CSVH0979I message LINKLST SET
> LNKST00 data sets allocated with secondary space? if what you say is
> valid ?

It is a condition to be aware of, as you can still have problems if you are 
foolish enough (or forced to) do maintenance on your live system. Shifting an 
important module intoa new extend of for example, SYS!.LNKLST, could be a fatal 
error leading to an IPL.

But, Mark is correct, it's not a problem if you do maintenance to a different 
set of targets and copy them to a new SYSRES for implementation.

> 
> Carmen
> 
> 
> On 9/22/2022 3:13 PM, Mark Zelden wrote:
> > Secondary extents are certainly supported in the LNKLST.
> 
> --
> 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: Assembler courses

[Gibney, Dave]

The course I took in 370 assembler out of the Struble book made learning COBOL 
At my 1st job (a paying internship) a trivial matter. Never looked back. I 
haven't counted the languages I've had occasion to use (or many  I guess modify 
existing code in) in the last 42ish years.

I credit the Assembler course with the reason I've had a job all this time. And 
I've told the professor so. And, yes, I very rarely write it any more, but it's 
been handy at times.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bob T Roller
> Sent: Saturday, September 17, 2022 1:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler courses
> > 
> I learned PL/I, WATFIV, FORTRAN, GPSS, assembler, and a few other
> languages in college. Never used any of them. COBOL was an elective, which
> I took, and used extensively for 25 years. One professor, when asked what
> JCL was by a fellow student, said it’s unimportant and will be irrelevant. JCL
> was probably the most important & used “language” of my career. Which I
> learned via the EDS OPD program.
> 
> Sent from Proton Mail for iOS
> 
> On Sat, Sep 17, 2022 at 3:29 PM, Farley, Peter x23353 <031df298a9da-
> dmarc-requ...@listserv.ua.edu> wrote:
> 
> > My experience was the opposite of yours over a few more years (50). I
> learned assembler early via OJT at one of my first permanent jobs, and got to
> use it more and more as I moved to other employers. Knowing assembler got
> me in the door at more than one of those employers.
> >
> > It was the FORTRAN I learned in engineering college that I never used
> anywhere else.
> >
> > Peter
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of Bob T Roller
> > Sent: Saturday, September 17, 2022 3:17 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Assembler courses
> >
> > Learning assembler is like taking latin in high school. It might help you on
> Jeopardy but will not be of much help in real life. I took assembler in 
> college
> & never used it and never worked at an employer that used it. That’s a
> dozen+ employers over 45 years.
> >
> > Sent from Proton Mail for iOS
> >
> > On Fri, Sep 16, 2022 at 10:11 PM, Gary Weinhold 
> wrote:
> >
> >> To help a person who has COBOL and C language experience learn to
> write assembler, I would like them to learn from the start both reentrant and
> baseless coding techniques. Is there training available that assumes the
> instruction set available on the z12 is the starting point and that teaches
> reentrancy as the norm?
> >>
> >> (Cross-posted to IBM-Main and Assembler-list)
> >>
> >> Gary Weinhold
> >> Senior Application Architect
> >> DATAKINETICS | Data Performance & Optimization
> >> Phone:+1.613.523.5500 x216
> >> Email: weinh...@dkl.com
> > --
> >
> > 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

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

Re: Old volumes DFHSM WTOR

[Gibney, Dave]

The Query Active show show you what DFHSM is trying to do that requires the 
volume

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jake Anderson
> Sent: Monday, September 05, 2022 8:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Old volumes DFHSM WTOR
> 
> Unfortunately the started task was recycled (I know it's not the
> rexommeded
> way)
> 
> If this occurs again what is it need to be looking at HSEND Q ACTIVE ?
> 
> I deleted this volumes from the PRIMARY backup
> 
> Is there any other places where this PRIMARY volumes might be stored? May
> be in the tape unit specified under ARCMDXX
> 
> Is there a command to list these volume entries from any of the CDs ?
> 
> On Mon, Sep 5, 2022, 5:11 AM Gibney, Dave <
> 03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > Have you tried an HSEND QUERY ACTIVE command while the WTOR is
> outstanding?
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List 
> On
> > > Behalf Of Jake Anderson
> > > Sent: Sunday, September 04, 2022 11:38 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Old volumes DFHSM WTOR
> > >
> > > I deleted the volume using delvol under primary but still I got a message
> > > about replying with valid device.
> > >
> > > Is there anyother things to be looked at?
> > >
> > > On Sun, May 8, 2022, 12:31 AM Brian Fraser 
> > > wrote:
> > >
> > > > Have you tried DELVOL OSSYB1 PRIMARY? (assuming it was a primary
> > > volume)
> > > >
> > > > Brian
> > > >
> > > > On Sun, 8 May 2022 at 02:39, Jake Anderson
> 
> > > > wrote:
> > > >
> > > > > Hello Group
> > > > >
> > > > > We used to have a volume named OSSYB1 in ARCMDxx which I have
> > > removed
> > > > > already and DFHSM comes up successfully. After sometime DFHSM
> > > complains
> > > > > that the volume OSSYB1 is offline and it throws a WTOR to reply with
> > a
> > > > > valid device number to make it online.
> > > > >
> > > > > Not sure why DFHSM doesn't say anything while initialization but
> > looks
> > > > for
> > > > > the volume after sometime which is not part of ARCMDxx anymore.
> > > > >
> > > > > Is there any places that I need to be looking at ?
> > > > >
> > > > > 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
> >
> > --
> > 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: Old volumes DFHSM WTOR

[Gibney, Dave]

Have you tried an HSEND QUERY ACTIVE command while the WTOR is outstanding?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jake Anderson
> Sent: Sunday, September 04, 2022 11:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Old volumes DFHSM WTOR
> 
> I deleted the volume using delvol under primary but still I got a message
> about replying with valid device.
> 
> Is there anyother things to be looked at?
> 
> On Sun, May 8, 2022, 12:31 AM Brian Fraser 
> wrote:
> 
> > Have you tried DELVOL OSSYB1 PRIMARY? (assuming it was a primary
> volume)
> >
> > Brian
> >
> > On Sun, 8 May 2022 at 02:39, Jake Anderson 
> > wrote:
> >
> > > Hello Group
> > >
> > > We used to have a volume named OSSYB1 in ARCMDxx which I have
> removed
> > > already and DFHSM comes up successfully. After sometime DFHSM
> complains
> > > that the volume OSSYB1 is offline and it throws a WTOR to reply with a
> > > valid device number to make it online.
> > >
> > > Not sure why DFHSM doesn't say anything while initialization but looks
> > for
> > > the volume after sometime which is not part of ARCMDxx anymore.
> > >
> > > Is there any places that I need to be looking at ?
> > >
> > > 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

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

Re: IDC3009I & IDC1566I with a weird dsn

[Gibney, Dave]

I believe they are the best shot at fixing an issue like you describe. 
Since the garbage is in the usercat, FIXVVDS tools aren't likely helpful.

You other possibility would be to define a new usercat and REPRO MERGECAT all 
the good entries to the new usercat.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jack Zukt
> Sent: Wednesday, August 31, 2022 9:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IDC3009I & IDC1566I with a weird dsn
> 
> [EXTERNAL EMAIL]
> 
> Hi Dave,
> I do not think that I will get the go ahead for that, even it would be
> worth a try.
> Thank you anyway
> Regards,
> Jack
> 
> On Wed, 31 Aug 2022 at 16:49, Gibney, Dave <
> 03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > Try a free trial of one of the Catalog utility addons.  Rocket has the
> > Mainstar product. Dinosoft has one.
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List 
> On
> > > Behalf Of Jack Zukt
> > > Sent: Wednesday, August 31, 2022 3:42 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: IDC3009I & IDC1566I with a weird dsn
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > Hi Joe,
> > >
> > > Thank you for you input.  I had seen that.We are running 2.4 in which
> > that
> > > APAR PTF  (UJ00743) has already been SUP (UJ02056)
> > > I have 34 pairs of those messages for 7 usercats, on a job that lists 66
> > > usercats. I think that if this was a bug t would affect all the listcats.
> > > I do not know how these entries got there. Probably some utility that did
> > > not end as expected. But as the "dataset name" does not adhere to MVS
> > > rules, I cannot find a way to get ride of them.
> > > Regards
> > > Jack
> > >
> > >
> > > On Tue, 30 Aug 2022 at 17:36, Joe Monk  wrote:
> > >
> > > > Might be this:
> > >
> https://urldefense.com/v3/__https://www.ibm.com/support/pages/apar/O
> > >
> A57619__;!!JmPEgBY0HMszNaDT!qbrh2jxLqNZygDoVJ62dAkhZOvSQxuhv78u
> > > bqh78z7GtnLWv1yIQyvd8gcrIKNPkHzKfBPotP9zFHQ$
> > > >
> > > > Users of CSI and LISTCAT Level may receive inconsistent errors
> > > > on entries that have no problem otherwise due to uninitialized
> > > > workarea data.
> > > >
> > > >
> > > > Joe
> > > >
> > > > On Tue, Aug 30, 2022 at 9:04 AM Jack Zukt  wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Another situation that come up. Is anyone of you familiar with these
> > > > > messages:
> > > > >
> > > > > IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS
> > > IGG0CLFF-5
> > > > > IDC1566I ** .|. ...8..U...2. NOT LISTED
> > > > >
> > > > > As far as I can see, there is not one dataset with such a name on
> > any of
> > > > > the available DASD. And yet I have 34 of those messages across 7 user
> > > > > catalogs (and they can be there for a long time)
> > > > > Aside from a RC(04) on the LISTCAT CAT(), there seems to be no other
> > > > issue.
> > > > > However, I cannot find a way to get rid of those as the dataset name
> > > does
> > > > > not adhere to restrictions.
> > > > > Any ideas?
> > > > > 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
> >
> 
> --
> 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: IDC3009I & IDC1566I with a weird dsn

[Gibney, Dave]

Try a free trial of one of the Catalog utility addons.  Rocket has the Mainstar 
product. Dinosoft has one.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jack Zukt
> Sent: Wednesday, August 31, 2022 3:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IDC3009I & IDC1566I with a weird dsn
> 
> [EXTERNAL EMAIL]
> 
> Hi Joe,
> 
> Thank you for you input.  I had seen that.We are running 2.4 in which that
> APAR PTF  (UJ00743) has already been SUP (UJ02056)
> I have 34 pairs of those messages for 7 usercats, on a job that lists 66
> usercats. I think that if this was a bug t would affect all the listcats.
> I do not know how these entries got there. Probably some utility that did
> not end as expected. But as the "dataset name" does not adhere to MVS
> rules, I cannot find a way to get ride of them.
> Regards
> Jack
> 
> 
> On Tue, 30 Aug 2022 at 17:36, Joe Monk  wrote:
> 
> > Might be this:
> https://urldefense.com/v3/__https://www.ibm.com/support/pages/apar/O
> A57619__;!!JmPEgBY0HMszNaDT!qbrh2jxLqNZygDoVJ62dAkhZOvSQxuhv78u
> bqh78z7GtnLWv1yIQyvd8gcrIKNPkHzKfBPotP9zFHQ$
> >
> > Users of CSI and LISTCAT Level may receive inconsistent errors
> > on entries that have no problem otherwise due to uninitialized
> > workarea data.
> >
> >
> > Joe
> >
> > On Tue, Aug 30, 2022 at 9:04 AM Jack Zukt  wrote:
> >
> > > Hi all,
> > >
> > > Another situation that come up. Is anyone of you familiar with these
> > > messages:
> > >
> > > IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS
> IGG0CLFF-5
> > > IDC1566I ** .|. ...8..U...2. NOT LISTED
> > >
> > > As far as I can see, there is not one dataset with such a name on any of
> > > the available DASD. And yet I have 34 of those messages across 7 user
> > > catalogs (and they can be there for a long time)
> > > Aside from a RC(04) on the LISTCAT CAT(), there seems to be no other
> > issue.
> > > However, I cannot find a way to get rid of those as the dataset name
> does
> > > not adhere to restrictions.
> > > Any ideas?
> > > 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: Linklist and Syncsort confusion

[Gibney, Dave]

You might have got away with a F LLA,REFRESH. I think you are correct, all 
UNALLOCATE/AlLOCATE does is ENQ related. No re-reading the libraries involved.



> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Pommier, Rex
> Sent: Monday, August 22, 2022 11:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Linklist and Syncsort confusion
> 
> [EXTERNAL EMAIL]
> 
> Hi list,
> 
> I don't know if this is specifically a Syncsort issue or a more generic 
> confusion
> about linklist datasets.  Here goes.
> 
> We have the SYNCLINK library defined in the linklist.  We have installed
> Precisely's IEBGENER replacement as part of our install.  We determined
> SYNCLINK was too small.  I allocated a larger version of the library on the
> same volume as the current one.  We had an IPL scheduled for Saturday so
> right before the IPL, I logged in and did the library swap.  My process was 
> (as I
> thought) pretty standard.
> 
> Shut down LLA and VLF
> SETPROG LNKLST,UNALLOCATE
> Rename the 2 libraries to get the new, larger one with the right name
> SETPROG LNKLST,ALLOCATE
> Start LLA and VLF.
> 
> The operator then needed to run a couple pre-IPL jobs that use IEBGENER.
> They failed with
> IEW4009I FETCH FAILED FOR MODULE IEBGENER FROM DDNAME -LNKLST-
> BECAUSE OF AN I/O ERROR.
> IEW4005I FETCH FOR MODULE IEBGENER FROM DDNAME -LNKLST- FAILED
> BECAUSE IEWFETCH ISSUED RC 0F AND REASON 40
> CSV031I LIBRARY ACCESS FAILED FOR MODULE IEBGENER, RETURN CODE 24,
> REASON CODE 26080021, DDNAME *LNKLST*
> 
> The manuals were less than helpful.  IPLing took care of the problem but I'm
> not clear as to either what I did wrong or if my understanding of the
> UNALLOCATE/ALLOCATE is wrong.  I was under the impression that doing the
> UNALLOCATE then ALLOCATE rebuilt the linklist.  It appears now to me that
> all the UNALLOCATE does is remove the enqueues on the datasets and
> ALLOCATE simply reestablishes the enqueues, still pointing to the original
> location, but even that doesn't compute in my mind because I didn't change
> any locations of either the old or new libraries.  Or was it a mismatch
> between the linklist and the LLA, and that possibly the linklist was still
> pointing to the original location of the SYNCLINK library but the LLA is now
> pointing to the new location?  Would I have not had the problem if, instead
> of just doing the UNALLOCATE/ALLOCATE, I would have built and activated a
> LNKLST01 concatenation?
> 
> I see the cautions in the system commands manual against moving or
> deleting a linklist dataset while the allocations are inactive and I 
> obviously got
> burned by disobeying that warning.  I'm just trying to figure out what the
> UNALLOCATE is doing and how to not have this happen when I have to
> perform this kind of maintenance.
> 
> TIA,
> 
> Rex
> 
> --
> 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 intended recipient, you are hereby notified that any
> disclosure, distribution, copying, or any action taken or action omitted in
> reliance on it, is strictly prohibited and may be unlawful. If you have 
> received
> this communication in error, please notify us immediately by replying to this
> message and destroy the material in its entirety, whether in electronic or
> hard copy format. Thank you.
> 
> 
> --
> 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