Re: zOSMF - Installing z/OS 3.1 Observations
When all else fails, use a sledge hammer! Sent with Proton Mail secure email. On Wednesday, May 15th, 2024 at 8:50 AM, Shaffer, Terri <017d5f778222-dmarc-requ...@listserv.ua.edu> wrote: > So this is my first real time using zOSMF for a software installation. So I > have a few complaints. > > First No SSA is being used, IBM decided to tack on a .# to every dataset, > HATE this and I modified it. > > I have SMS rules already defined for SYS1SSA, so I changed my configuration > layout to my SYS1 datasets are now SYS1SSA.SYS1. > > This allowed my already setup SMS rules to function. > > NEXT they don’t allow an already added defined ZFS for workdir to be used, > they wanted to allocate at 14451 cylinder dataset. Not going to happen. > > I already have 2 full MOD-27 defined for SMPNTS and UNZIP space. > > So I edited the BUILT JCL and deleted every place they tried to define and > use /tmp and pointed to my already defined work space! > > And my jobs are happily running now.. > > Ms Terri E Shaffer > Senior Systems Engineer, > z/OS Support: > ACIWorldwide – Telecommuter > H(412-766-2697) C(412-519-2592) > terri.shaf...@aciworldwide.com > > > > [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] > http://www.aciworldwide.com > > This email message and any attachments may contain confidential, proprietary > or non-public information. The information is intended solely for the > designated recipient(s). If an addressing or transmission error has > misdirected this email, please notify the sender immediately and destroy this > email. Any review, dissemination, use or reliance upon this information by > unintended recipients is prohibited. Any opinions expressed in this email are > those of the author personally. > > -- > 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/OS freeware
We are in the process of converting from one JCL/SYSOUT archiver to another one. We need the ability to feed the current and new archiver. At my previous life, we used JRB to accomplish that. My current employer will not spend the additional money to get JRB (even though it is relatively inexpensive, and can be rented on a monthly basis). Sent with Proton Mail secure email. On Tuesday, May 14th, 2024 at 9:33 AM, Lionel B. Dyck <057b0ee5a853-dmarc-requ...@listserv.ua.edu> wrote: > What functions/features do you need? > > > Lionel B. Dyck <>< > > Github: https://github.com/lbdyck > System Z Enthusiasts Discord: https://discord.gg/sze > > “Worry more about your character than your reputation. Character is what you > are, reputation merely what others think you are.” - - - John Wooden > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > rpinion865 > > Sent: Tuesday, May 14, 2024 8:24 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: z/OS freeware > > I need the functionality of McKinney Systems JRB (JES Report Broker) product, > but for free. Is there anything on the CBTTape that would do what JRB does? > > Sent with Proton Mail secure email. > > -- > 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
z/OS freeware
I need the functionality of McKinney Systems JRB (JES Report Broker) product, but for free. Is there anything on the CBTTape that would do what JRB does? Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Consultation on the Potential Risks of Deleting Specific Datasets
You will need to consider datasets coded in JCL that are not opened. Unless a dataset is opened, the last reference date will not be set. Sent with Proton Mail secure email. On Wednesday, May 8th, 2024 at 8:17 AM, Jason Cai wrote: > Dear all > > I am reaching out to discuss a specific operation we are considering for our > z/OS DCOLLECT reports. Currently, we are planning to delete all the datasets > where LASTREF=NONE and DSORG=PS. This operation seems crucial for system > maintenance and optimization, yet I wanted to clarify any potential risks > associated with this action. > As far as I understand, LASTREF refers to the last accessed date of the file. > Hence, LASTREF=NONE implies that the file has not been accessed since its > creation. Could you confirm if my understanding is correct？ > Additionally, I have been attempting to search for more information about > LASTREF=NONE in the IBM manual, but my efforts have yielded limited success. > If possible, could you kindly guide me on how to navigate the manual to find > specific information like this one or recommend any reliable resources where > such details may be more readily available? > > Lastly, does IBM have any specific requirements regarding the closure of PS > datasets? By this I mean if a PS has been opened and never closed, would the > LASTREF also be none? > > Any advice or insights you have on this matter would be highly appreciated. > Looking forward to your helpful response. > Best regards, > Jason Cai > > -- > 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
LOL, "polish my English" a small play on words. Sent from Proton Mail Android Original Message On 4/27/24 6:07 PM, Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > (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: SMS & GDG SCRATCH option
I think ACC from DTS Software gave one the ability to override things in the JCL, IDCAMS define, and SMS parameters. Sent with Proton Mail secure email. On Thursday, April 18th, 2024 at 10:14 AM, Gormley, Steve <062689d47664-dmarc-requ...@listserv.ua.edu> wrote: > Hi > You can’t do anything in the ACS routines as a GDG base define isn’t an > allocation. > You have the option of setting the default in IGGCATxx member in Parmlib - > GDGSCRATCH(YES) > But if people code noscratch in their IDCAMS JCL this will override the > default > > Steve > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Jack Zukt > > Sent: Thursday, April 18, 2024 14:49 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SMS & GDG SCRATCH option > > Hi all, Where, if possible, on the ASC routines of a SMS managed environment, > can I force the SCRATCH option for a GDG base entry at definition time? > Regards Jack > -- For > IBM-MAIN > ZjQcmQRYFpfptBannerStart > This Message Is From an External Sender > Do not click links or open attachments unless you recognize the sender and > know the content is safe. > ZjQcmQRYFpfptBannerEnd > > Hi all, > > > > Where, if possible, on the ASC routines of a SMS managed environment, can I > > force the SCRATCH option for a GDG base entry at definition time? > > Regards > > Jack > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edumailto: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: Anyone exploiting ZEDC?
Also, you will need this for SMF compression. ISRBROBA PINIONR.BAS.PARMLIB(SMFPRM00) - 01.12Line 00 Col 00 Command ===> Scroll ===> Top of Data INTVAL(30) /* SMF GLOBAL RECORDING INTERVAL*/ ACTIVE /* ACTIVE SMF RECORDING */ RECORDING(LOGSTREAM) LSNAME(IFASMF.,TYPE(110),COMPRESS) LSNAME(IFASMF.,TYPE(100:102),COMPRESS) LSNAME(IFASMF.,TYPE(70,89),COMPRESS) LSNAME(IFASMF.,TYPE(0:99,103:109,111:2047), COMPRESS) Sent with Proton Mail secure email. On Wednesday, April 17th, 2024 at 8:08 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Thank-you very much for this! I suspect this is the route we will have to > take. To answer your other question, yes, ZEDC is a chargeable feature > (although very inexpensive) and is turned on in IFAPRD00. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of > rpinion865 042a019916dd-dmarc-requ...@listserv.ua.edu > > Date: Tuesday, April 16, 2024 at 3:41 PM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Anyone exploiting ZEDC? > FWIW, here is a snippet of the SMS ACS DC code that we were using for zEDC. > /* DEFINE extra data sets to receive zEDC compression / > // > FILTLIST COMP_DSN INCLUDE(CCM. CCM. FDR. *, > > > FWIW, here is a snippet of the SMS ACS DC code that we were using for zEDC. > > > > / DEFINE extra data sets to receive zEDC compression / > > > > // > > > > > > > > FILTLIST COMP_DSN INCLUDE(CCM.CCM.FDR., > > RMS.PROD.MSA.BKUP., > > LOGR.IFASMF., > > DB2%.ARCHLOG%.) > > > > - - - - - - - - - - - - - - - - - - 46 Line(s) not Displ > > > > /* RULES FOR DISK zEDC HW data compression / > > > > /*/ > > > > WHEN ( = _DSN) SET ='COMP' > > WHEN ( = 'GDS' && > 270MB) > > > SET ='COMP' > > WHEN ( = 'ADRDSSU' && > 55MB) > > > SET ='COMP' > > > > > > > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > 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: Anyone exploiting ZEDC?
Is it not true that even though you get the zEDC engines on the z15 and z16,
you still have to pay for the exploitation by enabling Featurename('ZEDC') in
parmlib's IFAPRDxx?
Sent with Proton Mail secure email.
On Wednesday, April 17th, 2024 at 4:44 AM, Timothy Sipples
wrote:
> rpinion865 wrote:
>
> > At a prior life, we got the zEDC cards on a z15, and turned that on
> > for PS datasets.
>
>
> Just to clarify, every IBM z15, LinuxONE III, and higher model machine has
> on-chip zEDC (compression). It’s formally called the “Integrated Accelerator
> for zEDC,” and you can expand the zEDC part if you want to be more verbose.
> On-chip zEDC is included at no additional charge in these more recent
> machines. No zEDC cards required, no machine feature code required. Moreover,
> it’s not possible to carry forward the zEDC cards to the newer machine models
> even if you wanted to.
>
> I realize it’s not the major point of this thread, but here’s a quick comment
> about VSAM performance. I think it’s important to “sanity check” performance
> assumptions periodically because past assumptions often no longer reflect
> reality and time and technology progress. When I participate in such
> assessments (and write reports) I typically include an “expiration date.” I
> include a statement such as, “We recommend reassessing these performance
> metrics no later than April 30, 2028.” That sort of statement might be based
> on some educated guesswork, but I try to set a reasonable boundary in the
> circumstances. There’ve been lots of VSAM-related performance improvements
> over the years and decades, and they continue. zHyperWrite and the IBM Z
> Digital Integration Hub (zDIH) are only two examples.
>
> In terms of zEDC applicability to VSAM, just in case anybody needs the
> official documentation here it is (z/OS 3.1 link):
>
> https://www.ibm.com/docs/en/zos/3.1.0?topic=sets-characteristics-compressed-format-data
>
> The “Requirements for Compression” subsection is also relevant.
>
> There’s a lot of meaning packed into those two pages, more than usual I’d
> say. For example, these words are quite important: “A compressed format data
> set cannot be opened for update.” Those few words are doing some heavy
> lifting. I’d add that a non-compressed format data set (that can be opened
> for update) CAN contain data compressed with zEDC. As one example, a Java
> program can compress data with zEDC then store the compressed data in a data
> set (via JZOS for example).
>
> —
> Timothy Sipples
> Senior Architect
> Digital Assets, Industry Solutions, and Cybersecurity
> IBM Z/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: Anyone exploiting ZEDC?
FWIW, here is a snippet of the SMS ACS DC code that we were using for zEDC. /* DEFINE extra data sets to receive zEDC compression */ /**/ FILTLIST COMP_DSN INCLUDE(CCM.CCM.FDR.**, RMS.PROD.MSA.BKUP.**, LOGR.IFASMF.**, DB2%.ARCHLOG%.**) - - - - - - - - - - - - - - - - - - 46 Line(s) not Displ /* RULES FOR DISK zEDC HW data compression*/ /**/ WHEN ( = _DSN) SET ='COMP' WHEN ( = 'GDS' && > 270MB) SET ='COMP' WHEN ( = 'ADRDSSU' && > 55MB) SET ='COMP' Sent with Proton Mail secure email. On Tuesday, April 16th, 2024 at 3:30 PM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > No Hogan here. We use IAM in a bunch of applications because it is > significantly faster than VSAM (or was). > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of > rpinion865 042a019916dd-dmarc-requ...@listserv.ua.edu > > Date: Tuesday, April 16, 2024 at 3:27 PM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Anyone exploiting ZEDC? > Curious, do you use IAM for Hogan applications? My previous life did, and the > applications group was very satisfied with the IAM performance vs. native > VSAM. However, we had to impress on them, that periodic reorgs were more > necessary for IAM, > > > Curious, do you use IAM for Hogan applications? My previous life did, and the > applications group was very satisfied with the IAM performance vs. native > VSAM. However, we had to impress on them, that periodic reorgs were more > necessary for IAM, than under VSAM. And, we found out that ADRDSSU > dump/restore of VSAM was what was being used to perform VSAM reorgs, as > opposed to IDCAMS REPRO, DELETE, > > DEFINE, REPRO. Guess what, ADRDSSU sees an IAM dataset as extended format PS! > > > > > > > > > > Sent with Proton Mail secure email. > > > > > On Tuesday, April 16th, 2024 at 3:02 PM, Jousma, David > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu wrote: > > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > 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: Anyone exploiting ZEDC?
Curious, do you use IAM for Hogan applications? My previous life did, and the applications group was very satisfied with the IAM performance vs. native VSAM. However, we had to impress on them, that periodic reorgs were more necessary for IAM, than under VSAM. And, we found out that ADRDSSU dump/restore of VSAM was what was being used to perform VSAM reorgs, as opposed to IDCAMS REPRO, DELETE, DEFINE, REPRO. Guess what, ADRDSSU sees an IAM dataset as extended format PS! Sent with Proton Mail secure email. On Tuesday, April 16th, 2024 at 3:02 PM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Thanks for that. We do have IAM here, we’ll open a ticket with BMC asking > about support. I was just doubting since it presents to the OS as a VSAM > dataset. > > We were hoping to make ZEDC “inclusive” as in everyone gets it to reap the > space reduction, and job performance improvements and that the OS would > decide for us if a particular dataset that has the DATACLAS assigned to it > would just ignore, but that wont be the case. > > I have the ability to code ZEDC_preferred or ZEDC-Required. Required will > actually fail the allocation, which I don’t want to either, but I also don’t > want to use non-accelerated compression either. > > So, now as you pointed out, we’ll have to approach ZEDC as “exclusive” and > only opt-in file types that are supported like GDG’s for sure. We may roll > the dice on all PS, exempting temp datasets and ISPF work datasets, and more > as we stumble upon other incompatibilities. > > With knowing the technical details, I think IBM missed the boat here. ZEDC > ought to be a drop-in replacement for compression, period. I can specify > COMPACTION YES for VSAM files but ZEDC wont touch them. Why? > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of > rpinion865 042a019916dd-dmarc-requ...@listserv.ua.edu > > Date: Tuesday, April 16, 2024 at 2:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Anyone exploiting ZEDC? > At my previous life, we were using BMC's IAM VSAM interface. I think IAM > could use zEDC. But I was told by then IDP support, that IAM's internal > compression was Moe (as in Moe Howard) better than even zEDC. Regarding > coding for PS datasets > > > At my previous life, we were using BMC's IAM VSAM interface. I think IAM > could use zEDC. But I was told by then IDP support, that IAM's internal > compression was Moe (as in Moe Howard) better than even zEDC. > > > > Regarding coding for PS datasets opened in/out, I think DAF will show how a > PS dataset is being opened. We chose to use zEDC compression for > new,catlg,delete GDGs because we were very confident that no one was going to > process that combination as in/out. > > And does not the IBM zBNA tool highlight good candidates? We did not want to > clutter up our SMS ACS DC routines with too many actions to put certain PS > datasets into zEDC compression. But in the end, we did put certain large PS, > not opened in/out, datasets in the ACS DC routine. > > > > > > > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > 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: Anyone exploiting ZEDC?
At my previous life, we were using BMC's IAM VSAM interface. I think IAM could use zEDC. But I was told by then IDP support, that IAM's internal compression was Moe (as in Moe Howard) better than even zEDC. Regarding coding for PS datasets opened in/out, I think DAF will show how a PS dataset is being opened. We chose to use zEDC compression for new,catlg,delete GDGs because we were very confident that no one was going to process that combination as in/out. And does not the IBM zBNA tool highlight good candidates? We did not want to clutter up our SMS ACS DC routines with too many actions to put certain PS datasets into zEDC compression. But in the end, we did put certain large PS, not opened in/out, datasets in the ACS DC routine. Sent with Proton Mail secure email. On Tuesday, April 16th, 2024 at 1:58 PM, Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > I could be wrong about VSAM compression here then. Maybe that is all CP > compressed and I misunderstood by what mechanism that is done. We could not > survive here without VSAM compression. Many of our VSAM files are > 4G space > even compressed. > > > I do know we ARE using zEDC based on various internal communications I have > seen. I just do not know the exact details. > > Peter > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Jousma, David > > Sent: Tuesday, April 16, 2024 1:13 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Anyone exploiting ZEDC? > > > Peter, > > > > Interesting. IBM says VSAM does NOT exploit ZEDC. VSAM can be compressed, but > it must all be done on CP, which would be expensive. Within a VSAM LINEAR > dataset used as ZFS, ZFS will engage ZEDC. > > > > Dave Jousma > > Vice President | Director, Technology Engineering > > > > From: IBM Mainframe Discussion List > mailto:IBM-MAIN@LISTSERV.UA.EDU> on behalf of > Farley, Peter > <031df298a9da-dmarc-requ...@listserv.ua.EDUmailto:031df298a9da-dmarc-requ...@listserv.ua.edu> > > > Date: Tuesday, April 16, 2024 at 1:10 PM > > To: ibm-m...@listserv.ua.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU > mailto:IBM-MAIN@LISTSERV.UA.EDU> > > > Subject: Re: Anyone exploiting ZEDC? > > > > I do not know what criteria the sysprogs here set things up. But we are > successfully using zEDC here especially for our huge VSAM and GDG production > files. > > > > I wish I could tell you more, but the sysprogs here are outsourced and > getting answers from them requires official paperwork and bureaucracy that I > have no business reason to cover. > > > > From: IBM Mainframe Discussion List > mailto:IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of > Jousma, David > > > > > Sent: Tuesday, April 16, 2024 12:39 PM > > > > To: ibm-m...@listserv.ua.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU > > > > > Subject: Re: Anyone exploiting ZEDC? > > > > Thank-you for this feedback. I’m starting to feel like this is a half-baked > solution looking for a problem. I know of no way to systematically code for > open for update…. > > > > Dave Jousma > > Vice President | Director, Technology Engineering > > > > From: IBM Mainframe Discussion List > mailto:IBM-MAIN@LISTSERV.UA.EDU> on behalf of > rpinion865 > <042a019916dd-dmarc-requ...@listserv.ua.EDUmailto:042a019916dd-dmarc-requ...@listserv.ua.edu> > > > > > Date: Tuesday, April 16, 2024 at 12:29 PM > > > > To: ibm-m...@listserv.ua.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU > mailto:IBM-MAIN@LISTSERV.UA.EDU> > > > > > Subject: Re: Anyone exploiting ZEDC? > > > > At a prior life, we got the zEDC cards on a z15, and turned that on for PS > datasets. But like you, we quickly learned that PS datasets opened for in/out > processing (update in place) did not work. As a compromise, we narrowed down > to new PS > > > > At a prior life, we got the zEDC cards on a z15, and turned that on for PS > datasets. But like you, we quickly learned that PS datasets opened for in/out > processing (update in place) did not work. As a compromise, we narrowed down > to new PS GDG datasets. Also we looked at new PS GDG datasets over a certain > size. We picked an arbitrary number of tracks/cylinders to apply the zEDC > compression to. Once we did that, our production job abends disappeared and > we started seeing a reduction in space usage on the storage groups where > these datasets were being allocated on. > > > > Sent with Proton Mail secure email. > > > > > On Tuesday, April 16th, 2024
Re: Anyone exploiting ZEDC?
At a prior life, we got the zEDC cards on a z15, and turned that on for PS datasets. But like you, we quickly learned that PS datasets opened for in/out processing (update in place) did not work. As a compromise, we narrowed down to new PS GDG datasets. Also we looked at new PS GDG datasets over a certain size. We picked an arbitrary number of tracks/cylinders to apply the zEDC compression to. Once we did that, our production job abends disappeared and we started seeing a reduction in space usage on the storage groups where these datasets were being allocated on. Sent with Proton Mail secure email. On Tuesday, April 16th, 2024 at 12:16 PM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Is anyone exploiting ZEDC data compression accelerator in your environments? > We recently licensed the enablement and are working through the issues in our > DEV environment. > > We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, > but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have > issues. We’ve turned back off for now. > > There is no central location in any IBM doc(including recent REDBOOKS) that > discusses where we can and cannot leverage ZEDC. As it stands now, we had to > back out, and looking at taking a new approach in our ACS routines checking > for DSORG=PS, and then if not temp-dataset, or tape assign a DC with the > right options. > > What I am wondering is if anyone is further along that can share how they > rolled out? I really don’t want to have to make the applications teams have > to “opt-in” by coding a DC in their JCL or other dataset allocations. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > 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: IBM key management products
Did you have the auditors present so they could certify your actions :) ? Sent with Proton Mail secure email. On Monday, April 15th, 2024 at 2:32 PM, Pommier, Rex wrote: > Didn't phase the drill bit one bit (sorry for the bad pun). I just had to be > careful not to punch a hole in the bottom of the drives so as to not get > glass shards dropping on my (very messy) shop floor. > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of Tom > Brennan > > Sent: Monday, April 15, 2024 12:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXTERNAL] Re: IBM key management products > > Nice! That's the first I've heard of glass platters. Hope your drill bit > survived the trauma :) > > On 4/15/2024 8:33 AM, Pommier, Rex wrote: > > > Hi Tom, > > > > Regarding #2, at a former job I got to decommission an HDS box that > > was shared between the mainframe and Unix boxes. Unencrypted disk in > > it. Mgmt wanted the data destroyed so they asked me to take the > > individual drives home and drill through each of them. That was when > > I found out that this particular disk drive had glass platters. There > > was no getting data off them when the drill bit shattered every > > platter in every spindle. > > > > Rex > > > > -Original Message- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > Behalf Of Tom Brennan > > Sent: Friday, April 12, 2024 1:41 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [EXTERNAL] Re: IBM key management products > > > > We use SKLM/GKLM for data-at-rest encryption of DS8000/TS7000 devices, all > > internal disk storage, no external cartridge tapes. So what does that do > > for the customer, since (unless you're using an additional form of > > encryption on the mainframe) the data is still spit out of the devices > > unencrypted (not counting the additional feature that allows > > FICON-in-transit encryption). > > > > I have a few theories on this: > > > > #1 If someone gets into the datacenter and steals disks (or the entire > > DS/TS box), the encrypted contents should be useless. > > > > #2 When a DS/TS box is decommissioned, a customer could "potentially" > > skip any further destruction of the data in the box. Still, what I've > > seen in reality for decom is to run the IBM SDO (secure data overwrite > > to blot out the disks) and sometimes even shred the individual disks > > (I'd sure like to see that in action!) > > > > #3 If you steal a DS/TS box, make sure you steal the associated key server > > unit too. > > > > I'd appreciate any comments on these theories. > > > > On 4/12/2024 9:21 AM, Jousma, David wrote: > > > > > To place a bit more focus on what Rick says….. You lose/destroy the > > > key(s), you have lost your data. There is a lot of discussion about the > > > scope/use of the keys. One key, or one per application, or one per > > > dataset, etc. There is no right/wrong answer (well just one key for > > > everything is probably not advisable). > > > > > > I personally am still having a hard time wrapping my head around the > > > “real benefit” of dataset encryption. Everyone who has READ or more > > > access to the dataset, must also be permitted to the Key. Those same > > > people are still able to copy/print/steal that data. So who does that > > > leave? Those that are not permitted to the dataset, and those who > > > administer the storage. Those that don’t have access to the dataset > > > aren’t going to get the data, encrypted or not. Those who administer the > > > storage usually have access to move/manage the installations data. These > > > are the people who dataset encryption is protecting against. That is a > > > very small population to go to this effort on. > > > > > > Dave Jousma > > > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on > > > behalf of Rick Troth 058ff5c2d0a7-dmarc-requ...@listserv.ua.edu > > > Date: Friday, April 12, 2024 at 10:59 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: IBM key management products Not discounting Luke's > > > excellent response: key management is hard. Look for utilities with > > > reliable import/export capability. Be prepared to OWN your keys. I > > > say this again as a CISSP, own your keys. This is your bread and > > > butter, so to speak, > > > > > > Not discounting Luke's excellent response: key management is hard. > > > > > > Look for utilities with reliable import/export capability. Be > > > prepared > > > > > > to OWN your keys. > > > > > > I say this again as a CISSP, own your keys. This is your bread and > > > > > > butter, so to speak, the family jewels. > > > > > > So take care when using these products to ensure that they do what > > > you > > > > > > want them to do and that you know what they're doing. > > > > > > One shop where I recently worked had a great
Re: DFSORT SUBDAYS function
You are correct about the record format and length. Thank you for the control statements! Sent with Proton Mail secure email. On Tuesday, April 9th, 2024 at 12:12 PM, Sri Hari Kolusu wrote: > > > The date begins in column 1 and is 10 characters long. I know I want to > > > use the SUBDAYS function. I am looking at the DFSORT Programmer Guide. > > > But I learn best by example. > > > Richard, > > Your input date has separators and DFSORT date arithmetic functions works on > date without separators. So, we just need to strip off the separators and > then apply the SUBDAYS function. > > I assumed your input has RECFM=FB and LRECl=80 and you want to subtract 35 > days from the input. We first strip off the separators and put that date a > temp location (81) and then apply the subdays function on that. Here is a > sample. > > > //STEP0100 EXEC PGM=SORT > //SYSOUT DD SYSOUT=* > //SORTIN DD * > 2024/04/09 - CURR DATE > 2024/02/28 - NON LEAP YEAR DATE > 2024/02/29 - LEAP YEAR DATE > 2007/02/29 - INVALID DATE > //SORTOUT DD SYSOUT=* > //SYSIN DD * > SORT FIELDS=COPY > INREC IFOUTLEN=80, > IFTHEN=(WHEN=INIT, > OVERLAY=(81:01,10,UFF,M11,LENGTH=8, > 01:81,8,Y4T,SUBDAYS,+35,TOGREG=(Y4T(/ > /* > > The output from the above is. > > 2024/03/05 - CURR DATE > 2024/01/24 - NON LEAP YEAR DATE > 2024/01/25 - LEAP YEAR DATE > ** - INVALID DATE > > > Note that the last record has an invalid date and that subdays function > replaced it with asterisks. > > > Thanks, > Kolusu > DFSORT Development > IBM Corporation > > > > -- > 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
DFSORT SUBDAYS function
I have the following field in a dataset, that I want to subtract days from, leaving the date in the original format. The date begins in column 1 and is 10 characters long. I know I want to use the SUBDAYS function. I am looking at the DFSORT Programmer Guide. But I learn best by example. 2024/04/09 Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
As you have determined, it seems that MODE B (Block Mode) is the kicker. Using XMIT or TERSE would eliminate the need for MODE B. But we all know there is CPU consumption from using those two utilities on both ends. Sent with Proton Mail secure email. On Thursday, March 28th, 2024 at 10:31 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > And all lpars are at the same levels of software. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: Jousma, David david.jou...@53.com > > Date: Thursday, March 28, 2024 at 10:30 AM > To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Slow FTP's > Max, > > As mentioned, the 50Gb file with MODE B and EBCDIC is slow. Same file just > binary mode, it is fast. Of course, cant transmit a DSS dump as just binary. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of > Massimo Biancucci 05a019256424-dmarc-requ...@listserv.ua.edu > > Date: Thursday, March 28, 2024 at 10:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Slow FTP's > Dave, it becomes more interesting. Could it depend on the file data itself ? > Have you tried a BIG file, EBCDIC with mostly the same data inside ? Same > kind of transmission, MODE B and EBCDIC. Regards. Max. Il giorno gio 28 mar > 2024 alle ore > > > Dave, > > > > it becomes more interesting. > > Could it depend on the file data itself ? > > > > Have you tried a BIG file, EBCDIC with mostly the same data inside ? > > Same kind of transmission, MODE B and EBCDIC. > > > > Regards. > > Max. > > > > > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > 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: Slow FTP's
What about non-zEDC compression for the destination output dataset? Sent with Proton Mail secure email. On Thursday, March 28th, 2024 at 10:08 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > As I mentioned, a standard binary transfer runs all day to all lpars at > 140Mb/sec. It seems that only DSS dump files with MODE B, and EBCDIC > specified slows them down. > > I have reached out to our network/firewall teams to see if there some sort of > data inspection going on. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of > Styles, Andy (CIO GS - Core Infrastructure & IT Operations ) > 00d68f765d25-dmarc-requ...@listserv.ua.edu > > Date: Thursday, March 28, 2024 at 9:54 AM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Slow FTP's > Classification: Public Do you have access to any other kind of transfer > mechanism, and if so, does it happen with that too? (thinking Connect: Direct > for example). Is the target device of the transfer the same on fast vs slow? > Andy Styles z/Series > > > Classification: Public > > > > Do you have access to any other kind of transfer mechanism, and if so, does > it happen with that too? (thinking Connect:Direct for example). > > Is the target device of the transfer the same on fast vs slow? > > > > Andy Styles > > z/Series Systems Programmer > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > 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: Slow FTP's
FWIW I transferred a DSS dump of a z/OS 2.4 SYS1.LINKLIB (3540 tracks) to a test LPAR that is capped and to a production LPAR that is not capped. On the test LPAR I got 31MB/sec and on the production LPAR I got 70MB/sec. Sent with Proton Mail secure email. On Thursday, March 28th, 2024 at 9:36 AM, Mike Schwab <05962a42dc49-dmarc-requ...@listserv.ua.edu> wrote: > How about processors (z15/z16)? > > On Thu, Mar 28, 2024 at 7:30 AM Jousma, David > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu wrote: > > > All, > > > > Grasping at straws here, IBM support center is baffled too. > > > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > > transfer. There is some environmental issue causing slow file transfers to > > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other > > systems on the same CEC. With IBM support help, we’ve narrowed down the > > problem to the specification of MODE B and EBCDIC on the transfer since it > > is a DSS dump. Remove those, and the transfer is fast on the slow systems, > > and still fast on the fast systems. Obviously that isn’t a solution though. > > > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are to > > the K systems(control systems), and all the “slow” transfers are to the > > traditional application systems. TEST, DEV, PROD makes no difference, nor > > does LPAR busy or not busy. > > > > It seems there is something configured differently on the “slow” systems > > that is affecting mode b, ebcdic file transfers, but for the life of me, I > > cannot put my finger on what, nor can the support center, except that the > > issue is at the remote end, in that the OS cannot offload the data fast > > enough, so TCPIP/FTP is slowing the transfer pace. > > > > A virtual adult beverage of choice to the one that can point in a direction > > to look…. > > > > Dave Jousma > > Vice President | Director, Technology Engineering > > > > This e-mail transmission contains information that is confidential and may > > be privileged. It is intended only for the addressee(s) named above. If you > > receive this e-mail in error, please do not read, copy or disseminate it in > > any manner. If you are not the intended recipient, any disclosure, copying, > > distribution or use of the contents of this information is prohibited. > > Please reply to the message immediately by informing the sender that the > > message was misdirected. After replying, please erase it from your computer > > system. Your assistance in correcting this error is appreciated. > > > > -- > > 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: Slow FTP's
z/OS TCP/IP is not my area of expertise. I would check to insure the ITRACE and PKTTRACE are turned off, and take a look at TCPCONFIG TCPMAXRCVBUFRSIZE TCPRCVBUFRSIZE TCPSENDBFRSIZE And, another possibility D TCPIP,tcpipname,NETSTAT,DEV Look for CHECKSUMOFFLOAD YES Sent with Proton Mail secure email. On Thursday, March 28th, 2024 at 8:30 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > All, > > Grasping at straws here, IBM support center is baffled too. > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file transfer. > There is some environmental issue causing slow file transfers to some systems > (40mb’s a sec) and fast file transfers (150Mb/sec) to other systems on the > same CEC. With IBM support help, we’ve narrowed down the problem to the > specification of MODE B and EBCDIC on the transfer since it is a DSS dump. > Remove those, and the transfer is fast on the slow systems, and still fast on > the fast systems. Obviously that isn’t a solution though. > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are to > the K systems(control systems), and all the “slow” transfers are to the > traditional application systems. TEST, DEV, PROD makes no difference, nor > does LPAR busy or not busy. > > It seems there is something configured differently on the “slow” systems that > is affecting mode b, ebcdic file transfers, but for the life of me, I cannot > put my finger on what, nor can the support center, except that the issue is > at the remote end, in that the OS cannot offload the data fast enough, so > TCPIP/FTP is slowing the transfer pace. > > A virtual adult beverage of choice to the one that can point in a direction > to look…. > > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > 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: Changes to user's TSO PROFILE
I did some checking of our CLIST libraries, and found a CLIST which changes the TSO PROFILE setting. The user says she uses that CLIST quite often. Thanks for your help everybody! Sent with Proton Mail secure email. On Monday, March 4th, 2024 at 10:21 AM, Lennie Bradshaw wrote: > The TSO prefix is stored in an unprotected control block (the ECT I think). > As such, almost any program running in the TSO session can change it. I don't > think that any of RACF, ACF2 or TSS can protect you against that. > > Lennie > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Steve Beaver > > Sent: 04 March 2024 15:09 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Changes to user's TSO PROFILE > > Is there anything that tracks changes to a TSO user's PREFIX? I have a user > who says her PREFIX keeps getting changed to NOPREFIX. > > RACF, ACF2, TSS > > Regards, > > > Steve > > > > > 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-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jousma, David > Sent: Monday, March 4, 2024 8:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Changes to user's TSO PROFILE > > Is she logging off cleanly? Or is she letting her session 522 off. If the > latter profile changes don’t get written out and would explain the behavior. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of > rpinion865 042a019916dd-dmarc-requ...@listserv.ua.edu > > Date: Monday, March 4, 2024 at 9:40 AM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > Subject: Changes to user's TSO PROFILE > Is there anything that tracks changes to a TSO user's PREFIX? I have a user > who says her PREFIX keeps getting changed to NOPREFIX. Sent with Proton Mail > > > Is there anything that tracks changes to a TSO user's PREFIX? I have a user > who says her PREFIX keeps getting changed to NOPREFIX. > > > > Sent with Proton Mail secure email. > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > 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
Changes to user's TSO PROFILE
Is there anything that tracks changes to a TSO user's PREFIX? I have a user who says her PREFIX keeps getting changed to NOPREFIX. Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSMSHSM reports.
Also, if you have FDREPORT it can report on HSM. Sent from Proton Mail mobile Original Message On Mar 2, 2024, 10:32 AM, Nigel Morton wrote: > Claude, I have used DFSORT in the past to create reports, usually for one-off > projects. A few thoughts on the idea of HSM reporting: 1. Detecting > migrate/recall thrashing is a good thing to do 2. Reviewing migration and > backup failures is probably worthwhile. I've seen datasets failing to migrate > day after day (usually because of invalid DSORG which can point to datasets > being allocated and consuming space but never, ever opened) and it's wasteful > to repeat the same checks and fail every day. 3. There's a lot of good stuff > in DCOLLECT records, too. 4. IBM has an HSM reporting product, Tivoli > Advanced Reporting for DFSMShsm. IMHO, this is overkill but the documentation > might give you some ideas for your own reports. HTH Regards On Fri, 1 Mar > 2024 at 20:07, Claude Richbourg wrote: > Good afternoon all, > > I have a > little side project going on here to see what kind of reports I > can get > from SMF type 240 and 241 records for HSM. We use HSM quite a lot > and > currently we don't have any reports for it yet. > > When I look at the record > layout from the DFSMSHSM Data Areas manual, I > was amazed on the extensive > amount of offsets in the DSR - Daily Statistics > Record. > > The question I > have is/has anyone created a report from those and did you > use SAS, > Easytrieve or DFSORT to do so? > I am looking at Easytrieve, as we have that > here and I just wanted to see > if anyone else has created those HSM reports > from the SMF records. > > > Best Regards, > Claude > > > -- > 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: Insecure security -- When broken how far it may reach.....
Regarding the OPM incident. I received a letter stating that my information had been accessed. I have never worked for the federal government, nor have I ever applied for a job with the federal government. I contacted the OPM to find out why they would have my information. After several weeks, I received a letter stating that they could not locate anything pertaining to me. Next, I asked my US representative to look into the matter. The US representative's office received the same reply that I did. So, did they have my information or not??? Sent with Proton Mail secure email. On Thursday, February 15th, 2024 at 11:32 AM, Steve Thompson wrote: > Reading the articles, I find a similar thing that is done: Paying > for a year of ID theft insurance or some such. > > Here is the situation for those of us that were part of the OPM > cracking from 2015: > > Random attempts to open bank accounts by bad actors in our name > (which ever one of us it happens/ed to be) > > Random attempts to open credit accounts by bad actors in our name > (which ever one it happens to). > > So OPM did the one year thing to find out that it would have to > become permanent. So I get regular notices of attempts to open an > account. One person I personally know who was in law enforcement > and worked with Secret Service and Home land security is > constantly having problems like this. > > My point is, once this has happened, you never know when you are > going to get hit and from what direction. And so these guys think > that 1 year of such "protection" is going to help. > > And for those of you who own property, you might want to make > sure that you get notified if there is any activity, such as a > lien for some credit thing, or even a quit claim deed being > filed. You might have your property sold out from under you. > > Just say'n'. > > BTW -- that OPM crack included data on people that were not > getting clearances, but had to be talked with about the person > applying for the clearance(s). So this even included foreign > nationals that one is related to!! > > So depending on the entity that is cracked, the information gets > into the dark web and it may include people that didn't even know > they had anything to do with the entity that got cracked. > > Security on mainframes (and others) sometimes has a greater reach > when cracked than we realize. > > Steve Thompson > > On 2/15/2024 10:54 AM, P H wrote: > > > Passwords and hackers. Is there anything safe? > > > > https://eandt.theiet.org/2024/02/15/southern-water-admits-data-breach-may-impact-nearly-half-million-customers?utm_source=related-content-bullet-list > > > > https://eandt.theiet.org/2024/02/15/state-sponsored-hackers-using-ai-cyber-attacks-microsoft-warns?utm_campaign=E%2BT > > News - Template Redesign 15 Feb (Split test)_content=E%26T News - > > Members_medium=email_source=Adestra_term=865089 > > > > Sent from Outlook for Androidhttps://aka.ms/AAb9ysg > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of > > Jack Zukt 059cd493dd41-dmarc-requ...@listserv.ua.edu > > Sent: Thursday, February 15, 2024 3:25:18 PM > > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Insecure security - was SDSF PS Command column > > > > Hi Bill, > > I can relate to your suspicions about password managers. Not to long ago > > Lastpass found out that they have been hacked, which must have been a big > > problem for its end users (which, fortunately I am not). On the other hand, > > I have way too many passwords to be manageable without a password manager. > > So, I use not one, but two. With different master passwords. And using a > > password manager will not prevent you from sharing passwords with trusted > > friends. I usually tell my colleagues that use excel or notepad to keep > > their passwords to try and use keepass. It is as easy to use as those > > methods but far for secure. > > Regards > > Jack > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another Getting away from the mainframe tale
2022??? Sent with Proton Mail secure email. On Friday, January 19th, 2024 at 2:40 PM, Steve Beaver <050e0c375a14-dmarc-requ...@listserv.ua.edu> wrote: > I was up in Seattle at Pemco insurance. They made the decision to leave the > mainframe > In 1995, > > Well its 2022 and they are still on the mainframe > > > > Regards, > > > Steve > > > Steve Thompson > > On 1/19/2024 1:42 PM, Tim Ribble wrote: > > > Greetings all, > > > > Haven't posted here in quite some time but I thought it'd be fun to post > > another "getting off the mainframe" story. Been working for the City of > > San Antonio for 25 years now. I started as part of the mainframe staff and > > that was my primary function until 2009 when it was decided to move away > > from the mainframe. In the intervening years, my primary function moved to > > storage/backup systems which made sense for me since I dealt heavily with > > storage/backup operations on the mainframe and HDS storage. We were > > supposed to be off the mainframe by 30 Sep 2012 but here we are in 2024 and > > it's still running production applications. It's just a handful but > > they're critical. So here I am maintaining both a z/890 & HDS USP-V with > > no IBM or Hitachi support (just hardware support contracts from third party > > vendors). I'm now hearing we'll be off of it by Nov of this year. You > > think I'm going to hold my breath? I may actually retire before it's > > gone. Anyway, I just thought this audience may be amused by this. > > > > Cheers all, > > > > Tim > > > > -- > > 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: ADRDSSU COMPRESS and enq
Do you have access to the FDR products? Sent with Proton Mail secure email. On Friday, January 19th, 2024 at 9:18 AM, Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > Gentlemen, > First, thank you for your answers. I appreciate it. > > Regarding TOLENQF - it doesn't work with COMPRESS or CONSOLIDATE. The > manual is clear here. > > Regarding rename - this is the thing I wanted to avoid for several reasons: > 1. There is some risk to rename wrong "copy" of the dataset, or alter > ICF entries for wrong copy. > 2. Valid copies are located on non-SMS disk, but cataloged out of > regular catalog search (SYS1.name in some UCAT). Plus some aliases, etc. > I want to not destroy it. > 3. I don't know how to rename such datasets! Yes, I could imagine access > from another z/OS image, but it would be a series of manual ISPF r > command. Non-repeatable, error prone. Is there any tool allowing to > rename such datasets in batch? Wildcard support (i.e. REN SYS1.* SYS2.*) > would be welcome. > > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > W dniu 19.01.2024 o 13:27, Radoslaw Skorupka pisze: > > > I want to compress some system datasets like SYS1.LINKLIB, but not > > real "live", rather offline copies. > > DSS ends with RC8, because of failed serialization. > > SETPROG LNKLST,UNALLOCATE will not solve all the enqueues, because > > some datasets are serialized by other entities like TSO users. > > > > And I also want to CONSOLIDATE some datasets as well. > > > > Any clue? > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Security Portal
Thank you everyone for your very helpful replies! Sent with Proton Mail secure email. On Wednesday, January 10th, 2024 at 3:43 PM, Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > Yes. They make their way into normal RSUs just like all other recommended > PTFs. Without access to the security portal they won't be identified as > SECINT PTFs though. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > On Wednesday, January 10th, 2024 at 3:22 PM, rpinion865 > 042a019916dd-dmarc-requ...@listserv.ua.edu wrote: > > > > > Which begs the next question. Would security related PTFs make their way > > into normal RSUs, or must they be ordered separately as per the holddata? > > > > Sent with Proton Mail secure email. > > > > On Wednesday, January 10th, 2024 at 3:14 PM, Allan Staller > > 0387911dea17-dmarc-requ...@listserv.ua.edu wrote: > > > > > Classification: Confidential > > > > > > This is a severely manual process. > > > The PTFS/APARS can be determined from the HOLDDATA. > > > > > > The PTFs are individually orderable via ShopZ (just like any other PTF). > > > The only difference is that the PTF/APAR information is only available in > > > the HOLDDATA. > > > > > > HTH, > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > > > rpinion865 > > > > > > Sent: Wednesday, January 10, 2024 2:03 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: IBM Security Portal > > > > > > [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.] > > > > > > I know how to navigate to IBM's Security Portal and pull down the > > > security hold data. My question pertains to where does one get the > > > security related PTFs and APARs. In other words, do the security related > > > PTFs and APARs have to be pulled down from another site, as opposed to > > > the site where one pulls down general maintenance? Thanks in advance. > > > > > > Sent with Proton Mail secure email. > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ::DISCLAIMER:: > > > > > > The contents of this e-mail and any attachment(s) are confidential and > > > intended for the named recipient(s) only. E-mail transmission is not > > > guaranteed to be secure or error-free as information could be > > > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or > > > may contain viruses in transmission. The e mail and its contents (with or > > > without referred errors) shall therefore not attach any liability on the > > > originator or HCL or its affiliates. Views or opinions, if any, presented > > > in this email are solely those of the author and may not necessarily > > > reflect the views or opinions of HCL or its affiliates. Any form of > > > reproduction, dissemination, copying, disclosure, modification, > > > distribution and / or publication of this message without the prior > > > written consent of authorized representative of HCL is strictly > > > prohibited. If you have received this email in error please delete it and > > > notify the sender immediately. Before opening any email and/or > > > attachments, please check them for viruses and other defects. > > > > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Security Portal
Which begs the next question. Would security related PTFs make their way into normal RSUs, or must they be ordered separately as per the holddata? Sent with Proton Mail secure email. On Wednesday, January 10th, 2024 at 3:14 PM, Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > This is a severely manual process. > The PTFS/APARS can be determined from the HOLDDATA. > > The PTFs are individually orderable via ShopZ (just like any other PTF). The > only difference is that the PTF/APAR information is only available in the > HOLDDATA. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > rpinion865 > > Sent: Wednesday, January 10, 2024 2:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: IBM Security Portal > > [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.] > > I know how to navigate to IBM's Security Portal and pull down the security > hold data. My question pertains to where does one get the security related > PTFs and APARs. In other words, do the security related PTFs and APARs have > to be pulled down from another site, as opposed to the site where one pulls > down general maintenance? Thanks in advance. > > Sent with Proton Mail secure email. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses > in transmission. The e mail and its contents (with or without referred > errors) shall therefore not attach any liability on the originator or HCL or > its affiliates. Views or opinions, if any, presented in this email are solely > those of the author and may not necessarily reflect the views or opinions of > HCL or its affiliates. Any form of reproduction, dissemination, copying, > disclosure, modification, distribution and / or publication of this message > without the prior written consent of authorized representative of HCL is > strictly prohibited. If you have received this email in error please delete > it and notify the sender immediately. Before opening any email and/or > attachments, please check them for viruses and other defects. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM Security Portal
I know how to navigate to IBM's Security Portal and pull down the security hold data. My question pertains to where does one get the security related PTFs and APARs. In other words, do the security related PTFs and APARs have to be pulled down from another site, as opposed to the site where one pulls down general maintenance? Thanks in advance. Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OpenSSH CVE-2023-48795 vulnerability
The IBM SECINT portal is what I searched. Sent with Proton Mail secure email. On Friday, January 5th, 2024 at 10:47 AM, Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > IBM has a subscription only list for SECINT PTFs. This information is not > openly published. > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > rpinion865 > > Sent: Friday, January 5, 2024 9:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: OpenSSH CVE-2023-48795 vulnerability > > [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.] > > I have already searched there and did not find anything related to this > particular vulnerability. I did find one PTF from 2023 which is for ssh. That > PTF is applied on our sandbox LPAR, scheduled to be rolled out into > production shortly. Also, the IBM documentation for z/OS 2.4 SSH states that > it is based on Open SSH 6.4p1. Which I think is quite old. > > > > > Sent with Proton Mail secure email. > > > On Friday, January 5th, 2024 at 10:33 AM, Kirk Wolf k...@coztoolkit.com wrote: > > > > > This would be found in the IBM Security Portal. > > Here is information on registering to obtain access: > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > ibm.com%2Fcommunity%2Fz%2Fwp-content%2Fuploads%2Fsites%2F14%2F2022%2F0 > > 6%2FzSystem-Integrity.pdf=05%7C02%7Callan.staller%40HCL.COM%7Cf73 > > 64caa6e214dbc63fb08dc0e04899c%7C189de737c93a4f5a8b686f4ca9941912%7C0%7 > > C0%7C638400660032783209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC > > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=CfT > > tRH5qZibRTMsmRhCA%2FY5FttlA7FUiOgt8Ksa87qo%3D=0 > > > > Kirk Wolf > > Dovetailed Technologies > > http:// > > https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdovet > > ail.comcoztoolkit.com%2F=05%7C02%7Callan.staller%40HCL.COM%7Cf736 > > 4caa6e214dbc63fb08dc0e04899c%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C > > 0%7C638400660032939455%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ > > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=mxy1 > > qvKZXQ9DnC0QnfWuQ6CVgRv8slRgsMZM2dEFjIY%3D=0 > > > > On Fri, Jan 5, 2024, at 6:50 AM, rpinion865 wrote: > > > > > Does anyone know if the z/OS implementation of ssh is vulnerable to > > > CVE-2023048795? I tried searching for z/OS and OpenSSH (CVE-2023-48795). > > > But, I did not get any hits specific to z/OS. Thanks in advance. > > > > > > Cross posting to IBMTCP-L and IBM Main > > > > > > Sent with Proton Mail secure email. > > > > > > > > > -- 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 > ::DISCLAIMER:: > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses > in transmission. The e mail and its contents (with or without referred > errors) shall therefore not attach any liability on the originator or HCL or > its affiliates. Views or opinions, if any, presented in this email are solely > those of the author and may not necessarily reflect the views or opinions of > HCL or its affiliates. Any form of reproduction, dissemination, copying, > disclosure, modification, distribution and / or publication of this message > without the prior written consent of authorized representative of HCL is > strictly prohibited. If you have received this email in error please delete > it and notify the sender immediately. Before opening any email and/or > attachments, please check them for
Re: OpenSSH CVE-2023-48795 vulnerability
I have already searched there and did not find anything related to this particular vulnerability. I did find one PTF from 2023 which is for ssh. That PTF is applied on our sandbox LPAR, scheduled to be rolled out into production shortly. Also, the IBM documentation for z/OS 2.4 SSH states that it is based on Open SSH 6.4p1. Which I think is quite old. Sent with Proton Mail secure email. On Friday, January 5th, 2024 at 10:33 AM, Kirk Wolf wrote: > This would be found in the IBM Security Portal. > Here is information on registering to obtain access: > https://www.ibm.com/community/z/wp-content/uploads/sites/14/2022/06/zSystem-Integrity.pdf > > Kirk Wolf > Dovetailed Technologies > http:// http://dovetail.comcoztoolkit.com > > > On Fri, Jan 5, 2024, at 6:50 AM, rpinion865 wrote: > > > Does anyone know if the z/OS implementation of ssh is vulnerable to > > CVE-2023048795? I tried searching > > for z/OS and OpenSSH (CVE-2023-48795). But, I did not get any hits specific > > to z/OS. Thanks in advance. > > > > Cross posting to IBMTCP-L and IBM Main > > > > Sent with Proton Mail secure email. > > > > -- > > 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
OpenSSH CVE-2023-48795 vulnerability
Does anyone know if the z/OS implementation of ssh is vulnerable to CVE-2023048795? I tried searching for z/OS and OpenSSH (CVE-2023-48795). But, I did not get any hits specific to z/OS. Thanks in advance. Cross posting to IBMTCP-L and IBM Main Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Merry Christmas
Merry Christmas to all, and to all a good night, from Ralphie and Randy . Sent from Proton Mail mobile Original Message On Dec 25, 2023, 11:27 AM, Steve Beaver wrote: > Merry Christmas to all 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
Shameless post
If this post is not acceptable on the list, then please disregard it. If you, or someone you know needs some part-time IBM system programming work, I offer my services. I am interested in 10 to 15 hours a week. I have a full time job. But, I want to supplement my income, and fill in the gaps of my day. My desired hourly rate is quite reasonable. I do not want to do contract work. I do not want the tax hassles of doing that type of work. I want to work strictly as a W-2 employee. Thanks in advance. Richard Pinion Sent with Proton Mail secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMC Splash screen
You have to logon as an administrator. Select HMC Management, followed by the Create Welcome Text option. Lastly, if you put something in the Classification box, that will be the background for the Welcome screen. Sent with Proton Mail secure email. --- Original Message --- On Tuesday, September 5th, 2023 at 10:10 AM, Patrick Loftus wrote: > Never seen an option to do thatwhere is it? > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > rpinion865 > > Sent: Tuesday, September 5, 2023 3:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: HMC Splash screen > > Never mind we found where to change it! > > > > > Sent with Proton Mail secure email. > > > --- Original Message --- > On Tuesday, September 5th, 2023 at 9:42 AM, rpinion865 > 042a019916dd-dmarc-requ...@listserv.ua.edu wrote: > > > > > We would like to change the DR HMC splash screen. How can this be done? > > > > Sent with Proton Mail secure email. > > > > -- > > 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: HMC Splash screen
Never mind we found where to change it! Sent with Proton Mail secure email. --- Original Message --- On Tuesday, September 5th, 2023 at 9:42 AM, rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu> wrote: > We would like to change the DR HMC splash screen. How can this be done? > > Sent with Proton Mail secure email. > > -- > 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
HMC Splash screen
We would like to change the DR HMC splash screen. How can this be done? Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help for US Talent
I have had some off-shore recruiters ask for my SSN and birthdate. You can imagine how far that goes. Sent with Proton Mail secure email. --- Original Message --- On Tuesday, August 15th, 2023 at 10:18 AM, Steve Beaver <050e0c375a14-dmarc-requ...@listserv.ua.edu> wrote: > Yesterday I sent this to IBM Mainframe and RACF Discussions (See Below) > > Evidently several people from Mainframe and RACF groups have begun using > this > Little script. > > I continue to use this script and the off-shore recruiter; Well you can > hear them > Just die on the phone. They continue on their script and they tell me what > they > Can do monetarily then I tell them they are $50/HR low or whatever. Then I > wish > them good Luck and hang up > > Steve > > = = = = = = = = = = = = = = = = = = = > > Every time a recruiter calls me I have a sure way get rid of them and > increase what they need to pay. > > They ask me if I'm Steve, and I say yes > > Then I tell them "Are you calling me with a job that pays $125/HR W2 or > $210,000 perm?" > > You hear them fade or die on the other end then I hang up. > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help for US Talent
I get tons of emails from offshore recruiters. Some are geared toward my listed experience. But there are some that do not come close. The only thing that matches me is the state I live in. Sent from Proton Mail mobile Original Message On Aug 14, 2023, 7:32 PM, Bob Bridges wrote: > I haven't had any recruiters ask me about forklifts, but yeah, I do get some > that just match me up with "something computer-related" and contact me about > that. But it occurs to me belatedly that you're talking about phone calls. I > don't know what you and I are doing differently, but most recruiters email > me, and the rare phone calls I get are (so far) all w real gigs for me, I > mean gigs that I might conceivably be interested in. The ones that aren't a > good match, or when it's two or three recruiters from the same company > contacting me about the same req, those all come from just one or two > recruiting companies. But they almost never know my name, and I can throw > their emails in my Junk folder without pangs of conscience. Mostly if a > recruiter knows my name (I mean, addresses his email to me and not just to > "Greetings"), I take the trouble to reply politely. They're still my source > of work, after all. And I may suddenly need to come out of my > semi-retirement, in which case I want them to think well of me. --- Bob > Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* The art of not reading > is a very important one. It consists in not taking an interest in whatever > may be engaging the attention of the general public at any particular time. > When some political or ecclesiastical pamphlet, or novel, or poem is making a > great commotion, you should remember that he who writes for fools always > finds a large public. A precondition for reading good books is not reading > bad ones: for life is short. -Schopenhauer */ -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Grant Taylor Sent: Monday, > August 14, 2023 18:43 I've dealt with way too many bad recruiters this year. > I've told them up front, what I'm looking for in very clear and concise > manner. I clearly provided; salary, location / remote, and job function. Too > many of them would inquire if I wanted to drive a forklift or install cable > TV wiring in a completely different state across the country. It got to the > point that I would ban recruiter companies from my mail server after the 3rd > such wildly incorrect inquiry. It's routine for different recruiters from the > same company to reach out, thinking that filtering is based on email address. > I've even had a recruiting company stop sending from their company email > addresses and use Gmail in order to avoid email filters. These are the low > ball recruiters that I want to simply go away and stop talking to me. --- On > 8/14/23 3:23 PM, Bob Bridges wrote: > Am I missing something? Why the > interest in making life hard for > recruiters? Ok, I'm a contractor so my > continued employment depends > on their existence. Still, why? > > If I > thought that you normally work under those conditions - $125/hr > or outside > the US half the time - then of course you're just stating > up front one of > your requirements. From the tone, though, it sounds > like you're trying to > make them unhappy for the fun of it. Is there > something going on here that > I'm not aware of? > -- For > IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help for US Talent
I ask them, as a US citizen with a legal residence in the State of Tennessee, may I work remotely, outside of the USA for at least six months a year? I usually never hear from them again. Sent from Proton Mail mobile Original Message On Aug 14, 2023, 3:52 PM, Steve Beaver wrote: > Every time a recruiter calls me I have a sure way get rid of them and > increase what they need to pay. They ask me if I'm Steve, and I say yes Then > I tell them "Are you calling me with a job that pays $125/HR W2 or $210,000 > perm?" You hear them fade or die on the other end then I hang up. > -- For > IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Anther definition of Mainframe
https://www.reddit.com/r/80sdesign/comments/o9d0qw/mainframe_a_new_instore_shop_concept_from_sears/?rdt=41395 Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS performance question
Sorry I forgot to mention, the Development LPAR has access to a ZIIP. Sent with Proton Mail secure email. --- Original Message --- On Friday, August 11th, 2023 at 11:34 AM, Jon Butler wrote: > Depending on the actual work characteristics, you might consider buying a > zIIP. You could share this between PROD and DEV to offload a lot of "grunt" > work that runs in an SRB, including Sorts and many ISV products from BMC and > Broadcom. More good news, any work offloaded from the GPs may cut your MLC > charges. > > -- > 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/OS performance question
Additional update on our configuration. We have a z15-T02, with two physical engines. Our production LPAR has one dedicated GCP and shares the second GCP with the Development LPAR. Since Development only has access to only one physical processor, our performance and tuning company feels that adding another logical GCP would not help. They have pointed out that the DB2 work coming from the DB2 batch jobs, may be generating SRBs, which are always dispatched before TCBs and due to the capping, TSO and other work gets delayed. Sent with Proton Mail secure email. --- Original Message --- On Wednesday, August 9th, 2023 at 11:02 PM, Graham Harris wrote: > I have seen Db2 unloads use vastly more (overall total) CPU when doing > parallelised processing, compared to non-parallelised. > Obviously you are doing reload (I presume) rather than unload, but the same > thing may apply. > So might be something worth checking/testing, if parallelism is relevant to > your situation. Not just for the overall CPU aspect (which was never > determined as to whether it was an actual bug or not, as far as I > remember), but also with regard to the numerous threads that would be > trying to dispatch simultaneously, and the contention that would generate > on a single CP LPAR. > > On Wed, 9 Aug 2023 at 17:06, rpinion865 < > 042a019916dd-dmarc-requ...@listserv.ua.edu> wrote: > > > Well, for starters the DB2 address spaces are in a service class named > > STCHI, which has the following WLM definitions. > > Importance Level 1 with an execution velocity of 55. Regarding the > > situation when "DB2" uses most of the CPU. It is > > not the DB2 address spaces that max out the CPU, rather the batch jobs > > using DB2, in this case a batch job to restore > > a database. We have a third party who does our performance management and > > makes recommendations. We have asked them > > to look at the DB2 batch jobs. One comment they made was that the > > database restore may be invoking internal sorts, > > with little I/O interrupts. Therefore allowing this batch job, with the > > related WLM controls, to dominate the CPU. > > > > Which is why I think adding another logical CP to the LPAR would help > > other work. What we have to be very careful > > about is not to increase the MSU usage of this LPAR. We run several IBM > > and non-IBM products on this LPAR that have > > their pricing based on the capped MSU usage for this LPAR. > > > > Sent with Proton Mail secure email. > > > > --- Original Message --- > > On Wednesday, August 9th, 2023 at 11:24 AM, Rebecca Martin < > > 050348c1817e-dmarc-requ...@listserv.ua.edu> wrote: > > > > > By any chance do you have your Db2 address spaces in SYSSTC? If yes, get > > > them moved out AND share give development uses of both logical CPs. > > > IRLM should be there but the others should. On a 1 CP system, all > > > regular work stops while a task in SYSSTC is using the CPU. High CPU users > > > like Db2 should not be in SYSSTC; especially on a system with only 1 > > > logical CP. > > > > > > -- > > > 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: ISPF in batch
WOW 1998! Sent with Proton Mail secure email. --- Original Message --- On Thursday, August 10th, 2023 at 12:32 PM, Sri h Kolusu wrote: > > > Do any one of the group have any experience editing a file under 3.4 And > > > executing an Init MACRO > > > Steve, > > Check this > https://groups.google.com/g/bit.listserv.ispf-l/c/8IxI7mY2hhY/m/e8AnYi2QTrkJ > > Thanks, > Kolusu > > > > > > > > > Regards, > > > > > > Steve > > > > > -- > 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/OS performance question
Well, for starters the DB2 address spaces are in a service class named STCHI, which has the following WLM definitions. Importance Level 1 with an execution velocity of 55. Regarding the situation when "DB2" uses most of the CPU. It is not the DB2 address spaces that max out the CPU, rather the batch jobs using DB2, in this case a batch job to restore a database. We have a third party who does our performance management and makes recommendations. We have asked them to look at the DB2 batch jobs. One comment they made was that the database restore may be invoking internal sorts, with little I/O interrupts. Therefore allowing this batch job, with the related WLM controls, to dominate the CPU. Which is why I think adding another logical CP to the LPAR would help other work. What we have to be very careful about is not to increase the MSU usage of this LPAR. We run several IBM and non-IBM products on this LPAR that have their pricing based on the capped MSU usage for this LPAR. Sent with Proton Mail secure email. --- Original Message --- On Wednesday, August 9th, 2023 at 11:24 AM, Rebecca Martin <050348c1817e-dmarc-requ...@listserv.ua.edu> wrote: > By any chance do you have your Db2 address spaces in SYSSTC? If yes, get them > moved out AND share give development uses of both logical CPs. > IRLM should be there but the others should. On a 1 CP system, all regular > work stops while a task in SYSSTC is using the CPU. High CPU users like Db2 > should not be in SYSSTC; especially on a system with only 1 logical CP. > > -- > 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/OS performance question
While adjusting the WLM definitions might help TSO, I would like to add that I put my TSO userid in SYSSTC. Even running in that service class my TSO response is sluggish. Sent with Proton Mail secure email. --- Original Message --- On Monday, August 7th, 2023 at 8:30 AM, Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > Ok. You zre using 2 period TSO Service Defs. I suggest you adjust the period > 1 duration until 96% (vs. 90%) of transactions end in period one. > There is no easy way to measure this in advance. The RMF Service Class Period > report will however show the results after the fact. > > Increase the duration of period one and look at the RM report. Wash, rinse, > repeat until the desired goal is achieved. Beyond that, I do not believe > there can be much done. IIRC the DB2MSTR address space either runs at IMP 1 > or in the SYSSTC service class. > > Speculating (I am not a DB2 expert) if commits can be take during the > restore, it might help. > > Wish I could help more. > > > > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > rpinion865 > > Sent: Friday, August 4, 2023 12:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS performance question > > [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.] > > I am working with the Development LPAR (SC08D3). Below is the TSO service > class definition for that LPAR. > > Service Class Name . . . . . : TSOSC > > Description . . . . . . . . . TSO Production and Development > > Workload Name . . . . . . . . TSO (name or ?) > > Base Resource Group . . . . . (name or ?) > > Cpu Critical . . . . . . . . . NO (YES or NO) > > I/O Priority Group . . . . . . NORMAL (NORMAL or HIGH) > > Honor Priority . . . . . . . . DEFAULT (DEFAULT or NO) > > > > Specify BASE GOAL information. Action Codes: I=Insert new period, > > E=Edit period, D=Delete period. > > > > -- Period -- --- Goal --- > > Action # Duration Imp. Description > > __ _ _ _ > > __ 1 500 1 90% complete within 00:00:00.060 > > __ 2 _ 4 Execution velocity of 40 > > Next, is a mangled text view of the Development (SC08D3) LPAR definition. > Customize Image Profiles: Z15A:SC08D3 : SC08D3 : Processor Turn on context > sensitive help. > Collapse Z15A:SC08D3 > Collapse SC08D3 > General > Processor > Security > Storage > Options > Load > Crypto > Group Name > > > > Open or close the list box > Logical Processor Assignments > Dedicated processors > Select > Processor Type > Initial > Reserved > Selected > Central processors (CPs) > 1 > 0 > Selected > z Integrated Information Processors (zIIPs) > 1 > 0 > Not Dedicated Processor Details for: > CPs > zIIPs > CP Details > Initial processing weight > 60 > 1 to 999 > Initial capping > Enable workload manager > Minimum processing weight > 0 > Maximum processing weight > 0 > Absolute Capping > None > Number of processors > (0.01 to 255.0) > 0.18 > > > > > > Sent with Proton Mail secure email. > > > --- Original Message --- > On Thursday, August 3rd, 2023 at 12:17 PM, Allan Staller > 0387911dea17-dmarc-requ...@listserv.ua.edu wrote: > > > > > Classification: Confidential > > > > You did not say where the TSO response time issues were being observed. I > > suspect, from the information provided it is on SC08D3(possible) or SC14D4 > > (most likely). > > > > If you look, I suspect the majority of CPU consumption is from the *MSTR > > DB2 address space. DB2 will charge this back to the "user". This address > > space is most likely running in the SYSSTC Service class. > > > > I suggest you look at the service class definitions for TSO. At least 80% > > of all transactions should end in TSO Service Class Period 1, 80 % of the > > rest in TSO Service Class Period 2 (16%) and the remainder in TSO Service > > Class period 3 (4 %). Another variation could be TSO Service Class Period 1 > > at 96% and TSO Service Class Period 2 4%; No TSO Service Class Period 3. > > > > Depending on the scheme chosen above, except for the last TSO Service > > Class, all should run as importance 1. They may have differen
Re: z/OS performance question
I am working with the Development LPAR (SC08D3). Below is the TSO service class definition for that LPAR. Service Class Name . . . . . : TSOSC Description . . . . . . . . . TSO Production and Development Workload Name . . . . . . . . TSO (name or ?) Base Resource Group . . . . . (name or ?) Cpu Critical . . . . . . . . . NO(YES or NO) I/O Priority Group . . . . . . NORMAL(NORMAL or HIGH) Honor Priority . . . . . . . . DEFAULT (DEFAULT or NO) Specify BASE GOAL information. Action Codes: I=Insert new period, E=Edit period, D=Delete period. -- Period -- --- Goal --- Action # Duration Imp. Description ___ _ _ __1 500 190% complete within 00:00:00.060 __2 _ 4Execution velocity of 40 Next, is a mangled text view of the Development (SC08D3) LPAR definition. Customize Image Profiles: Z15A:SC08D3 : SC08D3 : Processor Turn on context sensitive help. Collapse Z15A:SC08D3 Collapse SC08D3 General Processor Security Storage Options Load Crypto Group Name Open or close the list box Logical Processor Assignments Dedicated processors Select Processor Type Initial Reserved Selected Central processors (CPs) 1 0 Selected z Integrated Information Processors (zIIPs) 1 0 Not Dedicated Processor Details for: CPs zIIPs CP Details Initial processing weight 60 1 to 999 Initial capping Enable workload manager Minimum processing weight 0 Maximum processing weight 0 Absolute Capping None Number of processors (0.01 to 255.0) 0.18 Sent with Proton Mail secure email. --- Original Message --- On Thursday, August 3rd, 2023 at 12:17 PM, Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > You did not say where the TSO response time issues were being observed. I > suspect, from the information provided it is on SC08D3(possible) or SC14D4 > (most likely). > > If you look, I suspect the majority of CPU consumption is from the *MSTR DB2 > address space. DB2 will charge this back to the "user". This address space is > most likely running in the SYSSTC Service class. > > I suggest you look at the service class definitions for TSO. At least 80% of > all transactions should end in TSO Service Class Period 1, 80 % of the rest > in TSO Service Class Period 2 (16%) and the remainder in TSO Service Class > period 3 (4 %). Another variation could be TSO Service Class Period 1 at 96% > and TSO Service Class Period 2 4%; No TSO Service Class Period 3. > > Depending on the scheme chosen above, except for the last TSO Service Class, > all should run as importance 1. They may have different performance goals, > but the importance should be 1. > > " From the activation profile for Development (SC08D3) the Processor > definition has the absolute Capping box Number of processors box set to > 0.18.”. This sentence does not make sense as written. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > rpinion865 > > Sent: Thursday, August 3, 2023 10:10 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: z/OS performance question > > [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.] > > Let me start off by saying I am not a z/OS performance and capacity planning > expert. If anything, I am a novice. I am looking for a trivial answer to a > non-trivial question. > We have a z15 (8562-T02) running three z/OS 2.4 LPAR's, Production (SC10D1), > Development (SC08D3), and Sysprog (SC14D4). Below is information from the RMF > Partition Report. My question/problem is this. On the Development LPAR, when > a DB2 database restore job runs, the MVS Busy goes to 100% as seen from both > SDSF DA and RMF CPU reports. Most of the CPU Busy goes to the DB2 restore > job. The batch job runs in a discretionary service class
z/OS performance question
Let me start off by saying I am not a z/OS performance and capacity planning expert. If anything, I am a novice. I am looking for a trivial answer to a non-trivial question. We have a z15 (8562-T02) running three z/OS 2.4 LPAR's, Production (SC10D1), Development (SC08D3), and Sysprog (SC14D4). Below is information from the RMF Partition Report. My question/problem is this. On the Development LPAR, when a DB2 database restore job runs, the MVS Busy goes to 100% as seen from both SDSF DA and RMF CPU reports. Most of the CPU Busy goes to the DB2 restore job. The batch job runs in a discretionary service class, and TSO users run in a higher service class with goal mode. But, response time for the TSO users gets long, 3 to 5 seconds between enter keys, ISPF screen swaps etc.. Normally the TSO response time is sub-second. As you can see, the Development LPAR has one Logical CP defined. Based on the capping characteristics of Development as displayed below, would adding another Logical CP help TSO response time? 1 P A R T I T I O N D A T A R E P O R T PAGE 3 z/OS V2R4 SYSTEM ID SC10 DATE 08/01/2023 INTERVAL 14.59.992 RPT VERSION V2R4 RMF TIME 05.45.00 CYCLE 1.000 SECONDS - MVS PARTITION NAME SC10D1 PHYS PROC NUM 5 LP GROUP NAME N/A INITIAL CAP NO IMAGE CAPACITY 138 CP 2 2 LIMIT N/A LPAR HW CAP NO NUMBER OF CONFIGURED PARTITIONS 5 ICF 1 AVAILABLE N/A HW GROUP CAP NO WAIT COMPLETION NO IIP 2 2 ABS MSU CAP NO DISPATCH INTERVAL DYNAMIC MVS PARTITION NAME SC08D3 PHYS PROC NUM 5 LP GROUP NAME N/A INITIAL CAP NO IMAGE CAPACITY 10 CP 2 1 LIMIT N/A LPAR HW CAP YES NUMBER OF CONFIGURED PARTITIONS 5 ICF 1 AVAILABLE N/A HW GROUP CAP NO WAIT COMPLETION NO IIP 2 1 ABS MSU CAP NO DISPATCH INTERVAL DYNAMIC - PARTITION DATA -- MSU --CAPPING--- NAME S BT WGT DEF ACT DEF WLM% NUM TYPE SC10D1 A N 999 138 27 N N N 0.0 2.0 CP SC08D3 A N 60 10 3 N Y N 0.0 1.0 CP (1) SC14D4 A N 18 4 2 N N N 0.0 1.0 CP TOTAL 1077 - From the activation profile for Development (SC08D3) the Processor definition has the absolute Capping box Number of processors box set to 0.18. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Chaining format 9 and format 3 DSCBs in EAV VTOC
Been there done that, got the t-shirt. Me to ops manager "we need to IPL ASAP due to CA-ACF2 CSA storage creep, CSA will run out very soon". Ops manager to me "no way we are going to IPL in the middle of the day". I told him do not call me when the system goes down tonight in the middle of batch!. About 23:00 that night I get called from operations, the system just went down. The shop ran IDMS, and an UPDATE batch job that ran CV, had been running for 3+ hours. I told them to call the ops manager. He told operations to IPL, and it took 3+ hours for IDMS to back out the updates from the batch job. Plus, they had to run the job again. Online IDMS was several hours late coming up the next day. What did the ops manager save... time, face, his rear-end??? Sent with Proton Mail secure email. --- Original Message --- On Monday, July 31st, 2023 at 7:33 AM, Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > Fortunately nowadays the reorg is possible without maintenance window. > BTW: I had similar situations and I learnt to reply "You may not allow > me to stop production, but it WILL stop, despite on you decision, and > your manager decision... However it likely will happen during peak > hours, not at night.". > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > W dniu 28.07.2023 o 22:48, Mike Schwab pisze: > > > YEP. management did not want to reorg a DB2 dataset with 100 extents. Did > > a batch update that failed when the 123rd extent filled. No more updates > > until reorg was completed, about 1995. > > > > On Fri, Jul 28, 2023, 12:08 Wendell Lovewell < > > 01e9c0ee0673-dmarc-requ...@listserv.ua.edu> wrote: > > > > > Thank you for the confirmation Radoslaw. Whatever I tried with either > > > VSAM or PDSe, I could not get more than 123 extents on a volume. But I > > > also never found the right document to describe the 123-extent limit. > > > > > > SO, I guess there wouldn't be a reason for multiple format-9 records for > > > the same file. 10 DS9F3 slots can point to 130 extents. > > > > > > Thanks to you and Bill for your help! > > > > > > Wendell > > > -- > 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
Download IBM's Tape Tools
It has been a while since I downloaded IBM's Tape Tools. Using the instructions I got from our mainframe provider does not work. The instructions assume a non AT-TLS FTP connection. Yet, when I run the provided FTP script, from both a batch job and TSO READ mode, I get 550 SSL/TLS required on the control channel Does anybody have a recent copy of their JCL to download the Tape Tools? We asked the mainframe provider. Currently they do not know. I have cobbled together some AT-TLS options for SYSFTPD input, which gets me past the initial AT-TLS negotiation. But, then I get FC1108 authServer: secure_coket_init failed with rc = 410 (SSL message format is incorrect). I looked up the RC 410, but that was not much help. I do not want to set up a SSL trace. And even if I did, I would not know what it means. Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS/Transaction Manager
I've said it before, and I'll say it again. The work done on HASP was "Half ASP". Play on words anyone??? Sent with Proton Mail secure email. --- Original Message --- On Tuesday, July 25th, 2023 at 4:53 PM, Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > Just a wild guess. The same reason ASP and HASP were so radically different. > They were written by different people with different priorities. > > -- > Tom Marchant > > On Tue, 25 Jul 2023 19:55:31 +, Schmitt, Michael michael.schm...@dxc.com > wrote: > > > So whi is the CICS architecture so radically different than IMS/TM? > > > -- > 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: Apply job failed GIM240001E for connect direct 6.2
Check you SMP/E output, specifically the part that shows dataset allocations, DDDEF and JCL, to insure you are picking up that library in the SYSLIB concatenation. Also, insure you updated the SYSLIB DDDEF for the target zone. Sent with Proton Mail secure email. --- Original Message --- On Tuesday, July 25th, 2023 at 2:26 PM, Sathish Kumar wrote: > Hi David, > > I have already tried to add SYSLIB CONCAT to SDGAMAC and run this job it's > failed with same error. > > Thanks. > > > On Tue, 25 Jul, 2023, 11:47 pm David Spiegel, < > 0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > > > Hi Satish, > > Please concatenate 'DGA.SDGAMAC' or equivalent (listed under SDGAMAC > > Target Zone DDDEF) > > to Target Zone SYSLIB DDDEF and retry. > > > > Regards, > > David > > > > On 2023-07-25 08:10, Sathish Kumar wrote: > > > > > Hi, > > > > > > I have updated SYSLIB CONCAT SYS1.MODGEN and rerun the job it's failed > > > with > > > same error. > > > > > > Thanks. > > > > > > On Tue, 25 Jul, 2023, 4:39 pm Gerry Tracey, gerry.tra...@gmail.com > > > wrote: > > > > > > > Hi, > > > > > > > > That is the target library for AMODGEN and can be used instead. > > > > > > > > Gerry > > > > > > > > > On 25 Jul 2023, at 12:04, Sathish Kumar zosedu...@gmail.com wrote: > > > > > > > > > > Yes we have Sys1.Modgen > > > > > > > > > > > On Tue, 25 Jul, 2023, 4:25 pm Gerry Tracey, gerry.tra...@gmail.com > > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > Do you have SYS1.MODGEN? > > > > > > > > > > > > Gerry > > > > > > > > > > > > > > On 25 Jul 2023, at 11:20, Sathish Kumar zosedu...@gmail.com > > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > Sure, I don't have AMODGEN Marco library. So how we can proceed? > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > On Tue, 25 Jul, 2023, 12:41 am Steve Thompson, ste...@wkyr.net > > > > > > > > wrote: > > > > > > > > What Allen said. > > > > > > > > > > > > > > > > And make sure you follow what the install doc says for > > > > > > > > Connect:Direct, as well as any HOLD ACTIONs: do the actions > > > > > > > > before BYPASS. > > > > > > > > > > > > > > > > Steve Thompson > > > > > > > > > > > > > > > > > On 7/24/2023 1:44 PM, Allan Staller wrote: > > > > > > > > > Classification: Confidential > > > > > > > > > > > > > > > > > > Most likley it is a missing library in the SYSLIB > > > > > > > > > concatenation. > > > > > > > > > > > > > > > > > > 1) Check the assembly listing for "macro not found" messages > > > > > > > > > 2) locate the macro > > > > > > > > > 3) Using the SMPE dialogs, adjust the SYSLIB DDDEF to include > > > > > > > > > the > > > > > > > > > missing macro library(ies) > > > > > > > > > HTH, > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU > > > > > > > > > On > > > > > > > > > Behalf Of Sathish Kumar > > > > > > > > > Sent: Monday, July 24, 2023 12:41 PM > > > > > > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > > > > > > Subject: Apply job failed GIM240001E for connect direct 6.2 > > > > > > > > > > > > > > > > > > [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.] > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > While apply the usermod I get below error for connect direct. > > > > > > > > > > > > > > > > > > GIM240001E ** Assembler processing for sysmid LDIACRJ failed > > > > > > > > > for > > > > > > > > > module > > > > > > > > > DGAXACRJ in the SDGASAMP library. The return code 12 Exceeded > > > > > > > > > for > > > > > > > > > the > > > > > > > > > allowable value. > > > > > > > > > ASMA057E undefined operation code. > > > > > > > > > > > > > > > > > > Lot of ASM* Errors messages in sysprint. > > > > > > > > > > > > > > > > > > Please advise on this. > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > -- > > > > > > > > > > > > > For IBM-MAIN subscribe / signoff / archive access > > > > > > > > > instructions, > > > > > > > > > send > > > > > > > > > email to lists...@listserv.ua.edu with the message: INFO > > > > > > > > > IBM-MAIN > > > > > > > > > ::DISCLAIMER:: > > > > > > > > > > > > > > > > > > The contents of this e-mail and any attachment(s) are > > > > > > > > > confidential > > > > > > > > > and > > > > > > > > > intended for the named recipient(s) only. E-mail transmission > > > > > > > > > is not > > > > > > > > > guaranteed to be secure or error-free as information could be > > > > > > > > > intercepted, > > > > > > > > > corrupted, lost, destroyed,
Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives
I'm probably wrong. But I thought IMS was developed for NASA during the Gemini and Apollo time frame. Sent with Proton Mail secure email. --- Original Message --- On Tuesday, July 25th, 2023 at 2:05 PM, Schmitt, Michael wrote: > No, I don’t know of an IMS/TM + DB2 system. > > But then the CICS systems I work with are also not using DB2. They use VSAM! > > And even for IMS/DB, my gut feel is there are a lot more CICS + IMS/DB > installations than IMS/TM + IMS/DB. > > > Also, CICS is from ~1966, IMS/DC (later renamed to IMS/TM in IMS Version 4) > must have been much later than that, but I can't find the date. > > Reason I think I it is much later (late 70's? early 80's?) is because, as I > understand it, the reason CICS was designed the way it is was because at the > time, the OS it ran on wasn't so great at multitasking. Or maybe didn't do > multitasking at all. But IMS/DC was designed at a time when the OS was good > at preemptive multitasking between tasks and jobs. Was this MVS? > > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > David Spiegel > > Sent: Tuesday, July 25, 2023 12:38 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it > survives > > Hi Michael, > I have yet to see a site running IMS/DC and not run IMS/DB. > Have you actually seen this? > > BTW, the article had more than one technical error. For example, a JCL > Step name with 9 characters. > > Regards, > David > > On 2023-07-25 13:16, Schmitt, Michael wrote: > > > The Ars Technica article was discussing CICS as an application server. I > > was comparing CICS as an application server to IMS/TM as an application > > server. The DBMS is a different issue; there's no reason why IMS/TM must be > > used with IMS/DB. You can use IMS/TM with DB2. > > > > The point I was trying to make was that CICS was designed as a cooperative > > multitasking system that reproduces all of the OS functions in itself. > > IMS/TM (originally IMS/DC) was designed to use the OS to do OS things and > > does none of that in itself, so it is much simpler. > > > > -Original Message- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > > David Spiegel > > Sent: Tuesday, July 25, 2023 11:48 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it > > survives > > > > Hi Michael, > > You said: "...CICS is to IMS as Windows 3.1 is to Windows 10. ..." > > You're comparing apples and oranges. > > (CICS has no native Database portion.) > > BTW, a lot of the banks, insurance companies etc. are running CICS+DB2. > > The majority of IMS users need it to support 40+ year old application > > systems. > > Which one is the real dinosaur? (Hint: It's not CICS) > > > > Regards, > > David > > > > On 2023-07-25 10:37, Schmitt, Michael wrote: > > > > > So CICS is no longer doing cooperative multitasking within each AOR, and > > > thus requiring CICS versions of OS commands to prevent wait states from > > > freezing the entire AOR? A CICS program can do direct GETMAINs, LOADS, > > > abends, rather than use CICS commands? CICS no longer requires special > > > versions of tools (e.g. debugger, abend dump management) and instead can > > > use the same tools as batch programs? A CICS programmer no longer needs > > > to learn a long list of CICS commands and EXEC CICS syntax? A CICS region > > > no longer contains the storage from all of the transactions currently > > > running and is now only one transaction in the region at a time? CICS > > > transactions can no longer stomp on each other's memory? > > > > > > Great, I did not know that. > > > > > > IMS/TM uses the operating system for multitasking. There are no IMS/TM > > > specific tools. An IMS/TM programmer only needs to know two commands, one > > > to get a message and another to send it. IMS transaction abends look > > > (almost) exactly like a batch abend. IMS programs have no restrictions on > > > OS facilities. An IMS program can even do an STIMER (WAIT) without > > > affecting any other transaction processing. Because, it uses the OS to do > > > preemptive multitasking, like a modern operating system. > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > > > Crawford Robert C (Contractor) > > > Sent: Tuesday, July 25, 2023 8:14 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why > > > it survives > > > > > > Sorry, I worked in a shop that had both and I can tell you CICS is way > > > more flexible, modern and performed better. > > > > > > I will give you this: IMS is a great piece of 90's technology. > > > > > > Robert Crawford > > > Abstract Evolutions LLC > > > (210) 913-3822 > > > > > > -Original Message- > >
Re: A question about CPU usage on z/OS
Anyone remember "wait states" in the early IBM/clone 8088 PC's because of the slower memory chips? Sent from Proton Mail mobile Original Message On Jul 15, 2023, 2:41 PM, Joel C. Ewing wrote: > The SU/sec advertised for those models indicates it is correct to call a 504 > cpu "slower" than a 701 cpu, even if that distinction is created at a level > above the physical hardware. If it is true that at the hardware level the > processor clock cycle is identical for all processors, then obviously that is > not the only determinant of the effective cpu execution speed. I would guess > that the capacity restrictions described force some desired percentage of > clock cycles to be idle/no-work cycles, reducing the effective execution > speed of the processor. That does seem like an ingenious approach for > allowing modest upgrade paths in an age where adding a full capacity cpu can > be way too large of an increment. JC Ewing On 7/15/23 05:43, P H wrote: > All > processing units (PUs), whether CPs zIIPs, SAPs, ICFs or IFLs have the SAME > cycle time (speed). It's the CAPACITY settings which are different. For > example, in case of the z16 the 701 is 100% then the relative capacity of a > 601 is approx 66% of the 701, 501 is approx 41% of the 701 and 401 is approx > 12% of the 701 > > Regards > > Parwez Hamid > > > From: IBM Mainframe Discussion List on > behalf of Jon Perryman > Sent: 15 July 2023 05:54 > To: > IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: A question about CPU usage on z/OS > > > While each cpu in the 504 is slower than a 701 cpu, running 4 batch jobs at > the same time should reduce run time because each batch job expect reduced > wait because there is reduced competition for the CPU. However, you could be > correct if the 4 batch jobs are experiencing heavy I/O wait. > On Friday, > July 14, 2023 at 06:05:24 PM PDT, Tom Brennan wrote: > > On 7/14/2023 3:01 > PM, Jon Perryman wrote: > > As for batch running slower at night after you > went from 1 CPU to 4, > that doesn't make sense unless other things changed. > > > I'm thinking it could be as simple as say, going from a 701 to a 504. > > The overall MIPS are bumped up, multi-task address spaces are happier, > but > single threaded work can be left in the dust. > > > -- > 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 -- Joel C. Ewing > -- 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: Userid schemes
I worked at a place where the VP didn't like using anything related to names, due to name changes and the such. Rather he used Nxxx, where "N" was for Number and "xxx" was a numeric value starting with 1 and being incremented for the next userid. Since he was first in the shop, and he knew RACF, he set himself up as N001, I was the next person hired, and I got N002. Sent with Proton Mail secure email. --- Original Message --- On Thursday, July 13th, 2023 at 5:22 PM, Phil Smith III wrote: > I've seen various schemes used for creating up-to-eight-character userids, > all truncated as needed, of course. These are IDs I've had, won't tell ya > where each was (and omitting just firstname, just lastname, or intials): > > 1. First initial, last name, plus a number as needed: PSMITH, PSMITH1 > 2. Last name || first name, with number if necessary, but always including > first initial: SMITHIIP, or SMITHIP2 if needed > 3. First three of last name, first two of first name, plus a number: SMIPH03 > (I've always wondered how they'd deal with Kyle Fuchs or Tyrone Shipman) > 4. First initial, last name, truncated to max of six with a two-digit number: > I was PSMITH87; friend was TSMITH99-we never found out what the next T. Smith > would get: would they reuse a hole, if any, or go to TSMIT100? > > > Anyone got any other variations? This is purely a curiosity item, no agenda. > > > -- > 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
Don't remember the manufacturer, I want the actual 3270 keyboard with the USB connect. Sent from Proton Mail mobile Original Message On Jul 4, 2023, 3:53 PM, billogden wrote: > Interesting discussion on screen sizes, keyboards, etc. Many of us have > various different opinions. My opinions have changed since the early days > when some of us (the "older" ones) used 2260s instead of 3270s. I am using a > 21" screen at the moment, with three "windows" open on it. I would not want a > larger screen and perhaps would prefer a slightly smaller one. I prefer a > size that does not require me to constantly move my head to focus on > different parts of the screen. For 3270 emulation I prefer 133 character > width (and most of us probably agree on that) and at least 50 lines high (and > this could vary somewhat). I find 17" laptop screens OK, but not great. More > important for me (because I work mostly with text) is having good character > resolution. Perhaps because I as not as young as I was a few years ago, I > find long periods with crudely-formed characters to be more exhausting. Given > a choice, I would say this is more important than the actual screen size. I > am not fond of laptop keyboards --- IMO they range from barely OK to poor. At > the moment I am using an old PC AT keyboard (with the "round" adapter plug > going to a converter to connect it to a USB port). It has the numeric keypad > (which I do not use) and has good "movement" of the keys that provides a > positive feedback for an old guy like me. (The "real" 3270 terminals had > great keyboards!) I can deal with the red "mouse control" on IBM-designed > laptop keyboards when needed, but I prefer a "real" mouse (with the center > "dial" function, if possible). I use the same glasses for reading books and > for dealing with terminals -- I am lucky that they are fairly "weak" glasses. > The discussion about z/OSMF? One of these months I will need to spend some > time with it. These days I mostly use a relatively slow machine for z/OS and > the performance is not attractive for z/OSMF. Bill Ogden > -- 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
What about Pimento University, good old PU. Sent from Proton Mail mobile Original Message On Jul 4, 2023, 7:32 AM, Tom Brennan wrote: > LOL On 7/3/2023 8:30 PM, Eric Erickson wrote: > PLUGH! > > > -- > 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
Broadcom SCRT
Anyone else having issues logging onto Broadcom SCRT website? Sent from Proton Mail mobile -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OSMF
Remember the days when you could purchase mainframe software? In 1987 we had UCC-1, UCC-7, and UCC-11. And we had just gotten ACF2, which had just been acquired by Uccel. The instructional material at the ACF2 class still had SKK printed on it. Then CA came along and bought Uccel, within a very short time of the Uccel acquisition of ACF2. That's when they started offering their Unipacks to replace the original Uccel purchase contracts. In my humble opinion, that's where mainframe software pricing took a turn for the worse. Sent with Proton Mail secure email. --- Original Message --- On Tuesday, June 27th, 2023 at 7:22 AM, Jack Zukt wrote: > A long time ago, when the only computers available were mainframes, IBM and > ISV pricing strategy may have made a lot of sense. > When I first started working on IT, four decades ago, around here there > were a few dozen of places running IBM MVS, VSE and VM. > Today, after bank and insurance consolidation, plus outsourcing, there are > very, very few remaining. And where before you could only rely on big iron > to run your loads, today there are several much cheaper alternatives being > aggressively offered. > It seems to me that IBM is not concerned with the smaller clients. If you > cannot pay the big bucks then, by all means, take your business elsewhere. > Those clients that need multiple LPARs on multiple boxes, probably will > continue with IBM for the foreseeable future. The others will give up due > to the price. > It is a suicidal strategy as those giving up today will pave the way for > the bigger ones to get out in the future. > Regards > Jack > > On Tue, Jun 27, 2023, 06:51 Neil O'Connor ver.z...@outlook.com wrote: > > > I used z/OSMF on a z13s from 2018 till the end of 2022. Since then it's on > > a z15 T02. I have not found performance to be an issue. It was really bad > > in the early days before it exploited Liberty Profile, but much better > > after that. > > > > Neil. > > > > -Original Message- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf > > Of Brian Westerman > > Sent: Tuesday, 27 June 2023 14:48 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OSMF > > > > I manage 3 sites that each have a z13s with no specialty processors, they > > were deemed unnecessary at the time of the purchase, and at the time IBM > > didn't disclose that shortly afterwards they would be shifting to z/OSMF > > which all but locks them out of installing the next release. > > > > Possibly IBM should not sell processors that are under powered for the > > mandatory processes, or possibly not force sites to upgrade the processor > > they purchased jsut because IBM has decided that z/OSMF is "easier" than > > Serverpac. > > > > It would have been smarter for IBM to keep z/OSMF based installation > > optional until the z13s was no longer a supported processor. > > > > 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 > > > -- > 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
Sigh, yes this has been happing for quite a few years. I first noticed it in 2002. Sent with Proton Mail secure email. --- Original Message --- On Wednesday, June 21st, 2023 at 11:01 AM, Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > Unfortunately, the ignoring of low-end processor client needs is just a > reflection of the Armonk attitude and position that only high-margin business > is worth IBM's attention. No concern for growing smaller clients into larger > ones at all. I have never understood that attitude, as it seems to me to be > guaranteed to drive you into oblivion. > > Decades ago I ran a VM/SP + VSE/SP shop (just me and one other half-systems, > half-applications programmer plus one just-applications programmer) for a > company running their accounting and word-processing storage processes on a > 1M-byte 4361 processor and multiple 8100 processors running DPPX and it > satisfied all their needs. After I left they abandoned IBM and went to an all > DEC mini-computer solution using packaged accounting software because IBM > totally ignored their growing needs. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Brian Westerman > > Sent: Wednesday, June 21, 2023 12:46 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OSMF > > After a couple years of use, I feel I'm pretty safe saying that, to me, > z/OSMF appears to be a poorly designed and very badly programmed product. > Most vendors would have ditched the product and stopped promoting it by now, > but IBM probably has grand "plans" that won't really come into fruition until > sometime around 2030 for z/OSMF. > > As you all know, the z/OSMF product is the ONLY way to install z/OS, (without > using COS), and the product doesn't even run in a usable way on their > smallest, (but still supported and sold) processors. So some poor site that > buys into a z/15 T02 or z/16 A01 with a single CPU can barely even get the > product up let alone have more than one user, and even that user (the systems > programmer doing the install) has abysmal response time. > > I have pointed the problem out to IBM (multiple times), and have gone through > the entire process of "proving" the issue(s) several times showing the issues > in detail, only to be pointed to a manual that states that you "should" have > a minimum of a 400MIP processor complex to use z/OSMF, (because that's what > they use(d) for testing). > > The next problem I already see happening is that they are throwing a bunch of > new "features" and add-ons into it, and some of them would be great products > on their own, but are being hobbled by the (IMO) poorly designed product. > > I still can't believe that the same company that proudly states that we can > still run code developed in the 1960's on the z/16 seems to care less about > the fact that their installation vehicle doesn't support their own small end > processors that you need the z/OSMF installation vehicle to install the OS > with. Any other vendor would be laughed out of town. > > One of the sites we support (a z13s, no zIIP, single CPU) can't even install > the updates from Broadcom via the "normal" method because using the Java > interface times out before authentication. The solution from Broadcom (until > IBM can fix their issue) is that they build a special delivery package for > the site to use. That's just sad, and what was IBM's response after 7 months > of "looking into" the problem? "The site could use a faster processor or the > vendor should increase the authentication time limit." Neither of those is a > possible solution in this case. > > Very sad and poorly played on IBM's part. > -- > > > 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: After installing z/OS 2.5 , we are not able to connect IP.
This is what I have coded for our TCP/IP stack running z/OS 2.5 under IBM's zPDT environment. BROWSEUSER.TCPPARMS(PROFILE1) - 01.73 Command ===> ; ; DEVICE DEFINITION DEVICE LDA400 MPCIPA LINK LDALNK1 IPAQENET LDA400 DEVICE LDA406 MPCIPA LINK LDALNK2 IPAQENET LDA406 D U,,,400,4 IEE457I 10.45.36 UNIT STATUS 163 UNIT TYPE STATUSVOLSER VOLSTATE SS 0400 OSA A-BSY 0 0401 OSA A 0 0402 OSA A-BSY 0 0403 OSA O 0 D NET,ID=OSATRL1,E IST097I DISPLAY ACCEPTED IST075I NAME = OSATRL1, TYPE = TRL MAJOR NODE 166 IST1314I TRLE = LDATRL1E STATUS = ACTIV CONTROL = MPC IST314I END Sent with Proton Mail secure email. --- Original Message --- On Friday, June 16th, 2023 at 10:40 AM, Manoj Bandi <03ba0b4ca1cc-dmarc-requ...@listserv.ua.edu> wrote: > Hi Edward, > > Still no. We are not sure which old DEVICE and LINK statements are removed. > > Thanks & Regards, > Manoj > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of Ed > Jaffe > > Sent: Friday, June 16, 2023 12:15 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: After installing z/OS 2.5 , we are not able to connect IP. > > Sent by an external sender. Please be cautious about clicking on links and > opening attachments. > > > On 6/15/2023 8:26 AM, Manoj Bandi wrote: > > > Am getting connection refused issue, after installing z/OS 2.5. Anybody any > > idea about z/OS 2.5 networking changes ? With z/OS 2.4 amble to connect. Am > > not a networking person, in my shop networking person not able to resolve > > the issue. > > > Didn't they finally get rid of the old DEVICE and LINK statements in z/OS 2.5? > > We started using the newer INTERFACE statements many years ago, so we weren't > affected... > > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RACF passphrase support
If I want to move away from passwords and use passphrases, how do I force users to use passphrases, i.e. RACF exit(s)? Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Receive order processing
Never mind, it finally came back. Looks like it is working. Sent with Proton Mail secure email. --- Original Message --- On Wednesday, June 7th, 2023 at 8:53 AM, rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu> wrote: > I have not performed any RECEIVE ORDER functions in a few months. Based on > the messages below, I was wondering if the recent changes that Kurt from IBM > posted about > are affecting my job. It has been sitting for quite some time. > > GIM20501I SET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 00. > > RECEIVE SYSMODS FORFMID(HLE77C0) > > ORDER(ORDERSERVER(ORDSRVR) > > CLIENT(MYCLIENT) > > CONTENT(RECOMMENDED) > > FORTGTZONES(MVST100) > > ) DELETEPKG . > > GIM68700I ORDER ORD4 HAS BEEN SENT TO THE SERVER AT > > https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/. > > GIM693I SMP/E HAS BEEN WAITING 15 MINUTES FOR ORDER ORD4. SMP/E WILL WAIT > > A MAXIMUM OF 120 MINUTES. > > PAGE 0001 - NOW SET TO GLOBAL ZONE DATE 06/07/23 TIME 07:16:16 SMP/E 37.12 > SMPRPT OUTPUT > > Sent with Proton Mail secure email. > > -- > 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
IBM Receive order processing
I have not performed any RECEIVE ORDER functions in a few months. Based on the messages below, I was wondering if the recent changes that Kurt from IBM posted about are affecting my job. It has been sitting for quite some time. GIM20501I SET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 00. RECEIVE SYSMODS FORFMID(HLE77C0) ORDER(ORDERSERVER(ORDSRVR) CLIENT(MYCLIENT) CONTENT(RECOMMENDED) FORTGTZONES(MVST100) ) DELETEPKG . GIM68700I ORDER ORD4 HAS BEEN SENT TO THE SERVER AT https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/. GIM693I SMP/E HAS BEEN WAITING 15 MINUTES FOR ORDER ORD4. SMP/E WILL WAIT A MAXIMUM OF 120 MINUTES. PAGE 0001 - NOW SET TO GLOBAL ZONE DATE 06/07/23 TIME 07:16:16 SMP/E 37.12 SMPRPT OUTPUT Sent with [Proton Mail](https://proton.me/) secure email. -- 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
I came to a new shop at this time last year. Me predecessor did all of the heavy lifting to install z/OS 2.4. Basically, I had to do a little customization, and roll 2.4 into TECH, DEV, and PROD. Fortunately my predecessor documented everything he had done, which made my job much easier. His documentation regarding /etc & /var showed much the same information that Mark Zelden shared earlier, up to showing the output of the diff commands. To answer your question, my predecessor started with the virgin 2.4 /etc and /var and applied all of the changes from the previously customized z/OS 2.2 /etc and /var. Sent with Proton Mail secure email. --- Original Message --- On Tuesday, June 6th, 2023 at 6:56 AM, Seymour J Metz wrote: > Then what did he to about the functionality previously done by the > customizations? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Pew, Curtis G [curtis@austin.utexas.edu] > Sent: Monday, June 5, 2023 2:00 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Best practice for /etc and /var when upgrading > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Searching for a process to clean my VTS
I've watched this thread for quite sometime. I come from a small systems background, and did not have any exposure to tape libraries and VTS's. Now that I'm working for a larger company, I feel lost in regards to the whole VTS thing. I wish there was a z/OS VTS class that would start from the beginning and work its way up to advanced concepts like clustering and the subject that you guys have been talking about. Just saying. Sent with Proton Mail secure email. --- Original Message --- On Sunday, June 4th, 2023 at 12:28 PM, jony cecil wrote: > Hello, > Pls correct me if I misunderstood the situation: > - you need to clean 0012 and 001F tapes on the cluster only, right? > There's no Rmm or Tcdb information for them, right? > Did you tried, just for one tape, to define it on tcdb with CREA VOLENT > with UATTR(SCRATCH) and force an ALTER on it? Did the category changed to a > scratch category, if so, you can an eject on it with LI E, tape, p. > HTH, regards > > A domingo, 4 de jun de 2023, 11:32, Nobuhiko Furuya furu...@v-sol.co.jp > > escreveu: > > > Hi, > > > > If category code 0002 doesn't have Expire Hold=On, you don't have to > > wait the expire time passes before eject request. > > > > Best regards, > > > > Nobuhiko Furuya(古谷信彦) > > V-SOL Inc. > > > > On 2023/06/03 23:54, Tom Longfellow wrote: > > > > > I have had some progress. Here is the sequence of command for one of > > > my volumes. > > > > > > DELETE 'VTD0900' VOLUMEENTRY > > > IDC3012I ENTRY VTD0900 NOT FOUND+ > > > IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42 > > > IDC0551I ** ENTRY VTD0900 NOT DELETED > > > IDC0014I LASTCC=8 > > > CREATE VOLUMEENT(NAME(VTD0900) LIBRARYNAME(JISVTS1) LOCATION(LIBRARY) > > > STORGRP(SCRTCH) MEDIATYPE(MEDIA2) RECORDING(36TRACK) > > > USEATTRIBUTE(SCRATCH) > > > RMM DV 'TD0900' FORCE > > > RMM AV TD0900 STATUS(VOLCAT) > > > RMM CV TD0900 RETPD(0) STATUS(USER) RELEASEACTION(SCRATCH) > > > RETENTIONMETHOD(EXPDT) > > > RMM DV TD0900 RELEASE > > > > > > This also works on volumes in Category 001F (PRIVATE). These commands > > > were then followed by EDGPLSCS with the command. > > > SQ TD0900 > > > > > > The final results are tapes in Category 0002. > > > > > > My next decision is when to try the EQ commands. Some are still > > > holding space until internal VTS reclaim process cleans the cache ( > > > Prefer Keep) status. > > > Some have a 'Expire Time' of two weeks. Others have an 'Expire Time' > > > of 'Not Set'. > > > I may just go ahead and give it a try after waiting for a RMM > > > Housekeeping to have a pass or two through the CDS. > > > > > > -- > > > 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: Are there samples of COBOL methods or classes?
When I started in 1980, we used 'objects' by copying the last similar program from someone else 's library. Sent from Proton Mail mobile Original Message On May 29, 2023, 9:47 AM, Andrew Rowley wrote: > On 29/05/2023 8:40 am, Tom Ross wrote: > ... The real > worl is not object > oriented...we do no instantiate a customer object and then > invoke a > 'send_a_bill' method on that object. We procedurally decide that it > is time > to send a cusotmer a bill and do it! I'm not sure I would agree... it > probably depends on what sort of code you work with, but I think it would be > extremely common to have a customer object and to have a bill object. Then > e.g. you might have dozens of ways line items might be added to a bill, but > the bill checks its status when you try to add an item and won't allow it if > the bill has already been sent. A program always has a sequence of actions > i.e. a procedure, but with well designed object classes you don't need to > know the procedures beforehand. > Re-usable tested mehods that could be > re-used to build > applications it just not really happening! It's happening > a lot! -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES3 system STC gets wrong Symbol replacements
I've always heard that JES2 was done half ASP. Sent with Proton Mail secure email. --- Original Message --- On Friday, May 12th, 2023 at 9:03 AM, Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > On Fri, 12 May 2023 02:11:03 -0700, Ed Jaffe wrote: > > > ... > > I would try coding SYMBOLS=EXECSYS just like you would with a normal > > batch job. If it doesn't work as expected, it might be an APARable > > behavior... > > When is the value of a dynamic system symbol fixed: > o At job step initiation? > o At SYSIN OPEN? > o Record-by-record as the SYSIN is read? > > If the last, might the same symbols have different values in different records > of the same SYSIN, or two different symbols have anachronistic behavior? > > -- > 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: COBOL to dynamic DD name
The date on the COBOL program is 2005. Sent from Proton Mail mobile Original Message On May 5, 2023, 7:06 PM, Farley, Peter wrote: > Took me a while to find it, but I *think* this is my re-implementation for > TIOT access in Rexx when SWA=ABOVE (I know I copied this technique from > another author whose name I did not save, so my apologies to that author - if > you are still reading this list, please take credit where it is due). Notes > about errors or omissions in the below logic are welcomed. The date on the > source member where I found these routines was 2006, so things may be > different now. I haven't had a need to use this code since 2006, and I can't > test it again right at this moment. If I can find any round tuits I can try > to convert the logic to valid Enterprise COBOL and test it. If someone else > has the time now, please be my guest and let us know your results. Peter > --- alldsn: procedure parse upper arg ddname nextdsn > = getdsn(ddname) dsnlist = '' do xi = 1 by 1 while nextdsn /= (ddname 'NOT > FOUND') dsnlist = dsnlist nextdsn nextdsn = getdsn(ddname'+'xi) end if xi = 1 > then , dsnlist = nextdsn return dsnlist getdsn: procedure parse upper arg > ddname parse var ddname ddname '+' concat if concat = '' then concat = 0 > tcb_address = storage(21C,4) tiot_address = > storage(d2x(c2d(tcb_address)+12),4) dd_address = d2x(c2d(tiot_address)+28) > dd_length = storage(d2x(c2d(tiot_address)+24),1) tiot_address = > d2x(c2d(tiot_address)+24) jfcb_address = storage(d2x(x2d(tiot_address)+12),3) > do while dd_length /= '00'x if storage(dd_address,8) = ddname then leave > tiot_address = d2x(x2d(tiot_address)+c2d(dd_length)) dd_length = > storage(tiot_address,1) dd_address = d2x(x2d(tiot_address)+4) jfcb_address = > storage(d2x(x2d(tiot_address)+12),3) end if dd_length = '00'x then return > ddname 'NOT FOUND' do concat tiot_address = > d2x(x2d(tiot_address)+c2d(dd_length)) dd_length = storage(tiot_address,1) > dd_address = d2x(x2d(tiot_address)+4) jfcb_address = > storage(d2x(x2d(tiot_address)+12),3) if dd_length = '00'x then return ddname > 'NOT FOUND' if storage(dd_address,8) /== ' ' then , return ddname 'NOT FOUND' > end return strip(storage(d2x(c2d(jfcb_address)+16),44),'T') > - -Original Message- From: IBM Mainframe > Discussion List On Behalf Of Farley, Peter Sent: Friday, May 5, 2023 5:58 PM > To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL to dynamic DD name EXTERNAL > EMAIL That logic is fine for SWA below the line, but I don't think many shops > still run that way, at least not the larger ones. ISTR there was at one time > a published Rexx implementation of the SWA-above logic, but I can't put my > finger on it just yet. That logic (if found) should be transferable to > Enterprise COBOL. Peter -Original Message- From: IBM Mainframe > Discussion List On Behalf Of rpinion865 Sent: Friday, May 5, 2023 2:00 PM > To: IBM-MAIN@LISTSERV.UA.EDU Subject: COBOL to dynamic DD name I don't know > if this program is of any use to the original poster. But, I came across the > source this afternoon. It would seem if you can read the JFCB, maybe you > could update it? IDENTIFICATION DIVISION. PROGRAM-ID. COBJFCB. INSTALLATION. > AUTHOR. KEVIN. DATE-WRITTEN. 11/07/2005. ENVIRONMENT DIVISION. INPUT-OUTPUT > SECTION. DATA DIVISION. FILE SECTION. WORKING-STORAGE SECTION. 01 > TCB-ADDRESS-POINTER. 05 TCB-ADDR-POINTER USAGE IS POINTER. 01 TIOT-SEG-POINT. > 05 TIOT-SEG-POINTER USAGE IS POINTER. 05 TIOT-SEG-PNT REDEFINES > TIOT-SEG-POINTER PIC S9(9) COMP. 01 JFCB-POINT. 05 JFCB-POINTER USAGE IS > POINTER. 05 JFCB-POINT-RED REDEFINES JFCB-POINTER. 10 FILLER PIC X. 10 > JFCB-LOW-3 PIC X(3). LINKAGE SECTION. 01 DDNAME-DSN-ARRAY. 05 DDNAME-DSN > OCCURS 100 TIMES INDEXED BY NDX1. 10 DDA-DDNAME PIC X(8). 10 DDA-DSN PIC > X(44). 01 TCB-POINTER USAGE IS POINTER. 01 TCB. 05 FILLER PIC X(12). 05 > TIOT-POINTER USAGE IS POINTER. 01 TIOT-START PIC X(24). 01 TIOT-SEG. 05 > TIO-LEN PIC X. 05 FILLER PIC X(3). 05 DD-NAME PIC X(8). 05 JFCB-ADDR PIC > X(3). 01 JFCB. 05 FILLER PIC X(16). 05 DS-NAME PIC X(44). PROCEDURE DIVISION > USING DDNAME-DSN-ARRAY. MOVE LOW-VALUES TO JFCB-POINT. MOVE X'021C' TO > TCB-ADDRESS-POINTER. SET ADDRESS OF TCB-POINTER TO TCB-ADDR-POINTER. SET > ADDRESS OF TCB TO TCB-POINTER. SET ADDRESS OF TIOT-START TO TIOT-POINTER. SET > TIOT-SEG-POINTER TO TIOT-POINTER. ADD 24 TO TIOT-SEG-PNT. SET ADDRESS OF > TIOT-SEG TO TIOT-SEG-POINTER. SET NDX1 TO 1. PERFORM UNTIL TIO-LEN = > LOW-VALUES OR NDX1 > 100 MOVE DD-NAME TO DDA-DDNAME(NDX1) MOVE JFCB-ADDR TO > JFCB-LOW-3 SET ADDRESS OF JFCB TO JFCB-POINTER MOVE DS-NAME TO DDA-DSN(NDX1) > DISPLAY DDA-DDNAME(NDX1) DDA-DSN(NDX1) ADD
COBOL to dynamic DD name
I don't know if this program is of any use to the original poster. But, I came across the source this afternoon. It would seem if you can read the JFCB, maybe you could update it? IDENTIFICATION DIVISION. PROGRAM-ID. COBJFCB. INSTALLATION. AUTHOR. KEVIN. DATE-WRITTEN. 11/07/2005. ENVIRONMENT DIVISION. INPUT-OUTPUT SECTION. DATA DIVISION. FILE SECTION. WORKING-STORAGE SECTION. 01 TCB-ADDRESS-POINTER. 05 TCB-ADDR-POINTER USAGE IS POINTER. 01 TIOT-SEG-POINT. 05 TIOT-SEG-POINTER USAGE IS POINTER. 05 TIOT-SEG-PNT REDEFINES TIOT-SEG-POINTER PIC S9(9) COMP. 01 JFCB-POINT. 05 JFCB-POINTER USAGE IS POINTER. 05 JFCB-POINT-RED REDEFINES JFCB-POINTER. 10 FILLER PIC X. 10 JFCB-LOW-3 PIC X(3). LINKAGE SECTION. 01 DDNAME-DSN-ARRAY. 05 DDNAME-DSN OCCURS 100 TIMES INDEXED BY NDX1. 10 DDA-DDNAME PIC X(8). 10 DDA-DSN PIC X(44). 01 TCB-POINTER USAGE IS POINTER. 01 TCB. 05 FILLER PIC X(12). 05 TIOT-POINTER USAGE IS POINTER. 01 TIOT-START PIC X(24). 01 TIOT-SEG. 05 TIO-LEN PIC X. 05 FILLER PIC X(3). 05 DD-NAME PIC X(8). 05 JFCB-ADDR PIC X(3). 01 JFCB. 05 FILLER PIC X(16). 05 DS-NAME PIC X(44). PROCEDURE DIVISION USING DDNAME-DSN-ARRAY. MOVE LOW-VALUES TO JFCB-POINT. MOVE X'021C' TO TCB-ADDRESS-POINTER. SET ADDRESS OF TCB-POINTER TO TCB-ADDR-POINTER. SET ADDRESS OF TCB TO TCB-POINTER. SET ADDRESS OF TIOT-START TO TIOT-POINTER. SET TIOT-SEG-POINTER TO TIOT-POINTER. ADD 24 TO TIOT-SEG-PNT. SET ADDRESS OF TIOT-SEG TO TIOT-SEG-POINTER. SET NDX1 TO 1. PERFORM UNTIL TIO-LEN = LOW-VALUES OR NDX1 > 100 MOVE DD-NAME TO DDA-DDNAME(NDX1) MOVE JFCB-ADDR TO JFCB-LOW-3 SET ADDRESS OF JFCB TO JFCB-POINTER MOVE DS-NAME TO DDA-DSN(NDX1) DISPLAY DDA-DDNAME(NDX1) DDA-DSN(NDX1) ADD 20 TO TIOT-SEG-PNT SET ADDRESS OF TIOT-SEG TO TIOT-SEG-POINTER SET NDX1 UP BY 1 END-PERFORM. GOBACK. Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CICS startup failure
Wondering if you upgraded the LE CICS definitions for LE z/OS 2.5. See CEE.SCEESAMP(CEECCSD). Sent with Proton Mail secure email. --- Original Message --- On Wednesday, May 3rd, 2023 at 3:14 PM, esst...@juno.com wrote: > Hello Dave - > . > After You manually install the list using CEDA, are you able to recycle CICS > with the GRPLIST to the SYSIN patrameters ? > . > > -- Original Message -- > From: Dave Quinn davequ...@prism-data.com > > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: CICS startup failure > Date: Wed, 3 May 2023 06:27:49 -0500 > > I'm installing a new Z/OS 2.5 and am down to the last piece; a CICS TS 5.6 > region. It would be complete except that when I add any valid GRPLIST to the > parameters on an initial start the startup fails and dumps without giving any > error. The CICS DFHCXRF indicates the autoinstall was successful but directly > afterwards it produces a dump and ends. If I take the GRPLIST out I am able > to startup and install the GRPLIST with CEDA without error. > > Thoughts or recommendations of where to begin looking? > > -- > 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 and zEDC compression of output
Wasting more time searching the internet about zEDC I came across several articles about SMF record compression when using log streams. It sounded almost like you did not need the zEDC Express software feature. So, I coded compress for the TECH LPAR, and did a SET SMF=xx. It failed with IFA730E. So, I guess not so lucky with SMF :( Thanks for the info! Sent with Proton Mail secure email. --- Original Message --- On Wednesday, April 26th, 2023 at 12:33 PM, Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > Yes. You don't need to license zEDC for JES2 to use it for spool compression. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > --- Original Message --- > On Wednesday, April 26th, 2023 at 11:52 AM, rpinion865 > 042a019916dd-dmarc-requ...@listserv.ua.edu wrote: > > > > > I happened to come across a PDF document from the 2020 NY Tampa Bay RUG > > titled Protecting SPOOL with pervasive encryption and other recent JES2 > > security changes. > > > > Stepping away from the encryption part, I found a section concerning JES2 > > compression of output, via the OUTCLASS paramter, using zEDC. The document > > states that JES2 can use the zEDC compression engine on the z15 with no > > software charge. I know that using zEDC compression for SMS managed > > datasets does require licensing zEDC Express software feature. > > > > Am I understanding that correctly, that JES2 will use zEDC and we don't > > have to pay anything extra for that? > > > > Sent with Proton Mail secure email. > > > > -- > > 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
JES2 and zEDC compression of output
I happened to come across a PDF document from the 2020 NY Tampa Bay RUG titled Protecting SPOOL with pervasive encryption and other recent JES2 security changes. Stepping away from the encryption part, I found a section concerning JES2 compression of output, via the OUTCLASS paramter, using zEDC. The document states that JES2 can use the zEDC compression engine on the z15 with no software charge. I know that using zEDC compression for SMS managed datasets does require licensing zEDC Express software feature. Am I understanding that correctly, that JES2 will use zEDC and we don't have to pay anything extra for that? Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Card processing application
Take a look at https://cvsystems.com/cv-payment-processing/ Sent with Proton Mail secure email. --- Original Message --- On Tuesday, April 25th, 2023 at 7:55 AM, Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > I'm looking for card processing application. > I mean a system which support ATMs, POS (shop terminals), customers PIN > & account verification, etc. > (note, full core-banking system is not an option). > Oh, z/OS based. :-) > > -- > Radoslaw Skorupka > Lodz, Poland > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Free TN3270E with GDDM support
Any suggestions for a free TN3270E emulator that has GDDM support? Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx Exec to Build 10,000 PDS Members: ALLOC vs ISPF Services vs ?
Please send me your email address. My email address is
rpinion...@protonmail.com
Sent with Proton Mail secure email.
--- Original Message ---
On Wednesday, April 19th, 2023 at 2:54 PM, David Spiegel
<0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:
> Hi Richard,
> I would be interested in obtaining a copy of this.
>
> Thanks and regards,
> David
>
> On 2023-04-19 14:41, rpinion865 wrote:
>
> > I have a very old assembler program. It was written to extract job log
> > information from a JES external writer output dataset, and create a member
> > for each job.
> >
> > GENEDIT CSECT
> > * *
> > ***
> > * *
> > * PROGRAM DESCRIPTION *
> > * *
> > * THIS PROGRAM READS A SEQUENTIAL DATA SET THAT WAS CREATED BY AN *
> > * EXTERNAL WRITER. THE SEQUENTIAL DATA SET CONTAINS CLASS H OUTPUT *
> > * FROM THE PREVIOUS NIGHT'S PRODUCTION JOBS. THE PROGRAM CREATES A *
> > * PDS MEMBER FOR EACH JOB. IF THERE ARE DUPLICATE JOBS, SECONDARY *
> > * MEMBERS ARE CREATED FROM THE FIRST SIX CHARACTERS OF THE JOB NAME *
> > * PLUS A TWO DIGIT COUNT OF THE NUMBER OF TOTAL SECONDARY MEMBER *
> > * NAMES. THE PROGRAM ABENDS WITH A USER ONE, IF A RETURN CODE *
> > * FROM STOW IS GREATER THAN 4. THE PDS CREATED HAS LRECL OF 133, *
> > * BLKSIZE OF 0, AND RECFM OF FB. *
> > * *
> > ***
> > * *
> >
> > Sent with Proton Mail secure email.
> >
> > --- Original Message ---
> > On Wednesday, April 19th, 2023 at 2:38 PM, Paul Gilmartin
> > 042bfe9c879d-dmarc-requ...@listserv.ua.edu wrote:
> >
> > > On Wed, 19 Apr 2023 14:21:58 -0400, David Spiegel wrote:
> > >
> > > > If I understand correctly ...
> > > > "ALLOC F(X) DA('MY.PDS') SH REU"
> > > >
> > > > Do i=1 to n
> > > > "ALLOC F(Y) DA('MY.PDS('member')') SH REU
> > > > "EXECIO * DISKW (FINIS
> > > > End
> > > >
> > > > Is this correct?
> > > > That's what I remember. But it might be better to remove the ALLOC and
> > > > EXECIO from
> > > > the loop and do
> > > > LMINIT DDNAME(X) /* outside the loop. /
> > > > then LMPUT, etc. / inside. */
> > >
> > > LMPUT requires exclusive allocation, not SHR.
> > > It's infuriating that ISPF has no support for REXX compould symbols,
> > > instead providing the bizarre MULTX form.
> > >
> > > IBM doesn't care.
> > >
> > > --
> > > 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
Re: Rexx Exec to Build 10,000 PDS Members: ALLOC vs ISPF Services vs ?
I have a very old assembler program. It was written to extract job log
information from a JES external writer output dataset, and create a member for
each job.
GENEDIT CSECT
* *
***
* *
*PROGRAM DESCRIPTION *
* *
* THIS PROGRAM READS A SEQUENTIAL DATA SET THAT WAS CREATED BY AN *
* EXTERNAL WRITER. THE SEQUENTIAL DATA SET CONTAINS CLASS H OUTPUT *
* FROM THE PREVIOUS NIGHT'S PRODUCTION JOBS. THE PROGRAM CREATES A *
* PDS MEMBER FOR EACH JOB. IF THERE ARE DUPLICATE JOBS, SECONDARY *
* MEMBERS ARE CREATED FROM THE FIRST SIX CHARACTERS OF THE JOB NAME *
* PLUS A TWO DIGIT COUNT OF THE NUMBER OF TOTAL SECONDARY MEMBER*
* NAMES. THE PROGRAM ABENDS WITH A USER ONE, IF A RETURN CODE *
* FROM STOW IS GREATER THAN 4. THE PDS CREATED HAS LRECL OF 133, *
* BLKSIZE OF 0, AND RECFM OF FB.*
* *
***
* *
Sent with Proton Mail secure email.
--- Original Message ---
On Wednesday, April 19th, 2023 at 2:38 PM, Paul Gilmartin
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 19 Apr 2023 14:21:58 -0400, David Spiegel wrote:
>
> > If I understand correctly ...
> > "ALLOC F(X) DA('MY.PDS') SH REU"
> >
> > Do i=1 to n
> > "ALLOC F(Y) DA('MY.PDS('member')') SH REU
> > "EXECIO * DISKW (FINIS
> > End
> >
> > Is this correct?
>
> That's what I remember. But it might be better to remove the ALLOC and EXECIO
> from
> the loop and do
> LMINIT DDNAME(X) /* outside the loop. /
> then LMPUT, etc. / inside. */
>
> LMPUT requires exclusive allocation, not SHR.
> It's infuriating that ISPF has no support for REXX compould symbols,
> instead providing the bizarre MULTX form.
>
> IBM doesn't care.
>
> --
> 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: AI wipes out humanity?
The first time I saw it on Tubi, I quit after 10 minutes. A few months later, I was really bored, and decided to watch it again. The second time, I watched it to the end. It really is cheesy. But that is what makes it funny. You really have to love their alien :) Sent with Proton Mail secure email. --- Original Message --- On Wednesday, April 12th, 2023 at 2:28 PM, Phil Smith III wrote: > Bob Bridges wrote: > > > Wow, that looks REALLY bad! Even for 1974. > > > Bob, it was a comedy. And a great one-I saw it first-run or thereabouts and > have VERY fond memories of it. Opening scene, which first Star Wars movie > kind of borrowed, has the ship moving majestically across the screen. Then > it just.stops. > > Dark Star I'm sure was meant to be funny; I remember a rumor that Ice > Pirates was supposed to be a serious science fiction movie, and that partway > through filming, someone looked at the rushes and said "This had better be a > comedy", so they made it into one. > > > -- > 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: AI wipes out humanity?
Here's the trailer. https://www.youtube.com/watch?v=lwISbJfRNz0 Sent with Proton Mail secure email. --- Original Message --- On Wednesday, April 12th, 2023 at 8:25 AM, rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu> wrote: > Also, please see > > https://en.wikipedia.org/wiki/Dark_Star_(film) > > "The bomb, having learned Cartesian doubt, trusts only itself. It is > convinced that only it exists, and that its sole purpose in life is to > explode, and it does so. Dark Star is destroyed" > > > > > Sent with Proton Mail secure email. > > > --- Original Message --- > On Wednesday, April 12th, 2023 at 8:23 AM, rpinion865 > 042a019916dd-dmarc-requ...@listserv.ua.edu wrote: > > > > > I tried to find a movie clip. But, this is the best I could find. I suggest > > watching the movie to get the full effect. The ending is really way, way > > out > > > > "The Evil Computer: The computere (or Thermostellar Triggering Device) > > aboard the space ship Dark Star is responsible for destroying unstable > > planets at the behest of Sergeant Pinback (Dan O'Bannon) by deploying > > nuclear bombs. > > > > Annoyingly, the ship's computer is damaged and decides that the Dark Star > > itself is fit for bombing. The crew attempt to reason with Bomb #20, which > > refuses to be convinced otherwise." > > > > Sent with Proton Mail secure email. > > > > --- Original Message --- > > On Wednesday, April 12th, 2023 at 7:52 AM, Bill Hitefield > > bill.hitefi...@dino-software.com wrote: > > > > > Yep. To quote Kirk: "We've got them right where they want us." > > > > > > Bill Hitefield > > > > > > > -Original Message- > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > > > Behalf Of Tom Brennan > > > > Sent: Wednesday, April 12, 2023 12:06 AM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Re: [EXTERNAL] Re: AI wipes out humanity? > > > > > > > > "Compute to the last digit, the value of pi." > > > > https://www.i/ > > > > mdb.com%2Ftitle%2Ftt0708491%2Freference%2F=05%7C01%7CBill.Hitefi > > > > eld%40DINO- > > > > SOFTWARE.COM%7C6911c35781664161929f08db3b0b590f%7Cbe5c5b1debb34 > > > > 3f3a3641e98fd405647%7C0%7C0%7C638168692151742793%7CUnknown%7CT > > > > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > > > > CI6Mn0%3D%7C3000%7C%7C%7C=RWXDCYObUEbzXO%2FEVAFr45uSgxj > > > > MWv00%2F9CW4n0zXik%3D=0 > > > > > > > > Maybe we shouldn't post these defensive methods since AI is watching. > > > > > > > > On 4/11/2023 8:44 PM, Mike Schwab wrote: > > > > > > > > > Return Of The Archons > > > > > https://www/. > > > > > > > > imdb.com%2Ftitle%2Ftt0708476%2F=05%7C01%7CBill.Hitefield%40DINO- > > > > S > > > > > > > > OFTWARE.COM%7C6911c35781664161929f08db3b0b590f%7Cbe5c5b1debb343 > > > > f3a3641 > > > > > > > > e98fd405647%7C0%7C0%7C638168692151742793%7CUnknown%7CTWFpbGZs > > > > b3d8eyJWI > > > > > > > > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > > > > 0%7 > > > > > > > > C%7C%7C=lBhJzv%2BMXa7yL91qLJzEwkFMxUFZgTx1oDFPuCv2NyA%3D > > > > > > > > > > > > > d=0 Captain Kirk shuts down computer after 6,000 years of running a > > > > > society. > > > > > > > > > > On Tue, Apr 11, 2023 at 7:34 PM Dale R. Smith > > > > > dale-sm...@columbus.rr.com wrote: > > > > > > > > > > > On Tue, 11 Apr 2023 21:22:53 +, Dave Barry dba...@ups.com wrote: > > > > > > > > > > > > > Sorry, Dave. I can't do that. > > > > > > > > > > > > > > -Original Message- > > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > > > > > > Behalf Of rpinion865 > > > > > > > Sent: Monday, April 10, 2023 10:22 AM > > > > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > > > > Subject: [EXTERNAL] Re: AI wipes out humanity? > > > > > > > > > > > > > > CAUTION! This email originated outside of the organization. > > > > > >
Re: [EXTERNAL] Re: AI wipes out humanity?
Also, please see https://en.wikipedia.org/wiki/Dark_Star_(film) "The bomb, having learned Cartesian doubt, trusts only itself. It is convinced that only it exists, and that its sole purpose in life is to explode, and it does so. Dark Star is destroyed" Sent with Proton Mail secure email. --- Original Message --- On Wednesday, April 12th, 2023 at 8:23 AM, rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu> wrote: > I tried to find a movie clip. But, this is the best I could find. I suggest > watching the movie to get the full effect. The ending is really way, way > out > > "The Evil Computer: The computere (or Thermostellar Triggering Device) aboard > the space ship Dark Star is responsible for destroying unstable planets at > the behest of Sergeant Pinback (Dan O'Bannon) by deploying nuclear bombs. > > Annoyingly, the ship's computer is damaged and decides that the Dark Star > itself is fit for bombing. The crew attempt to reason with Bomb #20, which > refuses to be convinced otherwise." > > > > > > Sent with Proton Mail secure email. > > > --- Original Message --- > On Wednesday, April 12th, 2023 at 7:52 AM, Bill Hitefield > bill.hitefi...@dino-software.com wrote: > > > > > Yep. To quote Kirk: "We've got them right where they want us." > > > > Bill Hitefield > > > > > -Original Message- > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > > Behalf Of Tom Brennan > > > Sent: Wednesday, April 12, 2023 12:06 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: [EXTERNAL] Re: AI wipes out humanity? > > > > > > "Compute to the last digit, the value of pi." > > > https://www.i/ > > > mdb.com%2Ftitle%2Ftt0708491%2Freference%2F=05%7C01%7CBill.Hitefi > > > eld%40DINO- > > > SOFTWARE.COM%7C6911c35781664161929f08db3b0b590f%7Cbe5c5b1debb34 > > > 3f3a3641e98fd405647%7C0%7C0%7C638168692151742793%7CUnknown%7CT > > > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > > > CI6Mn0%3D%7C3000%7C%7C%7C=RWXDCYObUEbzXO%2FEVAFr45uSgxj > > > MWv00%2F9CW4n0zXik%3D=0 > > > > > > Maybe we shouldn't post these defensive methods since AI is watching. > > > > > > On 4/11/2023 8:44 PM, Mike Schwab wrote: > > > > > > > Return Of The Archons > > > > https://www/. > > > > > > imdb.com%2Ftitle%2Ftt0708476%2F=05%7C01%7CBill.Hitefield%40DINO- > > > S > > > > > > OFTWARE.COM%7C6911c35781664161929f08db3b0b590f%7Cbe5c5b1debb343 > > > f3a3641 > > > > > > e98fd405647%7C0%7C0%7C638168692151742793%7CUnknown%7CTWFpbGZs > > > b3d8eyJWI > > > > > > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > > > 0%7 > > > > > > C%7C%7C=lBhJzv%2BMXa7yL91qLJzEwkFMxUFZgTx1oDFPuCv2NyA%3D > > > > > > > > > > d=0 Captain Kirk shuts down computer after 6,000 years of running a > > > > society. > > > > > > > > On Tue, Apr 11, 2023 at 7:34 PM Dale R. Smith > > > > dale-sm...@columbus.rr.com wrote: > > > > > > > > > On Tue, 11 Apr 2023 21:22:53 +, Dave Barry dba...@ups.com wrote: > > > > > > > > > > > Sorry, Dave. I can't do that. > > > > > > > > > > > > -Original Message- > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > > > > > Behalf Of rpinion865 > > > > > > Sent: Monday, April 10, 2023 10:22 AM > > > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > > > Subject: [EXTERNAL] Re: AI wipes out humanity? > > > > > > > > > > > > CAUTION! This email originated outside of the organization. Please > > > > > > do not > > > > > > open attachments or click links from an unknown or suspicious > > > > > > origin. > > > > > > = > > > === > > > > > > > > > == And, no one mentions the HAL 9000??? > > > > > > > > > > Before HAL: > > > > > TOS S2.E24 March 8, 1968 - The Ultimate Computer > > > > > https://www/ > > > > > > .imdb.com%2Ftitle%2Ftt0708481%2F%3Fref_%3Dfn_tt_tt_1=05%7C01%7 > > > CB > > > > > > > > ill.Hitefield%40DINO- > > > &
Re: [EXTERNAL] Re: AI wipes out humanity?
I tried to find a movie clip. But, this is the best I could find. I suggest watching the movie to get the full effect. The ending is really way, way out "The Evil Computer: The computere (or Thermostellar Triggering Device) aboard the space ship Dark Star is responsible for destroying unstable planets at the behest of Sergeant Pinback (Dan O'Bannon) by deploying nuclear bombs. Annoyingly, the ship's computer is damaged and decides that the Dark Star itself is fit for bombing. The crew attempt to reason with Bomb #20, which refuses to be convinced otherwise." Sent with Proton Mail secure email. --- Original Message --- On Wednesday, April 12th, 2023 at 7:52 AM, Bill Hitefield wrote: > Yep. To quote Kirk: "We've got them right where they want us." > > Bill Hitefield > > > -Original Message- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > Behalf Of Tom Brennan > > Sent: Wednesday, April 12, 2023 12:06 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: [EXTERNAL] Re: AI wipes out humanity? > > > > "Compute to the last digit, the value of pi." > > https://www.i/ > > mdb.com%2Ftitle%2Ftt0708491%2Freference%2F=05%7C01%7CBill.Hitefi > > eld%40DINO- > > SOFTWARE.COM%7C6911c35781664161929f08db3b0b590f%7Cbe5c5b1debb34 > > 3f3a3641e98fd405647%7C0%7C0%7C638168692151742793%7CUnknown%7CT > > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > > CI6Mn0%3D%7C3000%7C%7C%7C=RWXDCYObUEbzXO%2FEVAFr45uSgxj > > MWv00%2F9CW4n0zXik%3D=0 > > > > Maybe we shouldn't post these defensive methods since AI is watching. > > > > On 4/11/2023 8:44 PM, Mike Schwab wrote: > > > > > Return Of The Archons > > > https://www/. > > > > imdb.com%2Ftitle%2Ftt0708476%2F=05%7C01%7CBill.Hitefield%40DINO- > > S > > > > OFTWARE.COM%7C6911c35781664161929f08db3b0b590f%7Cbe5c5b1debb343 > > f3a3641 > > > > e98fd405647%7C0%7C0%7C638168692151742793%7CUnknown%7CTWFpbGZs > > b3d8eyJWI > > > > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > > 0%7 > > > > C%7C%7C=lBhJzv%2BMXa7yL91qLJzEwkFMxUFZgTx1oDFPuCv2NyA%3D > > > > > > > d=0 Captain Kirk shuts down computer after 6,000 years of running a > > > society. > > > > > > On Tue, Apr 11, 2023 at 7:34 PM Dale R. Smith > > > dale-sm...@columbus.rr.com wrote: > > > > > > > On Tue, 11 Apr 2023 21:22:53 +, Dave Barry dba...@ups.com wrote: > > > > > > > > > Sorry, Dave. I can't do that. > > > > > > > > > > -Original Message- > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > > > > Behalf Of rpinion865 > > > > > Sent: Monday, April 10, 2023 10:22 AM > > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > > Subject: [EXTERNAL] Re: AI wipes out humanity? > > > > > > > > > > CAUTION! This email originated outside of the organization. Please do > > > > > not > > > > > open attachments or click links from an unknown or suspicious origin. > > > > = > > === > > > > > > > == And, no one mentions the HAL 9000??? > > > > > > > > Before HAL: > > > > TOS S2.E24 March 8, 1968 - The Ultimate Computer > > > > https://www/ > > > > .imdb.com%2Ftitle%2Ftt0708481%2F%3Fref_%3Dfn_tt_tt_1=05%7C01%7 > > CB > > > > > > ill.Hitefield%40DINO- > > > > SOFTWARE.COM%7C6911c35781664161929f08db3b0b590f% > > > > 7Cbe5c5b1debb343f3a3641e98fd405647%7C0%7C0%7C638168692151898998 > > %7CUnk > > > > nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h > > aW > > > > wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AMOPd9rbDkzlWF97OHSNfg > > rsAl6Kgf > > > > > > inEUf9GkTOk5s%3D=0 > > > > > > > > -- > > > > Dale R. Smith > > > > > > > > - > > > > - 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: AI wipes out humanity?
And, no one mentions the HAL 9000??? Sent with Proton Mail secure email. --- Original Message --- On Monday, April 10th, 2023 at 10:12 AM, Bob Bridges wrote: > Getting into philosophy, but why not? > > Shmuel> Wouldn't that depend on the programming and training? > > > Me> Sure. Has anyone programmed self-preservation into any of the current > > AIs? I suspect no one's thought of such a thing yet. (And maybe anyone who > has thought of it has thought better of it.) > > The assumption that AIs want to preserve themselves is probably inseparable > from the assumption that AIs are self-aware*, and I suppose it's that > assumption that I'm questioning. I seriously doubt we ~can~ create > self-awareness, but that's debatable because we don't really know how to > define what self-awareness is. Assuming for the sake of argument that we > can, how would we determine whether an AI has it? We call that the Turing > test, but as far as I know we don't have one. > > (Stop me if I've told this one already: Decades ago I attended a software > conference in Anaheim. My best friend from high school lives in that area, > and when he heard that the guest speaker at the wrap-up banquet was to be > Gene Rodenberry, he shelled out $50 to attend the banquet himself. Gene > Rodenberry didn't show, pleading exhaustion, but the man who came in his > place was an entertaining speaker and I remember thoroughly enjoying his > talk. > > (In that decade it was fashionable to talk knowledgeably about the Turing > test. Partway through his presentation he mentioned it, and added "...and > by the way no one should be allowed to talk about the Turing test if they > can't pass it themselves". Terry and I burst into loud laughter - and > quickly stifled ourselves as we realized the rest of the room was silent. > The speaker paused, and then said "Well, I guess now we know who knows what > the Turing test is." Of course we had to laugh again, but more respectably > this time.) > > * I do not mean that the two ~propositions~ are inseparable. I'm just > thinking that anyone who ~assumes~ that AIs feel the need to preserve > themselves are assuming that they're self-aware. > > Schmuel> Some people lack an impulse to preserve themselves. Consider > > reckless behavior and suicide attempts. > > Me> I consider it, but neither one contradicts the assertion. Even those > > folks have a strong impulse to live. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* A man who has lived in many places is not likely to be deceived by the > local errors of his native village; the scholar has lived in many times and > is therefore in some degree immune from the great cataract of nonsense that > pours from the press and the microphone of his own age. -C S Lewis, "The > Weight of Glory" */ > > > From: Bob Bridges [robhbrid...@gmail.com] > Sent: Sunday, April 9, 2023 7:19 PM > > Yeah, I realize I didn't define anything. But in this case I'm really just > saying that we have no idea whether an AI can have an impulse to preserve > itself. We observe that impulse in every form of life, but it's well to > keep in mind that an AI isn't of that sort. It may have that impulse, but > so far that's just an assumption, no? > > -- > 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
zOSMF certificates
If you installed the zOSMF certificates from the IZUSEC member of SYS1.SAMPLIB, you might want to check the certificate expiration date. Ours was set to May 17, 2023. We've deleted and regenerated the certificate with a much later date. Hopefully, past my retirement date. Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Almost gone
I will second that. There are still job listings for remote system programmers, if you are interested in that. Sent with Proton Mail secure email. --- Original Message --- On Wednesday, March 29th, 2023 at 11:32 AM, Lionel B. Dyck wrote: > Thank you for ALL your contributions to the community. > > > Lionel B. Dyck <>< > > Website: https://www.lbdsoftware.com > Github: https://github.com/lbdyck > > “Worry more about your character than your reputation. Character is what you > are, reputation merely what others think you are.” - - - John Wooden > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > John McKown > > Sent: Wednesday, March 29, 2023 10:16 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Almost gone > > HealthMarkets z9BC is shutting down. User access will be removed 5Apr. CICS > will be unavailable after 31Mar. The last day is at the end of April. Most of > the equipment is so old it is being destroyed, except for the tape drives > which are being sold for parts. SCRT will be run on 2May. I'll be on the > payroll until the beginning of August in lieu of severance. > > -- > 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: linklist error at IPL
If memory serves me right, I think BMC had something in one of the auto operations products, that was a PC/Server application that acted as a console. With that, the PC/Server application could take action based on the console traffic. But, maybe I dreamed that :) Sent with Proton Mail secure email. --- Original Message --- On Friday, March 17th, 2023 at 9:21 AM, Richard McIntosh wrote: > A healthcheck would be nice. I normally do check the syslog following IPLs, > but forgot to check this lpar. Had several other lpars being IPL'd. > > Richard > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Mark Zelden > > Sent: Thursday, March 16, 2023 7:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [External] : Re: linklist error at IPL > > I know there are lots of critical errors that can happen during NIP so I > don't know exactly where to draw the line, but it would be great if the OS > could flag things like this (missing LNKLST library, missing LPA library or > MLPA, missing SVCs) and then > reflect the error in a health check post IPL. Normal console automation could > catch > that easily and warn someone and it could be fixed and the system re-IPLed at > the time. > > Personally, for planned IPLs I always check NIP on at least on one system in > a sysplex > if multiple systems are being IPLed (parms / sysres are shared anyway). > > 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__;!!ACWV5N9M2RV99hQ!Phf8pdW2TZtTCS1AQJE_5ft-eBZY0rQYttub1DhutrqWScssfSssBV6hkFOJUKuJ307RC4uk0o6ZrJT6RA$ > > > On Thu, 16 Mar 2023 17:20:36 -0500, Steve Horein steve.hor...@gmail.com wrote: > > > Do you have any kind of automation package available to you? > > > > On Thu, Mar 16, 2023 at 8:11 AM Richard McIntosh < > > richard.mcint...@oracle.com> wrote: > > > > > Is there anyway to get alerted to a linklist error duing the IPL process. > > > The error messages come out to early for any MPF processing to hilite > > > it and they rolled by to quick for operations to notice and caused > > > TLMS to not get initialized. Dataset is not in master catalog and the > > > wrong volser was specified. > > > > > > IGGN307I SYSP01,SYSR.TLMS.R14MA.CTAPLINK,DATA SET NOT FOUND ON > > > VOLUME > > > > > > IEA716I UNABLE TO OPEN LIBRARY - LNKLST DATA SET IGNORED > > > > > > SYSR.TLMS.R14MA.CTAPLINK > > > > > > I googled an old (18 years ago) message about someone using the > > > IEAVMXIT exit to check some storage to see if any error flags were > > > set, but there was no mention of what storage it was. > > > > > > Thanks > > > > > > Richard McIntosh > > > > > > - > > > - 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: Processing SMF Type 15 records help
Go to www.cbttage.org, and look for Dataset Audit Facility (DAF). Sent with Proton Mail secure email. --- Original Message --- On Thursday, March 16th, 2023 at 9:45 AM, Steve Doonan wrote: > Good Day Listserv readers, > > > > I have a need to provide report data on the updating of production source > and loadlib PDS dsns with the date/time stamps, userid/jobname, and > member/module name details. I can get all the data from ICETOOL reports that > I run against the output of IFASMFDP using USER2(IRRADU00) and > USER3(IRRADU86) except the member/module name details. > > > > I am not a Systems programmer, so I do not have the ability to code an > assembler program to process the type 15 records to obtain the information. > I have read through the MVS SMF manual to determine what my options are but > unfortunately I don't have the skill set to get the type 15 data. I have run > the IFASMFDP program pulling just the type 15's, but I don't have a way to > process them after that point. The shop does not have SAS or WPS installed > so that is not an option either. I was hoping someone on the list can > provide some direction from their experience. > > > > Thanks, > > Steve Doonan > > RACF Administrator > > > > > -- > 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: FW: SMP)e
I am assuming this is for z/OS 2.4. At my current employer, I have the PTF applied. I think that at my past employer, I ran into the same problem you did. I never was able to resolve the error at the previous employer. The only difference between old employer and new employer, was the date of the receiving of cumulative maintenance. Previous employer, date of receiving cumulative maintenance was third quarter 2021, current employer second quarter of 2022. Sent with Proton Mail secure email. --- Original Message --- On Thursday, March 9th, 2023 at 2:14 PM, Steve Beaver wrote: > Are any of you that are having the following error in SMPe? And if you > > Have had it - How did you get passed it > > > > GIM24608E ** SHELLSCR ENTRY BBLS2009 IS NEEDED TO PROCESS HFS BBL20009 FOR > > SYSMOD UI76945, BUT SHELLSCR BBLS2009 IS NOT IN THE MVST100 > ZONE. > > > > TIA > > Steve > > > -- > 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
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://entegriasystems.com and https://fastssr.net (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
Re: zOSMF
We were MVS/SP 1.3.6, which was installed in 1987. While is has been a very long time, I remember going from MVS/SP 1.3.6 to XA 2.2. Sent with Proton Mail secure email. --- Original Message --- On Wednesday, March 8th, 2023 at 2:46 PM, Mike Schwab wrote: > https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/1/897/ENUS283-141/index.html_locale=en > > Shows quite a few steps required to get to MVS/XA from MVS/370 3.8. > > On Wed, Mar 8, 2023 at 1:26 PM rpinion865 > 042a019916dd-dmarc-requ...@listserv.ua.edu wrote: > > > The last MVS/SP I ran was 1.3.6. That was in the 1987 time frame. The next > > leap I made was to MVS/XA 2.2, and that was in 1988. > > > > Sent with Proton Mail secure email. > > > > --- Original Message --- > > On Wednesday, March 8th, 2023 at 2:13 PM, Mike Schwab > > mike.a.sch...@gmail.com wrote: > > > > > > > MVS/SP Version 1.3.8 (for MVS/370) > > > > > > MVS/SP is for running 24 bit programs on 17-64MB real memory. > > > Copyrighted and not available currently. > > > MVS 3.8 is what is freely available, limited to 16MB real memory. > > > > > > On Wed, Mar 8, 2023 at 12:59 PM Tom Marchant > > > 000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote: > > > > > > > Maybe she means what she said. MVS/SP Version 1.3.8 is referenced as a > > > > supported operating environment in this: > > > > https://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd=sm=ShopzSeries=897/ENUS5695-002 > > > > > > > > -- > > > > Tom Marchant > > > > > > > > On Tue, 7 Mar 2023 16:03:13 -0500, David Spiegel > > > > dspiegel...@hotmail.com wrote: > > > > > > > > > Hi Terri, > > > > > Maybe you mean OS2/MVS 3.8(J)? > > > > > That could've been circa 1986. > > > > > (I also have a similar progression, but, did VS1 7D with BPE before > > > > > MVS.) > > > > > > > > > > Regards, > > > > > David > > > > > > > > > > On 2023-03-07 15:25, Shaffer, Terri wrote: > > > > > > > > > > > It was 1984/1985, maybe 1986 even, as my memory is foggy.. yes > > > > > > mvs/sp 3.8 I added the 1. Then XA/ESA/OS390/z-OS > > > > > > > > > > > > Ms Terri E Shaffer > > > > > > Senior Systems Engineer, > > > > > > z/OS Support: > > > > > > ACIWorldwide - Telecommuter > > > > > > H(412-766-2697) C(412-519-2592) > > > > > > terri.shaf...@aciworldwide.com > > > > > > > > -- > > > > 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 > > > > > -- > 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: zOSMF
The last MVS/SP I ran was 1.3.6. That was in the 1987 time frame. The next leap I made was to MVS/XA 2.2, and that was in 1988. Sent with Proton Mail secure email. --- Original Message --- On Wednesday, March 8th, 2023 at 2:13 PM, Mike Schwab wrote: > > > MVS/SP Version 1.3.8 (for MVS/370) > > > MVS/SP is for running 24 bit programs on 17-64MB real memory. > Copyrighted and not available currently. > MVS 3.8 is what is freely available, limited to 16MB real memory. > > On Wed, Mar 8, 2023 at 12:59 PM Tom Marchant > 000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote: > > > Maybe she means what she said. MVS/SP Version 1.3.8 is referenced as a > > supported operating environment in this: > > https://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd=sm=ShopzSeries=897/ENUS5695-002 > > > > -- > > Tom Marchant > > > > On Tue, 7 Mar 2023 16:03:13 -0500, David Spiegel dspiegel...@hotmail.com > > wrote: > > > > > Hi Terri, > > > Maybe you mean OS2/MVS 3.8(J)? > > > That could've been circa 1986. > > > (I also have a similar progression, but, did VS1 7D with BPE before MVS.) > > > > > > Regards, > > > David > > > > > > On 2023-03-07 15:25, Shaffer, Terri wrote: > > > > > > > It was 1984/1985, maybe 1986 even, as my memory is foggy.. yes mvs/sp > > > > 3.8 I added the 1. Then XA/ESA/OS390/z-OS > > > > > > > > Ms Terri E Shaffer > > > > Senior Systems Engineer, > > > > z/OS Support: > > > > ACIWorldwide - Telecommuter > > > > H(412-766-2697) C(412-519-2592) > > > > terri.shaf...@aciworldwide.com > > > > -- > > 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: Z15 EOM
To coincide with the AI capabilities of z/OS 3.1, IBM will announce the HAL-9000 class machine. I know, IBM had the ES-9000's in the 90's. Sent with Proton Mail secure email. --- Original Message --- On Thursday, March 2nd, 2023 at 8:44 AM, Mike Shorkend wrote: > The one rack z16 (aka Business Class) has not yet been announced,so I > expect the z16+1 is still some time in the not so near future. Likewise the > EOM for the z15. > > On Thu, 2 Mar 2023 at 15:34, Paul Gorlinsky p...@atsmigrations.com wrote: > > > It should also be noted that the z14 is still a supported processor for > > zOS 3.1 ... > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike Shorkend > m...@shorkend.com > Tel: +972524208743 > > https://www.linkedin.com/in/MikeShorkend/ > > > https://twitter.com/mikeShorkend > > > -- > 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
Load module/program object
Is it possible to list the SSI's of load modules/program objects with a utility? In other words, give the load library/program object library name to the utility, and dump the module names and SSI's for each module. Sent with [Proton Mail](https://proton.me/) secure email. -- 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
I remember, and remember using the output TSO command to sysout. Sent from Proton Mail mobile Original Message On Feb 18, 2023, 10:54 AM, Jay Maynard wrote: > Am I the only one who remembers the original Sysout Display and Search > Facility FDP and marvels at what SDSF has become? > -- 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
Amen to that Mark! Sent from Proton Mail mobile Original Message On Feb 17, 2023, 6:15 PM, Mark Zelden wrote: > On Wed, 15 Feb 2023 16:51:34 +0000, rpinion865 wrote: >"I think" the problem > was related to the expiration of the cert that zOSMF is using. I deleted the > cert, updated the RACDCERT job that created/installed the cert to have an > expiration in 2028 (it was 2021), and installed it again. After doing that, I > still received the error. However, in the last day or so, I have bounced > IZUSVR1 a few times, and today it worked. My assumption is that something was > still using the old >cert. And, yes I did the SETROPTS RACLIST(DIGTCERT) > REFRESH command after installing with the new expiration date. > > Be > thankful you didn't just install z/OSMF using the sample IZUSEC. I just > mentioned this in an IBM z/OSMF case yesterday (about something unrelated to > certificates) when I saw the manual and sample IZUSEC member even under z/OS > 2.5 still had a certificate expiration of 2023/05/17 and no instructions in > the installation to look at it / modify it to some future date before running > the job. I implemented z/OSMF in 2017/2018 and we are having to renew those > certificates now across 9 sysplexes. First one was done in a sandbox sysplex > today. Anyone else use the samples and not do expiring certificates > reporting? If not reporting, time to look at when yours expire. :) 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: > http://www.mzelden.com/mvsutil.html Systems Programming expert at > http://search390.techtarget.com/ateExperts/ > -- 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
Mr. SMP/E pointed me in that direction. I am in the process of getting the necessary PTF's. Sent with Proton Mail secure email. --- Original Message --- On Friday, February 17th, 2023 at 9:23 AM, Pete Vit wrote: > I had the same issue , unfortunately you need a ptf for the json file > Carmen > > Sent from my iPad > > > On Feb 16, 2023, at 2:02 PM, Tom Marchant > > 000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote: > > > > Remember to receive the latest HOLDDATA before running the REPORT > > MISSINGFIX. > > > > -- > > Tom Marchant > > > > On Thu, 16 Feb 2023 19:45:26 +, Kurt J. Quackenbush ku...@us.ibm.com > > wrote: > > > > > > An error was found in file "/u/pinionr/TDMF/IZUD00DF.json". Error: "The > > > > file contains data that is not supported by the current level of > > > > z/OSMF. The version = 8."IZUD277E Feb 16, 2023, 10:14:02 AM > > > > > > I suggest you use SMP/E REPORT MISSINGFIX and fix category > > > IBM.DrivingSystem-RequiredService to determine if you're missing any > > > other PTFs required on your z/OS 2.4 driving system. > > > https://www.ibm.com/support/pages/ibm-fix-category-values-and-descriptions > > > > -- > > 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
zOSMF
Running zOSMF under z/OS 2.4. In attempting to load the Portable Software Instance, retrieving the contents from the directory, that was used when the order was retrieved to our system, I get the following error. An error was found in file "/u/pinionr/TDMF/IZUD00DF.json". Error: "The file contains data that is not supported by the current level of z/OSMF. The version = 8."IZUD277E Feb 16, 2023, 10:14:02 AM I have no idea how to proceed. If I need to apply maintenance to zOSMF, how would I be able to proceed? Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zOSMF
"I think" the problem was related to the expiration of the cert that zOSMF is using. I deleted the cert, updated the RACDCERT job that created/installed the cert to have an expiration in 2028 (it was 2021), and installed it again. After doing that, I still received the error. However, in the last day or so, I have bounced IZUSVR1 a few times, and today it worked. My assumption is that something was still using the old cert. And, yes I did the SETROPTS RACLIST(DIGTCERT) REFRESH command after installing with the new expiration date. But, maybe I didn't click my heels three times while saying "There's no place like home." Sent with Proton Mail secure email. --- Original Message --- On Wednesday, February 15th, 2023 at 11:43 AM, Shaffer, Terri <017d5f778222-dmarc-requ...@listserv.ua.edu> wrote: > So I am guessing you looked at the IZUSRV1 logs and see an issue with the > certificate? > > Not sure about opera, but did you download and install that certificate into > the stores in OPERA? > > Ms Terri E Shaffer > Senior Systems Engineer, > z/OS Support: > ACIWorldwide - Telecommuter > H(412-766-2697) C(412-519-2592) > terri.shaf...@aciworldwide.com > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > rpinion865 > > Sent: Tuesday, February 14, 2023 3:40 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: zOSMF > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe. > > > I'm attempting to use the Portable Software Instance dialog to retrieve an > IBM order. This is for a z/OS 2.4 system. I've reached a point where I don't > know where to look to correct the problem I am having. > > I'm receiving IZUG1040E when I attempt to submit the generated job. I've run > the sample JCL IZUNUSEC to create zOSMF's certificates. I'm connecting to the > zOSMF instance using the Opera browser. > > Any help would be greatly appreciated. > > sent with Proton Mail secure email. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] > http://www.aciworldwide.com > > This email message and any attachments may contain confidential, proprietary > or non-public information. The information is intended solely for the > designated recipient(s). If an addressing or transmission error has > misdirected this email, please notify the sender immediately and destroy this > email. Any review, dissemination, use or reliance upon this information by > unintended recipients is prohibited. Any opinions expressed in this email are > those of the author personally. > > -- > 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
zOSMF
I'm attempting to use the Portable Software Instance dialog to retrieve an IBM order. This is for a z/OS 2.4 system. I've reached a point where I don't know where to look to correct the problem I am having. I'm receiving IZUG1040E when I attempt to submit the generated job. I've run the sample JCL IZUNUSEC to create zOSMF's certificates. I'm connecting to the zOSMF instance using the Opera browser. Any help would be greatly appreciated. sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CLIST for APF and link list datasets
DDLIST from any ISPF command line. Sent with Proton Mail secure email. --- Original Message --- On Tuesday, February 14th, 2023 at 2:47 PM, Bill Giannelli wrote: > I was shown a clist that had various options to display things like APFs and > LLA, etc. > I am struggling to remember the clist name to run. > I am hoping this vague question sparks someone's memory. > does anyone know the clist? > 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
Z/OS jobs in Eastern and Western Europe
What is z/is sysprog job market like in Eastern and Western Europe? Sent from Proton Mail mobile -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF puzzle
Check your PARMLIB SMFPRMxx member to insure the higher number is processed. Sent with Proton Mail secure email. --- Original Message --- On Tuesday, January 31st, 2023 at 8:29 AM, Ituriel do Neto <03427ec2837d-dmarc-requ...@listserv.ua.edu> wrote: > Hi all, > > I'm facing a problem with SMF that is completely unusual, and maybe you can > enlight me. > > I do have a program that generates SMF records and it is possible to specify > the SMF number > of any choice (bigger than 127). The SMF record is issued using SMFWTM macro. > > I also have an IEFU83 and IEFU84 SMF exits and since SMFWTM is being used, > IEFU83 will > be lunched to intercept the previously generated SMF record. > Since it is in test, the first thing IEFU83 does is to WTO the SMF type and > subtype it is processing, > for debugging purposes. > > Now comes the strange part. if the SMF number is between 128 and 205 > (inclusive), the WTO is > issued normaly, but if the SMF number is bigger than 205 it seems the exit is > not invoked because > no WTO is issued at all. > The SMF is generated correctly because I can extract it from SYS1.MANx > datasets. > > Here goes a piece of code of IEF83/4 to ilustrate. > > USING SMFRCD0,R9 * MAPS SMF RECORD HEADER > DXSOTHR CLI SMF0RTY,128 * SMF SYSTEM RECORD (<128)? > BL DXSTYSU * YES, CHECK TYPE/SUBTYPE/PROD > BAS R8,DXMSG <=== TEMP * DISPLAY AND RETURN > DXSTYSU DS 0H > > Are there any kind of restriction because it is completely crazy. > > Best Regards > > Ituriel do Nascimento Neto > z/OS System Programmer > > -- > 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
