Re: dataset allocation
Give us an idea of how big each file is. OPEN/CLOSE is expensive. QSAM with large buffers should go pretty quickly. LOCATE instead of MOVE mode can speed things up when you are reading. On a different note. I just compared EDIT macro performance versus IPOUPDTE. IPOUPDTE was about 600 times faster. On Wed, Oct 7, 2020 at 9:44 AM Farley, Peter x23353 < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > Joseph, > > I agree with Michael, if you are trying to do this in a TSO session, then > stop doing that. Run it as a batch job. > > It still may not get done very quickly, it is common for the initiators > that allow a programmer to run large CPU / large elapsed time batch jobs > also get bumped way down in the performance settings. That's a just fact > of life for programmers. > > If you can get away with it, try to get the batch job bumped up in > priority after it starts running, if you have any good friends in OPS. Or > you could try convincing your Capacity/Performance team that this really > needs to get done and you need the performance boost to get it done in > order to meet management's schedules. > > I would use the SORT utility at your shop as the main read/select process > if at all possible, even if it means setting up E15 and/or E35 exits > because the field selection or output re-formatting process needs more than > SORT control cards can provide. You may be surprised at how much SORT can > do for you though. > > As a POC, I personally I would set up the select-a-file-to-process logic > in Rexx and have Rexx invoke SORT to select the records I want extracted. > From my experience SORT has MUCH better I/O and record-selection and output > formatting performance than any other utility or custom program you can > name. > > If that POC works for 100 datasets but still takes too much time, then > re-code the select-a-file-to-process logic in COBOL (easier) or Assembler > (a little harder) or your favorite compiled language (maybe Metal C?) and > try that solution for 1000 files. > > Just saying how I would approach the problem. I too have to deal > regularly with very large VB files, so I do understand your predicament. > SORT is your friend for such files. > > If you are up to learning yet another language, the z/OS port of the > open-source lua scripting language is purported to be a pretty > high-performance tool. I don’t have any practical knowledge of it, just > reporting what I have read. > > HTH > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Michael Stein > Sent: Tuesday, October 6, 2020 6:15 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: dataset allocation > > EXTERNAL EMAIL > > On Tue, Oct 06, 2020 at 03:34:51PM -0400, Joseph Reichman wrote: > > Seemed like I processed 100 files concatenated a lot quicker > > > > But I didn’t do any exact testing you may be right > > I'd get or build a subroutine which captured the current real and cputime > (timeused macro?) and call it before/after each significant system call. > > This would include dynamic allocation, open, full file read, close, and > dealloc. > > Then look at how long real/cpu each took. > > You've said you have 4471 files, but not: > > How large each is, what type of device they are on (tape? disk? virt?) > > > Huge amounts of DASD > > 4,608 VB (huge) files > >How much is "huge". Given the size an estimate might be made >on the time to just read that amount of data... > > Is this a one time job or recurring every year, month, week, day? > > I'd suspect that if the delay is allocation/deallocation that they will > ENQ while processing and only allow one at a time if you try to do more > than one in a single address space. > > > Well this process is taking forever. I initially ran the program under > > TEST and it took 3 wall minutes to get to the 58th file > > That's about 19 files/minute so 4600 files is about 4 hours. Is this > really a problem? How long do you have? > > This might also depend on how your system performance is tuned to deal > with longer running TSO users (running as in not waiting for > the terminal). I remember TSO response tuning used to be (still is?) > set to give a wake up from terminal wait a quick response but if the TSO > session didn't go back to terminal wait push it's response down since it > didn't seem to be getting done. This helped maintain quick response for > the other users doing shorter running commands. A batch job might see > vastly different tuning/performance. > -- > > 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
Re: dataset allocation
Joseph, I agree with Michael, if you are trying to do this in a TSO session, then stop doing that. Run it as a batch job. It still may not get done very quickly, it is common for the initiators that allow a programmer to run large CPU / large elapsed time batch jobs also get bumped way down in the performance settings. That's a just fact of life for programmers. If you can get away with it, try to get the batch job bumped up in priority after it starts running, if you have any good friends in OPS. Or you could try convincing your Capacity/Performance team that this really needs to get done and you need the performance boost to get it done in order to meet management's schedules. I would use the SORT utility at your shop as the main read/select process if at all possible, even if it means setting up E15 and/or E35 exits because the field selection or output re-formatting process needs more than SORT control cards can provide. You may be surprised at how much SORT can do for you though. As a POC, I personally I would set up the select-a-file-to-process logic in Rexx and have Rexx invoke SORT to select the records I want extracted. From my experience SORT has MUCH better I/O and record-selection and output formatting performance than any other utility or custom program you can name. If that POC works for 100 datasets but still takes too much time, then re-code the select-a-file-to-process logic in COBOL (easier) or Assembler (a little harder) or your favorite compiled language (maybe Metal C?) and try that solution for 1000 files. Just saying how I would approach the problem. I too have to deal regularly with very large VB files, so I do understand your predicament. SORT is your friend for such files. If you are up to learning yet another language, the z/OS port of the open-source lua scripting language is purported to be a pretty high-performance tool. I don’t have any practical knowledge of it, just reporting what I have read. HTH Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Stein Sent: Tuesday, October 6, 2020 6:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: dataset allocation EXTERNAL EMAIL On Tue, Oct 06, 2020 at 03:34:51PM -0400, Joseph Reichman wrote: > Seemed like I processed 100 files concatenated a lot quicker > > But I didn’t do any exact testing you may be right I'd get or build a subroutine which captured the current real and cputime (timeused macro?) and call it before/after each significant system call. This would include dynamic allocation, open, full file read, close, and dealloc. Then look at how long real/cpu each took. You've said you have 4471 files, but not: How large each is, what type of device they are on (tape? disk? virt?) > Huge amounts of DASD > 4,608 VB (huge) files How much is "huge". Given the size an estimate might be made on the time to just read that amount of data... Is this a one time job or recurring every year, month, week, day? I'd suspect that if the delay is allocation/deallocation that they will ENQ while processing and only allow one at a time if you try to do more than one in a single address space. > Well this process is taking forever. I initially ran the program under > TEST and it took 3 wall minutes to get to the 58th file That's about 19 files/minute so 4600 files is about 4 hours. Is this really a problem? How long do you have? This might also depend on how your system performance is tuned to deal with longer running TSO users (running as in not waiting for the terminal). I remember TSO response tuning used to be (still is?) set to give a wake up from terminal wait a quick response but if the TSO session didn't go back to terminal wait push it's response down since it didn't seem to be getting done. This helped maintain quick response for the other users doing shorter running commands. A batch job might see vastly different tuning/performance. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dataset allocation
On Tue, Oct 06, 2020 at 03:34:51PM -0400, Joseph Reichman wrote: > Seemed like I processed 100 files concatenated a lot quicker > > But I didn’t do any exact testing you may be right I'd get or build a subroutine which captured the current real and cputime (timeused macro?) and call it before/after each significant system call. This would include dynamic allocation, open, full file read, close, and dealloc. Then look at how long real/cpu each took. You've said you have 4471 files, but not: How large each is, what type of device they are on (tape? disk? virt?) > Huge amounts of DASD > 4,608 VB (huge) files How much is "huge". Given the size an estimate might be made on the time to just read that amount of data... Is this a one time job or recurring every year, month, week, day? I'd suspect that if the delay is allocation/deallocation that they will ENQ while processing and only allow one at a time if you try to do more than one in a single address space. > Well this process is taking forever. I initially ran the program under > TEST and it took 3 wall minutes to get to the 58th file That's about 19 files/minute so 4600 files is about 4 hours. Is this really a problem? How long do you have? This might also depend on how your system performance is tuned to deal with longer running TSO users (running as in not waiting for the terminal). I remember TSO response tuning used to be (still is?) set to give a wake up from terminal wait a quick response but if the TSO session didn't go back to terminal wait push it's response down since it didn't seem to be getting done. This helped maintain quick response for the other users doing shorter running commands. A batch job might see vastly different tuning/performance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dataset allocation
Allocation takes time (everything does, of course) but you were allocating either way, right? OPEN takes time, and you are now doing 'n' OPENs rather than one -- but OPEN is not "slow" -- not as slow as it was once -- and with concatenation you are doing a "mini-OPEN" under the covers every time you move from dataset to dataset. You could try this approach for 10 and try the concatenation approach for the same 10 and benchmark the two. You could also do a combo of the two approaches: instead of concatenating all of them concatenate and process them 10 or 20 at a time. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joseph Reichman Sent: Tuesday, October 6, 2020 12:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: dataset allocation Seemed like I processed 100 files concatenated a lot quicker But I didn’t do any exact testing you may Be right > On Oct 6, 2020, at 3:30 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > On Tue, 6 Oct 2020 14:56:21 -0400, Joseph Reichman wrote: >> >> I posted a problem last week regarding allocating a concatenated dataset a >> few of you (Seymour,Paul Gilmartin) suggested that when processing the 4,608 >> VB (huge) files >> > (I believe Lizette offered a similar suggestion.) > >> That rather then concatenate them and when I reach the limit deco catenate >> them >> >> I just process on file at a time >> Alloc >> Open >>Read >>Close >> Unalloc >> >> Well this process is taking forever. I initially ran the program under TEST >> and it took 3 wall minutes to get to the 58th file >> > How does that compare to the time it takes to process the 58 concatenated? > Doesn't concatenation need the same 58 calls to DYNALLOC to allocate plus > one more to CONCAT? > > But concatenation might spare some OPEN/CLOSE/EOV overhead. > > Does TEST make a difference? > >> I am wondering whether BSAM with above the bar option would be worth the >> effort if it sped things up > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dataset allocation
Seemed like I processed 100 files concatenated a lot quicker But I didn’t do any exact testing you may Be right > On Oct 6, 2020, at 3:30 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > On Tue, 6 Oct 2020 14:56:21 -0400, Joseph Reichman wrote: >> >> I posted a problem last week regarding allocating a concatenated dataset a >> few of you (Seymour,Paul Gilmartin) suggested that when processing the 4,608 >> VB (huge) files >> > (I believe Lizette offered a similar suggestion.) > >> That rather then concatenate them and when I reach the limit deco catenate >> them >> >> I just process on file at a time >> Alloc >> Open >>Read >>Close >> Unalloc >> >> Well this process is taking forever. I initially ran the program under TEST >> and it took 3 wall minutes to get to the 58th file >> > How does that compare to the time it takes to process the 58 concatenated? > Doesn't concatenation need the same 58 calls to DYNALLOC to allocate plus > one more to CONCAT? > > But concatenation might spare some OPEN/CLOSE/EOV overhead. > > Does TEST make a difference? > >> I am wondering whether BSAM with above the bar option would be worth the >> effort if it sped things up > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dataset allocation
On Tue, 6 Oct 2020 14:56:21 -0400, Joseph Reichman wrote: > >I posted a problem last week regarding allocating a concatenated dataset a >few of you (Seymour,Paul Gilmartin) suggested that when processing the 4,608 >VB (huge) files > (I believe Lizette offered a similar suggestion.) >That rather then concatenate them and when I reach the limit deco catenate >them > >I just process on file at a time >Alloc > Open > Read > Close >Unalloc > >Well this process is taking forever. I initially ran the program under TEST >and it took 3 wall minutes to get to the 58th file > How does that compare to the time it takes to process the 58 concatenated? Doesn't concatenation need the same 58 calls to DYNALLOC to allocate plus one more to CONCAT? But concatenation might spare some OPEN/CLOSE/EOV overhead. Does TEST make a difference? >I am wondering whether BSAM with above the bar option would be worth the >effort if it sped things up -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dataset allocation
Thanks With the concatenation seemed to go a lot quicker I could be wrong > On Oct 6, 2020, at 3:19 PM, Charles Mills wrote: > > Try kicking up BUFNO. I think QSAM is generally about 98% as good as it > gets. I could be wrong. > > Reading a big pile of big files is going to take some time no matter what > you do. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Joseph Reichman > Sent: Tuesday, October 6, 2020 11:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: dataset allocation > > Hi > > > > I posted a problem last week regarding allocating a concatenated dataset a > few of you (Seymour,Paul Gilmartin) suggested that when processing the 4,608 > VB (huge) files > > > > That rather then concatenate them and when I reach the limit deco catenate > them > > I just process on file at a time > > > > Alloc > > Open > > Read > > Close > > Unalloc > > > > Well this process is taking forever. I initially ran the program under TEST > and it took 3 wall minutes to get to the 58th file > > > > I am wondering whether BSAM with above the bar option would be worth the > effort if it sped things up > > > > Thanks > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: 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: dataset allocation
Try kicking up BUFNO. I think QSAM is generally about 98% as good as it gets. I could be wrong. Reading a big pile of big files is going to take some time no matter what you do. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joseph Reichman Sent: Tuesday, October 6, 2020 11:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: dataset allocation Hi I posted a problem last week regarding allocating a concatenated dataset a few of you (Seymour,Paul Gilmartin) suggested that when processing the 4,608 VB (huge) files That rather then concatenate them and when I reach the limit deco catenate them I just process on file at a time Alloc Open Read Close Unalloc Well this process is taking forever. I initially ran the program under TEST and it took 3 wall minutes to get to the 58th file I am wondering whether BSAM with above the bar option would be worth the effort if it sped things up Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: IEASYS problem
It is the last one processed that takes precedence. Each one is processed from left to right with each parameter over riding the previous specification. On my system I specify (00,HW,H8). Note IEASYS00 is the first one processed. Matthew On Tue, 6 Oct 2020 11:32:34 +, Allan Staller wrote: >Classification: > >The Init/Tuning ref is quite specif c in the order of precedence between SYS00 >and SYSxx. >Remember, there may be more than one SYSxx. (e.g. SYSPARM=(aa,bb,cc,00) >specified in LOADxx, >I don't remember if it is the 1st hit or last hit that wins. > >In either case, is possible to "functionally replace" IEASYS00 with other >members. > >HTH, > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DAE Dataset - Compression
On Tue, 6 Oct 2020 09:31:26 -0700, Lizette Koehler wrote: >If you fix the issue, and the DAE entry is still in place, you might not see >if there is an issue. > >So as always, it depends. > >By removing the entry in DAE it might show if you actually fixed it > >Lizette > > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Jousma, David >Sent: Tuesday, October 6, 2020 9:12 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: DAE Dataset - Compression > >I guess I don’t agree with that Lizette? I mean we can agree to disagree, >there are many ways to run our environments, but clearing out DAE will just >retrigger DUMPs for repetitive issues all over again? It may be old >technology, but it works! 1400+ unique entries in our 20% utilized dae >allocated at 45 trks. Usually it’s the DB2 sysprogs that come to me to >re-enable a certain dump that’s being suppressed. > >Now, clearing out the sysplex dump directory regularly is something I agree >with. > >- DAE Display - > Row 1 to 14 of 1,437 >Command ===> Scroll ===> CSR > Enter an Action Code next to an entry. > Enter / next to an entry to choose from a list of Action Codes. > > Dataset: 'SYS2.SYSPLEX.DAE' > Dumps since last DAE Display: 215 Total Dumps suppressed: 163672 > Events since last DAE Display: 110606 Suppression rate: 94% > Have a look in "hlq.SBLSCLI0(ADYUPDAT)" and you can possibly use that to manage DAE as one of the options is CLEANUP and with that you can specify that entries older than so many days are deleted - no need to compress DAE. Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
dataset allocation
Hi I posted a problem last week regarding allocating a concatenated dataset a few of you (Seymour,Paul Gilmartin) suggested that when processing the 4,608 VB (huge) files That rather then concatenate them and when I reach the limit deco catenate them I just process on file at a time Alloc Open Read Close Unalloc Well this process is taking forever. I initially ran the program under TEST and it took 3 wall minutes to get to the 58th file I am wondering whether BSAM with above the bar option would be worth the effort if it sped things up Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DAE Dataset - Compression
If you fix the issue, and the DAE entry is still in place, you might not see if there is an issue. So as always, it depends. By removing the entry in DAE it might show if you actually fixed it Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: Tuesday, October 6, 2020 9:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DAE Dataset - Compression I guess I don’t agree with that Lizette? I mean we can agree to disagree, there are many ways to run our environments, but clearing out DAE will just retrigger DUMPs for repetitive issues all over again? It may be old technology, but it works! 1400+ unique entries in our 20% utilized dae allocated at 45 trks. Usually it’s the DB2 sysprogs that come to me to re-enable a certain dump that’s being suppressed. Now, clearing out the sysplex dump directory regularly is something I agree with. - DAE Display - Row 1 to 14 of 1,437 Command ===> Scroll ===> CSR Enter an Action Code next to an entry. Enter / next to an entry to choose from a list of Action Codes. Dataset: 'SYS2.SYSPLEX.DAE' Dumps since last DAE Display: 215 Total Dumps suppressed: 163672 Events since last DAE Display: 110606 Suppression rate: 94% _ Dave Jousma AVP | Director, Technology 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 Lizette Koehler Sent: Tuesday, October 6, 2020 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DAE Dataset - Compression **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I have not read this whole thread, so I apologize if I cover the same ground DAE dataset is very old technology. It is a sequential file and I am not sure you can make it compressed. That could be an RFS Second - shutting down DAE like you did - is the correct process There is no reason to keep everything in DAE unless you want to Every time we put in a new z/OS OS. I clear out completely the DAE dataset. Depending on how active your system is for abends, you might just want to make it bigger. You might need to put a process in place to clear it out weekly or daily or other Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Tuesday, October 6, 2020 7:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DAE Dataset - Compression Before I open up a ticket with IBM I wanted to ask if the DAE dataset can be allocated as compressed? I tried to migrate our shared DAE dataset to a newly allocated one that with compression enabled. It didn't go well. One SVCDUMP we received was this; COMPID=SC143,ISSUER=ADYTRNS FAILURE IN THE TRANSACTION PROCESSOR FOR DAE Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://protect2.fireeye.com/url?k=966eb008-ca324407-966e9a90-0cc47a33347c-21744e3782d3f911=https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **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: DAE Dataset - Compression
I guess I don’t agree with that Lizette? I mean we can agree to disagree, there are many ways to run our environments, but clearing out DAE will just retrigger DUMPs for repetitive issues all over again? It may be old technology, but it works! 1400+ unique entries in our 20% utilized dae allocated at 45 trks. Usually it’s the DB2 sysprogs that come to me to re-enable a certain dump that’s being suppressed. Now, clearing out the sysplex dump directory regularly is something I agree with. - DAE Display - Row 1 to 14 of 1,437 Command ===> Scroll ===> CSR Enter an Action Code next to an entry. Enter / next to an entry to choose from a list of Action Codes. Dataset: 'SYS2.SYSPLEX.DAE' Dumps since last DAE Display: 215 Total Dumps suppressed: 163672 Events since last DAE Display: 110606 Suppression rate: 94% _ Dave Jousma AVP | Director, Technology 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 Lizette Koehler Sent: Tuesday, October 6, 2020 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DAE Dataset - Compression **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I have not read this whole thread, so I apologize if I cover the same ground DAE dataset is very old technology. It is a sequential file and I am not sure you can make it compressed. That could be an RFS Second - shutting down DAE like you did - is the correct process There is no reason to keep everything in DAE unless you want to Every time we put in a new z/OS OS. I clear out completely the DAE dataset. Depending on how active your system is for abends, you might just want to make it bigger. You might need to put a process in place to clear it out weekly or daily or other Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Tuesday, October 6, 2020 7:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DAE Dataset - Compression Before I open up a ticket with IBM I wanted to ask if the DAE dataset can be allocated as compressed? I tried to migrate our shared DAE dataset to a newly allocated one that with compression enabled. It didn't go well. One SVCDUMP we received was this; COMPID=SC143,ISSUER=ADYTRNS FAILURE IN THE TRANSACTION PROCESSOR FOR DAE Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://protect2.fireeye.com/url?k=966eb008-ca324407-966e9a90-0cc47a33347c-21744e3782d3f911=https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **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: DAE Dataset - Compression
I have not read this whole thread, so I apologize if I cover the same ground DAE dataset is very old technology. It is a sequential file and I am not sure you can make it compressed. That could be an RFS Second - shutting down DAE like you did - is the correct process There is no reason to keep everything in DAE unless you want to Every time we put in a new z/OS OS. I clear out completely the DAE dataset. Depending on how active your system is for abends, you might just want to make it bigger. You might need to put a process in place to clear it out weekly or daily or other Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Tuesday, October 6, 2020 7:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DAE Dataset - Compression Before I open up a ticket with IBM I wanted to ask if the DAE dataset can be allocated as compressed? I tried to migrate our shared DAE dataset to a newly allocated one that with compression enabled. It didn't go well. One SVCDUMP we received was this; COMPID=SC143,ISSUER=ADYTRNS FAILURE IN THE TRANSACTION PROCESSOR FOR DAE Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DAE Dataset - Compression
DAE uses QSAM - the DCB is DAEDCB DCB MACRF=(GL,PM),DSORG=PS,RECFM=FB,LRECL=255,EROPT=ACC I don't know offhand of anything that would preclude using compressed data set for DAE. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 10/06/2020 10:11:28 AM: > From: "Tom Conley" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 10/06/2020 11:49 AM > Subject: Re: DAE Dataset - Compression > Sent by: "IBM Mainframe Discussion List" > > On 10/6/2020 10:06 AM, Mark Jacobs wrote: > > Before I open up a ticket with IBM I wanted to ask if the DAE > dataset can be allocated as compressed? I tried to migrate our > shared DAE dataset to a newly allocated one that with compression > enabled. It didn't go well. One SVCDUMP we received was this; > COMPID=SC143,ISSUER=ADYTRNS FAILURE IN THE TRANSACTION PROCESSOR FOR DAE > > > > Mark Jacobs > > Best guess is that datasets like DAE, LOGREC, etc. are so early in the > IPL that we don't have niceties like compression, extended format, etc. > DFSMS comes up way later. > > Regards, > Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to Refresh System REXX Libraries
I tried to look at that RFE so I could vote for it but was told I wasn't authorized ☹ Lionel B. Dyck < Website: https://www.lbdsoftware.com "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Harris Morgenstern Sent: Tuesday, October 6, 2020 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to Refresh System REXX Libraries To refresh the System REXX libraries, you'll need to stop System REXX, update AXRxx parmlib members and restart it. There is an open RFE against System REXX (#49562) to address this issue (Dynamic Reconfiguration of System REXX). Harris Morgenstern z/OS Storage Management and System REXX Dept. OBPA IBM Poughkeepsie 8-295-4221 hmor...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DAE Dataset - Compression
Point noted. Thanks. 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, October 6th, 2020 at 10:37 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > I guess my point was why even bother with dataset compression, even if it was > 100 cylinders. > > Dave Jousma > > AVP | Director, Technology 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Mark Jacobs > > Sent: Tuesday, October 6, 2020 10:33 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: DAE Dataset - Compression > > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or unexpected > emails > > The old one is 6 cylinders in size and is 100% full. We're a software > development organization so we tend to get more software errors than average. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://protect2.fireeye.com/url?k=ce974af8-92cbbef7-ce976060-0cc47a33347c-36a40ccc297901ee=https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > > On Tuesday, October 6th, 2020 at 10:23 AM, Jousma, David > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu wrote: > > > How big is your DAE dataset? We've got sysplex shared DAE, and it’s a > > whopping 45 tracks, and only 20% utilized. > > > > Dave Jousma > > > > AVP | Director, Technology 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf > > > > Of Mark Jacobs > > > > Sent: Tuesday, October 6, 2020 10:18 AM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Re: DAE Dataset - Compression > > > > CAUTION EXTERNAL EMAIL > > > > DO NOT open attachments or click on links from unknown senders or > > > > unexpected emails > > > > I issued a T DAE=01 to stop it across the sysplex, renamed the DAE datasets > > and then restarted DAE, T DAE=00. > > > > Mark Jacobs > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > GPG Public Key - > > > > https://protect2.fireeye.com/url?k=4525b7cf-197943c0-45259d57-0cc47a33 > > > > 347c-95a8c88408bcde43=https://api.protonmail.ch/pks/lookup?op=get > > > > arch=markjac...@protonmail.com > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Tuesday, October 6th, 2020 at 10:11 AM, Tom Conley > > pinnc...@rochester.rr.com wrote: > > > > > On 10/6/2020 10:06 AM, Mark Jacobs wrote: > > > > > > > Before I open up a ticket with IBM I wanted to ask if the DAE > > > > > > > > dataset can be allocated as compressed? I tried to migrate our > > > > > > > > shared DAE dataset to a newly allocated one that with compression > > > > > > > > enabled. It didn't go well. One SVCDUMP we received was this; > > > > > > > > COMPID=SC143,ISSUER=ADYTRNS FAILURE IN THE TRANSACTION PROCESSOR > > > > > > > > FOR > > > > > > > > DAE > > > > > > > > Mark Jacobs > > > > > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > > > > > GPG Public Key - > > > > > > > > https://protect2.fireeye.com/url?k=cd3d2e11-9161da1e-cd3d0489-0cc4 > > > > > > > > 7a > > > > > > > > 33347c-234b18a82a4f8b6a=https://protect2.fireeye.com/url?k=c29c4 > > > > > > > > 73d-9ec0b332-c29c6da5-0cc47a33347c-385b633fe089787d=https://api. > > > > > > > > protonmail.ch/pks/lookup?op=ge > > > > > > > > t=markjac...@protonmail.com > > > > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > > > > > send email to lists...@listserv.ua.edu with the message: INFO > > > > > > > > IBM-MAIN > > > > > > Best guess is that datasets like DAE, LOGREC, etc. are so early in > > > > > > the > > > > > > IPL that we don't have niceties like compression, extended format, etc. > > > > > > DFSMS comes up way later. > > > > > > Regards, > > > > > > Tom Conley > > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > > > send email to lists...@listserv.ua.edu with the message: INFO > > > > > > IBM-MAIN > > > > 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
Re: DAE Dataset - Compression
I guess my point was why even bother with dataset compression, even if it was 100 cylinders. _ Dave Jousma AVP | Director, Technology 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 Mark Jacobs Sent: Tuesday, October 6, 2020 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DAE Dataset - Compression **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** The old one is 6 cylinders in size and is 100% full. We're a software development organization so we tend to get more software errors than average. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://protect2.fireeye.com/url?k=ce974af8-92cbbef7-ce976060-0cc47a33347c-36a40ccc297901ee=https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Tuesday, October 6th, 2020 at 10:23 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > How big is your DAE dataset? We've got sysplex shared DAE, and it’s a > whopping 45 tracks, and only 20% utilized. > > Dave Jousma > > AVP | Director, Technology 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Mark Jacobs > > Sent: Tuesday, October 6, 2020 10:18 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: DAE Dataset - Compression > > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or > unexpected emails > > I issued a T DAE=01 to stop it across the sysplex, renamed the DAE datasets > and then restarted DAE, T DAE=00. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://protect2.fireeye.com/url?k=4525b7cf-197943c0-45259d57-0cc47a33 > 347c-95a8c88408bcde43=https://api.protonmail.ch/pks/lookup?op=get > arch=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > > On Tuesday, October 6th, 2020 at 10:11 AM, Tom Conley > pinnc...@rochester.rr.com wrote: > > > On 10/6/2020 10:06 AM, Mark Jacobs wrote: > > > > > Before I open up a ticket with IBM I wanted to ask if the DAE > > > > > > dataset can be allocated as compressed? I tried to migrate our > > > > > > shared DAE dataset to a newly allocated one that with compression > > > > > > enabled. It didn't go well. One SVCDUMP we received was this; > > > > > > COMPID=SC143,ISSUER=ADYTRNS FAILURE IN THE TRANSACTION PROCESSOR > > > FOR > > > > > > DAE > > > > > > Mark Jacobs > > > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > > > GPG Public Key - > > > > > > https://protect2.fireeye.com/url?k=cd3d2e11-9161da1e-cd3d0489-0cc4 > > > 7a > > > > > > 33347c-234b18a82a4f8b6a=https://protect2.fireeye.com/url?k=c29c4 > > > 73d-9ec0b332-c29c6da5-0cc47a33347c-385b633fe089787d=https://api. > > > protonmail.ch/pks/lookup?op=ge > > > > > > t=markjac...@protonmail.com > > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > > > send email to lists...@listserv.ua.edu with the message: INFO > > > > > > IBM-MAIN > > > > Best guess is that datasets like DAE, LOGREC, etc. are so early in > > the > > > > IPL that we don't have niceties like compression, extended format, etc. > > > > DFSMS comes up way later. > > > > Regards, > > > > Tom Conley > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > 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. > > > -- > -- > -- >
Re: DAE Dataset - Compression
The old one is 6 cylinders in size and is 100% full. We're a software development organization so we tend to get more software errors than average. 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, October 6th, 2020 at 10:23 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > How big is your DAE dataset? We've got sysplex shared DAE, and it’s a > whopping 45 tracks, and only 20% utilized. > > Dave Jousma > > AVP | Director, Technology 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Mark Jacobs > > Sent: Tuesday, October 6, 2020 10:18 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: DAE Dataset - Compression > > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or unexpected > emails > > I issued a T DAE=01 to stop it across the sysplex, renamed the DAE datasets > and then restarted DAE, T DAE=00. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://protect2.fireeye.com/url?k=4525b7cf-197943c0-45259d57-0cc47a33347c-95a8c88408bcde43=https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > > On Tuesday, October 6th, 2020 at 10:11 AM, Tom Conley > pinnc...@rochester.rr.com wrote: > > > On 10/6/2020 10:06 AM, Mark Jacobs wrote: > > > > > Before I open up a ticket with IBM I wanted to ask if the DAE > > > > > > dataset can be allocated as compressed? I tried to migrate our > > > > > > shared DAE dataset to a newly allocated one that with compression > > > > > > enabled. It didn't go well. One SVCDUMP we received was this; > > > > > > COMPID=SC143,ISSUER=ADYTRNS FAILURE IN THE TRANSACTION PROCESSOR FOR > > > > > > DAE > > > > > > Mark Jacobs > > > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > > > GPG Public Key - > > > > > > https://protect2.fireeye.com/url?k=cd3d2e11-9161da1e-cd3d0489-0cc47a > > > > > > 33347c-234b18a82a4f8b6a=https://api.protonmail.ch/pks/lookup?op=ge > > > > > > t=markjac...@protonmail.com > > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > > > send email to lists...@listserv.ua.edu with the message: INFO > > > > > > IBM-MAIN > > > > Best guess is that datasets like DAE, LOGREC, etc. are so early in the > > > > IPL that we don't have niceties like compression, extended format, etc. > > > > DFSMS comes up way later. > > > > Regards, > > > > Tom Conley > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > 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
Re: DAE Dataset - Compression
How big is your DAE dataset? We've got sysplex shared DAE, and it’s a whopping 45 tracks, and only 20% utilized. _ Dave Jousma AVP | Director, Technology 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 Mark Jacobs Sent: Tuesday, October 6, 2020 10:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DAE Dataset - Compression **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I issued a T DAE=01 to stop it across the sysplex, renamed the DAE datasets and then restarted DAE, T DAE=00. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://protect2.fireeye.com/url?k=4525b7cf-197943c0-45259d57-0cc47a33347c-95a8c88408bcde43=https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Tuesday, October 6th, 2020 at 10:11 AM, Tom Conley wrote: > On 10/6/2020 10:06 AM, Mark Jacobs wrote: > > > Before I open up a ticket with IBM I wanted to ask if the DAE > > dataset can be allocated as compressed? I tried to migrate our > > shared DAE dataset to a newly allocated one that with compression > > enabled. It didn't go well. One SVCDUMP we received was this; > > COMPID=SC143,ISSUER=ADYTRNS FAILURE IN THE TRANSACTION PROCESSOR FOR > > DAE > > > > Mark Jacobs > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > GPG Public Key - > > https://protect2.fireeye.com/url?k=cd3d2e11-9161da1e-cd3d0489-0cc47a > > 33347c-234b18a82a4f8b6a=https://api.protonmail.ch/pks/lookup?op=ge > > t=markjac...@protonmail.com > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > Best guess is that datasets like DAE, LOGREC, etc. are so early in the > > IPL that we don't have niceties like compression, extended format, etc. > > DFSMS comes up way later. > > Regards, > > Tom Conley > > -- > -- > --- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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: DAE Dataset - Compression
I issued a T DAE=01 to stop it across the sysplex, renamed the DAE datasets and then restarted DAE, T DAE=00. 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, October 6th, 2020 at 10:11 AM, Tom Conley wrote: > On 10/6/2020 10:06 AM, Mark Jacobs wrote: > > > Before I open up a ticket with IBM I wanted to ask if the DAE dataset can > > be allocated as compressed? I tried to migrate our shared DAE dataset to a > > newly allocated one that with compression enabled. It didn't go well. One > > SVCDUMP we received was this; COMPID=SC143,ISSUER=ADYTRNS FAILURE IN THE > > TRANSACTION PROCESSOR FOR DAE > > > > Mark Jacobs > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > Best guess is that datasets like DAE, LOGREC, etc. are so early in the > > IPL that we don't have niceties like compression, extended format, etc. > > DFSMS comes up way later. > > Regards, > > Tom Conley > > --- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: 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: DAE Dataset - Compression
On 10/6/2020 10:06 AM, Mark Jacobs wrote: Before I open up a ticket with IBM I wanted to ask if the DAE dataset can be allocated as compressed? I tried to migrate our shared DAE dataset to a newly allocated one that with compression enabled. It didn't go well. One SVCDUMP we received was this; COMPID=SC143,ISSUER=ADYTRNS FAILURE IN THE TRANSACTION PROCESSOR FOR DAE Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Best guess is that datasets like DAE, LOGREC, etc. are so early in the IPL that we don't have niceties like compression, extended format, etc. DFSMS comes up way later. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DAE Dataset - Compression
Before I open up a ticket with IBM I wanted to ask if the DAE dataset can be allocated as compressed? I tried to migrate our shared DAE dataset to a newly allocated one that with compression enabled. It didn't go well. One SVCDUMP we received was this; COMPID=SC143,ISSUER=ADYTRNS FAILURE IN THE TRANSACTION PROCESSOR FOR DAE Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How to Refresh System REXX Libraries
To refresh the System REXX libraries, you'll need to stop System REXX, update AXRxx parmlib members and restart it. There is an open RFE against System REXX (#49562) to address this issue (Dynamic Reconfiguration of System REXX). Harris Morgenstern z/OS Storage Management and System REXX Dept. OBPA IBM Poughkeepsie 8-295-4221 hmor...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEASYS problem
Classification: Agreed! -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Tuesday, October 6, 2020 7:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEASYS problem [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] W dniu 06.10.2020 o 13:39, Barbara Nitz pisze: >> In either case, is possible to "functionally replace" IEASYS00 with other >> members. > We have ieasys00 in our regular parmlib, overriding the IBM delivered one. > All our ieasys00 contains is CLPA, meaning that we always IPL with CLPA. All > the rest of the parms are in sysplex-/system-specific ieasys-members. So the > requirement to read ieasys00 is fulfilled and we can start our system(s) the > way we like. I have no member duplicates. All "IBM supplied" members do reside in "PARMLIB.ARCH" libraries which are out of PARMLIB concatenation. Just for reference. So whenever I see MEMBER00 I have no chance to view/edit wrong duplicate with same name but different content. In this case I have one IEASYS00. Usually I don't need another one, but in rare cases I simply create copy IEASYS00 (with different suffix) and use it. And some comment inside to describe who, when, what and why. And that copy is still concatenated with IEASYS00, but all the content is overriden by the copy. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mbank.pl%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7C4c5786be5aa044fa1e8408d869f1ee54%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637375835605091501sdata=RmjZWIO3azQyo5lBXgAovGCDTvBMvf3fPTdm%2FyI9r%2Fc%3Dreserved=0, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mbank.pl%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7C4c5786be5aa044fa1e8408d869f1ee54%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637375835605101493sdata=%2FvLDiq1IBb4bXhbhGfXqbBWxrrsars3s1WqGhzcCmCE%3Dreserved=0, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- 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
Re: IEASYS problem
>Try ieasynck from sys1.samplib I don't know of such a member. 'sys1.samplib(SPPINST)' installs a tool for which the front exec is SYSPARM. It has two main purposes -- help you to build a syntactically correct LOADxx and let you view what your parmlib members would look like with the identified set of system symbols. It does syntax-check GRSRNLxx. FWIW, some parmlib members support the syntax-check option of the SET command. For example SET PROG=(XX,C) 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: IEASYS problem
W dniu 06.10.2020 o 13:39, Barbara Nitz pisze: In either case, is possible to "functionally replace" IEASYS00 with other members. We have ieasys00 in our regular parmlib, overriding the IBM delivered one. All our ieasys00 contains is CLPA, meaning that we always IPL with CLPA. All the rest of the parms are in sysplex-/system-specific ieasys-members. So the requirement to read ieasys00 is fulfilled and we can start our system(s) the way we like. I have no member duplicates. All "IBM supplied" members do reside in "PARMLIB.ARCH" libraries which are out of PARMLIB concatenation. Just for reference. So whenever I see MEMBER00 I have no chance to view/edit wrong duplicate with same name but different content. In this case I have one IEASYS00. Usually I don't need another one, but in rare cases I simply create copy IEASYS00 (with different suffix) and use it. And some comment inside to describe who, when, what and why. And that copy is still concatenated with IEASYS00, but all the content is overriden by the copy. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEASYS problem
You want something unnecessary and impossible. IEASYS00 has to be read. But... Why do you want 0B member? a) you always choose 0B => just rename it to 00. b) you want to have a choice (0B, AA, 04, 0C...) In this case ...you have further choice: b.1) you may create empty or "almost empty" IEASYS00. Just put there something irrelevant, but syntactically correct. b.2) simply leave IEASYS00 as it is and put YOUR SETTINGS in IEASYS0B. In case of conflict 0B wins, so 00 definitions would remain ineffective. b.3) leave IEASYS00, but leave only those options which are not present in your 0B member and other members (04, 0C...). Just for simplicity. HTH -- Radoslaw Skorupka Lodz, Poland W dniu 06.10.2020 o 13:29, Gadi Ben-Avi pisze: I tried that. It complained, and the IPL stoped. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Tuesday, October 6, 2020 2:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEASYS problem Classification: Yo could try having no IEASYS00 in the parmlib concat -Original Message- From: IBM Mainframe Discussion List On Behalf Of Attila Fogarasi Sent: Monday, October 5, 2020 11:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEASYS problem [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] You cannot, 00 is always used as the base, you can only concatenate over-rides to it. LOADxx and IEASYMxx will concatenate to 00, and WTOR response will over-ride LOADxx and IEASYMxx -- but I know of no way to eliminate 00 as a base. Normally 0B would have all the needed over-ride values for 00 making it effectively the same as "only 0B" :) On Tue, Oct 6, 2020 at 3:18 PM Gadi Ben-Avi wrote: HI, The output from D IPLINFO,SYSP is IEE255I SYSTEM PARAMETER 'SYSP': (0B,00) I would like it to be only 0B Gadi -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Sunday, October 4, 2020 4:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEASYS problem What does DISPLAY IPLINFO,SYSP show? Peter Relson z/OS Core Technology Design == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEASYS problem
>In either case, is possible to "functionally replace" IEASYS00 with other >members. We have ieasys00 in our regular parmlib, overriding the IBM delivered one. All our ieasys00 contains is CLPA, meaning that we always IPL with CLPA. All the rest of the parms are in sysplex-/system-specific ieasys-members. So the requirement to read ieasys00 is fulfilled and we can start our system(s) the way we like. Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEASYS problem
Classification: The Init/Tuning ref is quite specific in the order of precedence between SYS00 and SYSxx. Remember, there may be more than one SYSxx. (e.g. SYSPARM=(aa,bb,cc,00) specified in LOADxx, I don't remember if it is the 1st hit or last hit that wins. In either case, is possible to "functionally replace" IEASYS00 with other members. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gadi Ben-Avi Sent: Monday, October 5, 2020 11:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEASYS problem [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Hi, During the IPL, The message: IEA008I SYSTEM PARMS FOLLOW FOR z/OS 02.03.00 HBB77B0 IEASYS0B IEASYS00 Was displayed. I then see IEE252I MEMBER IEASYS00 FOUND IN SYS1.PARMLIB IEA325I IEASYS00 PARAMETER LIST With a list of all of the parameters is IEASYS00 IEE252I MEMBER IEASYS0B FOUND IN SYS1.PARMLIB IEA325I IEASYS0B PARAMETER LIST With a list of all of the parameters is IEASYS0B IEE252I MEMBER IEASYS00 FOUND IN SYS1.PARMLIB IEA325I IEASYS00 PARAMETER LIST With a list of all of the parameters is IEASYS00 So it looks like IEASYS00 was read twice. When I looked in IEASYM00 it said: SYSDEF SYSPARM(00,L) SYMDEF(='V919') I changed IEASYM00 to: SYSDEF LPARNAME(CDVL) SYSPARM(0A,L) SYMDEF(='V919') SYSDEF LPARNAME(CMP1) SYSPARM(0B,L) SYMDEF(='V919') Which I hope will fix the problem. We have a product called Image Focus from NewEra Software, which among other things, parses the PARMLIB. It currently tells me that everything is OK. I'll have to wait for the next IPL to check. Gadi -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Monday, October 5, 2020 6:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEASYS problem SYS1.SAMPLIB(SPPINST) Is the member that provides code to install the SYSPARM dialog. . . 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 Roger Lowe Sent: Monday, October 5, 2020 5:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IEASYS problem CAUTION EXTERNAL EMAIL On Sun, 4 Oct 2020 23:53:18 -0500, Brian Westerman wrote: >I don't have a sysparm member in sys1.samplib, is it from an older release >than 2.3? > >Brian > Have a look in SAMPLIB for the "SPP*" members . Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for 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: IEASYS problem
I tried that. It complained, and the IPL stoped. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Tuesday, October 6, 2020 2:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEASYS problem Classification: Yo could try having no IEASYS00 in the parmlib concat -Original Message- From: IBM Mainframe Discussion List On Behalf Of Attila Fogarasi Sent: Monday, October 5, 2020 11:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEASYS problem [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] You cannot, 00 is always used as the base, you can only concatenate over-rides to it. LOADxx and IEASYMxx will concatenate to 00, and WTOR response will over-ride LOADxx and IEASYMxx -- but I know of no way to eliminate 00 as a base. Normally 0B would have all the needed over-ride values for 00 making it effectively the same as "only 0B" :) On Tue, Oct 6, 2020 at 3:18 PM Gadi Ben-Avi wrote: > HI, > The output from D IPLINFO,SYSP is > IEE255I SYSTEM PARAMETER 'SYSP': (0B,00) I would like it to be only 0B > > Gadi > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Peter Relson > Sent: Sunday, October 4, 2020 4:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IEASYS problem > > What does DISPLAY IPLINFO,SYSP show? > > 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEASYS problem
Classification: Yo could try having no IEASYS00 in the parmlib concat -Original Message- From: IBM Mainframe Discussion List On Behalf Of Attila Fogarasi Sent: Monday, October 5, 2020 11:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEASYS problem [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] You cannot, 00 is always used as the base, you can only concatenate over-rides to it. LOADxx and IEASYMxx will concatenate to 00, and WTOR response will over-ride LOADxx and IEASYMxx -- but I know of no way to eliminate 00 as a base. Normally 0B would have all the needed over-ride values for 00 making it effectively the same as "only 0B" :) On Tue, Oct 6, 2020 at 3:18 PM Gadi Ben-Avi wrote: > HI, > The output from D IPLINFO,SYSP is > IEE255I SYSTEM PARAMETER 'SYSP': (0B,00) I would like it to be only 0B > > Gadi > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Peter Relson > Sent: Sunday, October 4, 2020 4:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IEASYS problem > > What does DISPLAY IPLINFO,SYSP show? > > 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for 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
