Copy error Java module
Hi Cross posted I am trying to copy a java load module JVMLDMxx using TSO ISHELL copy function to a preallocated dataset with the attribute(library type, recfm=u,blocksize=32760). It fails with message THERE ID A RECORD FORMAT ERROR FOR A MVS DATASET SYS5.JAVA.LOADLIB. EITHER THE OUTPUT RECORD FORMAT IS UNDEFINED FOR A TEXT INPUT FILE, OR THE OUTPUT RECORD FORMAT IS NOT VALID Has anyone faced this message and what is the attribute of output dataset that can help moving the module from OMVS to a MVS. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Alias Listcat discrepancy betweeen sysplex'd LPARs
Thanks Lizette. I have verified with 3.4 and listcat - same results there are other datasets in the catalog that list on both LPARs and F CATALOG confirms it's allocated on bot LPARs Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
What happens if an SMF exit modifies the SMF record?
What happens if an SMF exit modifies the SMF record? Do the next exit in the chain, SYS1.MANx and/or the stream see the modified record, or is the exit only modifying a "private copy" of the SMF record? It would seem to me to be an important point, and the documentation is pretty much silent (or I am visually challenged). However, I tend to interpret "Word 1: The address of the record that SMF is to write" as implying that there is only a single copy that will get passed on down the line. I will submit an RCF once I get a definitive answer here. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYS1.MIGLIB and LNKLST
One of my first contracting jobs was working for state gov'mt, y2k, and my first task was to apply maint to the current OS, the SMP/E environment was pointing to a live sandbox system, I pointed this out to my boss, and he said yeah, we do this all the time, :( so I understand where David is coming from. Carmen Vitullo - Original Message - From: "Veryl Ellis" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, June 11, 2019 2:42:57 PM Subject: Re: SYS1.MIGLIB and LNKLST Applying maintenance to a target SYSRES volume. I never apply maintenance to a running system. S. Veryl -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: Tuesday, June 11, 2019 3:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYS1.MIGLIB and LNKLST Veryl, You are getting a lot of feedback that I consider a bit scary. Can you clarify something? Are you trying to apply maintenance to your running SYSRES? Or a copy of it, and are dealing with that type of enqueuer? If the latter, then yes, allocate a .NEW version of MIGLIB, copy the contents from the old to the new, and using appropriate tools, do the renames. If you are contemplating doing these activities on your running system, well then, let me pop up a bowl of popcorn, and pour a cocktail for this show. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Veryl Ellis Sent: Tuesday, June 11, 2019 2:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SYS1.MIGLIB and LNKLST **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB ran out of space (S/D37). Can anyone tell me how to get SYS1.MIGLIB out of the running Link List concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB? The standard SETPROG LNKLST stuff to delete a DSN from the link list doesn't work on SYS1.MIGLIB. Thanks for any assist. S. Veryl Ellis -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** 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
Re: SYS1.MIGLIB and LNKLST
Yep, I did. S. Veryl Ellis -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Tuesday, June 11, 2019 3:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYS1.MIGLIB and LNKLST On Tue, Jun 11, 2019 at 2:38 PM Veryl Ellis wrote: > Ah Ha!!! > The doc I have for "Removing or Compressing a Dataset in an Active LNKLST" > did not discuss using the UNALLOCATE for LINKLIB, MIGLIB, etc. > > That worked. > I was able to delete and reallocate a larger SYS1.MIGLIB on my target > SYSRES. > > These systems are not production environments. > Remember to do a SETPROG ALLOCATE again and START LLA. Just saying. > > Thank you for assist. > > > S. Veryl Ellis > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of John McKown > Sent: Tuesday, June 11, 2019 3:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SYS1.MIGLIB and LNKLST > > On Tue, Jun 11, 2019 at 1:59 PM Veryl Ellis > > wrote: > > > I'm applying maintenance to my target SYSRES and the target > > SYS1.MIGLIB ran out of space (S/D37). > > Can anyone tell me how to get SYS1.MIGLIB out of the running Link > > List concatenation, so I can delete and reallocate a larger target > SYS1.MIGLIB? > > The standard SETPROG LNKLST stuff to delete a DSN from the link list > > doesn't work on SYS1.MIGLIB. > > > > Interesting. You did a SETPROG UNALLOCATE and it remained allocated? > You also need to STOP LLA since that address space also allocates all > the LNKLST data sets + any others you put in the PARMLIB member. > > > > > > > > Thanks for any assist. > > > > > > > > S. Veryl Ellis > > > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > > > > -- > This is clearly another case of too many mad scientists, and not > enough hunchbacks. > > > Maranatha! <>< > John McKown > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: SYS1.MIGLIB and LNKLST
Applying maintenance to a target SYSRES volume. I never apply maintenance to a running system. S. Veryl -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: Tuesday, June 11, 2019 3:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYS1.MIGLIB and LNKLST Veryl, You are getting a lot of feedback that I consider a bit scary. Can you clarify something? Are you trying to apply maintenance to your running SYSRES? Or a copy of it, and are dealing with that type of enqueuer? If the latter, then yes, allocate a .NEW version of MIGLIB, copy the contents from the old to the new, and using appropriate tools, do the renames. If you are contemplating doing these activities on your running system, well then, let me pop up a bowl of popcorn, and pour a cocktail for this show. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Veryl Ellis Sent: Tuesday, June 11, 2019 2:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SYS1.MIGLIB and LNKLST **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB ran out of space (S/D37). Can anyone tell me how to get SYS1.MIGLIB out of the running Link List concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB? The standard SETPROG LNKLST stuff to delete a DSN from the link list doesn't work on SYS1.MIGLIB. Thanks for any assist. S. Veryl Ellis -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** 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: SYS1.MIGLIB and LNKLST
On Tue, Jun 11, 2019 at 2:38 PM Veryl Ellis wrote: > Ah Ha!!! > The doc I have for "Removing or Compressing a Dataset in an Active LNKLST" > did not discuss using the UNALLOCATE for LINKLIB, MIGLIB, etc. > > That worked. > I was able to delete and reallocate a larger SYS1.MIGLIB on my target > SYSRES. > > These systems are not production environments. > Remember to do a SETPROG ALLOCATE again and START LLA. Just saying. > > Thank you for assist. > > > S. Veryl Ellis > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of John McKown > Sent: Tuesday, June 11, 2019 3:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SYS1.MIGLIB and LNKLST > > On Tue, Jun 11, 2019 at 1:59 PM Veryl Ellis > wrote: > > > I'm applying maintenance to my target SYSRES and the target > > SYS1.MIGLIB ran out of space (S/D37). > > Can anyone tell me how to get SYS1.MIGLIB out of the running Link List > > concatenation, so I can delete and reallocate a larger target > SYS1.MIGLIB? > > The standard SETPROG LNKLST stuff to delete a DSN from the link list > > doesn't work on SYS1.MIGLIB. > > > > Interesting. You did a SETPROG UNALLOCATE and it remained allocated? You > also need to STOP LLA since that address space also allocates all the > LNKLST data sets + any others you put in the PARMLIB member. > > > > > > > > Thanks for any assist. > > > > > > > > S. Veryl Ellis > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > This is clearly another case of too many mad scientists, and not enough > hunchbacks. > > > Maranatha! <>< > John McKown > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYS1.MIGLIB and LNKLST
Ah Ha!!! The doc I have for "Removing or Compressing a Dataset in an Active LNKLST" did not discuss using the UNALLOCATE for LINKLIB, MIGLIB, etc. That worked. I was able to delete and reallocate a larger SYS1.MIGLIB on my target SYSRES. These systems are not production environments. Thank you for assist. S. Veryl Ellis -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Tuesday, June 11, 2019 3:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYS1.MIGLIB and LNKLST On Tue, Jun 11, 2019 at 1:59 PM Veryl Ellis wrote: > I'm applying maintenance to my target SYSRES and the target > SYS1.MIGLIB ran out of space (S/D37). > Can anyone tell me how to get SYS1.MIGLIB out of the running Link List > concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB? > The standard SETPROG LNKLST stuff to delete a DSN from the link list > doesn't work on SYS1.MIGLIB. > Interesting. You did a SETPROG UNALLOCATE and it remained allocated? You also need to STOP LLA since that address space also allocates all the LNKLST data sets + any others you put in the PARMLIB member. > > Thanks for any assist. > > > > S. Veryl Ellis > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: SYS1.MIGLIB and LNKLST
Veryl, You are getting a lot of feedback that I consider a bit scary. Can you clarify something? Are you trying to apply maintenance to your running SYSRES? Or a copy of it, and are dealing with that type of enqueuer? If the latter, then yes, allocate a .NEW version of MIGLIB, copy the contents from the old to the new, and using appropriate tools, do the renames. If you are contemplating doing these activities on your running system, well then, let me pop up a bowl of popcorn, and pour a cocktail for this show. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Veryl Ellis Sent: Tuesday, June 11, 2019 2:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SYS1.MIGLIB and LNKLST **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB ran out of space (S/D37). Can anyone tell me how to get SYS1.MIGLIB out of the running Link List concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB? The standard SETPROG LNKLST stuff to delete a DSN from the link list doesn't work on SYS1.MIGLIB. Thanks for any assist. S. Veryl Ellis -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** 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
Re: SYS1.MIGLIB and LNKLST
On Tue, Jun 11, 2019 at 2:19 PM Carmen Vitullo wrote: > I would not do anything to remove ENQ from the running systems MIGLIB > what I normally do is on the target volume > 1) allocate a new SYS1.MIGLIB.NEW - larger primary and more dir blocks > 2) copy the existing target MIGLIB to the new MIGLIB > 3) if you have authority you should be able to RENAME ON THAT TARGET > VOLUME the SYS1.MIGLIB to SYS1.MIGLIB.OLD, or something > IIRC, you can use IEHPROGM to do that. I don't think it does an ENQ on the DSN. > 4) uncatalog the new MIGLIB and rename it to SYS1.MIGLIB , rerun your > apply > all this assumes SMP/E target is setup to use VOLUME and DEVICE and not > the CATALOGED SYS1.MIGLIB on that system > > > > Carmen Vitullo > > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYS1.MIGLIB and LNKLST
I would not do anything to remove ENQ from the running systems MIGLIB what I normally do is on the target volume 1) allocate a new SYS1.MIGLIB.NEW - larger primary and more dir blocks 2) copy the existing target MIGLIB to the new MIGLIB 3) if you have authority you should be able to RENAME ON THAT TARGET VOLUME the SYS1.MIGLIB to SYS1.MIGLIB.OLD, or something 4) uncatalog the new MIGLIB and rename it to SYS1.MIGLIB , rerun your apply all this assumes SMP/E target is setup to use VOLUME and DEVICE and not the CATALOGED SYS1.MIGLIB on that system Carmen Vitullo - Original Message - From: "Veryl Ellis" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, June 11, 2019 1:59:28 PM Subject: SYS1.MIGLIB and LNKLST I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB ran out of space (S/D37). Can anyone tell me how to get SYS1.MIGLIB out of the running Link List concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB? The standard SETPROG LNKLST stuff to delete a DSN from the link list doesn't work on SYS1.MIGLIB. Thanks for any assist. S. Veryl Ellis -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: SYS1.MIGLIB and LNKLST
Allocate the new larger data set on target sysres as SYS1.MIGLIB.NEW then do a rename using a utility that does not perform an enqueue. See: http://www.cbttape.org/~jjaeger/nodsi.html In the example at this site they are doing a scratch. Just put in RENAME cards instead like the following: //S1 EXEC PGM=NODSI,PARM='IEHPROGM',REGION=0M //SYSPRINT DD SYSOUT=* //DD1 DD UNIT=3390,VOL=SER=VV,DISP=SHR //SYSIN DD * RENAME DSNAME=SYS1.MIGLIB,VOL=3390=VV,X NEWNAME=SYS1.MIGLIB.OLD RENAME DSNAME=SYS1.MIGLIB.NEW,VOL=3390=VV,X NEWNAME=SYS1.MIGLIB Michael Brennan -Original Message- From: IBM Mainframe Discussion List On Behalf Of Veryl Ellis Sent: Tuesday, June 11, 2019 1:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SYS1.MIGLIB and LNKLST I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB ran out of space (S/D37). Can anyone tell me how to get SYS1.MIGLIB out of the running Link List concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB? The standard SETPROG LNKLST stuff to delete a DSN from the link list doesn't work on SYS1.MIGLIB. Thanks for any assist. S. Veryl Ellis -- 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
Re: SYS1.MIGLIB and LNKLST
Without using SYSLIB MIGLIB(user.miglib) in an active PROGxx member, you won't be able to remove SYS1.MIGLIB from the system. A quick read of the doc seems to imply that you can issue a SET PROG=xx command to add it, then remove SYS1.MIGLIB, but I wouldn't do it myself. 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 Tuesday, June 11, 2019 2:59 PM, Veryl Ellis wrote: > I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB ran > out of space (S/D37). > Can anyone tell me how to get SYS1.MIGLIB out of the running Link List > concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB? > The standard SETPROG LNKLST stuff to delete a DSN from the link list doesn't > work on SYS1.MIGLIB. > > Thanks for any assist. > > S. Veryl Ellis > > > --- > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: 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: SYS1.MIGLIB and LNKLST
On Tue, Jun 11, 2019 at 1:59 PM Veryl Ellis wrote: > I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB > ran out of space (S/D37). > Can anyone tell me how to get SYS1.MIGLIB out of the running Link List > concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB? > The standard SETPROG LNKLST stuff to delete a DSN from the link list > doesn't work on SYS1.MIGLIB. > Interesting. You did a SETPROG UNALLOCATE and it remained allocated? You also need to STOP LLA since that address space also allocates all the LNKLST data sets + any others you put in the PARMLIB member. > > Thanks for any assist. > > > > S. Veryl Ellis > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SYS1.MIGLIB and LNKLST
I'm applying maintenance to my target SYSRES and the target SYS1.MIGLIB ran out of space (S/D37). Can anyone tell me how to get SYS1.MIGLIB out of the running Link List concatenation, so I can delete and reallocate a larger target SYS1.MIGLIB? The standard SETPROG LNKLST stuff to delete a DSN from the link list doesn't work on SYS1.MIGLIB. Thanks for any assist. S. Veryl Ellis -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Alias Listcat discrepancy betweeen sysplex'd LPARs
I can say I've done this also, removed the include additional qualifiers, not good timing, right after I created a new master catalog for my 2.1 or 2.2 systems YIKES! Carmen Vitullo - Original Message - From: "Dana Mitchell" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, June 11, 2019 1:02:40 PM Subject: Re: Alias Listcat discrepancy betweeen sysplex'd LPARs On Tue, 11 Jun 2019 17:28:44 +, Jesse 1 Robinson wrote: >We had a 'catalog anomaly' recently were one person got a different list of >data sets under 3.4 than I did, both of us using the same search criterion. >Turns out we had different selections set In the options list: > I experienced this just last week. The user inadvertently un-slahsed the 'Include Additional Qualifiers ' option. Produced very different results than expected. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
I have never found much barrier to entry with the IBM Business Partner process. The HUGE obstacle is customer inertia and conservatism. Customers may complain about software costs, but they are the big barriers to entry for small competitors. At my former employer we had customers say specifically "we love your product but we are not taking on any new software vendors." (In some cases you could overcome that by partnering with a reseller.) I would not want to be out there pitching "my ESM from Mills & Associates is way superior to RACF, Mr. Wells Fargo or Mr. Fidelity or whatever. You should drop RACF and install the Mills & Associates ESM." There is a concept in software marketing called "stickiness." A search engine has zero stickiness. If a better search engine came along tomorrow you would start using it in a heartbeat. An ESM is way sticky. Even if I could sell Mr. Fargo on the superiority of my ESM, who is going to migrate all their RACF rules and administrative processes and TEST them? Barry tried (or is still trying?) with a product (or prototype or concept) called DEADBOLT. http://ibmsystemsmag.com/mainframe/trends/ztalk/barry-schrager/ http://www.dignus.com/success_stories/JME/paper.html Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, June 11, 2019 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls On Tue, Jun 11, 2019 at 11:26 AM Bob Bridges wrote: > If that's what it stands for I should think those aren't just the big > three but the ~only~ three. At least, I've never heard of any others. > Which is odd, when you think about it; surely there's someone out there > wanting to break into the market? So says my capitalist assumptions. But > apparently not. > Most likely the entry cost. Developing z/OS software is _expensive_. I don't know, but when I looked a couple of years ago, the zPDT was something like $5000 / year with annual renewal. And you need to be approved by IBM as a "Business Partner". That is a stiff barrier to entry, IMO. I know some business people here have a zPDT system, but I doubt that Phoenix Software would really want to go up against IBM and CA for that market. Also, unlike a productivity tool such as (E)JES, an ESM is (or should be) "business critical" for protection. To convince a company to go with a "new & unknown" product in this era of PHI, HIPAA, GDPR, and so on is so unlikely as to be silly to even consider. Better to go with products such as (E)JES (Phoenix Software) or Systems/ASM (Dignus) which, I feel, are more likely to be considered without the company auditors having a fit. The reason I love Linux is the _zero_ cost of the GNU and other software. Basically I only pay for the hardware and electricity. Of course, I am not a software developer, just a bit of a dilettante so far as programming is concerned. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* Nearly all men can stand adversity. If you want to test a man's > character, give him power. -Abraham Lincoln */ > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Pommier, Rex > Sent: Thursday, May 30, 2019 11:22 > > I have been under the impression it stands for External Security Manager, > of which the "big 3" would be RACF, ACF2, Top Secret. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Tom Brennan > Sent: Thursday, May 30, 2019 10:21 AM > > I've seen the acronym ESM a few times in this thread. I'll assume that > means "Enterprise Security Management", and I'll guess it refers to > security processes (not RACF), such as assigning userid's, making sure > people have just the access they need, periodic audits, etc. > > Am I even close? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: Any way to set the PKM in "open code".
Right. A wild branch could do anything, but I think the damage from key 0 is more likely than that you happen to hit some privileged instruction. I think you misunderstood my two bullets. The first was the potential damage from supervisor state. The second was potential damage from key 0. Much more potential for damage from the second case. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Tuesday, June 11, 2019 12:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any way to set the PKM in "open code". On Mon, 10 Jun 2019 13:57:12 -0700 Charles Mills wrote: :>> Key0 is much much more dangerous than supervisor state (IMHO) :>Interesting. I never thought of that, but I agree. Which is the more likely :>error? :>- You accidentally code some privileged instruction that you did not intend? Perhaps with a wild branch. Or you branch to user code. :>- You code the wrong register number in an instruction, or destroy or forget :>to initialize the contents of a register (at least on some code paths), or a :>register gets incremented too far? Supervisor state does not you to accidentally overwrite storage in a system key. You need to set the PSW key or use one of the explicit keyed instructions. :>Charles :> :> :>-Original Message- :>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :>Behalf Of Binyamin Dissen :>Sent: Sunday, June 9, 2019 11:48 PM :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: Re: Any way to set the PKM in "open code". :> :>On Sun, 9 Jun 2019 20:15:40 -0400 Rob Schramm wrote: :> :>:>I suspect John's answer will be :>:>1) because it's cool to try new things :> :>Well, to do that he could encapsulate this code in a PC-CP with an altered :>AKM. :> :>:>2) because I want to limit the destruction if it goes wrong. :> :>Key0 is much much more dangerous than supervisor state (IMHO) :> :>:>Waiting for the real answer, :>:>Rob :>:> :>:>On Sun, Jun 9, 2019, 6:22 PM Binyamin Dissen :>:>wrote: :>:> :>:>> On Fri, 7 Jun 2019 08:57:38 -0500 John McKown < :>:>> john.archie.mck...@gmail.com> :>:>> wrote: :>:>> :>:>> :>I am not finding this. I want to change the PKM for my running, APF :>:>> :>authorized, program to include key 0. Why? So that I can switch in and :>:>> out :>:>> :>of key 0 using an SPKA instruction rather than MODESET. But mainly so :>:>> that :>:>> :>I can use the MVCSK and MVCDK instructions to read & update key 0, :>fetch :>:>> :>protected, storage without going into key 0. :>:>> :>:>> :>Or am I just being silly (again)? :>:>> :>:>> Why not simply run supervisor state which allows access to all keys? :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: Alias Listcat discrepancy betweeen sysplex'd LPARs
On Tue, 11 Jun 2019 17:28:44 +, Jesse 1 Robinson wrote: >We had a 'catalog anomaly' recently were one person got a different list of >data sets under 3.4 than I did, both of us using the same search criterion. >Turns out we had different selections set In the options list: > I experienced this just last week. The user inadvertently un-slahsed the 'Include Additional Qualifiers ' option. Produced very different results than expected. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any way to set the PKM in "open code".
On Fri, Jun 07, 2019 at 08:57:38AM -0500, John McKown wrote: > I am not finding this. I want to change the PKM for my running, APF > authorized, program to include key 0. Why? So that I can switch in and out > of key 0 using an SPKA instruction rather than MODESET. But mainly so that > I can use the MVCSK and MVCDK instructions to read & update key 0, fetch > protected, storage without going into key 0. > > Or am I just being silly (again)? Yes. You are already APF authorized, supervisor mode isn't that different a level of authorization. Some system routines will bypass parameter validity checking for JSCBAUTH callers. Of course, more will for supervisor or system key callers (0-7). x> Key0 is much much more dangerous than supervisor state (IMHO) Yes, much. I would recommend the use of supervisor mode, SPKA and running with a non-zero system key. I don't know IBM's position on this, however it worked really well whem I was developing IPC which allows problem mode communication between address spaces (and is a part of UCLA/Mail with source available at the cbttape site). I made the choice to run this way as at the time I was developing IPC I didn't have a VM system to test on. This was a long time ago on MVS/SP 1.1.3. I had MVS test time but most of that test time was with the understanding that while something might happen it was very low probability and others were using the system. Thus it was important to be mostly nondisruptive to other on the system. As a result, IPC code runs supervisor and an execution time parameter selected non-zero system key. This include the IPC type 1 SVC, IPC SRB routines, and IPC subsystem exit routines (EOT & EOM). Running with a non-zero protect key means it takes thought to reference a user parameter. Most areas are not just store protect but fetch protected as well. So just fetching from user storage (or a wild branch into his code) will result in a fetch exception. I did crash the system during IPC development when modifying IPC initialization code where I hadn't been as careful to avoid key zero code. Initialization only runs once, right? I had one bad base register and low storage was hit. This was above the low address protection and as I remember it, turned off some bits which told the MVS program check handler to simulate some cross memory instructions (3033 CPU). The system didn't live long after that. I quickly change the code to both fix the base register as well as switch keys so that there was much less key zero code during IPC initialization. That's the only system crash I remember from IPC development. IPC did take SDUMPs during development but these had minimal impact on the rest of the system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Alias Listcat discrepancy betweeen sysplex'd LPARs
We had a 'catalog anomaly' recently were one person got a different list of data sets under 3.4 than I did, both of us using the same search criterion. Turns out we had different selections set In the options list: Confirm Data Set Delete Confirm Member Delete Include Additional Qualifiers Display Catalog Name Display Total Tracks Prefix Dsname Level It's not about right or wrong choices, simply that unless the choices are identical, results can differ for the *same* person on the *same* system, in particular 'Include Additional Qualifiers'. Having these choices is great, but the consequences of selecting one--or not--can be surprising. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Tuesday, June 11, 2019 7:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Alias Listcat discrepancy betweeen sysplex'd LPARs What are you using to list the Datasets? IDCAMS? 3.4? Other tool? Just verifying apples to apples Also, list the catalog - From both LPARs - MVS Console Command F CATALOG,REPORT Provides general information on the status of the catalog address space. Current settings for CAS parameters and features are listed as well as CAS specialty tasks addresses and any CAS entry points that have been intercepted. There are other forms of the REPORT command that provide information on other aspects of the catalog address space. Maybe also from both LPARs F CATALOG,ALLOCATED - ensure the ucat is there on both systems. Then provide the entire output back to the list Lizette > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Elaine Beal > Sent: Tuesday, June 11, 2019 6:36 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Alias Listcat discrepancy betweeen sysplex'd LPARs > > LPARA SYSCAT SCS001123CCATALOG.ICF.VSCS001 > VCATICF > > LPARB SYSCAT SCS001123CCATALOG.ICF.VSCS001 > VCATICF > > Thanks, > Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
On Tue, Jun 11, 2019 at 11:26 AM Bob Bridges wrote: > If that's what it stands for I should think those aren't just the big > three but the ~only~ three. At least, I've never heard of any others. > Which is odd, when you think about it; surely there's someone out there > wanting to break into the market? So says my capitalist assumptions. But > apparently not. > Most likely the entry cost. Developing z/OS software is _expensive_. I don't know, but when I looked a couple of years ago, the zPDT was something like $5000 / year with annual renewal. And you need to be approved by IBM as a "Business Partner". That is a stiff barrier to entry, IMO. I know some business people here have a zPDT system, but I doubt that Phoenix Software would really want to go up against IBM and CA for that market. Also, unlike a productivity tool such as (E)JES, an ESM is (or should be) "business critical" for protection. To convince a company to go with a "new & unknown" product in this era of PHI, HIPAA, GDPR, and so on is so unlikely as to be silly to even consider. Better to go with products such as (E)JES (Phoenix Software) or Systems/ASM (Dignus) which, I feel, are more likely to be considered without the company auditors having a fit. The reason I love Linux is the _zero_ cost of the GNU and other software. Basically I only pay for the hardware and electricity. Of course, I am not a software developer, just a bit of a dilettante so far as programming is concerned. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* Nearly all men can stand adversity. If you want to test a man's > character, give him power. -Abraham Lincoln */ > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Pommier, Rex > Sent: Thursday, May 30, 2019 11:22 > > I have been under the impression it stands for External Security Manager, > of which the "big 3" would be RACF, ACF2, Top Secret. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Tom Brennan > Sent: Thursday, May 30, 2019 10:21 AM > > I've seen the acronym ESM a few times in this thread. I'll assume that > means "Enterprise Security Management", and I'll guess it refers to > security processes (not RACF), such as assigning userid's, making sure > people have just the access they need, periodic audits, etc. > > Am I even close? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
If that's what it stands for I should think those aren't just the big three but the ~only~ three. At least, I've never heard of any others. Which is odd, when you think about it; surely there's someone out there wanting to break into the market? So says my capitalist assumptions. But apparently not. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Nearly all men can stand adversity. If you want to test a man's character, give him power. -Abraham Lincoln */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Thursday, May 30, 2019 11:22 I have been under the impression it stands for External Security Manager, of which the "big 3" would be RACF, ACF2, Top Secret. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Thursday, May 30, 2019 10:21 AM I've seen the acronym ESM a few times in this thread. I'll assume that means "Enterprise Security Management", and I'll guess it refers to security processes (not RACF), such as assigning userid's, making sure people have just the access they need, periodic audits, etc. Am I even close? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another STORAGE OBTAIN question.
On 6/11/2019 4:49 AM, Peter Relson wrote: Whether or not a page is page-fixed, for example, is not part of the architectural definition. Right. We and (I assume) everyone else use PFTCADS for that. -- 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
Re: [External] Re: Hybrid SMS Storage Group - Database
Hi John, I don't want to derail the current thread, but, now that you've mentioned sub-optimal mainframe practices ... Approximately 35+ years ago, I worked at a multi-national food company whose datacenter manager came from the school of penny wise and pound foolish. His "strategy" of dealing with 3420 compatible tape reels which encountered I/O Errors, was to cut off 10 feet of tape and place a new silver strip on the tape. Every operator was expert at this type of activity due its regular occurrence. Some of the reels of tape were more than 20 years old and of course, the tapes were bargain basement variety (hint: The company was named after a Midwest town). A lot of these tapes had maybe 500 feet or fewer left on them (after all of the cutting). I guess one benefit of this strategy is that rewinds took very little time. Regards, David On 2019-06-11 09:29, John McKown wrote: > On Tue, Jun 11, 2019 at 8:20 AM Pommier, Rex > wrote: > >> John, >> >> No spares in the array? Or did a fail-over fail as well? If no spares, >> that sounds more like a bone-headed management move to try to save a couple >> bucks. Not absolving the admin from responsibility but it sounds like a >> bigger problem. >> > Many years ago. And I was not really involved. I just heard the story as a > "cautionary tale" around the "water cooler". And yes, the company was penny > wise and pound foolish. The CIO at the time told me that we would not > upgrade to the latest CICS release, but stay on the current unsupported > release because the new release cost more and asking for the increase in > budget would decrease his yearly bonus. Yes, he actually said that. That's > when I realized that upper management cared mainly about lining their > pockets, legally, rather than doing things "properly". Again, many years > ago at a company that basically no longer exists. > > > > >> Rex >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf >> Of John McKown >> Sent: Tuesday, June 11, 2019 8:06 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: [External] Re: Hybrid SMS Storage Group - Database >> >> On Tue, Jun 11, 2019 at 7:40 AM Mike Schwab >> wrote: >> >>> The problem with SSD storage is that the blocks in a matched set of >>> device start to fail at the same rate. Run long enough and you get >>> enough bad blocks in all devices and they all fail at roughly the same >>> time loosing the entire raid group, you don't have enough time between >>> failures to replace and recreate before the next drive goes. Close >>> monitoring of the physical failure rate is important to start swapping >>> and rebuilding raid. >>> >> This can happen with HDs also. We (Windows LAN) had a catastrophic failure >> years ago. On the weekend, the LAN backups failed. The storage admin >> decided "no problem I'll fix it Monday". We had an HD in the array fail. >> "No problem, RAID will keep us going." While the CE was on his way in to >> replace the failed HD, a second drive in the array failed. No array. No >> current backup. Result: New storage administrator. >> >> >> >>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnews.ycombinator.com%2Fitem%3Fid%3D12046524data=02%7C01%7C%7Cbbd9ebc3ec4944681c0d08d6ee70e0ea%7C84df9e7fe9f640afb435%7C1%7C0%7C636958565938612330sdata=EYz9d%2Fao3PDnFG952SUKHtwm72xDaaMKJ96oSTZeHio%3Dreserved=0 >>> >>> >> -- >> This is clearly another case of too many mad scientists, and not enough >> hunchbacks. >> >> >> Maranatha! <>< >> John McKown >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> The information contained in this message is confidential, protected from >> disclosure and may be legally privileged. If the reader of this message is >> not the intended recipient or an employee or agent responsible for >> delivering this message to the intended recipient, you are hereby notified >> that any disclosure, distribution, copying, or any action taken or action >> omitted in reliance on it, is strictly prohibited and may be unlawful. If >> you have received this communication in error, please notify us immediately >> by replying to this message and destroy the material in its entirety, >> whether in electronic or hard copy format. Thank you. >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Alias Listcat discrepancy betweeen sysplex'd LPARs
What are you using to list the Datasets? IDCAMS? 3.4? Other tool? Just verifying apples to apples Also, list the catalog - From both LPARs - MVS Console Command F CATALOG,REPORT Provides general information on the status of the catalog address space. Current settings for CAS parameters and features are listed as well as CAS specialty tasks addresses and any CAS entry points that have been intercepted. There are other forms of the REPORT command that provide information on other aspects of the catalog address space. Maybe also from both LPARs F CATALOG,ALLOCATED - ensure the ucat is there on both systems. Then provide the entire output back to the list Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Elaine Beal > Sent: Tuesday, June 11, 2019 6:36 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Alias Listcat discrepancy betweeen sysplex'd LPARs > > LPARA SYSCAT SCS001123CCATALOG.ICF.VSCS001 > VCATICF > > LPARB SYSCAT SCS001123CCATALOG.ICF.VSCS001 > VCATICF > > Thanks, > Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Alias Listcat discrepancy betweeen sysplex'd LPARs
LPARA SYSCAT SCS001123CCATALOG.ICF.VSCS001 VCATICF LPARB SYSCAT SCS001123CCATALOG.ICF.VSCS001 VCATICF Thanks, Elaine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: Hybrid SMS Storage Group - Database
On Tue, Jun 11, 2019 at 8:20 AM Pommier, Rex wrote: > John, > > No spares in the array? Or did a fail-over fail as well? If no spares, > that sounds more like a bone-headed management move to try to save a couple > bucks. Not absolving the admin from responsibility but it sounds like a > bigger problem. > Many years ago. And I was not really involved. I just heard the story as a "cautionary tale" around the "water cooler". And yes, the company was penny wise and pound foolish. The CIO at the time told me that we would not upgrade to the latest CICS release, but stay on the current unsupported release because the new release cost more and asking for the increase in budget would decrease his yearly bonus. Yes, he actually said that. That's when I realized that upper management cared mainly about lining their pockets, legally, rather than doing things "properly". Again, many years ago at a company that basically no longer exists. > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of John McKown > Sent: Tuesday, June 11, 2019 8:06 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [External] Re: Hybrid SMS Storage Group - Database > > On Tue, Jun 11, 2019 at 7:40 AM Mike Schwab > wrote: > > > The problem with SSD storage is that the blocks in a matched set of > > device start to fail at the same rate. Run long enough and you get > > enough bad blocks in all devices and they all fail at roughly the same > > time loosing the entire raid group, you don't have enough time between > > failures to replace and recreate before the next drive goes. Close > > monitoring of the physical failure rate is important to start swapping > > and rebuilding raid. > > > > This can happen with HDs also. We (Windows LAN) had a catastrophic failure > years ago. On the weekend, the LAN backups failed. The storage admin > decided "no problem I'll fix it Monday". We had an HD in the array fail. > "No problem, RAID will keep us going." While the CE was on his way in to > replace the failed HD, a second drive in the array failed. No array. No > current backup. Result: New storage administrator. > > > > > > > https://news.ycombinator.com/item?id=12046524 > > > > > -- > This is clearly another case of too many mad scientists, and not enough > hunchbacks. > > > Maranatha! <>< > John McKown > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby notified > that any disclosure, distribution, copying, or any action taken or action > omitted in reliance on it, is strictly prohibited and may be unlawful. If > you have received this communication in error, please notify us immediately > by replying to this message and destroy the material in its entirety, > whether in electronic or hard copy format. Thank you. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: Hybrid SMS Storage Group - Database
John, No spares in the array? Or did a fail-over fail as well? If no spares, that sounds more like a bone-headed management move to try to save a couple bucks. Not absolving the admin from responsibility but it sounds like a bigger problem. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Tuesday, June 11, 2019 8:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Hybrid SMS Storage Group - Database On Tue, Jun 11, 2019 at 7:40 AM Mike Schwab wrote: > The problem with SSD storage is that the blocks in a matched set of > device start to fail at the same rate. Run long enough and you get > enough bad blocks in all devices and they all fail at roughly the same > time loosing the entire raid group, you don't have enough time between > failures to replace and recreate before the next drive goes. Close > monitoring of the physical failure rate is important to start swapping > and rebuilding raid. > This can happen with HDs also. We (Windows LAN) had a catastrophic failure years ago. On the weekend, the LAN backups failed. The storage admin decided "no problem I'll fix it Monday". We had an HD in the array fail. "No problem, RAID will keep us going." While the CE was on his way in to replace the failed HD, a second drive in the array failed. No array. No current backup. Result: New storage administrator. > > https://news.ycombinator.com/item?id=12046524 > > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Hybrid SMS Storage Group - Database
Hi, Probably not the kind of input you're expecting but it'll be helpful to someone nonetheless. If you're a huge shop where a terabyte is not really a big deal, I would urge you to check out VAST data, and some of their Tech Field Day talks on YouTube. That stuff looks pretty much bulletproof for any flash requirement; the way they deal with flash's shortcomings is insane (will need to watch the talks on YT).. - Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List On Behalf Of Buckton, T. (Theo) Sent: 11 June 2019 09:47 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Hybrid SMS Storage Group - Database Hi, Is there a possibility of performance degradation if SSD storage is added to SMS storage group that consists mainly of 15K SAS storage. Database tables are written to the storage group. We use a Dynamic Provisioning pool at disk subsystem level. Regards Nedbank Group Limited Internal Use Only Nedbank disclaimer and confidentiality notice: This email may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this email or all or some of the information contained therein, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this email is neither an offer or a solicitation to buy or sell any securities, investment products or other financial product or service, nor is it an official confirmation of any transaction or an official statement of Nedbank. Any views or opinions presented are solely those of the author and do not necessarily represent those of Nedbank. Nedbank Ltd Reg No 1951/09/06. The following link displays the names of the Nedbank Board of Directors and Company Secretary. [http://www.nedbank.co.za/terms/DirectorsNedbank.htm] If you do not want to click on a link, please type the relevant address in your browser -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Hybrid SMS Storage Group - Database
On Tue, Jun 11, 2019 at 7:40 AM Mike Schwab wrote: > The problem with SSD storage is that the blocks in a matched set of > device start to fail at the same rate. Run long enough and you get > enough bad blocks in all devices and they all fail at roughly the same > time loosing the entire raid group, you don't have enough time between > failures to replace and recreate before the next drive goes. Close > monitoring of the physical failure rate is important to start swapping > and rebuilding raid. > This can happen with HDs also. We (Windows LAN) had a catastrophic failure years ago. On the weekend, the LAN backups failed. The storage admin decided "no problem I'll fix it Monday". We had an HD in the array fail. "No problem, RAID will keep us going." While the CE was on his way in to replace the failed HD, a second drive in the array failed. No array. No current backup. Result: New storage administrator. > > https://news.ycombinator.com/item?id=12046524 > > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Hybrid SMS Storage Group - Database
That’s not completely true. Current Enterprise level SSD's have stacked "reserve cells" that are mapped in as a cell degrades. This take place on the drive itself. Modern Hardware Raid controllers are constantly monitoring array and individual drive degradation and notify of an issue. The spare drive(s) are automatically inserted into the array and rebuilt. With SSD's the processes is very fast. Currently SSD prices have fallen to the point where they are less expensive than 15K RPM HDD's. We run RAID 6 in our systems (both VTL and DASD) so we can tolerate a dual drive failure and keep running. For VTL we normally run 7200RPM HDD and for DASD we use SSD for performance. Ken Kenneth A. Bloom CEO Avenir Technologies Inc /d/b/a Visara International 203-984-2235 bl...@visara.com www.visara.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Tuesday, June 11, 2019 8:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Hybrid SMS Storage Group - Database The problem with SSD storage is that the blocks in a matched set of device start to fail at the same rate. Run long enough and you get enough bad blocks in all devices and they all fail at roughly the same time loosing the entire raid group, you don't have enough time between failures to replace and recreate before the next drive goes. Close monitoring of the physical failure rate is important to start swapping and rebuilding raid. https://news.ycombinator.com/item?id=12046524 On Tue, Jun 11, 2019 at 8:47 AM Buckton, T. (Theo) wrote: > > Hi, > Is there a possibility of performance degradation if SSD storage is added to > SMS storage group that consists mainly of 15K SAS storage. Database tables > are written to the storage group. > We use a Dynamic Provisioning pool at disk subsystem level. > > Regards > > > > > Nedbank Group Limited Internal Use Only > > > Nedbank disclaimer and confidentiality notice: > > This email may contain information that is confidential, privileged or > otherwise protected from disclosure. If you are not an intended recipient of > this email or all or some of the information contained therein, do not > duplicate or redistribute it by any means. Please delete it and any > attachments and notify the sender that you have received it in error. Unless > specifically indicated, this email is neither an offer or a solicitation to > buy or sell any securities, investment products or other financial product or > service, nor is it an official confirmation of any transaction or an official > statement of Nedbank. Any views or opinions presented are solely those of the > author and do not necessarily represent those of Nedbank. Nedbank Ltd Reg No > 1951/09/06. > > The following link displays the names of the Nedbank Board of Directors and > Company Secretary. [http://www.nedbank.co.za/terms/DirectorsNedbank.htm] > > If you do not want to click on a link, please type the relevant address in > your browser > > > > -- > 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: Hybrid SMS Storage Group - Database
The problem with SSD storage is that the blocks in a matched set of device start to fail at the same rate. Run long enough and you get enough bad blocks in all devices and they all fail at roughly the same time loosing the entire raid group, you don't have enough time between failures to replace and recreate before the next drive goes. Close monitoring of the physical failure rate is important to start swapping and rebuilding raid. https://news.ycombinator.com/item?id=12046524 On Tue, Jun 11, 2019 at 8:47 AM Buckton, T. (Theo) wrote: > > Hi, > Is there a possibility of performance degradation if SSD storage is added to > SMS storage group that consists mainly of 15K SAS storage. Database tables > are written to the storage group. > We use a Dynamic Provisioning pool at disk subsystem level. > > Regards > > > > > Nedbank Group Limited Internal Use Only > > > Nedbank disclaimer and confidentiality notice: > > This email may contain information that is confidential, privileged or > otherwise protected from disclosure. If you are not an intended recipient of > this email or all or some of the information contained therein, do not > duplicate or redistribute it by any means. Please delete it and any > attachments and notify the sender that you have received it in error. Unless > specifically indicated, this email is neither an offer or a solicitation to > buy or sell any securities, investment products or other financial product or > service, nor is it an official confirmation of any transaction or an official > statement of Nedbank. Any views or opinions presented are solely those of the > author and do not necessarily represent those of Nedbank. Nedbank Ltd Reg No > 1951/09/06. > > The following link displays the names of the Nedbank Board of Directors and > Company Secretary. [http://www.nedbank.co.za/terms/DirectorsNedbank.htm] > > If you do not want to click on a link, please type the relevant address in > your browser > > > > -- > 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
Re: Another STORAGE OBTAIN question.
>You can't get much more "GUPI" than issuing the LPTEA instruction. LPTEA gets you the address, but is the page table entry itself PI? No. Anything beyond what is architecturally required to be in the PTE should not be considered part of the programming interface. Any program that chooses to rely on the architectural definition must be prepared to change if that architecture changes. Whether or not a page is page-fixed, for example, is not part of the architectural definition. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Client Web Enablement Toolkit
Yes, it's there.. Anyway, I've sorted it. Missed including a basic header - Content-type: application/json It's dumb that the HTTP 400 error is non-descriptive.. – Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List On Behalf Of ITschak Mugzach Sent: 11 June 2019 11:55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Client Web Enablement Toolkit I looked in my code. You nedd to add a call (hwthset) for HWTH_XLATE_RESPBODY_A2E as well. ITschak On Tue, Jun 11, 2019 at 11:22 AM Sankaranarayanan, Vignesh < vignesh.v.sankaranaraya...@marks-and-spencer.com> wrote: > Hi, > > It looks like I'm unable to translate the request body from EBCDIC to > ASCII (in REXX), when using the HWTH_OPT_TRANSLATE_REQBODY with a > value of HWTH_XLATE_REQBODY_E2A .. in the address hwthttp call. > > I'm using code based on SYS1.SAMPLIB(HWTHXRX1). > I see a HTTP 400 error saying Bad request, and in the request body, I > see the hex values that were/was sent. > It looks identical to what I see when I do a 'hex on' in ISPF against > the file with the payload (request body) open in 3.17 (USS). > > Any thoughts? All returning RC 0... > > - Vignesh > Mainframe Infrastructure > > > MARKSANDSPENCER.COM > > Unless otherwise stated above: > Marks and Spencer plc > Registered Office: > Waterside House > 35 North Wharf Road > London > W2 1NW > > Registered No. 214436 in England and Wales. > > Telephone (020) 7935 4422 > Facsimile (020) 7487 2670 > > www.marksandspencer.com > > Please note that electronic mail may be monitored. > > This e-mail is confidential. If you received it by mistake, please let > us know and then delete it from your system; you should not copy, > disclose, or distribute its contents to anyone nor act in reliance on > this e-mail, as this is prohibited and may be unlawful. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: SCRT dummy
Ok this helps a lot. Now I have to install java as well to invoke jzos.. Thanks On Tue, 11 Jun, 2019, 2:56 PM Richards, Robert B., < 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: > I am going the PTF route for the first time today and think it will still > produce the same code, so my guarded answer is yes until proven otherwise. > > Here is part of the JCL that answers your initial question: > > /SCRT EXEC PROC=JVMPRC86,JAVACLS='com.ibm.scrt.SCRTe' > > Bob > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jake Anderson > Sent: Tuesday, June 11, 2019 6:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SCRT dummy > > Hi > > Yes I am going through the SCRT guide.. just wondering if a java part is > required or not ? > > On Tue, 11 Jun, 2019, 2:44 PM Richards, Robert B., < > 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: > > > Jake, > > > > Not exactly. Producing SCRT reports involves: > > > > 1) Collecting certain SMF records (IIRC, 70, 72 and 89) from all lpars > > from the second day of the month until the first day of the following > > month. > > 2) Obtaining the latest version of the SCRT code from the IBM SCRT > > website, downloading and installing it. Newest, just released, is 27.1. > Two > > methods here: Loading a tar file into a USS filesystem and processing the > > install from there *or* get a PTF from IBM and install that with SMP/E. > > 3) You can run with just a day's worth of the above to prove that you are > > on the right track, but for reporting purposes, they (IBM) will want a > > month's worth. ISVs sometimes want ninety days worth. > > > > To actually send reports to IBM, you should already have subcapacity > > license agreements in place signed by both IBM and your contracting > folks. > > To send to other ISVs, not necessary to have the IBM contracts, but the > > ISVs may want some of their own agreements signed. > > > > Bottom line, you need to do the homework. Get a hold of the latest SCRT > > User's Guide and start from there. > > > > In closing, once you have set everything up, then, yes, you can just run > > some reports. As many as you want as often as you want. To get there, > > however, involves a bit of work. > > > > Bob > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Jake Anderson > > Sent: Tuesday, June 11, 2019 4:12 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: SCRT dummy > > > > Hi > > > > Well I must say I am quite new to SCRT and never ran it before . > > > > I understand this talks about the capacity reports and this report was > > asked by one of our ISV vendor. > > > > Is there a JCL which is standard to run on to obtain reports ? > > > > Jake > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT dummy
I am going the PTF route for the first time today and think it will still produce the same code, so my guarded answer is yes until proven otherwise. Here is part of the JCL that answers your initial question: /SCRT EXEC PROC=JVMPRC86,JAVACLS='com.ibm.scrt.SCRTe' Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake Anderson Sent: Tuesday, June 11, 2019 6:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT dummy Hi Yes I am going through the SCRT guide.. just wondering if a java part is required or not ? On Tue, 11 Jun, 2019, 2:44 PM Richards, Robert B., < 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: > Jake, > > Not exactly. Producing SCRT reports involves: > > 1) Collecting certain SMF records (IIRC, 70, 72 and 89) from all lpars > from the second day of the month until the first day of the following > month. > 2) Obtaining the latest version of the SCRT code from the IBM SCRT > website, downloading and installing it. Newest, just released, is 27.1. Two > methods here: Loading a tar file into a USS filesystem and processing the > install from there *or* get a PTF from IBM and install that with SMP/E. > 3) You can run with just a day's worth of the above to prove that you are > on the right track, but for reporting purposes, they (IBM) will want a > month's worth. ISVs sometimes want ninety days worth. > > To actually send reports to IBM, you should already have subcapacity > license agreements in place signed by both IBM and your contracting folks. > To send to other ISVs, not necessary to have the IBM contracts, but the > ISVs may want some of their own agreements signed. > > Bottom line, you need to do the homework. Get a hold of the latest SCRT > User's Guide and start from there. > > In closing, once you have set everything up, then, yes, you can just run > some reports. As many as you want as often as you want. To get there, > however, involves a bit of work. > > Bob > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jake Anderson > Sent: Tuesday, June 11, 2019 4:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SCRT dummy > > Hi > > Well I must say I am quite new to SCRT and never ran it before . > > I understand this talks about the capacity reports and this report was > asked by one of our ISV vendor. > > Is there a JCL which is standard to run on to obtain reports ? > > Jake > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Client Web Enablement Toolkit
I looked in my code. You nedd to add a call (hwthset) for HWTH_XLATE_RESPBODY_A2E as well. ITschak On Tue, Jun 11, 2019 at 11:22 AM Sankaranarayanan, Vignesh < vignesh.v.sankaranaraya...@marks-and-spencer.com> wrote: > Hi, > > It looks like I'm unable to translate the request body from EBCDIC to > ASCII (in REXX), when using the HWTH_OPT_TRANSLATE_REQBODY with a value of > HWTH_XLATE_REQBODY_E2A > .. in the address hwthttp call. > > I'm using code based on SYS1.SAMPLIB(HWTHXRX1). > I see a HTTP 400 error saying Bad request, and in the request body, I see > the hex values that were/was sent. > It looks identical to what I see when I do a 'hex on' in ISPF against the > file with the payload (request body) open in 3.17 (USS). > > Any thoughts? All returning RC 0... > > - Vignesh > Mainframe Infrastructure > > > MARKSANDSPENCER.COM > > Unless otherwise stated above: > Marks and Spencer plc > Registered Office: > Waterside House > 35 North Wharf Road > London > W2 1NW > > Registered No. 214436 in England and Wales. > > Telephone (020) 7935 4422 > Facsimile (020) 7487 2670 > > www.marksandspencer.com > > Please note that electronic mail may be monitored. > > This e-mail is confidential. If you received it by mistake, please let us > know and then delete it from your system; you should not copy, disclose, or > distribute its contents to anyone nor act in reliance on this e-mail, as > this is prohibited and may be unlawful. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT dummy
Hi Yes I am going through the SCRT guide.. just wondering if a java part is required or not ? On Tue, 11 Jun, 2019, 2:44 PM Richards, Robert B., < 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: > Jake, > > Not exactly. Producing SCRT reports involves: > > 1) Collecting certain SMF records (IIRC, 70, 72 and 89) from all lpars > from the second day of the month until the first day of the following > month. > 2) Obtaining the latest version of the SCRT code from the IBM SCRT > website, downloading and installing it. Newest, just released, is 27.1. Two > methods here: Loading a tar file into a USS filesystem and processing the > install from there *or* get a PTF from IBM and install that with SMP/E. > 3) You can run with just a day's worth of the above to prove that you are > on the right track, but for reporting purposes, they (IBM) will want a > month's worth. ISVs sometimes want ninety days worth. > > To actually send reports to IBM, you should already have subcapacity > license agreements in place signed by both IBM and your contracting folks. > To send to other ISVs, not necessary to have the IBM contracts, but the > ISVs may want some of their own agreements signed. > > Bottom line, you need to do the homework. Get a hold of the latest SCRT > User's Guide and start from there. > > In closing, once you have set everything up, then, yes, you can just run > some reports. As many as you want as often as you want. To get there, > however, involves a bit of work. > > Bob > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jake Anderson > Sent: Tuesday, June 11, 2019 4:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SCRT dummy > > Hi > > Well I must say I am quite new to SCRT and never ran it before . > > I understand this talks about the capacity reports and this report was > asked by one of our ISV vendor. > > Is there a JCL which is standard to run on to obtain reports ? > > Jake > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT dummy
Jake, Not exactly. Producing SCRT reports involves: 1) Collecting certain SMF records (IIRC, 70, 72 and 89) from all lpars from the second day of the month until the first day of the following month. 2) Obtaining the latest version of the SCRT code from the IBM SCRT website, downloading and installing it. Newest, just released, is 27.1. Two methods here: Loading a tar file into a USS filesystem and processing the install from there *or* get a PTF from IBM and install that with SMP/E. 3) You can run with just a day's worth of the above to prove that you are on the right track, but for reporting purposes, they (IBM) will want a month's worth. ISVs sometimes want ninety days worth. To actually send reports to IBM, you should already have subcapacity license agreements in place signed by both IBM and your contracting folks. To send to other ISVs, not necessary to have the IBM contracts, but the ISVs may want some of their own agreements signed. Bottom line, you need to do the homework. Get a hold of the latest SCRT User's Guide and start from there. In closing, once you have set everything up, then, yes, you can just run some reports. As many as you want as often as you want. To get there, however, involves a bit of work. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake Anderson Sent: Tuesday, June 11, 2019 4:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SCRT dummy Hi Well I must say I am quite new to SCRT and never ran it before . I understand this talks about the capacity reports and this report was asked by one of our ISV vendor. Is there a JCL which is standard to run on to obtain reports ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Alias Listcat discrepancy betweeen sysplex'd LPARs
On Mon, 10 Jun 2019 23:32:21 -0500, Elaine Beal wrote: >These LPARs do share a master catalog. >LOADxx syscat has the same parm on both LPARs > >A listcat of the master shows the alias entry > >ALIAS -,SYS7.R30 > >Thanks, >Elaine > Can you please show us the complete LOADxx member each LPAR is using? I'm specifically interested in the SYSCATs' multilevel alias value (at pos. 17), but prefer to see the entire LOADxxs, if no "trade secrets" involved. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Client Web Enablement Toolkit
Yes, I have set verbose on and I see the headers and response.
As I said, it shows the first and last 40 bytes of request body and the
equivalent in hex.
When I compare the hex values to a 'hex on' listing of the json payload in a
dataset / USS file, they are identical.
Does this mean the translate of EBCDIC to ASCII didn't work..?
– Vignesh
Mainframe Infrastructure
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
ITschak Mugzach
Sent: 11 June 2019 09:39
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Client Web Enablement Toolkit
If you set verbose mode a trace is written to sysout, so you will be able to
see the http headers and response.
ITschak
בתאריך יום ג׳, 11 ביוני 2019, 11:29, מאת Sankaranarayanan, Vignesh <
vignesh.v.sankaranaraya...@marks-and-spencer.com>:
> Code order --
>
> ReturnCode = -1
> DiagArea. = ''
> address hwthttp "hwthset ",
> "ReturnCode ",
> "RequestHandle ",
> "HWTH_OPT_REQUESTMETHOD ",
> "HWTH_HTTP_REQUEST_POST ",
> "DiagArea."
>
> ReturnCode = -1
> DiagArea. = ''
> address hwthttp "hwthset ",
> "ReturnCode ",
> "RequestHandle ",
> "HWTH_OPT_TRANSLATE_REQBODY ",
> "HWTH_XLATE_REQBODY_E2A ",
> "DiagArea."
>
> ReturnCode = -1
> DiagArea. = ''
> JSONPayload = '{"json":"yes"}'
> address hwthttp "hwthset ",
> "ReturnCode ",
> "RequestHandle ",
> "HWTH_OPT_REQUESTBODY ",
> "JSONPayload ",
> "DiagArea."
>
>
> - Vignesh
> Mainframe Infrastructure
>
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Sankaranarayanan, Vignesh
> Sent: 11 June 2019 09:22
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Client Web Enablement Toolkit
>
> Hi,
>
> It looks like I'm unable to translate the request body from EBCDIC to
> ASCII (in REXX), when using the HWTH_OPT_TRANSLATE_REQBODY with a
> value of HWTH_XLATE_REQBODY_E2A .. in the address hwthttp call.
>
> I'm using code based on SYS1.SAMPLIB(HWTHXRX1).
> I see a HTTP 400 error saying Bad request, and in the request body, I
> see the hex values that were/was sent.
> It looks identical to what I see when I do a 'hex on' in ISPF against
> the file with the payload (request body) open in 3.17 (USS).
>
> Any thoughts? All returning RC 0...
>
> - Vignesh
> Mainframe Infrastructure
>
>
> MARKSANDSPENCER.COM
>
> Unless otherwise stated above:
> Marks and Spencer plc
> Registered Office:
> Waterside House
> 35 North Wharf Road
> London
> W2 1NW
>
> Registered No. 214436 in England and Wales.
>
> Telephone (020) 7935 4422
> Facsimile (020) 7487 2670
>
> www.marksandspencer.com
>
> Please note that electronic mail may be monitored.
>
> This e-mail is confidential. If you received it by mistake, please let
> us know and then delete it from your system; you should not copy,
> disclose, or distribute its contents to anyone nor act in reliance on
> this e-mail, as this is prohibited and may be unlawful.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: 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
Hybrid SMS Storage Group - Database
Hi, Is there a possibility of performance degradation if SSD storage is added to SMS storage group that consists mainly of 15K SAS storage. Database tables are written to the storage group. We use a Dynamic Provisioning pool at disk subsystem level. Regards Nedbank Group Limited Internal Use Only Nedbank disclaimer and confidentiality notice: This email may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this email or all or some of the information contained therein, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this email is neither an offer or a solicitation to buy or sell any securities, investment products or other financial product or service, nor is it an official confirmation of any transaction or an official statement of Nedbank. Any views or opinions presented are solely those of the author and do not necessarily represent those of Nedbank. Nedbank Ltd Reg No 1951/09/06. The following link displays the names of the Nedbank Board of Directors and Company Secretary. [http://www.nedbank.co.za/terms/DirectorsNedbank.htm] If you do not want to click on a link, please type the relevant address in your browser -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Client Web Enablement Toolkit
If you set verbose mode a trace is written to sysout, so you will be able
to see the http headers and response.
ITschak
בתאריך יום ג׳, 11 ביוני 2019, 11:29, מאת Sankaranarayanan, Vignesh <
vignesh.v.sankaranaraya...@marks-and-spencer.com>:
> Code order --
>
> ReturnCode = -1
> DiagArea. = ''
> address hwthttp "hwthset ",
> "ReturnCode ",
> "RequestHandle ",
> "HWTH_OPT_REQUESTMETHOD ",
> "HWTH_HTTP_REQUEST_POST ",
> "DiagArea."
>
> ReturnCode = -1
> DiagArea. = ''
> address hwthttp "hwthset ",
> "ReturnCode ",
> "RequestHandle ",
> "HWTH_OPT_TRANSLATE_REQBODY ",
> "HWTH_XLATE_REQBODY_E2A ",
> "DiagArea."
>
> ReturnCode = -1
> DiagArea. = ''
> JSONPayload = '{"json":"yes"}'
> address hwthttp "hwthset ",
> "ReturnCode ",
> "RequestHandle ",
> "HWTH_OPT_REQUESTBODY ",
> "JSONPayload ",
> "DiagArea."
>
>
> - Vignesh
> Mainframe Infrastructure
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Sankaranarayanan, Vignesh
> Sent: 11 June 2019 09:22
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Client Web Enablement Toolkit
>
> Hi,
>
> It looks like I'm unable to translate the request body from EBCDIC to
> ASCII (in REXX), when using the HWTH_OPT_TRANSLATE_REQBODY with a value of
> HWTH_XLATE_REQBODY_E2A .. in the address hwthttp call.
>
> I'm using code based on SYS1.SAMPLIB(HWTHXRX1).
> I see a HTTP 400 error saying Bad request, and in the request body, I see
> the hex values that were/was sent.
> It looks identical to what I see when I do a 'hex on' in ISPF against the
> file with the payload (request body) open in 3.17 (USS).
>
> Any thoughts? All returning RC 0...
>
> - Vignesh
> Mainframe Infrastructure
>
>
> MARKSANDSPENCER.COM
>
> Unless otherwise stated above:
> Marks and Spencer plc
> Registered Office:
> Waterside House
> 35 North Wharf Road
> London
> W2 1NW
>
> Registered No. 214436 in England and Wales.
>
> Telephone (020) 7935 4422
> Facsimile (020) 7487 2670
>
> www.marksandspencer.com
>
> Please note that electronic mail may be monitored.
>
> This e-mail is confidential. If you received it by mistake, please let us
> know and then delete it from your system; you should not copy, disclose, or
> distribute its contents to anyone nor act in reliance on this e-mail, as
> this is prohibited and may be unlawful.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: 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] Client Web Enablement Toolkit
Code order --
ReturnCode = -1
DiagArea. = ''
address hwthttp "hwthset ",
"ReturnCode ",
"RequestHandle ",
"HWTH_OPT_REQUESTMETHOD ",
"HWTH_HTTP_REQUEST_POST ",
"DiagArea."
ReturnCode = -1
DiagArea. = ''
address hwthttp "hwthset ",
"ReturnCode ",
"RequestHandle ",
"HWTH_OPT_TRANSLATE_REQBODY ",
"HWTH_XLATE_REQBODY_E2A ",
"DiagArea."
ReturnCode = -1
DiagArea. = ''
JSONPayload = '{"json":"yes"}'
address hwthttp "hwthset ",
"ReturnCode ",
"RequestHandle ",
"HWTH_OPT_REQUESTBODY ",
"JSONPayload ",
"DiagArea."
- Vignesh
Mainframe Infrastructure
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Sankaranarayanan, Vignesh
Sent: 11 June 2019 09:22
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Client Web Enablement Toolkit
Hi,
It looks like I'm unable to translate the request body from EBCDIC to ASCII (in
REXX), when using the HWTH_OPT_TRANSLATE_REQBODY with a value of
HWTH_XLATE_REQBODY_E2A .. in the address hwthttp call.
I'm using code based on SYS1.SAMPLIB(HWTHXRX1).
I see a HTTP 400 error saying Bad request, and in the request body, I see the
hex values that were/was sent.
It looks identical to what I see when I do a 'hex on' in ISPF against the file
with the payload (request body) open in 3.17 (USS).
Any thoughts? All returning RC 0...
- Vignesh
Mainframe Infrastructure
MARKSANDSPENCER.COM
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW
Registered No. 214436 in England and Wales.
Telephone (020) 7935 4422
Facsimile (020) 7487 2670
www.marksandspencer.com
Please note that electronic mail may be monitored.
This e-mail is confidential. If you received it by mistake, please let us know
and then delete it from your system; you should not copy, disclose, or
distribute its contents to anyone nor act in reliance on this e-mail, as this
is prohibited and may be unlawful.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Client Web Enablement Toolkit
Hi, It looks like I'm unable to translate the request body from EBCDIC to ASCII (in REXX), when using the HWTH_OPT_TRANSLATE_REQBODY with a value of HWTH_XLATE_REQBODY_E2A .. in the address hwthttp call. I'm using code based on SYS1.SAMPLIB(HWTHXRX1). I see a HTTP 400 error saying Bad request, and in the request body, I see the hex values that were/was sent. It looks identical to what I see when I do a 'hex on' in ISPF against the file with the payload (request body) open in 3.17 (USS). Any thoughts? All returning RC 0... - Vignesh Mainframe Infrastructure MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SCRT dummy
Hi Well I must say I am quite new to SCRT and never ran it before . I understand this talks about the capacity reports and this report was asked by one of our ISV vendor. Is there a JCL which is standard to run on to obtain reports ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any way to set the PKM in "open code".
On Mon, 10 Jun 2019 13:57:12 -0700 Charles Mills wrote: :>> Key0 is much much more dangerous than supervisor state (IMHO) :>Interesting. I never thought of that, but I agree. Which is the more likely :>error? :>- You accidentally code some privileged instruction that you did not intend? Perhaps with a wild branch. Or you branch to user code. :>- You code the wrong register number in an instruction, or destroy or forget :>to initialize the contents of a register (at least on some code paths), or a :>register gets incremented too far? Supervisor state does not you to accidentally overwrite storage in a system key. You need to set the PSW key or use one of the explicit keyed instructions. :>Charles :> :> :>-Original Message- :>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :>Behalf Of Binyamin Dissen :>Sent: Sunday, June 9, 2019 11:48 PM :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: Re: Any way to set the PKM in "open code". :> :>On Sun, 9 Jun 2019 20:15:40 -0400 Rob Schramm wrote: :> :>:>I suspect John's answer will be :>:>1) because it's cool to try new things :> :>Well, to do that he could encapsulate this code in a PC-CP with an altered :>AKM. :> :>:>2) because I want to limit the destruction if it goes wrong. :> :>Key0 is much much more dangerous than supervisor state (IMHO) :> :>:>Waiting for the real answer, :>:>Rob :>:> :>:>On Sun, Jun 9, 2019, 6:22 PM Binyamin Dissen :>:>wrote: :>:> :>:>> On Fri, 7 Jun 2019 08:57:38 -0500 John McKown < :>:>> john.archie.mck...@gmail.com> :>:>> wrote: :>:>> :>:>> :>I am not finding this. I want to change the PKM for my running, APF :>:>> :>authorized, program to include key 0. Why? So that I can switch in and :>:>> out :>:>> :>of key 0 using an SPKA instruction rather than MODESET. But mainly so :>:>> that :>:>> :>I can use the MVCSK and MVCDK instructions to read & update key 0, :>fetch :>:>> :>protected, storage without going into key 0. :>:>> :>:>> :>Or am I just being silly (again)? :>:>> :>:>> Why not simply run supervisor state which allows access to all keys? :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
