Re: SMF Records
> -Original Message- > From: Vernooij, Kees (ITOPT1) - KLM > Sent: 17 May, 2017 8:41 > To: 'IBM Mainframe Discussion List' > Subject: RE: SMF Records > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of Jesse 1 Robinson > > Sent: 17 May, 2017 0:18 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SMF Records > > > > Keep in mind that SMF records are cut by applications or components > that > > choose to do so. It's not automatic. SMF is a record manager, not a > > creator. In particular, SFTP is an add-on product that is not related > to > > FTP(S) or TCP/IP. It may or may not create SMF records. If it does, > it's > > almost certainly the same records type for every transmission. > > > > . > > . > > And in addition to that: look at the SMF manual: SMF 15 is written > whenever a dataset is CLOSED after being opened for OUTPUT, period. > Every time a dataset is Closed for output, SMF15 is written, whether it > was the same dataset or not, the same user or not etc, just the CLOSE > cuts the record. This allows you to monitor via SMF who opened a dataset > during some perion, e.g. to determine the one that might have corrupted > it. > > Kees. Additional to that: in SMFPRMxx you can specify which records SMF will write and which it will not write when the application cuts them and gives them to SMF tob e written. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Records
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jesse 1 Robinson > Sent: 17 May, 2017 0:18 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF Records > > Keep in mind that SMF records are cut by applications or components that > choose to do so. It's not automatic. SMF is a record manager, not a > creator. In particular, SFTP is an add-on product that is not related to > FTP(S) or TCP/IP. It may or may not create SMF records. If it does, it's > almost certainly the same records type for every transmission. > > . > . And in addition to that: look at the SMF manual: SMF 15 is written whenever a dataset is CLOSED after being opened for OUTPUT, period. Every time a dataset is Closed for output, SMF15 is written, whether it was the same dataset or not, the same user or not etc, just the CLOSE cuts the record. This allows you to monitor via SMF who opened a dataset during some perion, e.g. to determine the one that might have corrupted it. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
UPDATE JOB(*) is dangerous. And was discussed in the IBM MAIN Archives, a couple of years ago I think. However, we use it with no ill effect. UPDATE Indicates that the system is to update an address space so that a specified job or jobs associated with that space can use the current LNKLST set. If the job is using another LNKLST set when the current LNKLST set is activated, it will continue to use the original LNKLST set until it completes operations. When the job completes and restarts, it then uses the data sets defined in the new currently active LNKLST set. See "Removing or Compressing a Data Set in an Active LNKLST Set" in z/OS MVS Initialization and Tuning Reference for information about LLA management of the LNKLST data set. Be careful when you use UPDATE. Updating an address space while a program in that address space is fetching a module can cause the fetch to fail or to locate an incorrect copy of the module. The system does not attempt to verify the validity of the data for UPDATE. Start of changeJOBNAME | JOB=jobnameEnd of change Specifies the name of the job or jobs to update. You can use wildcard characters (? or *) for jobname. UPDATE updates any job whose name matches the specified criteria. The system compares jobname to the name of any initiated job or jobs that match, or to the name of the address space. Dangle your foot in the fire. If it does not burn you are okay, If it does, take it out Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gibney, Dave > Sent: Tuesday, May 16, 2017 4:10 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: setrog lnklst question > > And the LNKLST UPDATE JOB(*) is documented as potentially dangerous. > > On the other hand, so far, I haven't have need to modify my linklst and > effect all running address spaces. It's usually limited to a smaller subset. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Lizette Koehler > > Sent: Tuesday, May 16, 2017 3:25 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: setrog lnklst question > > > > So an EXAMPLE would be > > > >/**/ > >/* Adding a dataset to the LINKLIST when it */ > >/* does not already exist */ > >/**/ > >LNKLST DEFINE NAME(NEWLNKA) COPYFROM(CURRENT) > >LNKLST ADDNAME(NEWLNKA) DSNAME(SYS1.NEWDSN.INLNK.LIST), > >AFTER(SYS1.LOCTION.INLNK.LIST) > >LNKLST DELETE NAME(NEWLNKA) DSNAME(SYS1.DELETE.THIS.LNKLST.DSN) > >LNKLST ACTIVATE NAME(NEWLNKA) > >LNKLST UPDATE JOB(*) > >APF ADD DSNAME(SYS1.NEWDSN.INLNK.LIST) VOLUME(&SYSR3) > > > > > > APF ADD is not needed if the file being added is already APF Authorized. > > DELETE is not needed if you are not removing anything from the Linklst. > > > > > > Lizette > > > > -Original Message- > > >From: Lizette Koehler > > >Sent: May 16, 2017 3:19 PM > > >To: IBM-MAIN@LISTSERV.UA.EDU > > >Subject: Re: setrog lnklst question > > > > > >You can create a parmlib member to > > > > > >COPY the current linklst to a new name Activate the new linklist name > > > > > >If you need further assistance let us know. > > > > > >Lizette > > > > > >-Original Message- > > >>From: william janulin <008d52e04f2e-dmarc- > > requ...@listserv.ua.edu> > > >>Sent: May 16, 2017 1:52 PM > > >>To: IBM-MAIN@LISTSERV.UA.EDU > > >>Subject: setrog lnklst question > > >> > > >>To list; > > >> Is it possible to add a dataset to the active lnklst? I tried a > > >>setprog lnklst > > add command and got a messagethat the lnklst was active. > > >> > > >>Thank you in advance, Bill J. > > >> > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: 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: SMF Records
>> What I am asking is if the SAME file is transmitted with the SAME file name >> again, is the SAME SMF Record Type cut or is a different SMF Record Type cut? > Normally when the same SMF events occur the same SMF record types will be cut. > > However, there can be some differences in exactly which records are cut if > the second transfer is not exactly the same. > > For example, if the first transfer creates the dataset and the second just > replaces the content, you should see SMF records related to creating catalog > entries etc. on the first transfer but not on the second. Maybe I am not understanding your question. Lets try and clear it up. Dataset creation yes Dataset write yes Dataset read yes The above is for 99.9 of all datasets. There are some exclusions the exclusion are system type datasets DSCB etc…But for all intents reasonable any batch/stc/tso are created SMF records are written. If we take your example, TCP creates a file - Yes SMF record(s) are written. If TCP reads the files - yes smh record is written. IF TCP overwrites a file SMF record is written. If TCP deletes a file SMF record(s) are written. The only unknown here is if its a unix file, I am sure that they are written but what types are is to me unknown but S/B easily findable The other *IF* is which type of records are cut. Types 14/15 are read write for non unix files there are records for unix files but I haven’t tried to go after them. As one responder says try DAF on the CBTTape it is a good program and its free. You only have to have a basic knowledge of MVS to read the report(s). Ed > > -- > Andrew Rowley > Black Hill Software > +61 413 302 386 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: 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: SMF Records
On 17/05/2017 8:11 AM, Sasso, Leonard wrote: What I am asking is if the SAME file is transmitted with the SAME file name again, is the SAME SMF Record Type cut or is a different SMF Record Type cut? Normally when the same SMF events occur the same SMF record types will be cut. However, there can be some differences in exactly which records are cut if the second transfer is not exactly the same. For example, if the first transfer creates the dataset and the second just replaces the content, you should see SMF records related to creating catalog entries etc. on the first transfer but not on the second. -- Andrew Rowley Black Hill Software +61 413 302 386 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables
On Tue, 16 May 2017 18:36:38 -0500, Mike Schwab wrote: >Maybe IBM can publish the info or an II apar to document the >application coding techniques causing the problem. > If move-with-truncation is a conventional COBOL operation, the resolution should not be, "Don't do that!" I detest quiet truncation. It's hardly better if it takes an inordinately long time. Another possible resolution, with its own performance consequence, is for the compiler-generated code to test (every time) whether overflow is about to occur and handle it as a special case. It might be better just to abandon the use of DFP. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables
Maybe IBM can publish the info or an II apar to document the application coding techniques causing the problem. On Tue, May 16, 2017 at 3:22 PM, Peter Hunkeler wrote: > >>It sounds like it's time to open a PMR. Do you want to do that and can you >>do that? > > > I'm not allowed to open a PMR by myself but asking my colleagues to open one > is not a problem. It is only that I don't see what to report as an error in > this case. From the long lasting investigation starting November 2016 to find > a problem with Smart/Restart that started to pop up more often for exactly > the same reason, I understand that the decimal overflow mask bit in the PSW > and Language Environment's duty to support the different expectations of > COBOL on one side and C and PL/I on the other side work as documented. > > > > We had a PMR open with LE during the analysis of the Smart/Restart problem, > and IBM LE did not seem to see a problem in the current behaviour. > > > What would you recommend we should report in the PMR? Maybe we continue to > discuss offline, and report back here when there is interesting news? > > > Regards, Peter > > > -- > Peter Hunkeler > > > > -- > 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: setrog lnklst question
And the LNKLST UPDATE JOB(*) is documented as potentially dangerous. On the other hand, so far, I haven't have need to modify my linklst and effect all running address spaces. It's usually limited to a smaller subset. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lizette Koehler > Sent: Tuesday, May 16, 2017 3:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: setrog lnklst question > > So an EXAMPLE would be > >/**/ >/* Adding a dataset to the LINKLIST when it */ >/* does not already exist */ >/**/ >LNKLST DEFINE NAME(NEWLNKA) COPYFROM(CURRENT) >LNKLST ADDNAME(NEWLNKA) DSNAME(SYS1.NEWDSN.INLNK.LIST), >AFTER(SYS1.LOCTION.INLNK.LIST) >LNKLST DELETE NAME(NEWLNKA) DSNAME(SYS1.DELETE.THIS.LNKLST.DSN) >LNKLST ACTIVATE NAME(NEWLNKA) >LNKLST UPDATE JOB(*) >APF ADD DSNAME(SYS1.NEWDSN.INLNK.LIST) VOLUME(&SYSR3) > > > APF ADD is not needed if the file being added is already APF Authorized. > DELETE is not needed if you are not removing anything from the Linklst. > > > Lizette > > -Original Message- > >From: Lizette Koehler > >Sent: May 16, 2017 3:19 PM > >To: IBM-MAIN@LISTSERV.UA.EDU > >Subject: Re: setrog lnklst question > > > >You can create a parmlib member to > > > >COPY the current linklst to a new name > >Activate the new linklist name > > > >If you need further assistance let us know. > > > >Lizette > > > >-Original Message- > >>From: william janulin <008d52e04f2e-dmarc- > requ...@listserv.ua.edu> > >>Sent: May 16, 2017 1:52 PM > >>To: IBM-MAIN@LISTSERV.UA.EDU > >>Subject: setrog lnklst question > >> > >>To list; > >> Is it possible to add a dataset to the active lnklst? I tried a setprog > >>lnklst > add command and got a messagethat the lnklst was active. > >> > >>Thank you in advance, Bill J. > >> > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: 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: SMF Records
You might want to consider that the OpenSSH SMF records are part of the Type 119 record and use subtype 94, 95, 96, 97, and 98 Subtype 96 is the "Server" transfer complete record and 97 is the "Client" equivalent. These records would give you who, what and where someone accessed a file, including the SFTP command executed against the file. I gathered the above information from: "z/OS IBM Ported Tools for z/OS: OpenSSH User's Guide Version 1 Release 3" (SA23-2246-03), the details for the subtypes 94 through 98 are in this manual and not in the "z/OS Communications Server: IP Programmer's Guide and Reference" which will have the other SMF 119 record subtype descriptions. Al Nims Systems Admin/Programmer 3 UFIT University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edward Finnell Sent: Tuesday, May 16, 2017 6:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF Records I think DAF off CBT will answer all the questions. In a message dated 5/16/2017 5:16:17 P.M. Central Daylight Time, stars...@mindspring.com writes: Basically SMF always writes a record, it does not check if that file name was done that way or not. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: SMF Records
I think DAF off CBT will answer all the questions. In a message dated 5/16/2017 5:16:17 P.M. Central Daylight Time, stars...@mindspring.com writes: Basically SMF always writes a record, it does not check if that file name was done that way or not. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Records
To add to that. The records are cut each time. There is no filtering to see if that event has already been done. Everytime the FTP(S) or TCP/IP does something that can create an SMF record type, it is created. Can you provide more detail as to the reason the question is being asked? Are you missing SMF Data? Or not getting SMF Data? Lizette -Original Message- >From: Jesse 1 Robinson >Sent: May 16, 2017 3:18 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMF Records > >Keep in mind that SMF records are cut by applications or components that >choose to do so. It's not automatic. SMF is a record manager, not a creator. >In particular, SFTP is an add-on product that is not related to FTP(S) or >TCP/IP. It may or may not create SMF records. If it does, it's almost >certainly the same records type for every transmission. > >. >. >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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Sasso, Leonard >Sent: Tuesday, May 16, 2017 3:12 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: SMF Records > >What I am asking is if the SAME file is transmitted with the SAME file name >again, is the SAME SMF Record Type cut or is a different SMF Record Type cut? > >Thank You, > >Len Sasso >System Administrator > > >RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400 >t: +1.518.257.4209 | m: +1.518.894.0879 >len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn >CSRA Think Next. Now. > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Steve Beaver >Sent: Tuesday, May 16, 2017 6:02 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMF Records > >The SMF process is a sequential process and each records has a time and data >stamp. SMF records DO NOT overwrite previous smf records > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Sasso, Leonard >Sent: Tuesday, May 16, 2017 4:47 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: SMF Records > >A customer transmits, via SFTP, a sequential file, from an external site to an >IBM Mainframe. An hour later, they transmit the same file with the SAME file >name, overwriting the original file. > >1. What SMF Record Type was cut when the first file was transmitted? > >2. Is another SMF Record cut for the overwrite and is it the SAME SMF Record >Type as the original? If not, what SMF Record Type is cut? > > > >Thank You, > >Len Sasso >System Administrator >RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400 >t: +1.518.257.4209 | m: +1.518.894.0879 >len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn >CSRA Think Next. Now. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Records
By file do you mean dataset or UNIX file? For a dataset: 1. Potentially an SMF Type 15. Type 15 would have to be enabled in SMFPRMxx. Potentially an SMF Type 80 (assuming RACF) if the dataset is audited. 2. Yes. Details would be different but it would still be an SMF Type 15. Potentially an SMF Type 80. For a UNIX file: 1. Potentially an SMF 92. Type 92 would have to be enabled in SMFPRMxx. I don't recall if RACF can audit USS file access. 2. Yes. Details would be different but it would still be an SMF Type 92. The above answers are for the access to the file or dataset. I am assuming you are referring to the receiving end. If the sending end is MVS, then same answers except SMF 15 becomes SMF 14. Other SMF records might also be cut: Job or TSO session start and end. Some SFTP implementations cut their own SMF records. Perhaps others. I know of no distinction in any SMF records for "the first time you do something" versus "re-doing it a little later." SMF records tend to stand on their own. SMF record cutting is essentially stateless. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sasso, Leonard Sent: Tuesday, May 16, 2017 2:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF Records A customer transmits, via SFTP, a sequential file, from an external site to an IBM Mainframe. An hour later, they transmit the same file with the SAME file name, overwriting the original file. 1. What SMF Record Type was cut when the first file was transmitted? 2. Is another SMF Record cut for the overwrite and is it the SAME SMF Record Type as the original? If not, what SMF Record Type is cut? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
So an EXAMPLE would be /**/ /* Adding a dataset to the LINKLIST when it */ /* does not already exist */ /**/ LNKLST DEFINE NAME(NEWLNKA) COPYFROM(CURRENT) LNKLST ADDNAME(NEWLNKA) DSNAME(SYS1.NEWDSN.INLNK.LIST), AFTER(SYS1.LOCTION.INLNK.LIST) LNKLST DELETE NAME(NEWLNKA) DSNAME(SYS1.DELETE.THIS.LNKLST.DSN) LNKLST ACTIVATE NAME(NEWLNKA) LNKLST UPDATE JOB(*) APF ADD DSNAME(SYS1.NEWDSN.INLNK.LIST) VOLUME(&SYSR3) APF ADD is not needed if the file being added is already APF Authorized. DELETE is not needed if you are not removing anything from the Linklst. Lizette -Original Message- >From: Lizette Koehler >Sent: May 16, 2017 3:19 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: setrog lnklst question > >You can create a parmlib member to > >COPY the current linklst to a new name >Activate the new linklist name > >If you need further assistance let us know. > >Lizette > >-Original Message- >>From: william janulin <008d52e04f2e-dmarc-requ...@listserv.ua.edu> >>Sent: May 16, 2017 1:52 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: setrog lnklst question >> >>To list; >> Is it possible to add a dataset to the active lnklst? I tried a setprog >>lnklst add command and got a messagethat the lnklst was active. >> >>Thank you in advance, Bill J. >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Records
Keep in mind that SMF records are cut by applications or components that choose to do so. It's not automatic. SMF is a record manager, not a creator. In particular, SFTP is an add-on product that is not related to FTP(S) or TCP/IP. It may or may not create SMF records. If it does, it's almost certainly the same records type for every transmission. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sasso, Leonard Sent: Tuesday, May 16, 2017 3:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: SMF Records What I am asking is if the SAME file is transmitted with the SAME file name again, is the SAME SMF Record Type cut or is a different SMF Record Type cut? Thank You, Len Sasso System Administrator RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400 t: +1.518.257.4209 | m: +1.518.894.0879 len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn CSRA Think Next. Now. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Beaver Sent: Tuesday, May 16, 2017 6:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF Records The SMF process is a sequential process and each records has a time and data stamp. SMF records DO NOT overwrite previous smf records -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sasso, Leonard Sent: Tuesday, May 16, 2017 4:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF Records A customer transmits, via SFTP, a sequential file, from an external site to an IBM Mainframe. An hour later, they transmit the same file with the SAME file name, overwriting the original file. 1. What SMF Record Type was cut when the first file was transmitted? 2. Is another SMF Record cut for the overwrite and is it the SAME SMF Record Type as the original? If not, what SMF Record Type is cut? Thank You, Len Sasso System Administrator RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400 t: +1.518.257.4209 | m: +1.518.894.0879 len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn CSRA Think Next. Now. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
You can create a parmlib member to COPY the current linklst to a new name Activate the new linklist name If you need further assistance let us know. Lizette -Original Message- >From: william janulin <008d52e04f2e-dmarc-requ...@listserv.ua.edu> >Sent: May 16, 2017 1:52 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: setrog lnklst question > >To list; > Is it possible to add a dataset to the active lnklst? I tried a setprog >lnklst add command and got a messagethat the lnklst was active. > >Thank you in advance, Bill J. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Records
My basic understanding is this: An SMF record is created for each event. So, if you create a file/delete it - that would be a create and delete SMF Record. If you do it hours apart, again new SMF records for create and delete are created. SMF does not monitor to see if it is the same file or not. It just creates records. Now you may have a tool in your shop that does filtering. Then I am not sure what that would do. Basically SMF always writes a record, it does not check if that file name was done that way or not. Lizette -Original Message- >From: "Sasso, Leonard" >Sent: May 16, 2017 3:11 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMF Records > >What I am asking is if the SAME file is transmitted with the SAME file name >again, is the SAME SMF Record Type cut or is a different SMF Record Type cut? > >Thank You, > >Len Sasso >System Administrator > > >RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400 >t: +1.518.257.4209 | m: +1.518.894.0879 >len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn >CSRA >Think Next. Now. > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Steve Beaver >Sent: Tuesday, May 16, 2017 6:02 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMF Records > >The SMF process is a sequential process and each records has a time and data >stamp. SMF records DO NOT overwrite previous smf records > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Sasso, Leonard >Sent: Tuesday, May 16, 2017 4:47 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: SMF Records > >A customer transmits, via SFTP, a sequential file, from an external site to an >IBM Mainframe. An hour later, they transmit the same file with the SAME file >name, overwriting the original file. > >1. What SMF Record Type was cut when the first file was transmitted? > >2. Is another SMF Record cut for the overwrite and is it the SAME SMF Record >Type as the original? If not, what SMF Record Type is cut? > > > >Thank You, > >Len Sasso >System Administrator >RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400 >t: +1.518.257.4209 | m: +1.518.894.0879 >len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn >CSRA Think Next. Now. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Records
What I am asking is if the SAME file is transmitted with the SAME file name again, is the SAME SMF Record Type cut or is a different SMF Record Type cut? Thank You, Len Sasso System Administrator RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400 t: +1.518.257.4209 | m: +1.518.894.0879 len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn CSRA Think Next. Now. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Beaver Sent: Tuesday, May 16, 2017 6:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF Records The SMF process is a sequential process and each records has a time and data stamp. SMF records DO NOT overwrite previous smf records -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sasso, Leonard Sent: Tuesday, May 16, 2017 4:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF Records A customer transmits, via SFTP, a sequential file, from an external site to an IBM Mainframe. An hour later, they transmit the same file with the SAME file name, overwriting the original file. 1. What SMF Record Type was cut when the first file was transmitted? 2. Is another SMF Record cut for the overwrite and is it the SAME SMF Record Type as the original? If not, what SMF Record Type is cut? Thank You, Len Sasso System Administrator RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400 t: +1.518.257.4209 | m: +1.518.894.0879 len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn CSRA Think Next. Now. This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: Cyber attack
The CEO of Carbon Black was on Bloomberg yesterday. Sharp guy, guess I came away with three things. 1)Too soon to tell who did it. There is already a wannacry 2.0 2)NSA data dumpers are threatening to do a dump month. 3)Cartels/Syndicates have their own TOR like networks to move info and $$$ undetected in traditional sense. In a message dated 5/16/2017 10:25:49 A.M. Central Daylight Time, jesse1.robin...@sce.com writes: Thanks for this link. I have reported it to our cybersecurity folks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Records
The SMF process is a sequential process and each records has a time and data stamp. SMF records DO NOT overwrite previous smf records -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sasso, Leonard Sent: Tuesday, May 16, 2017 4:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF Records A customer transmits, via SFTP, a sequential file, from an external site to an IBM Mainframe. An hour later, they transmit the same file with the SAME file name, overwriting the original file. 1. What SMF Record Type was cut when the first file was transmitted? 2. Is another SMF Record cut for the overwrite and is it the SAME SMF Record Type as the original? If not, what SMF Record Type is cut? Thank You, Len Sasso System Administrator RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400 t: +1.518.257.4209 | m: +1.518.894.0879 len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn CSRA Think Next. Now. This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMF Records
A customer transmits, via SFTP, a sequential file, from an external site to an IBM Mainframe. An hour later, they transmit the same file with the SAME file name, overwriting the original file. 1. What SMF Record Type was cut when the first file was transmitted? 2. Is another SMF Record cut for the overwrite and is it the SAME SMF Record Type as the original? If not, what SMF Record Type is cut? Thank You, Len Sasso System Administrator RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400 t: +1.518.257.4209 | m: +1.518.894.0879 len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn CSRA Think Next. Now. This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: setrog lnklst question
You have to use SETPROG to make a copy of the active list, add your new library and activate the new list. Read all the special caveats > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of william janulin > Sent: Tuesday, May 16, 2017 1:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: setrog lnklst question > > To list; > Is it possible to add a dataset to the active lnklst? I tried a setprog > lnklst add > command and got a messagethat the lnklst was active. > > Thank you in advance, Bill J. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
setrog lnklst question
To list; Is it possible to add a dataset to the active lnklst? I tried a setprog lnklst add command and got a messagethat the lnklst was active. Thank you in advance, Bill J. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Re. Whacking a Job, or Getting rid of an Address Space
> On May 16, 2017, at 10:40 AM, Walt Farrell wrote: > > On Tue, 16 May 2017 09:57:16 -0400, Sam Golob wrote: > >>That having been said, the system doctor sometimes has to deal with >> things that go wrong. It's nice when the system is working as >> designed. But sometimes, the NON-CANCELABLE job or STC goes awry, and >> it has to be restarted. In such a case, as in the middle of a day's >> production, you want to avoid an emergency IPL. And so you need a tool >> in the toolbox, to cancel the job or STC. Sometimes the only solution >> is to blow it away. > > However, you should be prepared, when you use the tool, to have to IPL > anyway. And that should be clearly stated in any documentation for the tool. > > -- > Walt —SNIP——— In the early days of MVS we had constant issues of jobs going non cancelable. Our IBM SE wrote a super cancel (callrtm) command. We *WERE* using it sparingly. It was a last grasp to IPL. Although most of our issues had to due with allocation (Q4) getting hung. We were IPLing once or twice in 3 days (sometimes as many as 8). IBM rewrote allocation and just about eliminated the need for it. We did still use it from time to time and it did save IPL’s. Our other IBMer who worked behind mountains of standalone dumps was used to it and didn’t raise it as an issue. But it was understood by the group that using it was a last gasp attempt and then only making sure there were no allocation hangups. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables
>It sounds like it's time to open a PMR. Do you want to do that and can you do >that? I'm not allowed to open a PMR by myself but asking my colleagues to open one is not a problem. It is only that I don't see what to report as an error in this case. From the long lasting investigation starting November 2016 to find a problem with Smart/Restart that started to pop up more often for exactly the same reason, I understand that the decimal overflow mask bit in the PSW and Language Environment's duty to support the different expectations of COBOL on one side and C and PL/I on the other side work as documented. We had a PMR open with LE during the analysis of the Smart/Restart problem, and IBM LE did not seem to see a problem in the current behaviour. What would you recommend we should report in the PMR? Maybe we continue to discuss offline, and report back here when there is interesting news? Regards, Peter -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables
It sounds like it's time to open a PMR. Do you want to do that and can you do that? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables
Very interesting analysis Peter. We are beginning our conversion to COBOL V5.2 and this will be a great help to us. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, May 16, 2017 7:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables Not a question, just some interesting stuff for the curious people :-) I have recently been asked to help analyze why a job was running very long and was using much CPU. Since all DB2 access paths were very efficient, we started an MA-Tune trace to see where the job was spending its time. MA-Tune reported that the job was spending almost 100% of its time at the following statement in module XYZ: MOVE ARG-CNT TO DISPLAY-ARG-CNT This did not make much sense, because that MOVE statement is not part of any loop construct. One would have expected that MA-Tune would see the job in other places as well. Since MA-Tune could not help, I have taken an SVC-Dump of the job the next time I was made aware it was not ending again. Analysis of the dump showed that the job was spending almost all time recovering from a program check 00A (decimal owerflow exception) . It was not obvious whether this was a recovery loop because of some error in the environment, i.e. Cobol runtime, Language Environment, or some restart product we're using, although neither of this seemed plausible. Further investigation finally showed that the problem arises because the target field in the above MOVE statement is not large enough to receive the source value once it grows above 9'999'999: The source and target fields are declared as follows: 01 ARG-CNTPIC 9(10) BINARY 01 DISPLAY-ARG-CNT PIC 9(07) Ignoring any overflow when the source count is greater than 9'999'999 might be intended from a programming point of view, but it may cause a dramatic performance degradation. The reason for the performance degradation lies in the following facts: * Firstly, Cobol wants to silently ignore a decimal overflow when it appears as part of a MOVE (and other) statement. * Secondly, the processor (hardware) supports two modes of operation regarding decimal overflow: It can either indicate an overflow by setting the condition code, or it can raise a program check hardware interruption of type 00A. While coding techniques such as in the example above did rarely hurt performance in Cobol up to version 4, it may more likely cause problems with Cobol V5.2 and above. The reason being that the Cobol compiler is making use of modern, better performing instructions on one hand, and the high likelihood that the processor is running in the mode where an overflow causes a hardware interruption to occur on the other hand. Every hardware interruption has to be handled by Language Environment's error recovery routines. This recovery code will interpret the interrupt, and in the case above comes to the conclusion that the decimal overflow is to be expected, and to be silently ignored. It will thus give control back to the interrupted program code. Why is this so bad from a performance perspective? The path length of the code involved from the time the operating system recognizes the program check hardware interruption until Language Environment returns control to the interrupted program is quite long by itself. In addition it depends on the system setup. Especially the size of the system trace table has a great influence in the elapsed time. This system has 4 (logical) CPs, 3 (logical) z IIPs, and a system trace table size of 15MiB per processor. It took between 0.05 and 0.15 seconds (yes, this is in seconds!) elapsed time to handle a single overflow. That time is spent mostly to create a snapshot of the 105 MiB (7*15MiB) system trace tables in anticipation of a dump request. At the time the dump was taken (I had been involved late), the source counter value was 10'181'270, i.e. an overflow exception had occurred for the last 181'271 times the above statement was executed. Ignoring any other delay this alone took some 181271 * 0.1s, i.e. some 5 hours of elapsed time. Regards Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, sen
Re: Whacking a Job, or Getting rid of an Address Space
Hi Folks, I want to point out that not all versions of CNCLPG on CBT File 826 have BURN or KILL capability for JOBs or STCs. The earlier versions of the program (included in the file) have less power. You have the choice of installing one of the earlier versions of the program (1.10, 1.11, or 1.20) if you only want to make jobs non-cancelable or non-swappable (1.11 and 1.20). So then you can use one of the earlier versions. My point is to let you know that in an emergency, the power is there. All the best of everything to all of you. Sincerely,Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables
>I have a suspicion that this is a mixed language program. That is, it >consists of COBOL and, say C. (Or it uses COBOL features with a C run time >implementation such as XML or OO COBOL.) Can you confirm this is the case? Allan, I cannot confirm this because I did not investigate so far in this case, but it may well be that XML is being used. As far as I know, we do not make use of OO COBOL. I can, however, confirm that we're facing a lot of troubles with programs after they get recompiled with COBOL V5.2 instead of COBOL V4.2. The reason being that the different instruction stream which COBOL V5.2 (and newer) generates increase the likelihood that the program may run into decimal overflow conditions. A simple MOVE statements that moves A to B where A is declared as PIC 9(7)V9(4) and B is declared as PIC V9(18) had never caused a decimal overflow in COBOL V4 but may well in COBOL V5 because the later is making use of decimal instructions that will recognized decimal overflow. We also see the decimal overflow mask bit in the PSW is turned on much more often, when COBOL V5 is being used. We know that using the XML is one reason, and running the prorgam under the IBM Debugger is another one, but we also see other cases, but did not find out what causes the mask to be set. The result of all this is that a decimal overflow happens more often, and chances are much higher that the overflow will raise a 00a program check interruption that LE error handling has to deal with, just to find out the COBOL program can continue. I just found another job late this afternoon which runs between 1 and 2 hours since the program was recompiled, but ran only a few minutes before. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables
I'm sorry for the bad formatting of the initial post. Not a question, just some interesting stuff for the curious people :-) I have recently been asked to help analyze why a job was running very long and was using much CPU. Since all DB2 access paths were very efficient, we started an MA-Tune trace to see where the job was spending its time. MA-Tune reported that the job was spending almost 100% of its time at the following statement in module XYZ: MOVE ARG-CNT TO DISPLAY-ARG-CNT This did not make much sense, because that MOVE statement is not part of any loop construct. One would have expected that MA-Tune would see the job in other places as well. Since MA-Tune could not help, I have taken an SVC-Dump of the job the next time I was made aware it was not ending again. Analysis of the dump showed that the job was spending almost all time recovering from a program check 00A (decimal owerflow exception). It was not obvious whether this was a recovery loop because of some error in the environment, i.e. Cobol runtime, Language Environment, or some restart product we're using, although neither of this seemed plausible. Further investigation finally showed that the problem arises because the target field in the above MOVE statement is not large enough to receive the source value once it grows above 9'999'999: The source and target fields are declared as follows: 01 ARG-CNTPIC 9(10) BINARY 01 DISPLAY-ARG-CNT PIC 9(07) Ignoring any overflow when the source count is greater than 9'999'999 might be intended from a programming point of view, but it may cause a dramatic performance degradation. The reason for the performance degradation lies in the following facts: · Firstly, Cobol wants to silently ignore a decimal overflow when it appears as part of a MOVE (and other) statement. · Secondly, the processor (hardware) supports two modes of operation regarding decimal overflow: It can either indicate an overflow by setting the condition code, or it can raise a program check hardware interruption of type 00A. While coding techniques such as in the example above did rarely hurt performance in Cobol up to version 4, it may more likely cause problems with Cobol V5.2 and above. The reason being that the Cobol compiler is making use of modern, better performing instructions on one hand, and the high likelihood that the processor is running in the mode where an overflow causes a hardware interruption to occur on the other hand. Every hardware interruption has to be handled by Language Environment's error recovery routines. This recovery code will interpret the interrupt, and in the case above comes to the conclusion that the decimal overflow is to be expected, and to be silently ignored. It will thus give control back to the interrupted program code. Why is this so bad from a performance perspective? The path length of the code involved from the time the operating system recognizes the program check hardware interruption until Language Environment returns control to the interrupted program is quite long by itself. In addition it depends on the system setup. Especially the size of the system trace table has a great influence in the elapsed time. This system has 4 (logical) CPs, 3 (logical) z IIPs, and a system trace table size of 15MiB per processor. It took between 0.05 and 0.15 seconds (yes, this is in seconds!) elapsed time to handle a single overflow. That time is spent mostly to create a snapshot of the 105 MiB (7*15MiB) system trace tables in anticipation of a dump request. At the time the dump was taken (I had been involved late), the source counter value was 10'181'270, i.e. an overflow exception had occurred for the last 181'271 times the above statement was executed. Ignoring any other delay this alone took some 181271 * 0.1s, i.e. some 5 hours of elapsed time. Regards Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cyber attack
Brian Krebs is a super reliable source. He has one or two issues that he is over-obsessed with IMHO but he is often a good read. I've never read anything from Brian that I thought based on my knowledge or experience to be wrong. Not mainframe-oriented at all, of course, but many issues are more or less universal. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, May 16, 2017 8:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cyber attack Thanks for this link. I have reported it to our cybersecurity folks. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, May 16, 2017 5:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Cyber attack https://krebsonsecurity.com/2017/05/breach-at-docusign-led-to-targeted-email-malware-campaign/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables
Hi Peter I have a suspicion that this is a mixed language program. That is, it consists of COBOL and, say C. (Or it uses COBOL features with a C run time implementation such as XML or OO COBOL.) Can you confirm this is the case? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Whacking a Job, or Getting rid of an Address Space
Hi Folks, I just want to tell you that I very much appreciate this discussion. Very much depends on POINT OF VIEW, and when all the points of view get together, real progress is made, and everybody becomes wiser. There are at least three separate points of view here on this forum: 1. The systems programmers who have to set up and run the system software in data centers. 2. The professional "system level" programmers who usually work for vendors. 3. The IBM programmers who design and build the system software. There may be other people here also, such as application programmers and "programmer toolmakers" and more types, as well. Everybody has a separate point of view. In summary, here they are: People who run data centers, have to make sure everything run smoothly, and they have to deal with "the problems of the non-ideal world". Something breaks--fix it. Keep the system up. Make sure the system levels are correctly set for what we are doing, and for what we need. Professional "system level" programmers dig deep into the system. "Authority" is not what is usually on their mind, unless they are dealing with a security-related product. For example, doing cross-memory programming is usually "a piece of cake" for them. But changing some fields in another user's control blocks, which might be easy for THEM to do, is a nightmare from the system administrator's point of view, so you already see a difference in point of view between these two groups. Finally, the IBM designers and programmers have a big responsibility of delivering a consistent and reliable system, but they may tend (depending on the individual person's actual experience) to be a bit separated from the system programmer's "real world" problems, and the things that actually come up in a real data center, day by day. I am glad that my post is bringing these 3 points of view together, in a productive and fruitful way. If I did not write about this topic, then some sysprog might be without a necessary tool in his/her toolbox. When the emergency came up, they would be as helpless as I was, many years ago. On the other hand, we know that the tool can be used improperly, either by the right people or the wrong people. So I had a quandary: "To say, or NOT to say. That was the question." I opted to "say". I remember the pain in my heart, when JES2 couldn't be removed, and we had to IPL in the middle of the day. It was easy to fix if we could just cancel JES2, and restart it. I had already proven that to myself, at that time. But I was helpless and adrift. We had to IPL. NEVER AGAIN! I won't let that happen to someone! NEVER!!! So there. I trust we've all been helpful... All the best of everything to everyone. Sincerely,Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Re. Whacking a Job, or Getting rid of an Address Space
On Tue, 16 May 2017 09:57:16 -0400, Sam Golob wrote: > That having been said, the system doctor sometimes has to deal with >things that go wrong. It's nice when the system is working as >designed. But sometimes, the NON-CANCELABLE job or STC goes awry, and >it has to be restarted. In such a case, as in the middle of a day's >production, you want to avoid an emergency IPL. And so you need a tool >in the toolbox, to cancel the job or STC. Sometimes the only solution >is to blow it away. However, you should be prepared, when you use the tool, to have to IPL anyway. And that should be clearly stated in any documentation for the tool. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
On Tue, 16 May 2017 20:42:42 +0700, Robin Atwood wrote: >>However, as you're running work on behalf of various end-users, I hope you're >>authenticating those users and >running the work under the proper end-user >>identity in each case. And that would probably require authorization >of the >>STC. > >Yes, we run under the ACEE of the user. However, unless your STC runs single-threaded (handling requests for only 1 user at a time) it's not possible for you to run REXX execs invokiing ISPF services with proper security. It would require ensuring that none of the execs, or the services they invoke, perform any ATTACH requests., The new subtask created by ATTACH would not inherit the ACEE of the user on whose behalf you're running the request. (There is one exception to that, but it's used rarely enough that it probably won't apply to you. You would have to be using WLM services, and operating as a WLM servant to manage the requests that you're processing. Then, and only then as far as I know, would the user's ACEE propagate down to a new subtask.) -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Whacking a Job, or Getting rid of an Address Space
Paul Gilmartin wrote: >I sense a gradual escalation here. >Long ago, there was the CANCEL command so operators could terminate >troublesome jobs. >But a designer felt that sometimes the programmer knows better, and provided >the non-cancellable attribute. >Then a designer felt that sometimes the operator knows even better and >provided the FORCE command. >Then a designer felt that sometimes the programmer knows even better and >provided the non-forcible attribute. >Now someone feels that operators know better and is providing a WHACK facility. Not good. All involved must look why you need to WHACK it. For example, your job itself is waiting for a mount or is waiting for HSM to recall something, but there is a mount problem. Solve that, and you don't need all those fancy measures including a 222 abend. Ok, that is just one sample reason why 'WHACKING' or all those 'x who knows better' are not suitable. One example we got a few weeks ago was, a session was holding a CICS region. CPU% and region consumed climbed. Response times dropped on all CICS regions. Instead having WHACK down the troublesome CICS region, the network people simply VARY that session offline and all things returned to normal. No STCs were stopped at all. But, so, normally check all normal avenues, then escalate using more and more extreme measures as per Paul' suggestion. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cyber attack
Thanks for this link. I have reported it to our cybersecurity folks. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, May 16, 2017 5:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Cyber attack https://krebsonsecurity.com/2017/05/breach-at-docusign-led-to-targeted-email-malware-campaign/ Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Monday, May 15, 2017 4:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cyber attack I got one over the weekend with a name I don't recognize. Did not open or pursue because I was suspicious. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Beaver Sent: Monday, May 15, 2017 4:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Cyber attack I have been seen a lot of emails for what appears to be DocuSign and I have been killing them when I seen them -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Re. Whacking a Job, or Getting rid of an Address Space
..and sometimes a Doctor uses a Sonic Screw Driver. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Tuesday, May 16, 2017 10:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Re. Whacking a Job, or Getting rid of an Address Space On Tue, 16 May 2017 09:57:16 -0400, Sam Golob wrote: > the system doctor sometimes has to deal with things that go wrong. > >The >doctor needs to have a scalpel. Most doctors don't often need to use >the scalpel. Sometimes the "doctor" isn't really a doctor, but a boy scout who may have learned some rudimentary first aid. And sometimes that thing that he thought was a scalpel is really a chain saw. -- Tom Marchant -- 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, and any attachments thereto, is intended solely for the use of the addressee(s) and may contain confidential and/or privileged material. Any review, retransmission, dissemination, copying, or other use of the transmitted information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. UNIGROUP.COM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Re. Whacking a Job, or Getting rid of an Address Space
On Tue, 16 May 2017 09:57:16 -0400, Sam Golob wrote: > the system doctor sometimes has to deal with >things that go wrong. > >The >doctor needs to have a scalpel. Most doctors don't often need to use >the scalpel. Sometimes the "doctor" isn't really a doctor, but a boy scout who may have learned some rudimentary first aid. And sometimes that thing that he thought was a scalpel is really a chain saw. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: How are Program Object sections with Defer attribute loaded?
>>Are they loaded into a specific subpool defined by MVS, or the >>loading piece of software responsible to do an appropriate >>STORAGE OBTAIN before using that internal interface? > > >Both are possible. The default system processing happens to use subpool 1 >(but the subpool number is not to be considered an interface). But the >exploiter can provide their own storage. Thank you, Sir Cheers, Peter -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Whacking a Job, or Getting rid of an Address Space
On Tue, 16 May 2017 07:59:56 -0400, Peter Relson wrote: >Maybe it's me, but I found this post kind of inappropriate since it came >without caveats. One might think/hope that whoever defined a space as >non-cancelale or non-memtermable had a legitimate reason for doing so. >That likely isn't of course always true, but isn't that what you really >need to assume? > I sense a gradual escalation here. Long ago, there was the CANCEL command so operators could terminate troublesome jobs. But a designer felt that sometimes the programmer knows better, and provided the non-cancellable attribute. Then a designer felt that sometimes the operator knows even better and provided the FORCE command. Then a designer felt that sometimes the programmer knows even better and provided the non-forcible attribute. Now someone feels that operators know better and is providing a WHACK facility. ... Perhaps there should be a numeric attribute and a CANCEL command argument, such that if the value supplied by the operator exceeds the program's attribute, the CANCEL just works. Floating point, of course. Decimal floating point. The operator will always have the nuclear option. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
We have a requirement to attach user modules from an unauthorised library and execute them from an STC which runs APF authorised. You need to reject that requirement. It cannot be accomplished while maintaining system integrity. Use of something like "fork" can perhaps accomplish the goal without meeting the letter of the requirement. Well, if you want to run unauthorized stuff you would first need to set your job as non-APF by resetting the bit. And if you do that, you must *never* turn the bit back on. Turning of JSCBAUTH is a fairly common approach, once the "authorized stuff" has been done. But you must then leave it off in order to maintain system integrity. In all likelihood you should NEVER use RSAPF=YES. It is provided so that the initiator can attach the jobstep program task. I have no idea why it was documented. Way back when, even internal things were documented. Maybe when internal-only things were being removed from the books, no one realized how internal this one was. The only z/OS-supported mechanism for authority-decreasing is SYNCH(X). And I do intentionally exclude authority-decreasing PC's (e.g., a PC that gets control in problem state when the invoker was supervisor state) from what is supported by z/OS. You can't be stopped from doing so, but things likely won't behave the way you need if there was a (E)SPIE present. There might be cases other than (E)SPIE that similarly would cause anomalous behavior. I have no idea if this is documented explicitly. It's just something I remember being told long long ago. 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. Whacking a Job, or Getting rid of an Address Space
Hi Folks, Of course, you're right, Peter. Jobs or STCs are marked NON-CANCELABLE for a very good reason. Under normal circumstances, they should not be cancelled, because it would endanger the system. That's what the PPT is for. Almost always, the safeguards that are there, are there for a very good reason. And I'm on management's side all the way. The idea is to keep the systems running as flawlessly and smoothly as possible. That having been said, the system doctor sometimes has to deal with things that go wrong. It's nice when the system is working as designed. But sometimes, the NON-CANCELABLE job or STC goes awry, and it has to be restarted. In such a case, as in the middle of a day's production, you want to avoid an emergency IPL. And so you need a tool in the toolbox, to cancel the job or STC. Sometimes the only solution is to blow it away. The expensive multi-utility packages all contain such tools. You wouldn't criticize Omegamon (TM) or RESOLVE (TM), would you? But a shop which can't afford to buy them is sometimes stuck, and is forced to IPL and lose a lot of production time. That's why I wrote CNCLPG 20 years after I had such an emergency, which I never forgot about. Systems programmers do not live in an ideal world. Problems come up, in running the data center, which can be very unforeseen. The doctor needs to have a scalpel. Most doctors don't often need to use the scalpel. But when you need it, and nothing else works, it's nice to know that it is there, sitting in the toolbox. This is where I come from. It's all for the purpose of keeping the shop running smoothly. Thanks for listening. All the best of everything to all of you. Sincerely,Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Effect of SET PROG=xx
Vernooij, Kees (ITOPT1) - KLM wrote: >Elardus Engelbrecht wrote: >> >This is the world's dumbest question if you're a sysprog but I'm a >> >developer with nearly zero sysprog experience. >> This is not a dumb question. Only wise people ask questions! ;-) >No, wise people are here to answer questions, fools to ask questions. Sometime >they ask questions that even 1000 wise men cannot answer. ;-) Hahahahahaha! Point taken Ok, but the wise persons have all the ANSWERS after they got them. Them fools who don't ask just stay SOL. For those questions where 1000 gurus can't answer at all - I have one simple answer. It is called 'middle finger'! ;-D Ok, time for a really serious joke: It is today my grand-grand-grandfather's birthday. I am very proud to say he manly and alone destroyed the whole german army communication system during world war one! What did he do? He ate the postal pigeon! To be sure those germans don't have a backup - he also ate snails - thus no snail mails for them too... ;-D Now returning back to my scheduled z/OS topics. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
>However, as you're running work on behalf of various end-users, I hope you're >authenticating those users and >running the work under the proper end-user >identity in each case. And that would probably require authorization >of the >STC. Yes, we run under the ACEE of the user. Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Effect of SET PROG=xx
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Elardus Engelbrecht > Sent: 16 May, 2017 15:15 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Effect of SET PROG=xx > > Charles Mills wrote: > > >This is the world's dumbest question if you're a sysprog but I'm a > developer with nearly zero sysprog experience. > > This is not a dumb question. Only wise people ask questions! ;-) > > No, wise people are here to answer questions, fools to ask questions. Sometime they ask questions that even 1000 wise men cannot answer. ;-) Kees. > Groete / Greetings > Elardus Engelbrecht > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
On Tue, 16 May 2017 14:09:49 +0700, Robin Atwood wrote: >Thanks to everyone for replying, I would never realised you had to flip >JSCBAUTH from the macro documentation. >The actual business requirement is that we run Rexx execs that call ISPF >services on behalf of workstation users >running an IDE. The STC doing this must run authorised because it >communicates with a comms task via cross-memory services. So we will have >control over what gets executed. This is still very much an experiment, I am >not sure it will actually work. Technically, for the communication you've described, only the comms task would have to run authorized. The STC could run unauthorized, using mechanisms setup by the authorized comms task. However, as you're running work on behalf of various end-users, I hope you're authenticating those users and running the work under the proper end-user identity in each case. And that would probably require authorization of the STC. It is a very tricky situation to manage properly and without introducing either system integrity or security issues. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Effect of SET PROG=xx
Charles Mills wrote: >This is the world's dumbest question if you're a sysprog but I'm a developer >with nearly zero sysprog experience. This is not a dumb question. Only wise people ask questions! ;-) >Whenever in the past that I have taken a quick look at SET PROG=(xx,yy) I >assumed that PROGxx + PROGyy in the parmlib concatenation *totally replaced* >the contents of whatever PROGaa and PROGbb had been specified in IEASYSxx at >IPL. Sort of 'replace', yes, but see my comments below. >But as I read the documentation now I get the impression instead that SET >PROG=(xx,yy) causes PROGxx and PROGyy to be processed essentially as scripts >each line of which incrementally modifies whatever is already in effect. True. >Is my latter impression more correct? Yes. Look at these two I did in the past: PROGXX: EXIT DELETE EXITNAME(SYS.IEFUTL) MODNAME(IEFUTL) LPA DELETE MODNAME(IEFUTL) FORCE(YES) CURRENT Later after assembling a new IEFUTL, I did this: PROGYY: LPA ADD MODNAME(IEFUTL) DSNAME(SYS??.LPALIB) EXIT ADD EXITNAME(SYS.IEFUTL) MODNAME(IEFUTL) STATE(ACTIVE) DSNAME(SYS??.LPALIB) >I'm more familiar with SET SMF=xx and that's how it works. SMFPRMxx does not >add to what came before; it replaces it. True. What I usually do is: I create a brand new SMFPRMxx. Modify the DSNAME or whatever (remove IEFUTL for example) and then do my SET SMF=xx. When finished, I issue my SET SMF=xx last used in IPL. All in all, I don't touch the *official* live PROGxx and SMFPRMxx members. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cyber attack
https://krebsonsecurity.com/2017/05/breach-at-docusign-led-to-targeted-email-malware-campaign/ Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Monday, May 15, 2017 4:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cyber attack I got one over the weekend with a name I don't recognize. Did not open or pursue because I was suspicious. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Beaver Sent: Monday, May 15, 2017 4:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Cyber attack I have been seen a lot of emails for what appears to be DocuSign and I have been killing them when I seen them -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How are Program Object sections with Defer attribute loaded?
Are they loaded into a specific subpool defined by MVS, or the loading piece of software responsible to do an appropriate STORAGE OBTAIN before using that internal interface? Both are possible. The default system processing happens to use subpool 1 (but the subpool number is not to be considered an interface). But the exploiter can provide their own storage. 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: Effect of SET PROG=xx
> only dumb developers I like you too, Tom. I thought we were friends. I did realize where I got this dumb idea from. I'm more familiar with SET SMF=xx and that's how it works. SMFPRMxx does not add to what came before; it replaces it. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Monday, May 15, 2017 5:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Effect of SET PROG=xx On 5/15/2017 7:25 PM, Charles Mills wrote: > This is the world's dumbest question if you're a sysprog but I'm a > developer with nearly zero sysprog experience. > > Whenever in the past that I have taken a quick look at SET > PROG=(xx,yy) I assumed that PROGxx + PROGyy in the parmlib > concatenation *totally replaced* the contents of whatever PROGaa and > PROGbb had been specified in IEASYSxx at IPL. > > But as I read the documentation now I get the impression instead that > SET > PROG=(xx,yy) causes PROGxx and PROGyy to be processed essentially as > scripts each line of which incrementally modifies whatever is already > in effect. In other words, if I entered SET PROG=ZZ and PROGZZ was > devoid of statements other than comments then the system would be left > unchanged, regardless of what had been in PROGaa and PROGbb at IPL. If > PROGZZ contained one APF ADD statement, then that DSN would get added > to the APF list, much as if I had entered SETPROG APF,ADD,DSN=...; and > every other system parameter would be left unchanged. > > Is my latter impression more correct? > There are no dumb questions, only dumb developers. ;-) SET PROG is additive, and yes, if you only have one line that is an APF ADD DSN, then it will add only that dataset. If you add and delete lines from your PROG00 member (assuming you start your system with that) which contains only APF ADD statements, then the ADDs will be added, but the ADD statements you removed will still be in APFLIST. To remove any datasets from APFLIST, you have to issue an explicit APF DEL with SET PROG, or SETPROG APF,DEL. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
> So we will have control over what gets executed As others have pointed out, you are exposing yourself to risks that you will have to manage. MVS would be willing to take on some of that management for you, but you are overriding that facility. You need to make absolutely sure of who has the ability to write into every single dataset used as a load or parameter or script library by every single thing called by your STC. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robin Atwood Sent: Tuesday, May 16, 2017 12:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH with RSAPF=YES Thanks to everyone for replying, I would never realised you had to flip JSCBAUTH from the macro documentation. The actual business requirement is that we run Rexx execs that call ISPF services on behalf of workstation users running an IDE. The STC doing this must run authorised because it communicates with a comms task via cross-memory services. So we will have control over what gets executed. This is still very much an experiment, I am not sure it will actually work. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Whacking a Job, or Getting rid of an Address Space
Maybe it's me, but I found this post kind of inappropriate since it came without caveats. One might think/hope that whoever defined a space as non-cancelale or non-memtermable had a legitimate reason for doing so. That likely isn't of course always true, but isn't that what you really need to assume? Unless you are willing to risk your system and its data by assuming that it is OK to cancel something that is non-cancelable or memterm something that is non-memtermable then the action taken by this tool is inappropriate. And by including "and its data" I mean to include that you could conceivably break some data that you won't be able to fix by re-IPL. Not likely, but conceivable. 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
Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables
Not a question, just some interesting stuff for the curious people :-) I have recently been asked to help analyze why a job was running very long and was using much CPU. Since all DB2 access paths were very efficient, we started an MA-Tune trace to see where the job was spending its time. MA-Tune reported that the job was spending almost 100% of its time at the following statement in module XYZ: MOVE ARG-CNT TO DISPLAY-ARG-CNT This did not make much sense, because that MOVE statement is not part of any loop construct. One would have expected that MA-Tune would see the job in other places as well. Since MA-Tune could not help, I have taken an SVC-Dump of the job the next time I was made aware it was not ending again. Analysis of the dump showed that the job was spending almost all time recovering from a program check 00A (decimal owerflow exception) . It was not obvious whether this was a recovery loop because of some error in the environment, i.e. Cobol runtime, Language Environment, or some restart product we're using, although neither of this seemed plausible. Further investigation finally showed that the problem arises because the target field in the above MOVE statement is not large enough to receive the source value once it grows above 9'999'999: The source and target fields are declared as follows: 01 ARG-CNTPIC 9(10) BINARY 01 DISPLAY-ARG-CNT PIC 9(07) Ignoring any overflow when the source count is greater than 9'999'999 might be intended from a programming point of view, but it may cause a dramatic performance degradation. The reason for the performance degradation lies in the following facts: · Firstly, Cobol wants to silently ignore a decimal overflow when it appears as part of a MOVE (and other) statement. · Secondly, the processor (hardware) supports two modes of operation regarding decimal overflow: It can either indicate an overflow by setting the condition code, or it can raise a program check hardware interruption of type 00A. While coding techniques such as in the example above did rarely hurt performance in Cobol up to version 4, it may more likely cause problems with Cobol V5.2 and above. The reason being that the Cobol compiler is making use of modern, better performing instructions on one hand, and the high likelihood that the processor is running in the mode where an overflow causes a hardware interruption to occur on the other hand. Every hardware interruption has to be handled by Language Environment's error recovery routines. This recovery code will interpret the interrupt, and in the case above comes to the conclusion that the decimal overflow is to be expected, and to be silently ignored. It will thus give control back to the interrupted program code. Why is this so bad from a performance perspective? The path length of the code involved from the time the operating system recognizes the program check hardware interruption until Language Environment returns control to the interrupted program is quite long by itself. In addition it depends on the system setup. Especially the size of the system trace table has a great influence in the elapsed time. This system has 4 (logical) CPs, 3 (logical) z IIPs, and a system trace table size of 15MiB per processor. It took between 0.05 and 0.15 seconds (yes, this is in seconds!) elapsed time to handle a single overflow. That time is spent mostly to create a snapshot of the 105 MiB (7*15MiB) system trace tables in anticipation of a dump request. At the time the dump was taken (I had been involved late), the source counter value was 10'181'270, i.e. an overflow exception had occurred for the last 181'271 times the above statement was executed. Ignoring any other delay this alone took some 181271 * 0.1s, i.e. some 5 hours of elapsed time. Regards Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Check out British computer expert who stopped ransomware says he's no hero -
_British computer expert who stopped ransomware says he's no hero - NY Daily News_ (http://www.nydailynews.com/news/world/british-computer-expert-stopped-ransomware-no-hero-article-1.3168684) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
Thanks to everyone for replying, I would never realised you had to flip JSCBAUTH from the macro documentation. The actual business requirement is that we run Rexx execs that call ISPF services on behalf of workstation users running an IDE. The STC doing this must run authorised because it communicates with a comms task via cross-memory services. So we will have control over what gets executed. This is still very much an experiment, I am not sure it will actually work. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: 15 May 2017 20:56 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH with RSAPF=YES Well, if you want to run unauthorized stuff you would first need to set your job as non-APF by resetting the bit. Of course, your authorized key8 storage will be subject to change by the unauthorized task, thus your authorized code must not use Key8 storage. (1) and (2) are not exclusive, as your authorized task would need to remain in supervisor state after resetting APF (assuming you still need APF services). If you no longer need APF services, simply reset APF do MODESET PROB and the garden variety ATTACH(X) Why do you want to run unauthorized code from this STC? What is the business case? On Mon, 15 May 2017 15:18:38 +0700 Robin Atwood wrote: :>We have a requirement to attach user modules from an unauthorised library :>and execute them from an STC which :> :>runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly what :>I want but every time I try it :> :>I get abend S306-0C, "authorised program attaching module from an :>unauthorized library". The ATTACH macro :> :>description states: :> :> :> :>RSAPF=YES when these conditions are met: :> :>. The caller is running in supervisor state, system key (0-7), :>or both :> :>. The caller is running non-APF authorized :> :>. The subtask is attached in the problem program state and with :>a nonsystem key. :> :> :> :>Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP :>and adding SM=PROB,KEY=PROP :> :>to the ATTACH but it made no difference. I seem to be missing something :>fairly massive here! Can anyone shed :> :>some light on this? :> :> :> :>Thanks :> :>Robin :> :> :>-- :>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
