Re: CTC conventions
On 10/17/2018 6:44 PM, Jesse 1 Robinson wrote: In hindsight I rue the decision to set aside both 4xxx and 5xxx addresses. In practice, the low order digit is severely underused. In the beginning I thought that we would need several different 'devices' for each LPAR. Never actually found a need for more than four, 0 - 3. I like Rob Jackson's idea of assigning even/odd numbers for gazinta and gazouta, or ranges like 0 - 7 and 8 - F. Eliminating 5xxx, for example, would free up 4096 addresses for DASD. It wasn't your fault. It was IBM's recommendation. The fact is that all but one bit of position 'w' is wasted and position 'x' is nearly always underutilized in the scheme below. However, it's not uncommon at all to have more than 16 LPARs per processor making position 'y' too small in today's world. It works great for small configurations, but should be reworked for larger environments -- perhaps by combining 'w' and 'x' to a single nybble and expanding 'y' to two nybbles. CTC 4-DIGIT NAMING SCHEME: wxyz w - one nibble to distinguish gazinta from gazouta x - one nibble that uniquely represents a processor; assigned by you arbitrarily y - one nibble that represents an LPAR on processor w, such as LPAR id from HCD z - one nibble to complete device address, assigned from 0 up to F -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC conventions
In hindsight I rue the decision to set aside both 4xxx and 5xxx addresses. In practice, the low order digit is severely underused. In the beginning I thought that we would need several different 'devices' for each LPAR. Never actually found a need for more than four, 0 - 3. I like Rob Jackson's idea of assigning even/odd numbers for gazinta and gazouta, or ranges like 0 - 7 and 8 - F. Eliminating 5xxx, for example, would free up 4096 addresses for DASD. OTOH we've never run out of CTC addresses or agonized over which address to use for which device on any LPAR on any CEC. . . 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 Ed Jaffe Sent: Wednesday, October 17, 2018 6:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: CTC conventions On 10/17/2018 4:23 PM, Jesse 1 Robinson wrote: > Just to be clear, a CTC naming convention is not tied uniquely to ESCON or > FICON architecture. We implemented a scheme in the mid-90s under ESCON well > before the advent of FICON. It's still in effect. > > The scheme we adopted (at IBM's suggestion) uses CEC, partition, direction > (in or out for XCF) to construct a four-digit unit number. It has served us > well for decades. The only 'cost' is that lots of addresses are reserved for > CTC. In our case, all 4xxx and 5xxx addresses. I'm sure a more limited scheme > could be utilized, but we connect every LPAR in every CEC to every other LPAR > via CTC, so lots of addresses are utilized. We copied your numbering scheme -- you've posted it here before using the "gazinta" and "gazouta" terminology -- and it works well. If we had more total devices, it might have made sense to fold the scheme down into a single 4xxx address range... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC conventions
On 10/17/2018 4:23 PM, Jesse 1 Robinson wrote: Just to be clear, a CTC naming convention is not tied uniquely to ESCON or FICON architecture. We implemented a scheme in the mid-90s under ESCON well before the advent of FICON. It's still in effect. The scheme we adopted (at IBM's suggestion) uses CEC, partition, direction (in or out for XCF) to construct a four-digit unit number. It has served us well for decades. The only 'cost' is that lots of addresses are reserved for CTC. In our case, all 4xxx and 5xxx addresses. I'm sure a more limited scheme could be utilized, but we connect every LPAR in every CEC to every other LPAR via CTC, so lots of addresses are utilized. We copied your numbering scheme -- you've posted it here before using the "gazinta" and "gazouta" terminology -- and it works well. If we had more total devices, it might have made sense to fold the scheme down into a single 4xxx address range... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC conventions
Indeed. And I didn't follow their guidelines either, though I certainly borrowed from them. I was loathe to eat into two address ranges. Instead, I have always picked one range, added the even-odd nibble for direction, then a nibble for the LPAR number, and then the device number. Never had enough LPARs or independent CECs to worry about it further. First Tennessee Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Wednesday, October 17, 2018 7:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CTC conventions [External Email] Just to be clear, a CTC naming convention is not tied uniquely to ESCON or FICON architecture. We implemented a scheme in the mid-90s under ESCON well before the advent of FICON. It's still in effect. The scheme we adopted (at IBM's suggestion) uses CEC, partition, direction (in or out for XCF) to construct a four-digit unit number. It has served us well for decades. The only 'cost' is that lots of addresses are reserved for CTC. In our case, all 4xxx and 5xxx addresses. I'm sure a more limited scheme could be utilized, but we connect every LPAR in every CEC to every other LPAR via CTC, so lots of addresses are utilized. . . 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 Allan Staller Sent: Wednesday, October 17, 2018 11:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: CTC conventions Thanks Rob, I found that book, but went right past the "ESCON CTC Device Numbering Scheme" on page 5. A virtual beer to you! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jackson, Rob Sent: Wednesday, October 17, 2018 1:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CTC conventions Goog this, Allan: "redbook paper ficon ctc implementation." Top of the list. First Tennessee Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CTC conventions [External Email] Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
Nice thoughts, but I do not believe that is the rule. I believe the stated rule is that everyone must preserve high halves for their callers. If you break it, you put it back together before returning. See Peter Relson 6/14/2016 "LINK and high order word of R1." > If you use it, you save it and restore it for your caller. > save ... in your own storage before you call someone else A safe set of advice, but it ddoes imply lots of superfluous saving: save before calling, even if the callee might not modify, and even if the callee might be saving them itself. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Wednesday, October 17, 2018 3:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit The simple answer to the "problem child" case is not "don't do that", but instead: If you use it, you save it and restore it for your caller. Don't expect anyone else to save it, so if you really need it after you get started then save again in your own storage before you call someone else who may or may not preserve it. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, October 17, 2018 6:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit On Wed, 17 Oct 2018 15:20:44 -0700, Charles Mills wrote: >And FWIW there is another overlapping complexity here besides AMODE 64 -- >speaking in theory only, because there is no reality of 64-bit COBOL. > >... A program could be AMODE 31 but either destroy the high halves of a >caller's registers and/or expect a called program to preserve the high halves >of its registers. (There are many common uses of all 64 bits of a register >outside of AMODE 64.) > Sounds like a "Don't do that!" Must a 31-bit caller not depend on both halves of R2-R13 being preserved by a 31-bit subroutine? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
abend a03
Hi I got the following abend after ending my tasks in a concurrent server. As I have not done any accepts at this point, my only guess was that I somehow have to terminate i.e. shutdown/close my listener sockets I issued a Shutdown/close again them only to receive errno 57 (the socket is not connected). Since the component message was BPX in the error message I assumed that my A03 abend was somehow related to socket. Task BPXP018I THREAD 2007E800, IN PROCESS 16842780, ENDED WITHOUT BEING UNDUBBED WITH COMPLETION CODE 80A03000 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC conventions
Just to be clear, a CTC naming convention is not tied uniquely to ESCON or FICON architecture. We implemented a scheme in the mid-90s under ESCON well before the advent of FICON. It's still in effect. The scheme we adopted (at IBM's suggestion) uses CEC, partition, direction (in or out for XCF) to construct a four-digit unit number. It has served us well for decades. The only 'cost' is that lots of addresses are reserved for CTC. In our case, all 4xxx and 5xxx addresses. I'm sure a more limited scheme could be utilized, but we connect every LPAR in every CEC to every other LPAR via CTC, so lots of addresses are utilized. . . 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 Allan Staller Sent: Wednesday, October 17, 2018 11:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: CTC conventions Thanks Rob, I found that book, but went right past the "ESCON CTC Device Numbering Scheme" on page 5. A virtual beer to you! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jackson, Rob Sent: Wednesday, October 17, 2018 1:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CTC conventions Goog this, Allan: "redbook paper ficon ctc implementation." Top of the list. First Tennessee Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CTC conventions [External Email] Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
The simple answer to the "problem child" case is not "don't do that", but instead: If you use it, you save it and restore it for your caller. Don't expect anyone else to save it, so if you really need it after you get started then save again in your own storage before you call someone else who may or may not preserve it. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, October 17, 2018 6:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit On Wed, 17 Oct 2018 15:20:44 -0700, Charles Mills wrote: >And FWIW there is another overlapping complexity here besides AMODE 64 -- >speaking in theory only, because there is no reality of 64-bit COBOL. > >... A program could be AMODE 31 but either destroy the high halves of a >caller's registers and/or expect a called program to preserve the high halves >of its registers. (There are many common uses of all 64 bits of a register >outside of AMODE 64.) > Sounds like a "Don't do that!" Must a 31-bit caller not depend on both halves of R2-R13 being preserved by a 31-bit subroutine? -- 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: COBOL 64bit
On Wed, 17 Oct 2018 15:20:44 -0700, Charles Mills wrote: >And FWIW there is another overlapping complexity here besides AMODE 64 -- >speaking in theory only, because there is no reality of 64-bit COBOL. > >... A program could be AMODE 31 but either destroy the high halves of a >caller's registers and/or expect a called program to preserve the high halves >of its registers. (There are many common uses of all 64 bits of a register >outside of AMODE 64.) > Sounds like a "Don't do that!" Must a 31-bit caller not depend on both halves of R2-R13 being preserved by a 31-bit subroutine? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
And FWIW there is another overlapping complexity here besides AMODE 64 -- speaking in theory only, because there is no reality of 64-bit COBOL. There are really *three* kinds of module: those that are AMODE 64, those that are AMODE 31 but use and/or count on the high halves of registers, and those that are "pure" 31/32-bit. That middle case is a problem child. A program could be AMODE 31 but either destroy the high halves of a caller's registers and/or expect a called program to preserve the high halves of its registers. (There are many common uses of all 64 bits of a register outside of AMODE 64.) The whole save area thing has gotten to be a little bit of a pile IMHO. It used to be the first two commandments: thou shalt do a STM 14,12,12(13) on entry and thou shalt provide an 18-word save area to callees. Now I am often in doubt and have to look up the rules and then I am still in doubt. How many formats of save areas are there now? IMHO if IBM was going to go to a new linkage convention -- which in itself was a great idea -- they should have addressed 64-bit compatibility. I think AMODE 64 was very much on the horizon before XPLINK ever saw the light of day. I would think they might have come up with a convention that was almost as efficient as current XPLINK(31) but provided for straightforward calling among the three types of programs I listed above. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Wednesday, October 17, 2018 2:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit On Wed, 17 Oct 2018 15:37:12 -0500, Allan Kielstra wrote: >It is only available in 31-bit. > >An interesting question to ask is: if it were available in 64-bit but mixing >and matching 31- and 64-bit modules was not possible (i.e., you would have to >recompile all modules in an application), would that be interesting? Or is it >the case that it is vital to be able to selectively compile modules (in 64-bit >mode) and mix and match? Thank you for asking. While I was a COBOL programmer for several years, I have not worked in that role for decades. AMODE(64) COBOL could be a valuable tool for for applications that could benefit from very large tables. In many cases, such a conversion could be made by changing a relatively small number of modules if they could easily interoperate between AMODE(31) and AMODE(64) modules. The decision that was made that LE would support AMODE(64) only using XPLINK-64 made such interoperability difficult and expensive. XPLINK was invented to solve a particular problem, that C has a propensity for creating very small subroutines. XPLINK reduces the overhead in calling such subroutines somewhat. At the same time, it makes it rather expensive to call programs that use standard linkage. In addition, XPLINK-64 was designed in a way that makes it incompatible with 31-bit XPLINK. COBOL programs typically do a considerable amount of I/O to data sets, often using GET and PUT, which require standard linkage. If COBOL were to implement AMODE(64) in such a way that the standard FxSA save areas were used, it could more easily allow the interoperability of AMODE(64) with AMODE(31) programs without such additional overhead. PL/I already supports AMODE(64) to some extent, but only for applications that are entirely AMODE(64). The reason is XPLINK-64. As far as I know, it has not been adopted in any significant way, if at all. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
On Wed, 17 Oct 2018 15:37:12 -0500, Allan Kielstra wrote: >It is only available in 31-bit. > >An interesting question to ask is: if it were available in 64-bit but mixing >and matching 31- and 64-bit modules was not possible (i.e., you would have to >recompile all modules in an application), would that be interesting? Or is it >the case that it is vital to be able to selectively compile modules (in 64-bit >mode) and mix and match? Thank you for asking. While I was a COBOL programmer for several years, I have not worked in that role for decades. AMODE(64) COBOL could be a valuable tool for for applications that could benefit from very large tables. In many cases, such a conversion could be made by changing a relatively small number of modules if they could easily interoperate between AMODE(31) and AMODE(64) modules. The decision that was made that LE would support AMODE(64) only using XPLINK-64 made such interoperability difficult and expensive. XPLINK was invented to solve a particular problem, that C has a propensity for creating very small subroutines. XPLINK reduces the overhead in calling such subroutines somewhat. At the same time, it makes it rather expensive to call programs that use standard linkage. In addition, XPLINK-64 was designed in a way that makes it incompatible with 31-bit XPLINK. COBOL programs typically do a considerable amount of I/O to data sets, often using GET and PUT, which require standard linkage. If COBOL were to implement AMODE(64) in such a way that the standard FxSA save areas were used, it could more easily allow the interoperability of AMODE(64) with AMODE(31) programs without such additional overhead. PL/I already supports AMODE(64) to some extent, but only for applications that are entirely AMODE(64). The reason is XPLINK-64. As far as I know, it has not been adopted in any significant way, if at all. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
The following is just my personal $0.02USD worth. I speak for myself only and not for my employer. Just like any other new version of the COBOL compiler, 64-bit addressing support must be able to be phased in, subroutine by subroutine. Forcing all subroutines in a main program to become 64-bit if any one of them becomes 64-bit is NOT acceptable. Neither is any serious performance impact acceptable in mixed 64-bit-plus-31-bit programs, no matter what the starting addressing mode may be. In other words, do NOT use XPLINK for 64-bit COBOL. Find a better way that is far more compatible with current static and dynamic calling conventions. For one specific example, many (if not most) large z/OS shops have shop-wide application subroutines for I/O processing of application-specific files which all or at least many different applications in the shop use when they need to access those files. If one application program needs or desires to be recompiled for 64-bit support, there is no way that the application-specific shop-wide subroutine can be allowed to be recompiled as 64-bit because then every other application in the shop would all have to be converted to 64-bit at the same time. That can't (and won't) happen. Keeping separate libraries and separately-compiled versions for 64-bit and 31-bit subroutines may seem like a solution, but it is a management and SDLC maintenance nightmare. COBOL V5+ forced shops to support PDSE libraries for production application executables, but forking that into new separate libraries for 31-bit and 64-bit is just not practical or feasible. Every application would then have to test and maintain 2 versions of every common subroutine that they own, and there are no resources available to support that level of work. Most of us are already running as fast as we can to stay in one place, with no time to spare for anything else. Piecemeal, phased recompilation must be supported, without any serious performance penalties for either the newly compiled 64-bit programs or for the remaining 31-bit programs that are used in the same main program. It is acceptable for all-64-bit programs to have "better" performance (FSVO "better"), but impacting current SLA's because one subroutine became 64-bit is NOT acceptable. SLA's are already far too tight with no slack available. IBM must not screw this up with impossible-to-implement-in-the-real-world conditions or performance penalties. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Kielstra Sent: Wednesday, October 17, 2018 4:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 64bit EXTERNAL EMAIL It is only available in 31-bit. An interesting question to ask is: if it were available in 64-bit but mixing and matching 31- and 64-bit modules was not possible (i.e., you would have to recompile all modules in an application), would that be interesting? Or is it the case that it is vital to be able to selectively compile modules (in 64-bit mode) and mix and match? -- 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: COBOL 64bit
It is only available in 31-bit. An interesting question to ask is: if it were available in 64-bit but mixing and matching 31- and 64-bit modules was not possible (i.e., you would have to recompile all modules in an application), would that be interesting? Or is it the case that it is vital to be able to selectively compile modules (in 64-bit mode) and mix and match? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL 64bit
Just an easy question - does anyone know if COBOL can be 64 bit or is it still only 31 bit? Lizette Sent from EarthLink Mobile mail -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another quick z/OSMF question
Isn't it just a profile setting in ISPF? >From anywhere do a ===>Prof 6and look for CAPS. ===>CAPS off Will do it for the session.===>CAPS off followed by ===>profile savewill make it the default. In a message dated 10/17/2018 2:47:33 PM Central Standard Time, mitchd...@gmail.com writes: Yeah, admittedly there isn't much to it, I just went through the workflow to get a feel for how it works, (and see if it works ;) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another quick z/OSMF question
Yeah, admittedly there isn't much to it, I just went through the workflow to get a feel for how it works, (and see if it works ;) On Wed, 17 Oct 2018 19:31:20 +, Jousma, David wrote: >I coded that up manually. Wasn’t even aware that there was an option to >generate that. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA PDSMAN and dynamic additions to APF list
On 2018-10-17 15:25, Carmen Vitullo wrote: you mentioned this was not your system but also add; We are seeing a ABEND306-4 issued by FOCUS (not by IBM Contents Supervision) after a BLDL against DDname USERLIB returns with GPR15=0004, R0=, GPR1=0306. System trace shows that PDSMAN code gets control for the BLDL, but IBM code does not, hence our interest in how PDSMAN responds to dynamic APF additions. The data set is in the APF list with volume*SMS* and we have been assured that it was added to APF dynamically before the above abend. In the dump, DEBFLGS1/DEBAPFIN is on. PDSMAN at the site I supported was used to monitor PDS's and member usage and run reports for statistics. Sorry I don't have PDSMAN and I don't recall what all the options or rules are but I don't think PDSMAN / traps, or intercepts dynamic APF updates. Correct. We don't have PDSMAN ourselves, but received a dump for the ABEND306-4 from a customer who does have PDSMAN. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another quick z/OSMF question
I coded that up manually. Wasn’t even aware that there was an option to generate that. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Dana Mitchell Sent: Wednesday, October 17, 2018 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Another quick z/OSMF question **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** If there is such a thing... I'm setting up z/OSMF 2.2 for the first time, I have it up and I just went through the 'Customization for the zOSMF plug-ins' workflow. The step to Update zOSMF (IZUPRMxx) parmlib member, attempting to add the PLUGIN statement to it, appears to have translated the entire existing IZUPRMxx member to upper case. Obviously this is a little disruptive on the JAVA_HOME parm, among others. So did I miss a tiny checkbox somewhere in the process of running that step that says preserve case or something? As long as I didn't do anything dumb, this will soon turn into a SR Dana -- 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: CTC conventions
Thanks Daniel. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Blake, Daniel J [CTR] Sent: Wednesday, October 17, 2018 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CTC conventions Not sure if this is it, https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsearch%3Fq%3DSG24-5666%26lnk%3Dmhsrch%26v%3D18%26en%3Dutf%26lang%3Den%26cc%3Dus&data=02%7C01%7Callan.staller%40HCL.COM%7C1ac56e4f29e5410f0b4308d6345a9c14%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636753961142412784&sdata=xWbEa%2BwMhWUdXFcGzJpBnUskqAioyM1vDTO6%2Fvio8AI%3D&reserved=0 ;-D an -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CTC conventions Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA PDSMAN and dynamic additions to APF list
you mentioned this was not your system but also add; We are seeing a ABEND306-4 issued by FOCUS (not by IBM Contents Supervision) after a BLDL against DDname USERLIB returns with GPR15=0004, R0=, GPR1=0306. System trace shows that PDSMAN code gets control for the BLDL, but IBM code does not, hence our interest in how PDSMAN responds to dynamic APF additions. The data set is in the APF list with volume *SMS* and we have been assured that it was added to APF dynamically before the above abend. In the dump, DEBFLGS1/DEBAPFIN is on. PDSMAN at the site I supported was used to monitor PDS's and member usage and run reports for statistics. Sorry I don't have PDSMAN and I don't recall what all the options or rules are but I don't think PDSMAN / traps, or intercepts dynamic APF updates. Carmen Vitullo - Original Message - From: "Gord Tomlin" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, October 17, 2018 1:57:56 PM Subject: Re: CA PDSMAN and dynamic additions to APF list On 2018-10-17 13:41, Carmen Vitullo wrote: > I really don't belive PDSMAN refreshes / adds or deletes libraries from APF, > dynamic or not, I know 'it used to' update LLA IF the PDS was managed, this > was back Y2K, so things may have changed. > the 306-4 is I think related to the concatenation, you lost authorization due > to the STEPLIB concatenation, can't prove any of this without seeing JCL, > APF...etc PDSMAN did not add the library to the APF list. The customer added the data set to the APF list, presumably using SETPROG APF,ADD,... The question has to do with what PDSMAN does (or doesn't do) when a library is added to the APF list. 306-4 does mean that "A LOAD macro requested, by the load to global option, a module residing in a library that is not authorized program facility (APF) authorized." However, the library is in fact in the APF list. PDSMAN returns to the BLDL issuer with GPR15=0004, R0=, GPR1=0306. The BLDL issuer then abends 306-4. This all makes me wonder whether PDSMAN maintains its own representation of the APF list, which may not be current after the APF list is dynamically updated. I know PDSMAN has this command: F PDSMAN,NEWRULES to reload the rules in the PDSMAN initialization member, PDSMINIT. But I have no idea whether that has any relationship to what PDSMAN may know about the APF list, and have not been able to find anything that says it does or doesn't. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Another quick z/OSMF question
If there is such a thing... I'm setting up z/OSMF 2.2 for the first time, I have it up and I just went through the 'Customization for the zOSMF plug-ins' workflow. The step to Update zOSMF (IZUPRMxx) parmlib member, attempting to add the PLUGIN statement to it, appears to have translated the entire existing IZUPRMxx member to upper case. Obviously this is a little disruptive on the JAVA_HOME parm, among others. So did I miss a tiny checkbox somewhere in the process of running that step that says preserve case or something? As long as I didn't do anything dumb, this will soon turn into a SR Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA PDSMAN and dynamic additions to APF list
On 2018-10-17 13:41, Carmen Vitullo wrote: I really don't belive PDSMAN refreshes / adds or deletes libraries from APF, dynamic or not, I know 'it used to' update LLA IF the PDS was managed, this was back Y2K, so things may have changed. the 306-4 is I think related to the concatenation, you lost authorization due to the STEPLIB concatenation, can't prove any of this without seeing JCL, APF...etc PDSMAN did not add the library to the APF list. The customer added the data set to the APF list, presumably using SETPROG APF,ADD,... The question has to do with what PDSMAN does (or doesn't do) when a library is added to the APF list. 306-4 does mean that "A LOAD macro requested, by the load to global option, a module residing in a library that is not authorized program facility (APF) authorized." However, the library is in fact in the APF list. PDSMAN returns to the BLDL issuer with GPR15=0004, R0=, GPR1=0306. The BLDL issuer then abends 306-4. This all makes me wonder whether PDSMAN maintains its own representation of the APF list, which may not be current after the APF list is dynamically updated. I know PDSMAN has this command: F PDSMAN,NEWRULES to reload the rules in the PDSMAN initialization member, PDSMINIT. But I have no idea whether that has any relationship to what PDSMAN may know about the APF list, and have not been able to find anything that says it does or doesn't. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC conventions
Thanks Rob, I found that book, but went right past the "ESCON CTC Device Numbering Scheme" on page 5. A virtual beer to you! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jackson, Rob Sent: Wednesday, October 17, 2018 1:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CTC conventions Goog this, Allan: "redbook paper ficon ctc implementation." Top of the list. First Tennessee Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CTC conventions [External Email] Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, ::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 FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: CTC conventions
Not sure if this is it, https://www.ibm.com/search?q=SG24-5666&lnk=mhsrch&v=18&en=utf&lang=en&cc=us ;-D an -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CTC conventions Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, ::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: CTC conventions
Goog this, Allan: "redbook paper ficon ctc implementation." Top of the list. First Tennessee Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Wednesday, October 17, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CTC conventions [External Email] Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, ::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 FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CTC conventions
Esteemed Listers, I am in the process of adding a new LPAR to my sysplex and need some documentation for CTC naming conventions. Many moons ago, there existed a document with a suggested naming convention such that device addresses could be associated with a particular LPAR and the direction of data flow. This would, in turn, enable simple specification of PATHIN/PATHOUT statements in SYS1.PARMLIB(COUPLExx). After a couple of hours spent with various search engines, websites, etc. I am unable to locate this suggested convention. I have found fragments of documentation that use the convention, but no expression of the convention itself. Does anyone, by chance, still have a copy? If so, can you post a copy or a link? A virtual beer to all responders, and thanks in advance, ::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: CA PDSMAN and dynamic additions to APF list
I really don't belive PDSMAN refreshes / adds or deletes libraries from APF, dynamic or not, I know 'it used to' update LLA IF the PDS was managed, this was back Y2K, so things may have changed. the 306-4 is I think related to the concatenation, you lost authorization due to the STEPLIB concatenation, can't prove any of this without seeing JCL, APF...etc Carmen Vitullo - Original Message - From: "Gord Tomlin" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, October 17, 2018 12:34:52 PM Subject: Re: CA PDSMAN and dynamic additions to APF list On 2018-10-17 13:19, Clark Morris wrote: > Is the data set in the concatenation twice because a symbolic is used > to change the name of none, one or both at start-up time to another > dataset? If APF is changed dynamically, should the change affect both > members of the concatenation? I don't have the JCL for the job, but it's reasonable to think that a symbolic was used to specify all or part of a data set name in a situation where a data set is concatenated with itself. Certainly an APF list change should affect all relevant data sets. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: CA PDSMAN and dynamic additions to APF list
On 2018-10-17 13:19, Clark Morris wrote: Is the data set in the concatenation twice because a symbolic is used to change the name of none, one or both at start-up time to another dataset? If APF is changed dynamically, should the change affect both members of the concatenation? I don't have the JCL for the job, but it's reasonable to think that a symbolic was used to specify all or part of a data set name in a situation where a data set is concatenated with itself. Certainly an APF list change should affect all relevant data sets. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA PDSMAN and dynamic additions to APF list
[Default] On 17 Oct 2018 09:50:18 -0700, in bit.listserv.ibm-main gt.ibm.li...@actionsoftware.com (Gord Tomlin) wrote: >On 2018-10-17 12:27, Steely.Mark wrote: >> To be clear, the data set is being accessed via a private DD statement: Is >> this the only Dataset specified on the DD statement ? > >There is a concatenation, but both members of the concatenation are the >same data set on the same volume. Is the data set in the concatenation twice because a symbolic is used to change the name of none, one or both at start-up time to another dataset? If APF is changed dynamically, should the change affect both members of the concatenation? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reconfigurable storage
Indeed it does, but on the MVS (z/OS) side unless I missed that chapter, does a poor job of; 1. providing good examples of configuring storage on or off, in increments 2. the feel good display from a tool other than the D M=STOR to validate, yes, all available storage configured 'reconfigurable' is indeed online and usable. Carmen Vitullo - Original Message - From: "Parwez Hamid" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, October 17, 2018 11:47:57 AM Subject: Re: Reconfigurable storage I thought the PR/SM Planning guide covers this topic and has some examples. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: CA PDSMAN and dynamic additions to APF list
On 2018-10-17 12:27, Steely.Mark wrote: To be clear, the data set is being accessed via a private DD statement: Is this the only Dataset specified on the DD statement ? There is a concatenation, but both members of the concatenation are the same data set on the same volume. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reconfigurable storage
I thought the PR/SM Planning guide covers this topic and has some examples. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA PDSMAN and dynamic additions to APF list
On 10/17/2018 12:31 PM, Gord Tomlin wrote: On 2018-10-17 12:23, Tom Conley wrote: Your client should open an incident with PDSMAN support. Absolutely! I've already suggested that. -- We both have an MO (Master of the Obvious) in Computer Science ;-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA PDSMAN and dynamic additions to APF list
On 2018-10-17 12:23, Tom Conley wrote: Your client should open an incident with PDSMAN support. Absolutely! I've already suggested that. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA PDSMAN and dynamic additions to APF list
To be clear, the data set is being accessed via a private DD statement: Is this the only Dataset specified on the DD statement ? Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Wednesday, October 17, 2018 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CA PDSMAN and dynamic additions to APF list On 2018-10-17 11:56, Carmen Vitullo wrote: > so you question is just 'in general' ? > It's been a while since I was at a site that used CA-PDSMAN but I'm thinking, > if managed, it would automatically refresh LLA, not sure about the linklist, > that refresh sometime causes issues with some vendor software, or at least it > use to. It's a specific problem we are looking at, in which a BLDL is failing with ABEND306-4 despite the data set being in the APF list. To be clear, the data set is being accessed via a private DD statement, not via the lnklst. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN *** Disclaimer *** This communication (including all attachments) is solely for the use of the person to whom it is addressed and is a confidential AAA communication. If you are not the intended recipient, any use, distribution, printing, or copying is prohibited. If you received this email in error, please immediately delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA PDSMAN and dynamic additions to APF list
On 10/17/2018 11:49 AM, Gord Tomlin wrote: On 2018-10-17 10:50, Lizette Koehler wrote: Did you do an LLA Update or Refresh? And is this a managed PDSMAN dataset or something in a STEPLIB? This is not on our system. We don't have CA PDSMAN, so we are unable to test for ourselves. We are seeing a ABEND306-4 issued by FOCUS (not by IBM Contents Supervision) after a BLDL against DDname USERLIB returns with GPR15=0004, R0=, GPR1=0306. System trace shows that PDSMAN code gets control for the BLDL, but IBM code does not, hence our interest in how PDSMAN responds to dynamic APF additions. The data set is in the APF list with volume *SMS* and we have been assured that it was added to APF dynamically before the above abend. In the dump, DEBFLGS1/DEBAPFIN is on. Gord, Your client should open an incident with PDSMAN support. 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: CA PDSMAN and dynamic additions to APF list
On 2018-10-17 11:56, Carmen Vitullo wrote: so you question is just 'in general' ? I'ts been a while since I was at a site that used CA-PDSMAN but I'm thinking, if managed, it would automatically refresh LLA, not sure about the linklist, that refresh sometime causes issues with some vendor software, or at least it use to. It's a specific problem we are looking at, in which a BLDL is failing with ABEND306-4 despite the data set being in the APF list. To be clear, the data set is being accessed via a private DD statement, not via the lnklst. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reconfigurable storage
W dniu 2018-10-16 o 19:10, Carmen Vitullo pisze: The fine manual 'for me' is not so easy to understand when configuring storage online, I've always had success configuring a storage element online and that amount was defined in the image profile and RSU parameter of IEASYSxx. I concur the above. I wish I would see some presentation describing "memory dynamic changes for beginners". What can be done, what conditions should be met, what is possible, what's not. Regards -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA PDSMAN and dynamic additions to APF list
so you question is just 'in general' ? I'ts been a while since I was at a site that used CA-PDSMAN but I'm thinking, if managed, it would automatically refresh LLA, not sure about the linklist, that refresh sometime causes issues with some vendor software, or at least it use to. Carmen Vitullo - Original Message - From: "Gord Tomlin" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, October 17, 2018 10:49:30 AM Subject: Re: CA PDSMAN and dynamic additions to APF list On 2018-10-17 10:50, Lizette Koehler wrote: > Did you do an LLA Update or Refresh? > > And is this a managed PDSMAN dataset or something in a STEPLIB? This is not on our system. We don't have CA PDSMAN, so we are unable to test for ourselves. We are seeing a ABEND306-4 issued by FOCUS (not by IBM Contents Supervision) after a BLDL against DDname USERLIB returns with GPR15=0004, R0=, GPR1=0306. System trace shows that PDSMAN code gets control for the BLDL, but IBM code does not, hence our interest in how PDSMAN responds to dynamic APF additions. The data set is in the APF list with volume *SMS* and we have been assured that it was added to APF dynamically before the above abend. In the dump, DEBFLGS1/DEBAPFIN is on. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: CA PDSMAN and dynamic additions to APF list
On 2018-10-17 10:50, Lizette Koehler wrote: Did you do an LLA Update or Refresh? And is this a managed PDSMAN dataset or something in a STEPLIB? This is not on our system. We don't have CA PDSMAN, so we are unable to test for ourselves. We are seeing a ABEND306-4 issued by FOCUS (not by IBM Contents Supervision) after a BLDL against DDname USERLIB returns with GPR15=0004, R0=, GPR1=0306. System trace shows that PDSMAN code gets control for the BLDL, but IBM code does not, hence our interest in how PDSMAN responds to dynamic APF additions. The data set is in the APF list with volume *SMS* and we have been assured that it was added to APF dynamically before the above abend. In the dump, DEBFLGS1/DEBAPFIN is on. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about support from vendor other than IBM
I've supported a Government site that used ADABAS and Natural, if you go to their site there is a link to the user community http://www.adabas.com/ Carmen Vitullo - Original Message - From: "Ron McCabe" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, October 16, 2018 2:07:53 PM Subject: Question about support from vendor other than IBM Hello, I wanted to know if anyone knows if there is a discussion list for ADABAS and Natural? Thanks, Ron McCabe Mutual of Enumclaw Confidentiality Notice: This e- mail and all attachments may contain CONFIDENTIAL information and are meant solely for the intended recipient. It may contain controlled, privileged, or proprietary information that is protected under applicable law and shall not be disclosed to any unauthorized third party. If you are not the intended recipient, you are hereby notified that any unauthorized review, action, disclosure, distribution, or reproduction of any information contained in this e- mail and any attachments is strictly PROHIBITED. If you received this e- mail in error, please reply to the sender immediately stating that this transmission was misdirected, and delete or destroy all electronic and paper copies of this e-mail and attachments without disclosing the contents. This e- mail does not grant or assign rights of ownership in the proprietary subject matter herein, nor shall it be construed as a joint venture, partnership, teaming agreement, or any other formal business relationship. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: 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: CA PDSMAN and dynamic additions to APF list
Did you do an LLA Update or Refresh? And is this a managed PDSMAN dataset or something in a STEPLIB? Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Gord Tomlin > Sent: Wednesday, October 17, 2018 7:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: CA PDSMAN and dynamic additions to APF list > > If a partitioned data set is defined to CA PDSMAN, and is then dynamically > added to the APF list, does PDSMAN automatically recognize the fact that the > data set is now defined to APF, or is a command required to cause PDSMAN to > update its information? If PDSMAN does automatically recognize the addition > to the APF list, is it done immediately or on an interval basis? > > Thanks! > > -- > > Regards, Gord Tomlin > Action Software International > (a division of Mazda Computer Corporation) > Tel: (905) 470-7113, Fax: (905) 470-6507 > Support: https://actionsoftware.com/support/ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CA PDSMAN and dynamic additions to APF list
If a partitioned data set is defined to CA PDSMAN, and is then dynamically added to the APF list, does PDSMAN automatically recognize the fact that the data set is now defined to APF, or is a command required to cause PDSMAN to update its information? If PDSMAN does automatically recognize the addition to the APF list, is it done immediately or on an interval basis? Thanks! -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Command to list aged, migrated items
Thanks Lizette, that modify command is just what I'm after.
PROF NOPREFIX-ing it just fails the command with RC8 when I tried.
- Vignesh
Mainframe Infrastructure
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Lizette Koehler
Sent: 16 October 2018 14:57
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Command to list aged, migrated items
And the other option.
When doing work in TSO (option 6 etc... in ISPF) you probably need to remove
your TSO Prefix.
PROF NOPREFIX
Issue HSEND command
Then turn prefix back on when you are done.
Lizette
> -Original Message-
> From: Lizette Koehler
> Sent: Tuesday, October 16, 2018 6:51 AM
> To: 'IBM Mainframe Discussion List'
> Subject: RE: [EXTERNAL] Re: Command to list aged, migrated items
>
> And before you ask, you can do this in batch jcl with the COMMAND JCL
> Statement. The USER= parm in JCL will need to have the ability to
> submit MVS commands and DFHSM commands
>
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List On
> > Behalf Of Lizette Koehler
> > Sent: Tuesday, October 16, 2018 6:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [EXTERNAL] Re: Command to list aged, migrated items
> >
> > Try this
> >
> > On the console enter the LIST portion of the command
> >
> > F dfhsm_task_name,LIST DSNAME ODS('your.dataset.name')
> > select(age(60))
> >
> >
> > Sometimes in TSO it can restrict your process
> >
> > Lizette
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List On
> > > Behalf Of Sankaranarayanan, Vignesh
> > > Sent: Tuesday, October 16, 2018 6:47 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: [EXTERNAL] Re: Command to list aged, migrated items
> > >
> > > Hi Lizette,
> > >
> > > I used this, same one as Chuck replied with -
> > >
> > > HSEND LIST DSNAME ODS('your.dataset.name') select(age(60))
> > >
> > > I don't think the output matters since I can say with ease that it
> > > shows just the files under my HLQ (from TSO PROFILE PREFIX, I think).
> > >
> > > DCOLLECT works but I was hoping a simple command has the answer..
> > >
> > >
> > > - Vignesh
> > > Mainframe Infrastructure
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List On
> > > Behalf Of Lizette Koehler
> > > Sent: 16 October 2018 14:15
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: [EXTERNAL] Re: Command to list aged, migrated items
> > >
> > > You will need to show us the command you used and some of the output.
> > > You can mask the HLQs but we need to see what the output looks
> > > like
> > >
> > > Be aware that the manual has many parameters and you may need to
> > > play with the LIST to get what you want.
> > >
> > > You may also need to do more than one command if you need both ML1
> > > and
> > > ML2 reports
> > >
> > >
> > > Lizette
> > >
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List
> > > > On Behalf Of Sankaranarayanan, Vignesh
> > > > Sent: Tuesday, October 16, 2018 5:44 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: [EXTERNAL] Re: Command to list aged, migrated items
> > > >
> > > > I used this, but it lists only the user's HLQ files.
> > > > Even though the manual says ALL datasets...
> > > >
> > > > - Vignesh
> > > > Mainframe Infrastructure
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List
> > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan,
> > > > Vignesh
> > > > Sent: Tuesday, October 16, 2018 4:02 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Command to list aged, migrated items
> > > >
> > > > Hello everyone,
> > > >
> > > > I'm looking for a command to list all ML1/ML2 datasets that have
> > > > an age of
> > > > 60 (2 months ago, they were migrated).
> > > > A working command would be ideal, as I'm looking to stick it
> > > > into a batch job..
> > > >
> > > > Thank you!
> > > >
> > > > - Vignesh
> > > > Mainframe Infrastructure
> > > >
> > > >
> > > > MARKSANDSPENCER.COM
> > > >
> > > sage: INFO IBM-MAIN
> > >
> > > --
> > > --
> > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO
> > > IBM-MAIN
> > >
> > > MARKSANDSPENCER.COM
> > >
> > > Unless otherwise stated above:
> > > Marks and Spencer plc
> > > Registered Office:
> > > Waterside House
> > > 35 North Wharf Road
> > > London
> > > W2 1NW
> > >
> > > Registered No. 214436 in England and Wales.
> > >
> > > Telephone (020) 7935 4422
> > > Facsimile (020) 7487 2670
> > >
> > > www.marksandspencer.com
> > >
> > > Please note that electronic mail may be monitored.
> > >
> > > This e-mail is confidential. If you received it by mistake, please
> > > let us know and then delete it from your system; you should not
> > > copy, di
