Re: Concurrent Server Task Dispatch issue multitasking issue
> There is another problem COMECBPT is key 0 storage and MY_ECB is key > 8 WAIT requires the user to be in the key of the ECB would I have the > that problem using SELECB Except for the communications ECB! There is a special check in wait for the communications ECB to allow problem key callers to wait on it even though the communications ECB is in key zero storage.. The following is a good point from Rob Scott > Personally I would not mix the operator communications in the same task > and ECBLIST as the TCP/IP API. > I would have a master controller task that would deal with any operator > comms and also manage the various "other" subtasks of which one would > be the listener agent. > The listener agent would then attach handler subtasks itself. > Any operator initiated action would to captured by the controller task > and communicated down to the listener which can then pass it down to > the handler tasks. > Suggested task structure : > TCB1 (Main controller - Deals with CIBs) > ---> TCB2 (TCP/IP listener - subtask of TCB1) > ->TCB3A TCB3B TCB3C (Socket handler subtasks of TCB2) One reason for this is to avoid doing a wait on the communications ECB every time your task doing most of the work wakes up. The assumption is that the communications ECB will usually not be posted so removing it from the ECBLIST makes the list 1 shorter. That's one less ECB which: a. on wait gets validity checked b. on wait gets the wait bit set c. post validity checks the target ECB, then if post is to wake the task: e. - post validity check the ther ECBs in the ECBLIST d. - clear the wait bit on other ECBs in ECBLIST It's also possibly much more overhead than 1 ECB less as the "exception" which allows waiting on the communications task isn't (wasn't) a short code path. At least in MVS 3.8 it involved wait getting a program check trying to validate the communications ECB and wait's FRR deciding no, that was ok, it's the communications ECB. So to avoid this extra overhead the task which waits on the communications ECB should be one which rarely wakes up. PS: The MVS code may have changed since them... Or not... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCRE init module
I have to create an ACEE in the init module because the jobstep runs in user mode. That work fine currently. I will find a better sub-pool to use. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: 15 January 2019 00:50 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE init module I am thinking storage in a user sub-pool and saving the address in the ACEE since we create that. An ASCRE Initialization routine must not obtain storage in user-region subpools because after the initialization routine runs, the user region is (re-)initialized. Maybe you shouldn't be creating an ACEE (at least not until the jobstep program begins)? 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
SCLM problem
Hi, I am trying to install an ISV product. The product was delivered as 3 XMITed libraries. I used RECEIVE to create the product libraries. When I try to edit members in the libraries, I get a message that edit is not allowed because they are under SCLM control. SCLM is being used for application source code libraries. How do I remove them from SCLM control? We are running z/OS v2.2 Gadi ? ?? ? ?? ??? ??? ?? ? ??? ?? ??. ?? , ?? ??? ?, ??? ? ?? ??? ? ?? ?? ?. ? ? ?? ?? ?? ?? ?? ??? ??? ???, ?/?? ?, ? ?? ? ? ? ? ?? ?? ? ??? ?/?? ?? ?? ??. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol and Hiperspace (was 64-bit C code fetching IGGCSI00)
You can access hiperspaces in COBOL using the MVS Callable Services for HLLs Window Services https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieac100/ws.htm. There are code examples. On 15/01/2019 2:58 am, scott Ford wrote: Peter: My typos ..sorry the question was in regard to a Cobol program creating and then referencing Hiperspaces. You answer was what I thought, so thank you. Scott On Mon, Jan 14, 2019 at 12:59 PM Peter Relson wrote: So how does a Cobol Pgm , 31bit address say a Hiperspace ? I assume an interface program units AR registers , etc., am I correct ? I have don’t this want to... I could not parse this. What were you trying to ask? Hiperspaces are not directly referenced. You use services to put data in and get data out. And then you reference the buffer you identified, which is in your address space. So aside from invoking the hiperspace services themselves (and dspserv to create/delete the hiperspace), there's nothing special related to Cobol (or any other language). HSPSERV supports only AMODE 31 invocation. 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
Re: HCD question
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Edward Finnell > Sent: Monday, January 14, 2019 4:05 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: HCD question > > Don't forget to update LOAD and PARMLIB values. True. I'm at MFaaS (Cloud lpars) now. SYS1.IPLPARM is on one of "Their" volumes :) More because it's their IODF. But, by careful use of the IEASYM and PARMLIB statements in LOADxx, everything else is on my volumes. I will be presenting at Share, Phoenix on my experiences doing a "lift and shift" migration from our local z9 to z shared z21 in Omaha. > > In a message dated 1/14/2019 4:24:49 PM Central Standard Time, > gib...@wsu.edu writes: > It will all fit on a Mod 27. As below, Start with Mark Zelden's example. > Tailor > for your needs. > > -- > 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
Thanks Ed. I do remember that first discussion now, I think I got busy at work and missed following the other longer one. Hmm-m-m. Maybe an RCF for PoOp complaining about the lack of examples for many of the more recent complex instructions, including vectors and the several newer "PERFORM . . . " instructions, at least the ones that aren't privileged. I suppose one could use the C compiler with ARCH(Max value for your version of the compiler) and OPT(0) and METAL to generate relatively human-understandable examples, albeit not the very most efficient ones. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, January 14, 2019 6:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue) On 1/14/2019 11:18 AM, Farley, Peter x23353 wrote: > I also participate in ASSEMBLER-LIST and I don't remember such a discussion. > Can you pinpoint the approximate time period for that discussion? > > My biggest complaint/concern with the vector instructions is the woeful lack > of any example code showing how to use them for just the kind of functions > you described. It's hard to imagine how to use such complex instructions > without at least some straight-forward examples. I first mentioned using vector instructions in place of SRST in October 2016 in a thread entitled, "SRST Performance" with eight posts. The group was debating which was faster, TRT or SRST. My comment was: "SRST is much, much faster than TRT but still orders of magnitude slower than the vector instructions." to which you replied as you have here with a desire for good examples from the PoOp owners. No one else seemed interested... Later, in October of last year in another thread entitled, "Count Words?" with nearly 50 posts, I once again recommended use of vector instructions to solve the issue under discussion and that time was met with serious push-back from some list participants (not you). In the end, I smiled to myself content in the knowledge that I could solve the problem with a vector-based routine that would run circles around anything any of those "experts" could write using the alternative techniques being suggested. Of course, such a routine would normally be written using dual-path code with fall back to Plan B if the vector instructions were not available. So discussing the best implementation for Plan B wasn't time wasted... -- 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: HCD question
Don't forget to update LOAD and PARMLIB values. In a message dated 1/14/2019 4:24:49 PM Central Standard Time, gib...@wsu.edu writes: It will all fit on a Mod 27. As below, Start with Mark Zelden's example. Tailor for your needs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
Sounds like a SHARE presentation to me! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, January 14, 2019 11:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue) Ed, I also participate in ASSEMBLER-LIST and I don't remember such a discussion. Can you pinpoint the approximate time period for that discussion? My biggest complaint/concern with the vector instructions is the woeful lack of any example code showing how to use them for just the kind of functions you described. It's hard to imagine how to use such complex instructions without at least some straight-forward examples. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
On 1/14/2019 11:18 AM, Farley, Peter x23353 wrote: I also participate in ASSEMBLER-LIST and I don't remember such a discussion. Can you pinpoint the approximate time period for that discussion? My biggest complaint/concern with the vector instructions is the woeful lack of any example code showing how to use them for just the kind of functions you described. It's hard to imagine how to use such complex instructions without at least some straight-forward examples. I first mentioned using vector instructions in place of SRST in October 2016 in a thread entitled, "SRST Performance" with eight posts. The group was debating which was faster, TRT or SRST. My comment was: "SRST is much, much faster than TRT but still orders of magnitude slower than the vector instructions." to which you replied as you have here with a desire for good examples from the PoOp owners. No one else seemed interested... Later, in October of last year in another thread entitled, "Count Words?" with nearly 50 posts, I once again recommended use of vector instructions to solve the issue under discussion and that time was met with serious push-back from some list participants (not you). In the end, I smiled to myself content in the knowledge that I could solve the problem with a vector-based routine that would run circles around anything any of those "experts" could write using the alternative techniques being suggested. Of course, such a routine would normally be written using dual-path code with fall back to Plan B if the vector instructions were not available. So discussing the best implementation for Plan B wasn't time wasted... -- 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: HCD question
It will all fit on a Mod 27. As below, Start with Mark Zelden's example. Tailor for your needs. I did find that a separate SYSCAT volume made the subsequent steps of recovery easier.. I IPL the single system to refresh the other copy of the single system and a resuce SYSCAT, then IPL each Lpar (4 monolex) with the refreshed SYSRES/SYSCAT pair. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of R.S. > Sent: Monday, January 14, 2019 1:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: HCD question > > See Mark Zelden's Utilities. > Or just make it yourself, it's not black magic. > Recipe: > Review your sandbox/tech system. Note all your volumes. Try to put as much > as possible on same volume. Shrink opeational datasets (page, spool, RACF > db) as possible. > Delete all SMPE operational datasets (CSI, LTS, xLOGs, PTS, etc.). > Delete all DLIB libraries. > > Last, but not least: without any of the above you are able to put all the > stuff > on ONE volume. Take EAV... > > BTW: what's wrong in 5-pack or 8-pack OS? > We already know that single EAV can be much larger than n-pack... > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2019-01-14 o 17:05, scott Ford pisze: > > Guys: > > > > I want to build a three pack rescue system , where do i find the 'how to ' > > ...?? > > > > Scott > > > > On Mon, Jan 14, 2019 at 10:51 AM R.S. > > > wrote: > > > >> W dniu 2019-01-14 o 13:16, Tony Thigpen pisze: > >>> We have a 3-pack rescue system that was built by a person long-gone. > >>> On the 3-pack system, there are several IODF files. I need to update > >>> the current IODF file. > >>> > >>> But, the IODF files on the rescue packs are not cataloged to the > >>> production z/OS. When I use the HCD panels, it does not appear that > >>> there is a way to specify the volume where the file is located, so HCD > >>> always says the file can not be found. > >>> > >>> Is there a way to specify the volume, along with the name, when using > >>> the panel? Or, a command to start the panels using the uncataloged > >>> IODF file? > >>> > >> BTDT many times. > >> Few ways: > >> 1. Just copy hlq.IODF to the3-pack system and have in ming this file > >> will be uncataloged from 3-pack system point of view. However this is > >> quite OK for IPL. In addition put packed version (DSS DUMP, IDCAMS > >> EXPORT) of the IODF just to unpack it under 3-pack system. > >> > >> 2. Use cross-system cataloging, which is allowed for VSAM files with > >> HLQ=SYS1. So your IODF will be in your MCAT and in 3-packs's MCAT. Not > >> convenient, but feasible. You can still use the newest (uncataloged in > >> 3-pack) IODF for IPL and then recatalog it. > >> > >> 3. Take the smallest volume, name it SHARED or as you want. Put there > >> UCAT and define alias, lets say . Name your iodf files: .IODFxx. > >> Import connect the UCAT in you 3-pack system and any other system. > Done > >> once work forever. Suggested way IMHO. > >> > >> > >> > >> > >> -- > >> 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
Re: HCD question
See Mark Zelden's Utilities. Or just make it yourself, it's not black magic. Recipe: Review your sandbox/tech system. Note all your volumes. Try to put as much as possible on same volume. Shrink opeational datasets (page, spool, RACF db) as possible. Delete all SMPE operational datasets (CSI, LTS, xLOGs, PTS, etc.). Delete all DLIB libraries. Last, but not least: without any of the above you are able to put all the stuff on ONE volume. Take EAV... BTW: what's wrong in 5-pack or 8-pack OS? We already know that single EAV can be much larger than n-pack... -- Radoslaw Skorupka Lodz, Poland W dniu 2019-01-14 o 17:05, scott Ford pisze: Guys: I want to build a three pack rescue system , where do i find the 'how to ' ...?? Scott On Mon, Jan 14, 2019 at 10:51 AM R.S. wrote: W dniu 2019-01-14 o 13:16, Tony Thigpen pisze: We have a 3-pack rescue system that was built by a person long-gone. On the 3-pack system, there are several IODF files. I need to update the current IODF file. But, the IODF files on the rescue packs are not cataloged to the production z/OS. When I use the HCD panels, it does not appear that there is a way to specify the volume where the file is located, so HCD always says the file can not be found. Is there a way to specify the volume, along with the name, when using the panel? Or, a command to start the panels using the uncataloged IODF file? BTDT many times. Few ways: 1. Just copy hlq.IODF to the3-pack system and have in ming this file will be uncataloged from 3-pack system point of view. However this is quite OK for IPL. In addition put packed version (DSS DUMP, IDCAMS EXPORT) of the IODF just to unpack it under 3-pack system. 2. Use cross-system cataloging, which is allowed for VSAM files with HLQ=SYS1. So your IODF will be in your MCAT and in 3-packs's MCAT. Not convenient, but feasible. You can still use the newest (uncataloged in 3-pack) IODF for IPL and then recatalog it. 3. Take the smallest volume, name it SHARED or as you want. Put there UCAT and define alias, lets say . Name your iodf files: .IODFxx. Import connect the UCAT in you 3-pack system and any other system. Done once work forever. Suggested way IMHO. -- 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: Abend 106 (was Generic query on Region allocation failure)
Thanks guys, very helpful. Peter, I have tested with LLA stopped,thought I posted that test.Still received S106-C. Since the problem started with CICS 5.3, I think a PMR with CICS is the next step. I'll run more tests today (I'm at a different client today). Wayne On Tue, Jan 15, 2019 at 3:06 AM Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 14 Jan 2019 08:30:20 -0600, Tom Marchant wrote: > > >On Sat, 12 Jan 2019 14:59:05 +1100, Wayne Bickerdike wrote: > > > >>Step end stats: > >> > >>IEF032I STEP/STEP020 /STOP 2019011.2148 > >> > >>CPU: 0 HR 00 MIN 00.05 SECSRB: 0 HR 00 MIN 00.01 > >>SEC > >>VIRT: 7908K SYS: 260K EXT:4K SYS:10876K > >> > >>ATB- REAL: 3104K SLOTS: 0K > >> > >> VIRT- ALLOC: 12M SHRD: 0M > >> > >> > > > >Look at module DFHEISUP in the load library. Is it marked RMODE(24)? > According to your Fault Analyzer report, the module is over 7 MB and it > seems to be loaded below the line. Your job is using only 4K above the line. > > > >I would suggest you open a PMR with IBM. > > I looked at DFHEISUP on our system. It is indeed over 7MB in size and is > marked RMODE(24). > > Open a PMR with CICS. IMO, there is no excuse for such a large module > requiring RMODE(24). > > -- > Tom Marchant > > > > >>On Sat, Jan 12, 2019 at 2:52 PM Wayne Bickerdike > wrote: > >> > >>> REGION=0M and same abend with REGION=512M. > >>> > >>> Took an SVC dump, here's some FA information. > >>> > >>> JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 > >>> 21:21:48 > >>> > >>> > >>> IBM Fault Analyzer Abend Job Information: > >>> > >>> Abend Date. . . . . . . . : 2019/01/11 > >>> Abend Time. . . . . . . . : 21:21:48 > >>> System Name . . . . . . . : S0W1 > >>> Job Type. . . . . . . . . : Batch > >>> Job ID. . . . . . . . . . : JOB02430 > >>> Job Name. . . . . . . . . : $SDO512M > >>> Job Step Name . . . . . . : n/a > >>> ASID. . . . . . . . . . . : 1C > >>> Abend TCB Address . . . . : 007FE990 > >>> Job Execution Class . . . : A > >>> Region Size . . . . . . . : 0M > >>> EXEC Program Name . . . . : DFHEISUP > >>> User ID . . . . . . . . . : BDB204 > >>> Accounting Information. . : n/a > >>> > >>> Execution Environment: > >>> > >>> Operating System. . . . . : z/OS V2R2M0 > >>> Data Facility Product . . : DFSMS z/OS V2R2M0 > >>> CPU Model . . . . . . . . : 2817 > >>> > >>> NOTE: The execution environment for this event is no longer valid, save > >>> areas > >>> and data might have subsequently been updated. This is normally > >>> caused > >>> by condition handling routine processing. > >>> > >>> > >>> > >>> Load Module Name. . . . . . : DFHEISUP > >>> > >>> At Address. . . . . . . . : 7F90 > >>> > >>> Load Module Length. . . . : X'7B6070' > >>> > >>> > >>> > >>> Machine Instruction . . . . : 0A08 SVC 8 (LOAD) > >>> > >>> At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset > X'7B5DE0') > >>> > >>> AMODE . . . . . . . . . . : 31 > >>> > >>> > >>> > >>> Additional instructions around event offset: > >>> > >>> > >>> > >>> Offset HexInstruction > >>> > >>>-2C 58C0 0010 L R12,16 > >>> > >>>-28 58C0 C000 L R12,0(,R12) > >>> > >>>-24 58C0 C004 L R12,4(,R12) > >>> > >>>-20 58C0 C144 L R12,324(,R12) > >>> > >>>-1C 58C0 C004 L R12,4(,R12) > >>> > >>>-18 BFCF C020 ICM R12,15,32(R12) > >>> > >>>-14 A784 0005 BRC 8,*+10 > >>> > >>>-10 180C LR R0,R12 > >>> > >>> -E A7F4 007D BRC 15,*+250 > >>> > >>> -A 4120 7008 LA R2,8(,R7) > >>> > >>> -6 4100 2000 LA R0,0(,R2) > >>> > >>> -2 1B11 SR R1,R1 > >>> > >>> 007BDD70 0A08 SVC 8(LOAD) > >>> > >>> +2 58C0 322C L R12,556(,R3) > >>> > >>> +6 166C OR R6,R12 > >>> > >>> +8 164C OR R4,R12 > >>> > >>> +A A7F4 0071 BRC 15,*+226 > >>> > >>> JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 > >>> 21:21:48 > >>> +2 58C0 322C L R12,556(,R3) > >>> > >>> +6 166C OR R6,R12 > >>> > >>> +8 164C OR R4,R12 > >>> > >>> +A A7F4 0071 BRC 15,*+226 > >>> > >>> +E A7F8 0010 LHI R15,16 > >>> > >>> +12 5820 7018 L R2,24(,R7) > >>> > >>> +16 1812 LR R1,R2 > >>> > >>> > >>> > >>> Program Status Word (PSW) . : 078D 807BDD72 > >>> > >>> PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 8, AMODE 31, > >>> Problem > >>>State > >>> > >>> > >>> > >>> General Purpose Registers (AMODE: 64 31 24 , Bytes: Dec Hex ): > >>> >
Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
Ed, I also participate in ASSEMBLER-LIST and I don't remember such a discussion. Can you pinpoint the approximate time period for that discussion? My biggest complaint/concern with the vector instructions is the woeful lack of any example code showing how to use them for just the kind of functions you described. It's hard to imagine how to use such complex instructions without at least some straight-forward examples. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, January 14, 2019 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue) On 1/13/2019 8:47 PM, David Crayford wrote: Sadly, I've tried to convince the assembler programmers on ASSEMBLER-LIST that vector instructions are useful for such purposes, but have been met with a surprising level of skepticism (despite my real-world experience and glowing endorsement) -- primarily due to flawed interpretation of what they've read in PoOp rather than just trying it out and seeing for themselves. Oh well... LOL -- 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: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
> I've taken to defining functions in header files to take advantage of both > (we don't use IPA). Looking at the code generated by the XLC compiler, I see that it sometimes (often?) in-lines functions even when they are defined in the (same, obviously) implementation file. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Sunday, January 13, 2019 8:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue) On 14/01/2019 6:06 am, Ed Jaffe wrote: > On 1/13/2019 4:08 AM, David Crayford wrote: >> On 13/01/2019 7:06 pm, Tony Thigpen wrote: >>> I have seen some reports that current C compilers, which understand >>> the z-hardware pipeline, can actually produce object that is faster >>> running than an assembler. Mainly because no sane assembler >>> programmer would produce great pipe-line code because it would be >>> un-maintanable. >>> >> It's well established that that's been true for a well over a decade >> now. Not just C but all compilers including COBOL which got a new >> optimizer a few releases back. > > > Far, far less true now than it used to be. > Good to hear. The best optimization is done in hardware where you don't have to recompile. Followed by a JIT. > Back in the old days, things ran a lot faster if you interleaved > unrelated things in an "unfriendly" way. For example, this code fragment: > > |LGF R0,Field1 Increment Field1 > |AGHI R0,1(same) > |ST R0,Field1 (same) > |LGF R0,Field2 Increment Field2 > |AGHI R0,1(same) > |ST R0,Field2 (same) > |LGF R0,Field3 Increment Field3 > |AGHI R0,1(same) > |ST R0,Field3 (same) > |LGF R0,Field4 Increment Field4 > |AGHI R0,1(same) > |ST R0,Field4 (same) > > ran much faster when coded this way (which is not how a programmer > would usually write things): > > |LGF R0,Field1 Increment Field1 > |LGF R1,Field2 Increment Field2 > |LGF R2,Field3 Increment Field3 > |LGF R3,Field4 Increment Field4 > |AGHI R0,1(same) > |AGHI R1,1(same) > |AGHI R2,1(same) > |AGHI R3,1(same) > |ST R0,Field1 (same) > |ST R1,Field2 (same) > |ST R2,Field3 (same) > |ST R3,Field5 (same) > > But once OOO execution came on the scene with z196, you could get the > same enhanced performance from this easy-to-code and easy-to-read > version: > > |LGF R0,Field1 Increment Field1 > |AGHI R0,1(same) > |ST R0,Field1 (same) > |LGF R1,Field2 Increment Field2 > |AGHI R1,1(same) > |ST R1,Field2 (same) > |LGF R2,Field3 Increment Field3 > |AGHI R2,1(same) > |ST R2,Field3 (same) > |LGF R3,Field4 Increment Field4 > |AGHI R3,1(same) > |ST R3,Field4 (same) > > These days, many performance improvements are realized by the compiler > using newer instructions that replace older ones. For example, on z10 > and higher, this very same code can be replaced with: > > |ASI Field1,1Increment Field1 > |ASI Field2,1Increment Field1 > |ASI Field3,1Increment Field1 > |ASI Field4,1Increment Field1 > IIRC, the interleaved instruction scheduling was to mitigate the AGI problem? In my experienced the two optimizations that make the most difference are function inlining and loop unrolling. I've taken to defining functions in header files to take advantage of both (we don't use IPA). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol and Hiperspace (was 64-bit C code fetching IGGCSI00)
Peter: My typos ..sorry the question was in regard to a Cobol program creating and then referencing Hiperspaces. You answer was what I thought, so thank you. Scott On Mon, Jan 14, 2019 at 12:59 PM Peter Relson wrote: > > > So how does a Cobol Pgm , 31bit address say a Hiperspace ? > > I assume an interface program units AR registers , etc., am I correct ? > > I have don’t this want to... > > > I could not parse this. What were you trying to ask? > > Hiperspaces are not directly referenced. You use services to put data in > and get data out. And then you reference the buffer you identified, which > is in your address space. So aside from invoking the hiperspace services > themselves (and dspserv to create/delete the hiperspace), there's nothing > special related to Cobol (or any other language). > > HSPSERV supports only AMODE 31 invocation. > > 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 > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a utility or command that will show load module characteristics?
File-AID/MVS should provide what you are looking for using option 3.1, Library Utilitiy. File-AID - Directory Information --- COMMAND ===> Dataset: PFHKXC0.USER.ISPLLIB(ESSCOBL) TTR 24 - - - - - - - - - - - - Directory entry in HEX format - - - - - - - - - - - - Char ESSCOBL B\.. Zone CEECDCD40022CE0100818000 Numr 52236230004C200E80C20100 +1+2+3+. SSI: - - - - - - - - - - - - - - Link edit attributes - - - - - - - - - - - - - - EP 00 SIZE (HEX) 001E08 (DEC) 7,688 RENT YES OVLYNO SCTRNO REUS YES DC NO NE NO REFR NO EP ZERO YESZERO ORIGIN YES OL NO TESTNO TEST SYMBOLSNO EXEC YES RLD YES1 BLOCK/NO RLD NO RMODEANY PAGE ALIGN NO APF CODE000 AMODE31 You can also get information on specific CSECTs within the LOADMOD including compiler, compiler options (COBOL and PL/I), dates, A/R modes, etc. KEVIN CORBETT | Product Manager | Compuware -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Thursday, November 1, 2018 1:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there a utility or command that will show load module characteristics? if you have IBM file manager or File-aid that may give you what you want Load Module COFDBIRD Linked on 2017.118 at 10:01:16 by PROGRAM BINDER 5695-PMB V2R1 EPA 00 Size 0002290 TTR 000315 SSI AC 01 AM 24 RM 24 Address CSECT name Type Size AMODE RMODE Compiler 1 → * * * * * <---+-> <---+10---+-> <--> <---+-> <---> <---> <---+10---+2+> 000 COFDBIRD SD 000228A 24 24 HIGH-LEVEL ASSEMBLER V1R6 000 COFDBIRD.COFDBIRD LD 000228A 24 24 HIGH-LEVEL ASSEMBLER V1R6 End of data Carmen Vitullo - Original Message - From: "Charles Mills" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 1, 2018 12:46:30 PM Subject: Is there a utility or command that will show load module characteristics? Seems like there should be a way to do this. I tried IEHLIST LISTPDS FORMAT but it seems pretty basic. The library in question is a PDSE, so I guess the right term is "program object." I'm most interested in alternative entry point names and their addresses. I'd prefer an IBM utility to a CBT program just because it would be quicker to do. Few vendor products available in my datacenter. Charles -- 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 The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unreadable code (Was: Concurrent Server Task Dispatch issue multitasking issue)
On 1/13/2019 8:47 PM, David Crayford wrote: IIRC, the interleaved instruction scheduling was to mitigate the AGI problem? Yes. The AGI "problem" is still there, but with an OOO machine you can avoid it simply by using different registers rather than by completely reordering your code. In my experienced the two optimizations that make the most difference are function inlining and loop unrolling. I've taken to defining functions in header files to take advantage of both (we don't use IPA). Yes. both are important. In HLASM one would use a macro to inline a function. Manual loop unrolling is something we do only in the performance path. I've noticed (depending on compiler options) the C optimizer is starting to use vector instructions. They can be a bit hairy even for experienced assembler programmers. Best to leave that to a compiler IMO. Haha! We were part of the z13s ESP and we started using vector instructions in our HLASM programs even before the machine was GA! We use them for all kinds of primitives including string FIND, bitmap manipulation, and other equally-simple, but important, stuff. Those "vectorized" routines perform literally orders of magnitude faster than their non-vector counterparts! Using them instead of SRST, we were able reduce the total CPU used by an (E)JES FIND across a multi-million line SPOOLed report by something in the neighborhood of 23%! (And if you can imagine all of the other work being done -- such as calling numerous routines, stack manipulation, reading and deblocking of SPOOL records, etc. -- 23% is a HUGE amount!!!) Sadly, I've tried to convince the assembler programmers on ASSEMBLER-LIST that vector instructions are useful for such purposes, but have been met with a surprising level of skepticism (despite my real-world experience and glowing endorsement) -- primarily due to flawed interpretation of what they've read in PoOp rather than just trying it out and seeing for themselves. Oh well... LOL -- 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: Cobol and Hiperspace (was 64-bit C code fetching IGGCSI00)
> So how does a Cobol Pgm , 31bit address say a Hiperspace ? > I assume an interface program units AR registers , etc., am I correct ? > I have don’t this want to... I could not parse this. What were you trying to ask? Hiperspaces are not directly referenced. You use services to put data in and get data out. And then you reference the buffer you identified, which is in your address space. So aside from invoking the hiperspace services themselves (and dspserv to create/delete the hiperspace), there's nothing special related to Cobol (or any other language). HSPSERV supports only AMODE 31 invocation. 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: ASCRE init module
I am thinking storage in a user sub-pool and saving the address in the ACEE since we create that. An ASCRE Initialization routine must not obtain storage in user-region subpools because after the initialization routine runs, the user region is (re-)initialized. Maybe you shouldn't be creating an ACEE (at least not until the jobstep program begins)? 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: HCD question
Guys: I want to build a three pack rescue system , where do i find the 'how to ' ...?? Scott On Mon, Jan 14, 2019 at 10:51 AM R.S. wrote: > W dniu 2019-01-14 o 13:16, Tony Thigpen pisze: > > We have a 3-pack rescue system that was built by a person long-gone. > > On the 3-pack system, there are several IODF files. I need to update > > the current IODF file. > > > > But, the IODF files on the rescue packs are not cataloged to the > > production z/OS. When I use the HCD panels, it does not appear that > > there is a way to specify the volume where the file is located, so HCD > > always says the file can not be found. > > > > Is there a way to specify the volume, along with the name, when using > > the panel? Or, a command to start the panels using the uncataloged > > IODF file? > > > > BTDT many times. > Few ways: > 1. Just copy hlq.IODF to the3-pack system and have in ming this file > will be uncataloged from 3-pack system point of view. However this is > quite OK for IPL. In addition put packed version (DSS DUMP, IDCAMS > EXPORT) of the IODF just to unpack it under 3-pack system. > > 2. Use cross-system cataloging, which is allowed for VSAM files with > HLQ=SYS1. So your IODF will be in your MCAT and in 3-packs's MCAT. Not > convenient, but feasible. You can still use the newest (uncataloged in > 3-pack) IODF for IPL and then recatalog it. > > 3. Take the smallest volume, name it SHARED or as you want. Put there > UCAT and define alias, lets say . Name your iodf files: .IODFxx. > Import connect the UCAT in you 3-pack system and any other system. Done > once work forever. Suggested way IMHO. > > > > > -- > 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 > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
On Mon, 14 Jan 2019 08:30:20 -0600, Tom Marchant wrote: >On Sat, 12 Jan 2019 14:59:05 +1100, Wayne Bickerdike wrote: > >>Step end stats: >> >>IEF032I STEP/STEP020 /STOP 2019011.2148 >> >>CPU: 0 HR 00 MIN 00.05 SECSRB: 0 HR 00 MIN 00.01 >>SEC >>VIRT: 7908K SYS: 260K EXT:4K SYS:10876K >> >>ATB- REAL: 3104K SLOTS: 0K >> >> VIRT- ALLOC: 12M SHRD: 0M >> >> > >Look at module DFHEISUP in the load library. Is it marked RMODE(24)? According >to your Fault Analyzer report, the module is over 7 MB and it seems to be >loaded below the line. Your job is using only 4K above the line. > >I would suggest you open a PMR with IBM. I looked at DFHEISUP on our system. It is indeed over 7MB in size and is marked RMODE(24). Open a PMR with CICS. IMO, there is no excuse for such a large module requiring RMODE(24). -- Tom Marchant > >>On Sat, Jan 12, 2019 at 2:52 PM Wayne Bickerdike wrote: >> >>> REGION=0M and same abend with REGION=512M. >>> >>> Took an SVC dump, here's some FA information. >>> >>> JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 >>> 21:21:48 >>> >>> >>> IBM Fault Analyzer Abend Job Information: >>> >>> Abend Date. . . . . . . . : 2019/01/11 >>> Abend Time. . . . . . . . : 21:21:48 >>> System Name . . . . . . . : S0W1 >>> Job Type. . . . . . . . . : Batch >>> Job ID. . . . . . . . . . : JOB02430 >>> Job Name. . . . . . . . . : $SDO512M >>> Job Step Name . . . . . . : n/a >>> ASID. . . . . . . . . . . : 1C >>> Abend TCB Address . . . . : 007FE990 >>> Job Execution Class . . . : A >>> Region Size . . . . . . . : 0M >>> EXEC Program Name . . . . : DFHEISUP >>> User ID . . . . . . . . . : BDB204 >>> Accounting Information. . : n/a >>> >>> Execution Environment: >>> >>> Operating System. . . . . : z/OS V2R2M0 >>> Data Facility Product . . : DFSMS z/OS V2R2M0 >>> CPU Model . . . . . . . . : 2817 >>> >>> NOTE: The execution environment for this event is no longer valid, save >>> areas >>> and data might have subsequently been updated. This is normally >>> caused >>> by condition handling routine processing. >>> >>> >>> >>> Load Module Name. . . . . . : DFHEISUP >>> >>> At Address. . . . . . . . : 7F90 >>> >>> Load Module Length. . . . : X'7B6070' >>> >>> >>> >>> Machine Instruction . . . . : 0A08 SVC 8 (LOAD) >>> >>> At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset X'7B5DE0') >>> >>> AMODE . . . . . . . . . . : 31 >>> >>> >>> >>> Additional instructions around event offset: >>> >>> >>> >>> Offset HexInstruction >>> >>>-2C 58C0 0010 L R12,16 >>> >>>-28 58C0 C000 L R12,0(,R12) >>> >>>-24 58C0 C004 L R12,4(,R12) >>> >>>-20 58C0 C144 L R12,324(,R12) >>> >>>-1C 58C0 C004 L R12,4(,R12) >>> >>>-18 BFCF C020 ICM R12,15,32(R12) >>> >>>-14 A784 0005 BRC 8,*+10 >>> >>>-10 180C LR R0,R12 >>> >>> -E A7F4 007D BRC 15,*+250 >>> >>> -A 4120 7008 LA R2,8(,R7) >>> >>> -6 4100 2000 LA R0,0(,R2) >>> >>> -2 1B11 SR R1,R1 >>> >>> 007BDD70 0A08 SVC 8(LOAD) >>> >>> +2 58C0 322C L R12,556(,R3) >>> >>> +6 166C OR R6,R12 >>> >>> +8 164C OR R4,R12 >>> >>> +A A7F4 0071 BRC 15,*+226 >>> >>> JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 >>> 21:21:48 >>> +2 58C0 322C L R12,556(,R3) >>> >>> +6 166C OR R6,R12 >>> >>> +8 164C OR R4,R12 >>> >>> +A A7F4 0071 BRC 15,*+226 >>> >>> +E A7F8 0010 LHI R15,16 >>> >>> +12 5820 7018 L R2,24(,R7) >>> >>> +16 1812 LR R1,R2 >>> >>> >>> >>> Program Status Word (PSW) . : 078D 807BDD72 >>> >>> PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 8, AMODE 31, >>> Problem >>>State >>> >>> >>> >>> General Purpose Registers (AMODE: 64 31 24 , Bytes: Dec Hex ): >>> >>>R0: 007BDA48 (Module DFHEISUP + X'7B5AB8') >>> >>>R1: (2,048 bytes of storage addressable) >>> >>>R2: 007BDA48 (Module DFHEISUP + X'7B5AB8') >>> >>>R3: 007BDC78 (Module DFHEISUP + X'7B5CE8') >>> >>>R4: 0064 (1,948 bytes of storage addressable) >>> >>>R5: 6FE8 (8,093,720 bytes of storage addressable) >>> >>>R6: 007BD800 (Module DFHEISUP + X'7B5870') >>> >>>R7: 807BDA40 (Module DFHEISUP + X'7B5AB0') >>> >>>R8: 007AED20 (Module DFHEISUP + X'7A6D90') >>> >>>R9: 007F8190 (32,368 bytes of storage addressable) >>> >>>R10: (2,048 bytes of storage addressable) >>> >>>R11: 807BD82A (Module DFHEISUP +
Re: HCD question
W dniu 2019-01-14 o 13:16, Tony Thigpen pisze: We have a 3-pack rescue system that was built by a person long-gone. On the 3-pack system, there are several IODF files. I need to update the current IODF file. But, the IODF files on the rescue packs are not cataloged to the production z/OS. When I use the HCD panels, it does not appear that there is a way to specify the volume where the file is located, so HCD always says the file can not be found. Is there a way to specify the volume, along with the name, when using the panel? Or, a command to start the panels using the uncataloged IODF file? BTDT many times. Few ways: 1. Just copy hlq.IODF to the3-pack system and have in ming this file will be uncataloged from 3-pack system point of view. However this is quite OK for IPL. In addition put packed version (DSS DUMP, IDCAMS EXPORT) of the IODF just to unpack it under 3-pack system. 2. Use cross-system cataloging, which is allowed for VSAM files with HLQ=SYS1. So your IODF will be in your MCAT and in 3-packs's MCAT. Not convenient, but feasible. You can still use the newest (uncataloged in 3-pack) IODF for IPL and then recatalog it. 3. Take the smallest volume, name it SHARED or as you want. Put there UCAT and define alias, lets say . Name your iodf files: .IODFxx. Import connect the UCAT in you 3-pack system and any other system. Done once work forever. Suggested way IMHO. -- 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: Exit Calls or Using
I agree with Skip, working in Security, i.e. ; RACF etc, usually exits enforced rules , such as passwords or installation restrictions and / or standards. Scott On Fri, Jan 4, 2019 at 10:02 PM Jesse 1 Robinson wrote: > Tom and I grappled with a menagerie of system exits that had been adopted > and adapted by SCE during the 70s (?) and 80s. Exit code had been tweaked > to some extent to fit installation standards, but likewise standards had > been shaped to some extent by the way exits worked. Today when I get > questions about why we do things a certain way, I sometimes answer honestly > 'just cuz'. This is not a dodge. At core is the issue of what it's worth to > do things a different way. > > My current colleagues brought with them the delightful term 'scream test'. > When you believe you have rendered something unnecessary--whether exit code > or a whole product--you shut it off and listen for complaints. The problem > with this strategy is that a deficiency may not show up right away. Worst > of all, once revealed, the deficiency may prove expensive to recover from. > This is another flavor of the question "what's it worth to do things a > different way?" > > My recommendation. If continuing to do things the same way exposes an > insurmountable obstacle--like needing to modify an exit whose source code > has dropped off the earth--then resolve to seek an extraordinary remedy. > Otherwise never mind. > > . > . > 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 Tom Brennan > Sent: Friday, January 04, 2019 10:03 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Exit Calls or Using > > On 1/4/2019 4:35 AM, Peter Relson wrote: > > > Whether or not your exit routine is doing anything useful can only be > > determined by examining the routine and understanding the exit. > > That means someone has to find the source code, make sure it's the actual > version running, and then be able to understand it well enough to make a > decision about whether the processing is needed or not. I've seen sites > where even step 1 is a problem. So maybe a more realistic approach might > be: Turn off the exit, wait to see if the phone rings, and be ready to put > it back. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
I'd still like Wayne to post the untruncated CSV031I message... (or re-post it if he had done so but I missed amidst the many appends). Check out the reason code of the S106-xx message. It could be that the module it's trying to load is in LLA, but LLA REFRESH was not done after replacing the module. LLA is involved (the DDNAME of *VLF* shows that). The 106-0C is due to an obtain of storage being unsuccessful. I can't think of a way that LLA REFRESH could have an impact (whether done or not done). S106 - 0C - NOT ENOUGH STORAGE WAS AVAILABLE FOR FETCH TO DO A GETMAIN FOR THE MODULE OR CONTROL BLOCKS. CHECK REGISTER 0: If you're going to post something like this, please post from the official documentation. That documentation is "Not enough storage was available for FETCH to get storage for the module or control blocks.". There is no information in register 0. The specific piece of data happens to be in register 4 (feel free to submit an RCF to ask that this be included in the documentation). As shown in one of the posts, the value in reg 4 at time of the abend 106-0C is x'14'. The module appears to be small (less than x'C000') and has no relocation needs. Since there was no relocation, the only reason for the 106-0C for x'14' for *VLF* is that LLA's attempt to obtain storage for that amount was not successful. For all I know, the utility did some variable-length GETMAIN and ate up all the private storage below 16M. Take a dump of the address space and see. And look at the system trace entry for the completion of the conditional getmain (an SSRV entry) which would contain things such as the size requested (in case there was some weirdness going on between the "right size" and the "requested size"). You could always try things like stopping LLA, or not having LLA manage the CEE.SCEERUN (perhaps named SYS1.CEE.SCEERUN) data set. That would keep LLA from trying to obtain the storage, but then normal module fetch would try to obtain the same amount. I wonder if the difference between releases is that the module in question (which sounds like it's CEEBINIT) is now eligible for LLA caching (but doesn't work for some reason once it is cached), whereas it did not used to be. 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: Abend 106 (was Generic query on Region allocation failure)
On Sat, 12 Jan 2019 14:59:05 +1100, Wayne Bickerdike wrote: >Step end stats: > >IEF032I STEP/STEP020 /STOP 2019011.2148 > >CPU: 0 HR 00 MIN 00.05 SECSRB: 0 HR 00 MIN 00.01 >SEC >VIRT: 7908K SYS: 260K EXT:4K SYS:10876K > >ATB- REAL: 3104K SLOTS: 0K > > VIRT- ALLOC: 12M SHRD: 0M > > Look at module DFHEISUP in the load library. Is it marked RMODE(24)? According to your Fault Analyzer report, the module is over 7 MB and it seems to be loaded below the line. Your job is using only 4K above the line. I would suggest you open a PMR with IBM. -- Tom Marchant >On Sat, Jan 12, 2019 at 2:52 PM Wayne Bickerdike wrote: > >> REGION=0M and same abend with REGION=512M. >> >> Took an SVC dump, here's some FA information. >> >> JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 >> 21:21:48 >> >> >> IBM Fault Analyzer Abend Job Information: >> >> Abend Date. . . . . . . . : 2019/01/11 >> Abend Time. . . . . . . . : 21:21:48 >> System Name . . . . . . . : S0W1 >> Job Type. . . . . . . . . : Batch >> Job ID. . . . . . . . . . : JOB02430 >> Job Name. . . . . . . . . : $SDO512M >> Job Step Name . . . . . . : n/a >> ASID. . . . . . . . . . . : 1C >> Abend TCB Address . . . . : 007FE990 >> Job Execution Class . . . : A >> Region Size . . . . . . . : 0M >> EXEC Program Name . . . . : DFHEISUP >> User ID . . . . . . . . . : BDB204 >> Accounting Information. . : n/a >> >> Execution Environment: >> >> Operating System. . . . . : z/OS V2R2M0 >> Data Facility Product . . : DFSMS z/OS V2R2M0 >> CPU Model . . . . . . . . : 2817 >> >> NOTE: The execution environment for this event is no longer valid, save >> areas >> and data might have subsequently been updated. This is normally >> caused >> by condition handling routine processing. >> >> >> >> Load Module Name. . . . . . : DFHEISUP >> >> At Address. . . . . . . . : 7F90 >> >> Load Module Length. . . . : X'7B6070' >> >> >> >> Machine Instruction . . . . : 0A08 SVC 8 (LOAD) >> >> At Address. . . . . . . . : 007BDD70 (Module DFHEISUP offset X'7B5DE0') >> >> AMODE . . . . . . . . . . : 31 >> >> >> >> Additional instructions around event offset: >> >> >> >> Offset HexInstruction >> >>-2C 58C0 0010 L R12,16 >> >>-28 58C0 C000 L R12,0(,R12) >> >>-24 58C0 C004 L R12,4(,R12) >> >>-20 58C0 C144 L R12,324(,R12) >> >>-1C 58C0 C004 L R12,4(,R12) >> >>-18 BFCF C020 ICM R12,15,32(R12) >> >>-14 A784 0005 BRC 8,*+10 >> >>-10 180C LR R0,R12 >> >> -E A7F4 007D BRC 15,*+250 >> >> -A 4120 7008 LA R2,8(,R7) >> >> -6 4100 2000 LA R0,0(,R2) >> >> -2 1B11 SR R1,R1 >> >> 007BDD70 0A08 SVC 8(LOAD) >> >> +2 58C0 322C L R12,556(,R3) >> >> +6 166C OR R6,R12 >> >> +8 164C OR R4,R12 >> >> +A A7F4 0071 BRC 15,*+226 >> >> JOBNAME: $SDO512M SYSTEM ABEND: 106S0W1 2019/01/11 >> 21:21:48 >> +2 58C0 322C L R12,556(,R3) >> >> +6 166C OR R6,R12 >> >> +8 164C OR R4,R12 >> >> +A A7F4 0071 BRC 15,*+226 >> >> +E A7F8 0010 LHI R15,16 >> >> +12 5820 7018 L R2,24(,R7) >> >> +16 1812 LR R1,R2 >> >> >> >> Program Status Word (PSW) . : 078D 807BDD72 >> >> PSW Summary . . . . . . . . : Primary Space Mode, PSW Key 8, AMODE 31, >> Problem >>State >> >> >> >> General Purpose Registers (AMODE: 64 31 24 , Bytes: Dec Hex ): >> >>R0: 007BDA48 (Module DFHEISUP + X'7B5AB8') >> >>R1: (2,048 bytes of storage addressable) >> >>R2: 007BDA48 (Module DFHEISUP + X'7B5AB8') >> >>R3: 007BDC78 (Module DFHEISUP + X'7B5CE8') >> >>R4: 0064 (1,948 bytes of storage addressable) >> >>R5: 6FE8 (8,093,720 bytes of storage addressable) >> >>R6: 007BD800 (Module DFHEISUP + X'7B5870') >> >>R7: 807BDA40 (Module DFHEISUP + X'7B5AB0') >> >>R8: 007AED20 (Module DFHEISUP + X'7A6D90') >> >>R9: 007F8190 (32,368 bytes of storage addressable) >> >>R10: (2,048 bytes of storage addressable) >> >>R11: 807BD82A (Module DFHEISUP + X'7B589A') >> >>R12: (2,048 bytes of storage addressable) >> >>R13: 6F50 (8,093,872 bytes of storage addressable) >> >>R14: 807BD8FE (Module DFHEISUP + X'7B596E') >> >>R15: 007BDC78 (Module DFHEISUP + X'7B5CE8') >> >> Abend Code. . . . . . . . . : S106-X'C' >> >> Machine Instruction . . . . : 0A0D SVC 13 (ABEND) >>At Address. . . . . . . . : 01074DB8 >>AMODE .
Re: zos program to supply web based client
> On Jan 11, 2019, at 11:14 PM, Brian Westerman > wrote: > > Since it does use Adabas, maybe EntireX is the proper answer for this. Right. Also, you mentioned COM-PLETE, which has some ability to act as a web server. You might investigate that. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HCD question
Hi Tony, You could use IDCAMS with DEFINE RECATALOG (before invoking HCD). Regards, David On 2019-01-14 07:52, Tony Thigpen wrote: > Thanks, Sounds like EXPORT/IMPORT is the best way. I was hoping for > some 'trick' with the panels, but I guess not. > > Tony Thigpen > > Gadi Ben-Avi wrote on 1/14/19 7:22 AM: >> This is a job I use to copy an IODF to another system. >> //DEL EXEC PGM=IDCAMS >> //SYSPRINT DD SYSOUT=* >> //DD1 DD DISP=SHR,UNIT=3390,VOL=SER=Z23R01 >> //SYSIN DD * >> DELETE SYS1.IODF15.CLUSTER FILE(DD1) CATALOG(ICFCAT.MCATZ23) >> SET MAXCC = 0 >> //DSSC0087 EXEC PGM=ADRDSSU >> //SYSPRINT DD SYSOUT=* >> //SYSIN DD * >> COPY DATASET( - >> INCLUDE( - >> SYS1.IODF15.CLUSTER - >> )) - >> REPLACE - >> TOL(ENQF) - >> BYPASSACS(**) - >> NULLSTORCLAS - >> PROCESS(SYS1) - >> RECATALOG(ICFCAT.MCATZ23) - >> OUTDYNAM(Z23R01) - >> SHARE >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Tony Thigpen >> Sent: Monday, January 14, 2019 2:16 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: HCD question >> >> We have a 3-pack rescue system that was built by a person long-gone. >> On the 3-pack system, there are several IODF files. I need to update >> the current IODF file. >> >> But, the IODF files on the rescue packs are not cataloged to the >> production z/OS. When I use the HCD panels, it does not appear that >> there is a way to specify the volume where the file is located, so >> HCD always says the file can not be found. >> >> Is there a way to specify the volume, along with the name, when using >> the panel? Or, a command to start the panels using the uncataloged >> IODF file? >> >> -- >> Tony Thigpen >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> הודעה זו נשלחה אליך מטעם חברה בקבוצת מלם תים וייתכן שהיא מוגנת תחת >> סודיות מסחרית. כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד >> וחתום על ידי מורשה החתימה של החברה. החברה רשאית לנטר כל תכתובת העוברת >> בשרתיה והיא לא תישא באחריות לכל נזק, ו/או אובדן, שיבוש או פגיעה במידע >> כלשהו שנגרם מסיבות של תקיפה חיצונית ו/או זדונית על הארגון. >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HCD question
Thanks, Sounds like EXPORT/IMPORT is the best way. I was hoping for some 'trick' with the panels, but I guess not. Tony Thigpen Gadi Ben-Avi wrote on 1/14/19 7:22 AM: This is a job I use to copy an IODF to another system. //DEL EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //DD1 DD DISP=SHR,UNIT=3390,VOL=SER=Z23R01 //SYSIN DD * DELETE SYS1.IODF15.CLUSTER FILE(DD1) CATALOG(ICFCAT.MCATZ23) SET MAXCC = 0 //DSSC0087 EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //SYSIN DD * COPY DATASET( - INCLUDE( - SYS1.IODF15.CLUSTER - )) - REPLACE- TOL(ENQF) - BYPASSACS(**) - NULLSTORCLAS - PROCESS(SYS1) - RECATALOG(ICFCAT.MCATZ23) - OUTDYNAM(Z23R01) - SHARE -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Thigpen Sent: Monday, January 14, 2019 2:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: HCD question We have a 3-pack rescue system that was built by a person long-gone. On the 3-pack system, there are several IODF files. I need to update the current IODF file. But, the IODF files on the rescue packs are not cataloged to the production z/OS. When I use the HCD panels, it does not appear that there is a way to specify the volume where the file is located, so HCD always says the file can not be found. Is there a way to specify the volume, along with the name, when using the panel? Or, a command to start the panels using the uncataloged IODF file? -- Tony Thigpen -- 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: HCD question
This is a job I use to copy an IODF to another system. //DEL EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //DD1 DD DISP=SHR,UNIT=3390,VOL=SER=Z23R01 //SYSIN DD * DELETE SYS1.IODF15.CLUSTER FILE(DD1) CATALOG(ICFCAT.MCATZ23) SET MAXCC = 0 //DSSC0087 EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //SYSIN DD * COPY DATASET( - INCLUDE( - SYS1.IODF15.CLUSTER - )) - REPLACE- TOL(ENQF) - BYPASSACS(**) - NULLSTORCLAS - PROCESS(SYS1) - RECATALOG(ICFCAT.MCATZ23) - OUTDYNAM(Z23R01) - SHARE -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Thigpen Sent: Monday, January 14, 2019 2:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: HCD question We have a 3-pack rescue system that was built by a person long-gone. On the 3-pack system, there are several IODF files. I need to update the current IODF file. But, the IODF files on the rescue packs are not cataloged to the production z/OS. When I use the HCD panels, it does not appear that there is a way to specify the volume where the file is located, so HCD always says the file can not be found. Is there a way to specify the volume, along with the name, when using the panel? Or, a command to start the panels using the uncataloged IODF file? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN הודעה זו נשלחה אליך מטעם חברה בקבוצת מלם תים וייתכן שהיא מוגנת תחת סודיות מסחרית. כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשה החתימה של החברה. החברה רשאית לנטר כל תכתובת העוברת בשרתיה והיא לא תישא באחריות לכל נזק, ו/או אובדן, שיבוש או פגיעה במידע כלשהו שנגרם מסיבות של תקיפה חיצונית ו/או זדונית על הארגון. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] HCD question
Why not just export your IODF files from your production system and import them onto the rescue system volume? Or import/connect the catalog on the rescue system to your live system and use a different hlq (e.g. SYSR.) for those data sets? Just two thoughts - hope this helps. -- Lionel B. Dyck (Contractor) < Mainframe Systems Programmer - RavenTek Solution Partners -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Monday, January 14, 2019 6:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] HCD question We have a 3-pack rescue system that was built by a person long-gone. On the 3-pack system, there are several IODF files. I need to update the current IODF file. But, the IODF files on the rescue packs are not cataloged to the production z/OS. When I use the HCD panels, it does not appear that there is a way to specify the volume where the file is located, so HCD always says the file can not be found. Is there a way to specify the volume, along with the name, when using the panel? Or, a command to start the panels using the uncataloged IODF file? -- Tony Thigpen -- 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
HCD question
We have a 3-pack rescue system that was built by a person long-gone. On the 3-pack system, there are several IODF files. I need to update the current IODF file. But, the IODF files on the rescue packs are not cataloged to the production z/OS. When I use the HCD panels, it does not appear that there is a way to specify the volume where the file is located, so HCD always says the file can not be found. Is there a way to specify the volume, along with the name, when using the panel? Or, a command to start the panels using the uncataloged IODF file? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
