Goodbye, thanks, and take care!
I will retire by the end of the month. Thank you so much for all the help, and for all the bearing with me. I learnt a hell lot just by following this and other fora. Quite often I was able to solve problems based on the help and the advice given by you. I wish you good health and much fun. Goodbye Peter -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Where can I find an eexamples of an assembler modules using classes?
> It isn't obvious to me how one loads a deferred class (or which macro > instructions provide the support). Is it possible that the high-level > languages use the binder APIs to do it and there aren't any native zOS > services? I asked that some time last year, when I understood that Enterprise Cobol V5 and later uses this to store debug information with the load module instead of in side files. ISTR that Peter Relson responded that this is not intended to be a public interface. Tried to search IBM-MAIN so I could post a link, but somehow searching does not return any result for me today, no matter what I search for. — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Generic query on Region allocation failure
>I would like to make a suggestion. REGION=xxx and other settings should remain the same. If you specify REGION=(#K,#M,#G), where you are requesting 24, 31, and 64 bit memory amounts subject to other suffixes and normal override measures. I don‘t get your point. There is no „#G“ specification for REGION=, and you don‘t specify above the bar amounts (64bit memory) via REGION. — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Generic query on Region allocation failure
>So when we move to a higher version of hardware the storage area below the line shrinks ? Not necessarily. It may or may not, and the cautious system programmer may or may not be able to avoid it. There are certain boundaries in the address space map that must lie on a megabyte boundary. The boundary between the common and the private areas is one. A single byte more used in the common area might move the common-private boundary down by one megabyte. One is often able to reduced the size of some common areas (CSA/SQA) by a small about and thus avoid the common-private boundary shift. HTH Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: RES: Generic query on Region allocation failure
>A possible reason can be the fragmentation that normally occurs. >It is possble to prevent it by coding VSM CHECKREGIONLOSS(xxxK,xM) on your >>DIAGxx member of PARMLST. Such fragmentation can only occur in batch initiators, or z/OS UNIX initiators, aka BPXAS), which are address spaces that are being reused job by job, or UNIX process by UNIX process, resp. The OP talks about started tasks, and those get a new address space each time they are started. Fragmentation leading to S822 might only occur in multistep STCs, but even then would I consider it most unlikely. — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Generic query on Region allocation failure
>IEF085I REGION NOT AVAILABLE ERROR CODE = 20 >IEF187I NJJJ FAILED - SYSTEM ERROR IN INITIATOR >IEF472I NJJJ IEF085I lists four reasons for reason 20. You probably haven‘t specified V=R (ADDRSPC=REAL), so two of them do not apply. You mentioned „started task“, so there will be a new adderess space each time, thus fragmentation does not apply, leaving only „there is not enough virtual storage in the reason“ as explanation. Specifying REGION=5M gives you 5M below and 32M above. I cannot imagine 32M not being available above the line. The only reason left you be that you don‘t have 5M below now, but you had before the move. I/O defintions or other HW dependend parts might have cause the top of the private are below to drop from 5M to 4M. With what value of REGION does the STC run? I would guess that you specified some value larger or equal to 16M. This will give you all there is below the line, and allow the step to start. — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Wtrln.: Are those SSRV trace entires relate to the I/O interrupt?
>Yes, they are part of the I/O interrupt processing, and are not related to the interrupted program (unless the I/O operation that caused the interrupt is related to the interrupted program) . Thanks, Jim. Can you say something about when they occur and when not? Just curious because I see them most of the time in this dump but only occasionally in other dumps, it seems. — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Wtrln.: Are those SSRV trace entires relate to the I/O interrupt?
Agrrr.. Sorry for the misformatted mail. Trying again. I'm chasing another problem where an LE program (COBOL) gets into an endless, rather tight loop in CEEPLPKA after an S04E abend I'm trying to understand the relation between I/O interrupt system trace entries, and a pair of SSRV entries that very often follow the I/O entry. Here is a sample sequence from the trace: 0003 031C 009FEA30 DSP_0872C4B6 26C62364 0003 031C 009FEA30 EXT TIMR _0872BFAE 1005 0001 031C 009FEA30 DSP_0872BFAE 26C62364 0001 031C 009FEA30 I/O 06B16 _0872C2C8 00104007 745786C0 0001 031C 009FEA30 SSRV 11F 9EE5C3D6 16701A80 8000 157A25F8 0001 031C 009FEA30 SSRV 150 02F5F020 7EB06940 The program is dispatched (DSP), interrupted at end of time slice (EXT TIMR), dispatched again (DSP), then interrupted by an I/O which completed (I/O). Very often, two system service calls (SSRV), first for RELEASE (SSRV 115), second for DFSMS Media Manager ICYDIE (SSRV 150) are seen. First I thought the SSRVs are related to the program, but I now have my doubts. I'd rather think they are caused by I/O interrupt handling. Especially, since I have seen such sequences in another dumps, although much less often. Can anyone say something about the nature of those SSRV calls. Am I safe to say they do not belong to the problem at hand? — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Are those SSRV trace entires relate to the I/O interrupt?
I'm chasing another problem where an LE program (COBOL) gets into an endless, rather tight loop in CEEPLPKA after an S04E abend I'm trying to understand the relation between I/O interrupt system trace entries, and a pair of SSRV entries that very often follow the I/O entry. Here is a sample sequence from the trace: 0003 031C 009FEA30 DSP_0872C4B6 26C62364 0785 8000 0003 031C 009FEA30 EXT TIMR _0872BFAE 1005 07851000 8000 0001 031C 009FEA30 DSP_0872BFAE 26C62364 07851000 8000 0001 031C 009FEA30 I/O 06B16 _0872C2C8 00104007 745786C0 0C000100 0785 8000 025AC1C0 0040 0001 031C 009FEA30 SSRV 11F 9EE5C3D6 16701A80 8000 157A25F8 00F6 0001 031C 009FEA30 SSRV 150 02F5F020 7EB06940 The program is dispatched (DSP), interrupted at end of time slice (EXT TIMR), dispatched again (DSP), then interrupted by an I/O which completed (I/O). Very often, two system service calls (SSRV), first for RELEASE (SSRV 115), second for DFSMS Media Manager ICYDIE (SSRV 150) are seen.First I thought the SSRVs are related to the program, but I now have my doubts. I'd rather think they are caused by I/O interrupt handling. Especially, since I have seen such sequences in another dumps, although much less often. Can anyone say something about the nature of those SSRV calls. Am I safe to say they do not belong to the problem at hand? — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Thanks For All the Fish
Many thanks for all the help you offered, and the patience you always had with. Good health and best of all. May you enjoy every day. Best regards Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Setting MAXMMAPAREA
>What might be the impact of increasing this OMVS limit from 40,000 to 120,000 >What areas of OMVS or z/OS do I need to monitor to make sure "bad things" do >not happen You want to monitor ECSA usage (which you probably already do). This function is something alike „selective common area data-in-virtual“. It requires quite some ECSA storage to administer the virtual storage pages shared between mmap() users. See „MVS Initialization & Tuning Guide - BMXPRMxx“ - MAXMMAPAREA for details about how much ECSA is used. — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Region size for OMVS tasks
One more thought: Look At he SMF30 records for one such session. You should get an idea of what‘s going on in that process and its child processes. There will be one record for each command, i.e. when a fork()ed or spawd()ed process ends, and at each exec(). You may find the one program eating up all that storage. — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Peter, Mike: Yes, I remember Peter pointing at Mark's page, but for some reason I moved on past that to some other line of enquiry. I've now done what you said, and the results from REXXSTOR in PuTTY are: V I R T U A LS T O R A G EU S A G E --- REGION REQUESTED: 55296K LIMIT IN-USE AVAIL BELOW 16M: 8168K 4K 8164K ABOVE 16M: 2088984K 840K 2088144K So, the 55296K is that 54M that I've been chasing and the rest of the report shows that I've been given the maximum amount of memory possible - 2G, right? Have you cut some columns? There should be more. The "Limit" is a bit misleading, since you can only have some 1.5G, the rest is in use by the common area. Anyway, this session is not about to run out of storage, because only 840K are in use. But this is you session, not the developer's, who is having the problems, right. Can you have him to run that REXX after login and once he got to the out of storage? Since the problem occurs only with _BPX_SHAREAS=YES, when all the processes share a single address space, what exactly are they trying to do? What has change since it worked? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Region size for OMVS tasks
>http://mzelden.com/mvsutil.html Yep, this is the invaluable link. As I wrote before, try the REXXSTOR rexx found there and run it in a) TSO, b) TSO -> OMVS (shell under TSO), c) putty (shell vie TCP/IP). If possible run in the environment where you‘re getting the out of stroage, and run it under the userid that is getting the problem. This may or may not give you a hint what to do next — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Just recognized that the parameter STATE=INACTIVE was missing in my previous post SETPROG EXIT,MODIFY,EXITNAME=SYS.IEFUSI,MODNAME=IEFUSI,STATE=INACTIVE -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Trying to follow-up on the stuff that Peter has suggested, I'm still chasing that elusive '54M' - Who sets it? Where is it set? How can I override it? It seems you missed this statement in my first reply in this thread: IEFUSI will gin control in the BPXAS address space before the UNIX process gets control. OMVS set REGION to the magic value 54M. This has not meaning and will later be replaced by the values from the originating batch job. (I don‘t know why 54M was chosen as the indicator value.) So, when your IEFUSI sees that value it should leave REGION and MEMLIMIT alone. Have tried alternate members from SYS1.IPLPARM, but none of then specify sufficient paging space. The 922 indicates that the initiator's ESTAE routine got control because of another ABEND, a program check, etc. I assume your IEFUSI code has a bug. It's not a question of paging space (Why do you think that is related to the problem?) Have you tried to deactivate the IEFUSI from the console? SETPROG EXIT,MODIFY,EXITNAME=SYS.IEFUSI,MODNAME=IEFUSI If you don't know EXITNAME and MODNAME, use D PROG,EXITS to get a list of active exits, then D PROG,EXIT,EXITNAME= to display MODNAME -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Where did you get all this from? Is it documented somewhere, or is it something you've 'soaked up through your fingertips' over the years? So I went back to the FMs. For any question of kind "How does that UNIX service behave regarding MVS resources, attributes, etc.", I always read what the "z/OS UNIX System Services Programming - Assembler Callable Services Reference" tells me. If something is to be said, there is a section called "Usage Notes". Here are some interesting snippet: For fork() it says: - The child process inherits the MEMLIMIT of the parent. - The child address space inherits the following address space attributes of the parent address space: region size and time limit. For spawn() it says: - The region size of the parent is inherited by the child, unless the INHESETREGIONSZ flag in the inheritance structure is set on to indicate that the value specified in INHEREGIONSZ is to be used to determine the child's region size. For more information, see What are soft limits? in z/OS UNIX System Services Planning and Inheriting soft limits in z/OS UNIX System Services Planning. - The MEMLIMIT of the parent is inherited by the child, unless the INHESETMEMLIMIT flag in the inheritance structure is set on to indicate that the value specified in INHEMEMLIMIT is to be used to determine the child's MEMLIMIT. Another useful source of information is "z/OS UNIX System Services Planning". This FM says about MAXASSIZE: MAXASSIZE is the maximum region size (in bytes) for an address space that was created by rlogind, telnetd, and other daemons. The MAXASSIZE value limits the combined size of above and below the 16 M line storage. If MAXASSIZE is greater than LDALIMIT (the <16M limit), then the LDAELIM (the >16M limit) is set to MAXASSIZE - LDALIM. You can set a system-wide limit in BPXPRMxx and then set higher limits for individual processes. Use the RACF ADDUSER or ALTUSER command to specify the ASSIZEMAX limit on a per-process basis as follows: ALTUSER userid OMVS(ASSIZEMAX() This manual also has a couple of pages discussing all about limits. Of special interest to this discussion it the section called "How are limits handled after an identity change?", and the following sections. Its too much to copy here. I suggets you have a read if your interested. (I've got the impression this part has not always be there in that detail. Great it is now) -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Region size for OMVS tasks
>Peter: I'm still trying to fully assimilate what you've said - very detailed & complete. Where did you get all this from? Is it documented somewhere, or is it something you've 'soaked up through your fingertips' over the years? I pasted one section which is one part of the „documented somewhere“. There is probably more parts that are documents, but I was too lazy to seek them all. So it‘s comes to „soaked up through your fingertips“, or better „discussing on fora“ and soaking up though the eyes :-) I‘ve been following and teaching z/OS UNIX for a couple of years when it came out in 1994. A lot has been discussed, and tested back then. That is why I wrote 2fading memory“. I haven‘t been following changes to z/OS UNIX as close as I used to. >Given that (probably poorly-informed) stance, then REGION and MEMLIMIT limits become pretty much meaningless. Don't they? I‘m can agree regarding REGION; I do not regarding MEMLIMIT. I‘m convinced a program going wild using 64bit memory can bring the system down in no time, if it is *not* limited to a reason amount. Remember: Even though a z13, or a z14 can have up to 10TiB, or 32TiB of real memory installed, z/OS V2.2, and V2.3 can only support up to 4TiB. 4TiB is nothing compared to 16EiB (the full 64bit addressing range). Storage finally needs to be backed by real storage. And, real storage needs to be backed by paging storage (virtual flash memory or paging DASD). Given the fact that the largest supported DASD EAV volume is 1TiB now, you would need 16.8 Million 1TiB paging devices to be able to back one single 64bit address space. From experience I know that programs *do* eventually go wild. Better protect your system with a low MEMLIMIT, and allow larges values only sparingly. My $0.02 only, of course. — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Region size for OMVS tasks
From fading memory, so things might have change slightly, but I think most of this still applies. The REGION and MEMLIMIT values that apply to z/OS UNIX processes depend on how and where the process is running: a) BATCH jobs, started tasks, TSO user sessions A program run as batch job, started task, or in a TSO session gets its REGION and MEMLIMIT via JCL, which may be changed by IEFUSI (and IEFLIMIT). When this program makes use of z/OS UNIX services, it will become dubbed, i.e. it becomes a UINX process. It still runs in the same address space. Nothing changes with respect to REGION or MEMLIMT. When this process spawn()s (non-local spawn) or fork()s a new process, that new process will be in a BPXAS address space. REGION and MEMLIMT will be inherited from the originating batch job address space. None of the z/OS UNIX settings apply. IEFUSI will gin control in the BPXAS address space before the UNIX process gets control. OMVS set REGION to the magic value 54M. This has not meaning and will later be replaced by the values from the originating batch job. (I don‘t know why 54M was chosen as the indicator value.) b) If a z/OS UNIX process is a daemon, such as FTPD, otelnetd, etc. which listens for incoming session calls, then authenticates the new user, and spawn()s / fork()s a new process for this new user, then REGION and MEMLIMIT will be set from the z/OS UNIX parameters (ASSIZEMAX/MAXASSIZE, etc). It is not useful to inherit those values from the parent process in these cases. The parent is the server, the childs are the unser sessions. They serve different means. So, your IEFUSI should not touch the REGION and MEMLIMIT field when it is called for OMVS address spaces (see flags as described in the IEFUSI description). And, for the putty sessions, the MAXASSIZE or ASSIZEMAX value should apply. Try to run Mark Zelden‘s REXXSTOR in a TSO session, after TSO OMVS, and in a putty session to see the differences From the „z/OS MVs Installation Exits“ manual: Additional Considerations for z/OS UNIX Applications: When running z/OS UNIX applications you need to consider that fork and spawn are issued to create new address spaces. The default processing on fork and spawn is for the z/OS UNIX kernel to propagate the region size from the parent to the child. Because the region size in the parent process has already passed through IEFUSI and has an approved region size, IBM recommends that you bypass normal IEFUSI processing when the subsystem (Word 8) is OMVS. At the time of IEFUSI processing, the kernel has not yet propagated the parent's region size to the child, so IEFUSI has nothing to work with. If IEFUSI modifies the region size of the child process, the kernel will honor that region size and not propagate the region size from parent to child. This can result in failure of a fork if the region size is insufficient in the child to capture the parent's storage. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: COBOL 64bit
+1 -- Peter Hunkeler Von: "Farley, Peter x23353" An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: COBOL 64bit Datum: 17.10.18, 23:29 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: S106 abends after copying into LINKLIST
>Are you sure space is reclaimed for deleted members if the data set is open by >LNKLST? Interesting question. Easy to test for someone with a sandbox system (I don't have any such to play with). Well, one could test with STEPLIB but that does not tell anything, if there was special code in PDSE processing to recognize the data set is in linklist usage (I doubt there is, but who knows?) I would assume that the space is reclaimed not matter whether the data set is open or not. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: ASCRE and ACEE inheritance
Peter, I don't care. I tried to help Robin, the OP. Maybe you can help to solve his problem? -- Peter Hunkeler Von: Peter Relson An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: ASCRE and ACEE inheritance Datum: 18.09.18, 13:44 - Is the INIT routine run under the region control task, or under the started task control task (I suspect the latter)? Why do you care under which task the routine runs? You should probably not be doing anything that cares. FWIW, it does not run under the RCT task. And it does not run under the dump task either. It certainly runs under a task that is older than the jobstep program task (which has not yet been identified since the proc has not yet been read). Why does more need to be stated? - Have any allocations asked for via DD statement in the procedure already been done? Your observation seems to indicate: yes, they have. No they have not. "Before" is "before". 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: ASCRE and ACEE inheritance
>Apologies for the delay in replying but your response got flagged as spam >somewhere and I did not see it. I finally found it in the archives! My bad. The flag had been set by GMX, and I badly missed to remove it from the subject when replying. I recognized after sending, and for a quick moment thought to correct and resend, but then decided otherwise. Ag... I'm sorry. >I am not sure where the original ACEE of the child STC is coming from since >both it and the parent STC have similar JCL procedure names that match to the >same RACF rule. So the ACEE could be coming from the RACF rule or it could be >inherited (like with forked address spaces or jobs submitted via internal >reader). My problem is that there seem to be two sets of rules in play: the >data sets allocated by JCL get the original STC's ACEE and the dynamically >allocated ones get the new ACEE I set in the address space initialisation exit >(in ASXBSENV). The doc states that the initialisation exit runs before the JCL >procedure but perhaps some JCL processing happens at the same time. I'm surely not authoritative to write "this is how it works", but the statement "It executes in the new address space before the procedure identified by SYS1.PROCLIB." Is foggy. A procedure is not executed, programs are. Your problem makes clear that this part of the documentation should be enhanced: - Is the INIT routine run under the region control task, or under the stated task control task (I suspect the latter)? - Have any allocations asked for via DD statement in the procedure already been done? Your observation seems to indicate: yes, they have. Would an RCF be sufficient? -- Peter Hunkeler -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: TOD clock values, leap seconds and BLSUXTOD conversion service
>There is nothing in error with any of the conversion services. They do what they intend to do. And yes they do the easy part. Is that clear from the description of the service? At least for BLSUXTOD I can't remember to have read about that fact. >What there is is a lack of functionality that would usually be unimportant to >have. Usually unimportant Hmmm. Suppose, I have a case to chase where z/OS as well as some non-mainframe parts are involved. Looking at a SYSTRACE of a related dump. Timestamps show by IPCS and those from somewhere else are, as of the last leap-second, 27 seconds apart. I don't say I had bee burnt by such a case, yet. But I would not state this fact as unimportant. I can live with this. I'm just surprised. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
TOD clock values, leap seconds and BLSUXTOD conversion service
So this is the first time I really care for leap seconds. I need a conversion from TOD clock value to readable format in REXX. Found the BLSUXTOD service. Works nice. so far so good. The PoP has a table of TOD clock values taking care of the 26 leap seconds inserted so far. The last one was inserted on June 30, 2015 after 23:59:59. So there is a valid time stamp 23:59:60 on June 30st, just before July 1st, 00:00:00. If I take the value for July 1st, 2015 from the PoP table and subtract the equivalent of one second I understand this is the TOD value for June 30 23:59:60. Am I mixing up things? If all is correct so far, I think BLSUXTOD is in error. It does not take care of the leap seconds. For the above value, it returns July 1st, 2015 00:00:25 -- Peter Hunkeler -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: COBANALZ CBT file 321
I don't remember having ever specified the WORKFILE option. Have you tried without? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: *** GMX Spamverdacht *** ASCRE and ACEE inheritance
>The obvious solution would be to set the ACEE in the address-space >initialisation exit and that is what I did and it seemed to work. The new STC >is still owned by the mother task's ACEE but data set accesses are governed by >the new ACEE. Since ASCRE starts a new started task similar to the START operator command, the new STC's userid (owner) and default group are determined by RACF (STARTED class profiles). Is this what causes you the trouble? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Question ABout ISPF Panels
>Hi,.I am trying to find examples of invoking a CLIST and a Program from the )PROC Section of a ISPF PANEL That is not the concept of ISPF. You either have a menu, aka selection panel, or a data entry or data display panel. With menus, you set the ZSEL variable to contain operands which are allowed on the ISPF SELECT service. ISPF then runs a SELECT service with those operands. This way you run (compiled) program, a CLIST/REXX script, or you let ISPF display another panel. Non-menu panel do not run programs. They are displayed *from* s running program, and the data entered, is then worked with in the program when ISPF returns from the DISPLAY service. This is a high-level, simplified view. The point is, there is no CALL or EXEC statement in a panel. ISPF Panels only have a very limited set of services you can use to verify the data the user has entered. With some release of ISPF (I don't remember which release), ISPF introduced the possibility to use REXX from within the panel to offer more flexibility to verify data. This was not intended to run "the logic" part of the application. -- ßph -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: FYI: IEEE Survey Ranks Programming Languages
>> Wot no COBOL? >COBOL is #39 [1]. Java and C# dominate the enterprise these days. Doesn't this nicely prove how worthless such surveys are? Go ask the same question to the mainframe community, and you will get a completely different ranking. Go ask the same question to the app programmer community, and you will get a completely different ranking. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OT - BREXIT parameter in CICS
It is almost Friday. I'm not a CICS guy, but while looking up something I stumbled across this: >From the CICS TS Reference, "Transaction Resources", I just learnt that the >CICS developers at Hursley long foresaw the UK will leave the EU one day or >the other: There is a transaction definition parameter called BREXIT, and an >associated START BREXIT command. LOL. Too cute not to share. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Will zIIP-eligible work unit loose zIIP-eligibility when executed on CP?
>It is kept. I have PAUSED and RELEASED a WU lots of times. Mostly, it runs >on the zIIP, but sometimes it runs on a CP due to the zIIP being busy. Thanks a lot. Much appreciated. This is in line with my expectation. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Will zIIP-eligible work unit loose zIIP-eligibility when executed on CP?
Cross-posted to IBM-MAIN and MXG-L Out of curiosity: Regarding the zIIP eligibility, what happens to a zIIP-eligible work unit when it is dispatched on a CP because the zIIPs are too busy (zIIP-on CP)? Will the work unit loose its zIIP-eligible state (flag)? Assume the WU is dispatched on the CP, then gets undispatched. Will the WU be requeued to the zIIP work unit queue when ready because is still is zIIP eligible? Or will it no longer be zIIP-eligible? I imagine the zIIP-eligibility is kept, but would anyone know (not just imagine)? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Z/OS trace entries - AINT
>The possibilities are any combination of >IQD,PCIE,CRYPTO,CF Do RoCE and zEDC cards also produce interrupts which are reported as AINT? Under type PCIE? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Linklist and APF
>It depends on your definition of "fairly recent". LNKAUTH=APFTAB was >introduced in MVS/XA SP2.1.1, about 35 years ago.. He wrote "I believe..." and you can always believe what you want . (No offence intended; just couln't resist). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Primary & secondary space values in DFSORT's dynamic work space allocation.
>Perhaps the OP should also put in the "estimate" on how big the input for all >the sorting work is in other terms. >Something like this: Have REGION= and OPTION >DYNSPC=512,SIZE=E9,MAINSIZE=MAX (which is working for my hungry sort >jobs.) The OP (me :-) wrote in the initial post that the application *cannot* provide an estimate. I did not write about the fact that DFSORT sometimes decides it cannot do in-memory sorting because it would hurt the overall system health. I did not because that is not part of my questions. Be assured I do understand the in-memory options DFSORT provides. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Primary & secondary space values in DFSORT's dynamic work space allocation.
>What is in fact the problem with this job, that the SORTWK specification >should be changed from JCL to dynamic? [snip] I totally agree with all you write. I don't know, and honestly I don't understand why they were asked to do change. I was only contacted by the desperate developer when he recognized the change could lead to production job abends. This was just before the software delivery cycle. I tried to understand how the parameters for the dynamic allocation work, so as to be able to give good recommendation to them. By testing, I found that the DYNAPCT creates some reserve work space data sets, but the total space of *all* the reserve data sets is roughly the space of a *single* initial work data set. Doesn't make sense to me, and IBM seems to agree. Therefore the PMR. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: IEC614I Scratch
Someone posted the text of the IEC614I. Doesn't look like a scratch message to me. Was initiates the deletion of the GDS? Roll-off due to LIMIT being reached? How is the GDG defined? Are the GDSs SMS managed? --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Primary & secondary space values in DFSORT's dynamic work space allocation.
>BTW, I wrote a test program meanwhile and found that the manual and the >reality diverge. I'm pursuing this offline and will report back once I know >more. I got a response from Kolusu. We're gonna open a PMR for this. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: DYNALLOC
>> A minute AFTER I hit "send" for my message I saw the error. >> >I do my best proofreading *after* I press the key... I'm excellent at finding my typos when I read my post after it is echoed back to me. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: load module loaded address between BPX LOAD (load_hfs) and ptrace+fork+exec?
>In a program, you can issue the BPX LOAD service to load a program into memory... and similar to the LOAD macro, this returns the address where the module was loaded, and the starting address. >Now - is there any guarantee that if you then do a BPX FORK and then a BPX EXEC to execute the module, that the module will be loaded at the same address in the child? The fork does a one by one copy of the address space (except from non-UNIXish things such as "DD allocations"). So the "BPX LOADed" load module is still at the same address. However, BPX EXEC is the equivalent of terminating the current job step, and starting a new job step where the BPX EXEC module will be the job step program. I therefore say the answer is NO. The only case where it could be loaded at the same address is when the BPX EXECed the load module is the same as the job step load module in the parent address space. But, I have never looked into an EXECed address space to see if that is the case or not. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Primary & secondary space values in DFSORT's dynamic work space allocation.
>It might be worth pointing out what might be a little known fact[snip] Thanks, I do understand this. Nevertheless, good point. Worth to be found in the archives. >If you think specifying FILSZ might help,... [snip] I do think so, indeed, but I talked to the application people and the have now way to tell and pass to sort in this case. BTW, I worth a test program meanwhile and found that the manual and the reality diverge. I'm pursuing this offline and will report back once I now more. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Netiquette (was:Sysplex between two hardware)
Peter,You've been asking for help here. I consider it very impolite that you don't answer peoples inquiries for details. -- Peter Hunkeler Von: Peter An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Sysplex between two hardware Datum: 06.07.18, 04:45 Hi We are looking up for a solution where we need a LPAR to have a hot standby in other LPAR running in a different machine . As we are trying to create a sysplex relationship between two LPARS running in a different machines . Apology for my ignorance and is it possible ? Peter -- 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
AW: Re: Friday - off topic - human factors and TN3270
>I use a white background with colors that are more or less the way they are described. The exceptions are white, which I have set to be black, and yellow, which I have set to a shade of brown. I find this to be much more pleasing to my eyes. It doesn't matter so much at 24 x 80, but at 88 x 142, it makes a big difference. Been working with just about these colors for the last 20+ years. I find it much more relaxing, especially when swapping between office suite windows and 3270 windows. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Function in SDSF to list Dynamic Exits
>Many require additional SAF authorization to run even though they appear on >the user's menu. I would prefer that they not appear at all if not authorized, >but that's grist for RFE Land. Is it? I thought it was part of SDSF customization to let different groups see different sets of functions. I never did this customization myself, but I do remember to have seen different sets. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Primary & secondary space values in DFSORT's dynamic work space allocation.
Some background, first. I was asked to help a COBOL application calling DFSORT internally via INPUT / OUTPUT PRODECURE (E15/E35) interface. The input data size is unknown, but varying greatly. FILESZ cannot be supplied. So, DFSORT has no way to calculate the required disk work space. The application was asked to change from JCL allocated SORTWKnn to dynamically allocated sort work space. DFSORT options DYNALLOC, DYNAPCT, and DYNSPC are the options used to help DFSORT optimally allocate the sort work space. Some extracts from the manual are listed below. I read the relevant parts in the Installation & Customization, the Application Programmer, and the Tuning Guide, but still I'm not sure I understand how and when the work space data set are allocated. The disk space allocated is of special interest here. Suppose: DYNALLOC=(,8),DYNAPCT=50,DYNSPC=2400 Now here are the statements with a lot of uncertainty, and question marks. I'd appreciate confirmation, or correction where I'm wrong. a) DFSORT will allocate 8 initial work data sets with primary space, and 50% of that, i.e. 4 reserve data sets with zero space initially. The total amount of primary space is the equivalent of 2400 MB. The manual says this is the total over *all* work data sets. b) So, the primary space for each of the 12 work data sets is 200MB, but only the 8 initial ones are allocated with that primary amount. The 4 reserved data sets are initially allocated with 0 space, but 200 MB will be allocated once DFSORT decides it needs them. c) The secondary space is said to be 20% of the primary, i.e. 480MB. It is not clear to me, whether this means any secondary extent is 480MB, or whether the secondary value is 480MB / 12, i.e. 40MB. This greatly influences the theoretical total amount of workspace. d) When DFSORT decides it needs more space, will it extend one, some, or all of the additional work data sets? At this time, the initial work data set have probably been extended to their maximum size (1 x primary + 15 x secondary). Will the additional data sets be extended by the primary amount only, and will grow later as needed? e) The first extension amount used with d) will be the primary amount calculated above, i.e. 200MB, right? Later, these additional data sets can be expanded by the secondary extent value, up to 15 times. Correct? Extracts from the Application Programmer's Guide: DYNAPCT=x specifies additional work data sets to be dynamically allocated with zero space. DFSORT only extends these data sets when necessary to complete a sort application. x specifies the number of additional work data sets (y) as a percentage of the maximum number of dynamically allocated work data sets (DYNALLOC/DYNALOC n value) in effect. DYNSPC=n DYNSPC=n temporarily overrides the DYNSPC installation option, which specifies the total default primary space allocation for all of the dynamically allocated work data sets when the input file size is unknown. ..., DFSORT uses the DYNSPC value in effect as the approximate amount of primary space. DFSORT uses 20% of the primary space as secondary space. Although the primary space is always allocated, secondary space (up to 15 extents) is only allocated as needed. n specifies the total default primary space, in megabytes, to be allocated for all dynamically allocated work data sets (n is not the primary space for each data set). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: CPU Utilization
>But if you specify the desired time on the job statement (the OP said 30 min?), IEFUTL would get called and could take the desired action (extend for another 30 after generating some console message?). I stand corrected. I had in mind he wanted an alert when some address space consumes more that a certain amount of CPU *percent*in an interval, not time. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: CPU Utilization
>No, IEFUTL is called INSIDE an Address Space as often as specified in SMFPRMxx >in statement JWT. and it would also be called when the CPU time used exceeds the time limit of the job or step (TIME= parameter). But this means also that the exit is most never called. And since we're at JWT: I only recently learnt that z/OS V2.1 introduced two new SMFPRMxx parameters called TWT and SWT. So, we can now manage continuous wait time differently for TSO users, STCs and all the rest, i.e. batch jobs, OMVS process address spaces (I'm just guessing that the latter are handled by JWT). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Formatting
>My post did not come out as I expected. No flowing. I'm going to shut up. I concur. When I read the explanation regarding "leading or trailing" blanks, I thought I finally understand. Then came your post, and I'm back to "I don't have a clue why it sometimes does work, and sometimes it does not". -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Would SHARE kindly kick IBM in the ass for what the've done with their web content?
Hello Harry,thank you very much for you response, and especially for picking this up. I know the subject I chose was a bit harshly formulated, but I did this on purpose. I was hoping that it would get things going, and it did. I'm grateful. Best regardsPeter -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: z/OS Internet Library Broken (again)
ROTFLOL. This is ridiculous, IBM! Case b) below is an intra-page reference; they don't get even this most basic of HTML right. -- Peter Hunkeler >b) Redisplays the same page: >https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r2-pdf-download?OpenDocument#DGW -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: ICEGENER to the rescue again?
> I'm fairly certain that ICEGENER would be able to do this, but have not yet found an example that comes anywhere close, that I can then adapt to my requirements. It's IEBGENER not ICEGENER which you probably mean. The latter does 1:1 copies of sequential data sets only. -- ßph -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: ICEGENER to the rescue again?
Please excuse the bad formatting. Trying Again. Are you familiar with REXX? If so, here is how you could do this: In a REXX:- LISTDS to get a list of the members in the PDS.- ALLOCATE an new PDS for the changed members.- FREE the output dsn. - In a loop for each member: -- ALLOCATE the input dsn(member_nn)-- EXECIO to read the member into input stem. -- FREE the input dsn -- in a loop move each reccord from input to output stem, but only first 72 positions --- end of inner loop -- ALLOCATE the output dsn(member_nn) -- EXECIO to write the changed data back into the member. -- FREE the output dsn -- end of outer loop Not the most efficient way, but if this is a one-time job, it probably doesn't matter. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: ICEGENER to the rescue again?
Are you familiar with REXX? If so, here is how you could do this: In a REXX:- LISTDS to get a list of the members in the PDS.- ALLOCATE an new PDS for the changed members.- FREE the output dsn. - In a loop for each member: -- ALLOCATE the input dsn(member_nn)-- EXECIO to read the member into input stem.-- FREE the input dsn -- in a loop move each reccord from input to output stem, but only first 72 positions--- end of inner loop -- ALLOCATE the output dsn(member_nn)-- EXECIO to write the changed data back into the member.-- FREE the output dsn -- end of outer loop Not the most efficient way, but if this is a one-time job, it probably doesn't matter. --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: 2 possible RFE --- ISPF & SDSF.
>Correct. The hex value is the important part. Depending on your codepage >and/or keyboard it may look like a completely different character. >But if you have something that not code-page aware and expects a $ (dollar >sign) then it's looking for x'5B'. You have to type whatever character on your >keyboard will give you that hex value. The latter is not generally true. It depends with what code page in mind the unaware application has been written. At a former employer, CP 500 was the standard. So every application, although code-page unaware, expected data to be in CP 500. And so a $ had to be x'5C'. The x'5B' applies when the unaware application, e.g. MVS, JESx, etc, was written with CP 037 in mind. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: 2 possible RFE --- ISPF & SDSF.
>I believe JCL's set of "allowable" characters is only a fraction of any code page. And probably only common code points. The problem with probabilities? They may fool you :-) The famous "national characters" @, #, and $ in some code pages (all hex values): CP 285 (UK, etc.): 7b, 7c, 4a CP 273 (Germany, etc.): b5, 7b, 5b CP 500 (International): 7c, 7b, 5c CP 280 (Italy, etc.): b5, b0, 5b -- Peter Hunkeler -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: [EXTERNAL] Re: Two new RFE's to consider supporting
> Does 3270 protocol require that PAS fields be writable, therefore tabbable? Bad design. It's perfectly reasonable to want to specify a read-only PAS menu item. (Too few bits in the attribute byte?) I'm no expert in the 3270 protocol, but I don't think PAS is described in the architecture. I'd rather think PAS is purely something a 3270 application has to implement: Read the cursor position returned, check if it lies within the "PAS field", and if so act accordingly. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: [EXTERNAL] Re: Two new RFE's to consider supporting
> Not all that difficult to do using standard 3270 orders: SBA to the screen location; SF to start an unprotected field. Immediately SF to start a protected field. I'm fairly certain this will allow TAB to go the the 0-length unprotected field which precedes the protected field. If not, then change the SF to say unprotected+dark and make then next data byte a simple blank. This will surely work, but the cursor will be placed ahead of the PAS text. Probably not the desired result. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Can a SLIP be set based on a message text?
MSGID='USERM001:' should do what you want. No need to involve automation. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: z/OS V2R1 content in KC (and Google)
Sue,thank you for correcting the inexcusable error so quickly. It was, however, unnecessary to post what may look as reasonable justification to you. To me "improve customer experience" is always announcing a step back in service, usability, availability. It's the current management buzzword to justify whatever nonsense they impose on us. --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Would SHARE kindly kick IBM in the ass for what the've done with their web content?
>Even if you have a z/OS 2.1 manual, some PTFs do add features or command or document changes to older versions, and they only update the newest manual. Very good point! I strongly prefer to read PDFs over KC web pages when I need to read more than a few paragraphs. However, with the change to continuous delivery, online documentation, being up to date, is required. I have a couple of gigabytes of z/OS related PDFs on my workstation, and on my iPad. However, I always look up the newest issue on the web when something looks odd. Maybe a PTF has introduced new behaviour. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Would SHARE kindly kick IBM in the ass for what the've done with their web content?
>Does this link not work for everyone? > >https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r1-pdf-download?OpenDocument I can't tell if it is working for everyone, but I can confirm that is for me. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: REXX calling bpxwunix when SIGNAL NOVALUE active
>call bpxwunix cmd,"unsorted_data.","sorted_data.",stderr. The FM manual describes the parameters to be "the name of a compound variable". If you don't quote, REXX will try to dereference the variables, does not find them, and raises NOVALUE if activated. If not, those which were initialized (unsorted_data & sorted_data) are replace by a blank. I think the examples in the doc should be updated to quote any and all of the parameters which denote a stem variable. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: [External] Re: AW: Re: CFSIZER no longer available?
>I concur. Thank you John. +1 >My wrath is directed at the PFCSK's doing the work! I concur as well with this. I tried to make clear in my statements, whom I'm attacking. Hopefully, I succeeded. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Would SHARE kindly kick IBM in the ass for what the've done with their web content?
I'm not a SHARE member, but I understand SHARE does have some influence in what IBM does and does not do. I would appreciate if SHARE would immediately go strongly after IBM for what they are currently doing to their web content. I'm not in a position to do that, unfortunately. I know there are members on this list who have a deeper connection to SHARE. Can any of you help us, please? This is sabotage! Sabotage to IBM's clients! For the last couple of years, IBM (and other companies) have forced us towards the internet. Acquiring information in usable formats such as Bookmaster or PDFs was made harder and harder, if you were lucky you could find a place to download documentation. But the longer the more, documentation became available as webpages only, without the possibility to save a copy locally for later reference. And now they feel comfortable to break that internet. Now they feel comfortable to remove content of products still in service. I have no confidence in my own management whatsoever, so I won'd even try to tell then what is going on, and ask them for help by approaching IBM. It's a waste of time. And this is why I'm hoping for SHARE to support us in this matter -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: CFSIZER no longer available?
Not attacking you personally, not at all, but do you have any information about all the other broken links, such as the WLM tools page, etc? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: SDSF DA display in z/OS 2.3
>Interesting! Though I'm not sure I'm getting that exact behavior. I can >place my cursor on the JOBNAME and then press enter, and it will behave as if >I had placed ? in the NP field and pressed enter. But I can't tab to the job >name. It bypasses it and goes to the Ptry column. Have a look at your ISPF (not SDSF) settings (Option 0 from the POM). There is s setting called "Tab to point-and-shoot fields". Is that enabled (has it a "/") in front of it? I'm not on z/OS V2.3 yet, so I cannot test. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: SYSLOG / OPERLOG displaying date.
All log data, or any data for which there is a potential need to be able to sort it, should only ever display dates in a sort friendly way, such as the ISO format. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Why are highly busy zIIPs worse than highly busy CPs?
>You really want Gary King or Dan Rosa to chime in, not me. I can rarely keep the details straight. If they provide me with information to relay on their behalf, I will be glad to. Thanks, for the offer. How about forwarding my initial post. I had written the points of interest to me, and I think to many here. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Why are highly busy zIIPs worse than highly busy CPs?
>zIIP dispatching is the same as GP dispatching. ZIIPAWMT has analogous parameters for GP (CCCAWMT) and zAAP (ZAAPAWMT). Alternate wait management was created long before there were specialty engines. Thank, Jim, much appreciated. Sorry, guys, for not reading the latest posts before writing mine talking about CCCAWMT -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Why are highly busy zIIPs worse than highly busy CPs?
>I believe hyper dispatch is very different from zIIP dispatch. I stand by my >assumption that GP dispatch is very different from zIIP dispatch, or why would >there be the ZIIPAWMT parameter and have the comment about waking up after >that interval to see if there is work. When non-zIIP work comes ready and a >processor is free, the work is dispatched. No waiting. The comments in the >parameter description for ZIIPAWMT is describing a polling environment, at >least to me. There is CCAWTM which does the same thing as ZAAPAWMT and ZIIPAWMT but for CPs. I think your statement about CP work being dispatched immediately when a CP is free, does not hold true. It was before "alternate wait management" was introduced (I don't remember when that was), when newly ready, higher priority work had interrupted lower priority work on a CP, or woken up a waiting CP. >I have looked through the internet, OK not the be-all and end-all but a >reasonable place to start, and there is a lot on what can get dispatched on a >zIIP, but no detail on how. The last five words are the very reason I started this thread. When it comes to zIIPs, there is much only fuzzy information out there. I did google and read every presentation I could get a hand on. So, coming back to one of my questions: The fuzzy information say that zIIP eligible work will suffer from a ZIIPAWMT delay when the zIIPs are overloaded and are asking for help from CPs. You mentioned the ZIIPAWMT delay *before* zIIPs idle zIIPs will start to work on newly arrived work. Ok, this is part of the delay. But as soon as there is a steady load of zIIP work, that start up delay will not occur again (think of my simplified case I initially described). Similarly the "ask for help ZIIPAWMT delay" will occur only once when there is work constantly seen on the the zIIP WUQ. I still think that, theoretically, zIIP eligible work will be served somewhat better than non zIIP eligible work *when* the zIIPs is being helped (depending on the works priority, of course). There are two processors looking after the single work queue. Oversimplified, you think? Maybe but its my starting point anyway. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Why are highly busy zIIPs worse than highly busy CPs?
>First of all, the dispatcher code for ZIIP processing is not the same as the >GP dispatcher. Do you know this, or is it just an assumption on your side? After all I read, it still would't make sense to me. If you think of the "need help" process for the zIIP to be special, isn't there a similar process for CPs? With hiperdispatch, the system tries to redispatch work to the same (L)CP as much as possible. In support of this, the CPs are grouped into nodes (I believe that is the term). Each node mainly serving its own, separate work init queue. But CPs from other nodes will help if one node becomes overloaded. The above is how I remember it from a discussion I had with Robert Vaupel (IBM). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Why are highly busy zIIPs worse than highly busy CPs?
>Some of this dispatcher design by IBM could be based on the assumption that >all the work is SRB and will be high priority work and of short duration. This doesn't sound correct to me. Client SRBs (preemptive SRBs) were invented to have some work done in another address space at client priority. Enclave SRBs were invented to let those client SRBs be run on zIIPs. So, there is a mix of SRBs with different priorities (WLM goals, WLM service classes) competing for zIIP capacity. And it's all preemptive kind of work. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Why are highly busy zIIPs worse than highly busy CPs?
>> Is it? If you think about Java, maybe. But when it comes to workload such as >> DB2, Sort, Monitors, that have shifted more and more of its task towards >> zIIPs, isn't this still the same workload? >> -- >> Peter Hunkeler > >The zIIP-eligible criteria for choosing a subset of tasks to run on zIIP engines, as I understand it, has nothing to do with installation defined service classes but is totally based on IBM marketing strategy. There is no reason to expect the mix of tasks eligible for zIIP resources to have the same service-class mix and CPU/IO usage patterns as those restricted at that same time to CP resources --the zIIP utilization may even peak at a totally different time of day. The total system workload may be the same as before things were made zIIP eligible, but with artificial separation into those that prefer a zIIP and those that must run on a CP, that workload is now artificially subdivided into two distinct and different workload subsets when competing for CPU resources. If zIIP utilization forces something that would normally run on zIIP onto a CP, it is now competing for CPU resources with a different subset of that total workload, and it would be surprising if that shift didn't affect response time. Didn't think that way when I read your previous statement. I now see what you meant and I agree. Very good point. Thanks. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Why are highly busy zIIPs worse than highly busy CPs?
>How prevalent are installations today where the CPs run at top speed, in other >words at the same speed as zIIP engines? I haven't got the faintest idea. We do, but that doesn't matter for this discussion. I thought this is complex enough, so I take one part of complexity out first: Different speed engines. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Why are highly busy zIIPs worse than highly busy CPs?
> the workload on the CP is totally different. Is it? If you think about Java, maybe. But when it comes to workload such as DB2, Sort, Monitors, that have shifted more and more of its task towards zIIPs, isn't this still the same workload? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: SORTLIB DD
I seem to remember similar problems, and telling sort an estimated amount of data to sort did help. Without looking up, I think the parm on the SORT statement is FILESZ=. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: [EXTERNAL] AW: Re: Weird thought for ISPF enhancement
>I have a fairly simple ISPF dialog to work with the ZSTART variable. Get it >from www.lbdsoftware.com/zstart.zip or www.cbttape.org file 314. Great! Thanks for the pointer. I just think it's a typical shame that the product (ISPF) delivers halfway features. How small an effort would this be to offer a similar dialog as part of ISPF? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Use of dynamic system symbols in JCL
>Are you specifying "EXPORT SYMLIST" in your JCL? That one is not needed for system symbols to become available in batch JCL. It the jobclass SYSSYM=ALLOW | DISALLOW that decides. BTW, the symbols are resolved at conversion time. The EXPORT SYMLIST is needed so that JCL symbols can be used on // DD * data. You also need SYMBOLS=JCLONLY | CNVTSYS | EXECSYS on the DD * statement. The later two enable system symbol replacement in DD * data irrespective of the SYSSYM= setting on the jobclass (IIRC). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Weird thought for ISPF enhancement
>If you like the benefits of many split screens then have a logon proc >(Clist/REXX) create the split screens automagically for you each logon. I have >8 session created behind the scenes. Have a look aht the ZSTART ISPF variable. It is there for just this reason. As usual with the ISPF guys, the forget to make it easy to use; there is no standard ISPF dialog to set it. Build your own or manipulate ZSTART via ISPF variable dialogue. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OT: Rap music (was Re: opinion: multi-platform program design)
It's amost Friday, right. At least here in Zurich >Rap music is performed by those that can not sing so others can not think. rap music? Isn't this a contradiction in terms ;-) Apologies to all the rappers out there, and the ones who like that contradiction, ahem.. music. No offense intended. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Why are highly busy zIIPs worse than highly busy CPs?
>... however, we were warned that 'some customers' were experiencing serious >performance problems when zIIP eligible work spilled over to general CPs. Yeah, that is what I read and hear also, and I have no reason not to believe it. In fact, I suspect we've just been bitten by zIIP overload. However, this is not at the level of technical detail I'm seeking to understand. >The reason, we were told, was that while general CP management had evolved >over the decades with a huge boatload of OS code to handle contention, zIIPs >were newcomers that were more or less on their own in playground competition. >The wiry little guys with little bully protection. Huh? Do you want to say you've been told that zIIP management (dispatcher and WLM/SRM) is new code that is distinct from the CP management (dispatcher and WLM/SRM) code? I must be misunderstanding you. zIIPs are general purpose processors exactly the same as CPs are, aren't they. They will run whatever work unit happens to be found on their dispatcher queue, don't they? The decision which work queue to chain a newly ready work unit on is made at queueing time. It is just an (not really) arbitrary decision that IBM chose only enclave SRBs are eligible to be queued on the zIIP WUQ. The only new thing is that the dispatcher, when running on a zIIP, may ask, i.e. flag a CP to also look for work on the zIIP WUQ. And it is the dispatcher, when running on that CP, which looks at both WUQ to select the next work unit to dispatch. This is how I think it works. Tell me, anyone, if this is not correct. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Why are highly busy zIIPs worse than highly busy CPs?
>Isn't "fall back to the CP" because one would typically want one's work to run *somewhere* even if a zIIP were not available but perhaps a CP was? If you meant no zIIPs are available to the LPAR (not configured or the CEC does not have some), then there is no fall-back. Work units get queue on CP work queues initially; the zIIP work queue is not being used. At least this is how I understand it. If you meant no free zIIP capacity is available, then part of the decision might have been that initially you could have only half as many zIIPs as you had CPs. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Why are highly busy zIIPs worse than highly busy CPs?
>Scheduling an SRB isn't cheap. I don't know whether that's why, but for >whatever reason, IBM has built this "fall back to the CP" mechanism. What falls back is still SRBs. The scheduling overhead has already been done before. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Why are highly busy zIIPs worse than highly busy CPs?
>Once the delay is long enough, the CP does the work. They cost about 10X the >price of zIIPs. I understand the potential impact on the software bill zIIP-on-CP might have. That is not the point I want to get a better understanding. I'm interested in the technical aspects, only. IMHO, from a technical point of view the invention of zIIPs and zAAPs is pure bullshit. From a financial point of view they are helping lowering costs -- and that is their only reason to be. I predict (and no I don't have any insight into IBM's plans) zIIPs will be gone in the not so distant future. Container Pricing makes the zIIP/zAAP concept superfluous. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where is the WLM website???
>I'll pass these comments on to the initiative leads so that they're aware of the specific problems and can hopefully direct resolutions ASAP. if your faint-hearted, don't read on. Someone better go off and kick'em in the ... and tell those useless m to go and look for another job. The Internet lives from links, from stable links. IBM has been the world leader in restructuring its websites and re-breaking links for years. But least the important ones to us technicians have survived so far. I wouldn't have imagined that someone can be so dumb and do what IBM seems to have done now. IBM is currently making it worse and worse for me to do my job. I need to be able to find information. Every valuable redpiece, every valuable redbook, every valuable presentation has links in it, useful links. If IBM is willingly breaking those links, the I understand that IBM is willingly sabotaging to our work. I had not intent to offend anyone, except those responsible for this disaster. I've gotten upset for quite some time whenever I was looking us something on IBM site. This has to get out once. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Where is the WLM website???
>Does anyone has a working link to the WLM site and/or to the tool? I tried some save links but all of them end up at either - www.ibm.com/it-infrastructure/z/. (note the lower case z, hi, hi) - the famous IBM KC Neither of this is helpful. It seems another m has succeeded in hindering us to find information, and finding it efficiently. Why , why, why, IBM, are you breaking links again and again?? ##$&%*<£$$**sch... -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Why are highly busy zIIPs worse than highly busy CPs?
There are some statements around zIIP utilization which I read here and there. Statements like: - "You should not utilize one zIIP more than 30%, two zIIPs more than 60%..." - "A task may become delayed for up to 3.2 ms (actually ZIIPAWMT) before the busy zIIP asks for help from a CP". For this discussion, lets assume equal speed CPs and zIIPs, and a reasonable CP to zIIP ratio, and more than on processor of each kind. It has been a long time strength of IBM Z (and all the predecessors) that the CPs in an LPAR can be utilized way above 90% without major problems arising. I seem to understand that this has changed lately, but still some 85% (?) should be fine. Now, all work running on zIIPs was once work running on CPs (and still is if there are no zIIPs). So the work is no different (apart from much being run under an SRB instead of a TCB), and the response time requirement is no different. Right? If so, how comes that busy zIIPs are said to be more of a problem than busy CPs? If the work can accept some queueing when run on CPs, why not when run on zIIPs. Queueing theory should apply equally to both. When a processor is busy 50%, then 50% of the time there is at least one ready task, the one executing. Maybe there are some more waiting on the work queue. But these 50% say nothing about the delay of the tasks on the work queue. In a simplified case, assume 5 tasks with equal priority, each one quickly, say after 0.5 ms, coming to the point where it has to give up the processor for a very short period of time before being requeued on the work queue. They all constantly work that way for 30 seconds in row, then become undispatchable for the remaining 30 seconds of that 50% busy minute. During the first 30 seconds, the zIIP is 100% busy, and after 3.2ms (ZIIPAWMT), the zIIP will ask a CP for help. None of the tasks has been delayed by 3.2ms, although the ZIIP recognized its work queue has not become empty for 3.2ms and asked for help. To the contrary, the work has gotten better service because two processors are now serving the single work queue. (Again for simplicity, not currently taking priorities into account). Same case but the task are working 1ms each time. Now it always takes more than 3.2ms for the last task on the work queue before it is being redispatched as long as the zIIP has not asked for help. But the zIIP will ask for help after 3.2ms, and the delay for the tasks will shrink. Isn't this a better situation for zIIP work than for non-zIIP work? Same scenario on CPs. There is no-one to help. Any thoughts? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: SLIP trap on High CPU usage
>But a GTF Trace probably can. I would look at GTF TRACE or VSM Traces. But this will monitor VSM calls, not CPU usage. I understand the GETMAIN/FREEMAIN are expected, but only every now and then, they go wild. I don't see how GTF can help here. I don't know the details, but I know we have some automation in place to detect high CPU users (jobs). AFAIK, it is based on MainView z/OS detecting such a job and then writting (WTO) a message, which in turn triggers automation. Do you have some tool like MainView or Omegamon? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Performance impact of using DFSMS's Data Set Separation feature?
I've been asked by my storage colleagues if I knew the impact of using DFSMS's Data Set Separation feature. I don't. Does anyone used it? Any pros and cons to share? While the number of data sets to keep separated is low, SMS will still need to search the list for *every* new allocation. How significant is the performance impact of this? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to get BPX loadhfs (BPX1LOD) to load module into writable memory?
>OK. You posted from "Glossary" (which I hadn't noticed): No, I did not. The paragraph I posted is from chapter 2 "Creating programs from source modules", topic "Module reusability", page 30. I was looking up in the z/OS V2.2 issue of that manual. When I read the text you posted, I thought IBM has changed the text in the V2.3 issue. Not so. There seem to be contradicting definitions of RENT on the very same manual. As long as I know, the rule I cited has been in place. This rule allows a program to modify its own storage, and still be used in a reenterable way, this disallowing it to be loaded into write-protected storage. As long as I know, there was the special rule for modules loaded from APF authorized libraries. I have not noticed the paragraph you posted until now. The wording "ordinarily" does not exclude above case. However, the wording related to z/OS UNIX: "... These cases include programs which the system treats as having been loaded from an authorized library, and also programs running under UNIX unless a debugging environment has been specified." ... surely cannot be correct. LOAD will still abide to the same rules, no matter whether the LOAD SVC was called from a dubbed task or a non-dubbed task. At least I hope so. It is ok for the "new" service BPX1LOD to behave differently. However, this different behaviour must be clearly documented, which it is not. Apart from BPX1LOD, loading program objects from the UNIX file system should be no different as loading a program object (or load module) from a load library. If a (RENT) program is in a (non APF-authorized) load library, it can simply be copied into the file system, and vice versa. I would expect both to behave identically. The former being loaded into SP251, the later into SP252?? Really?? If true, the sticky bit will change the behaviour of loaded code unexpectedly. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: How to get BPX loadhfs (BPX1LOD) to load module into writable memory?
>> What was Peter H. (informally?) quoting without citation? > >In: z/OS IBM MVS Program Management: User's Guide and Reference >Version 2 Release 3 SA23-1393-30 Re-read my post and you will find my citation. I admit I missed the word "Reference" and I did not include the pubs number. I thought it would be understood, nevertheless. It seems, not. I'm sorry for the confusion this may have caused. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to get BPX loadhfs (BPX1LOD) to load module into writable memory?
>Loading from the HFS seems to prefer to load RENT modules in read-only memory; without the "a" attribute. I haven't tested, and I believe what you say is what you see. However, this is not expected behaviour, since RENT does *not* mean the program must not modify itself. The Program Management User's Guide explicitly mentions that: Module reusability: o Reenterable (reentrant). The module is designed for concurrent execution by multiple tasks. If a reenterable module modifies its own data areas or other shared resources in any way, appropriate serialization must be in place to prevent interference between using tasks. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to get BPX loadhfs (BPX1LOD) to load module into writable memory?
>I believe that lately there's a PARMLIB option (REFRPROT?) which modulates >this. As the name implies, this has influence on the loading REFResable load modules. The manual does not mention it has any influence on loading RENT module. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: How to get BPX loadhfs (BPX1LOD) to load module into writable memory?
>It primarily has to do with the module attributes (is it reentrant?) and the APF authorization of the job step. I hate to correct you, but ISTR it is RENT plus loaded from an authorized library, no matter whether the step is actually running APF authorized or not. David: Does you HFS module have the "a" extended attribute set, and is it really required? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: File transfer Red Alert
>Correct. Since the attributes of an SVCDUMP are always FB/4160/4160, you can do a BINary download to a PC, then do a BINary upload to z/OS if you first do a "QUOTE SITE LRECL=FB LRECL=4106 BLKSIZE=4106". Just for the records, above QUOTE command has the values wrong. Correct is: 4160. And to improve performance, use BLKSIZE=29120, and RECFM=FBS. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: GETMAIN LOC=32
Paul, are you continuing to bother us under a new pseudonym now? -- Peter Hunkeler Von: somitcw <01b1f179dc6e-dmarc-requ...@listserv.ua.edu> An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: GETMAIN LOC=32 Datum: 11.05.18, 07:29 SG24-7605-00 z/OS Version 1 Release 10 Implementation April 2009 Pages 6 and 104 Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private. When did they move? Are we requesting a feature that is already there? IBM could do that real quick. Paul's wanting SVC 120 to get memory up to 4GB-1 and have IARV64 and IARST64 stick with 33 to 64bit addresses would actually need a couple of code changes and a little documentation. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: DFSMSdss Question
>From the DFSMSdss Storage Administration > >TYPRUN=NORUN Note that this is to be specified via EXEC,PARM='TYPRUN=NORUN', not SYSIN -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: GETMAIN LOC=32
This thread was one of the most amusing threads I read for a while. It's only a quarter to 9am here, but this was definitely the highlight of the day, not to say the week. Kudos to all of you who have patiently responded to Paul's arguments, trying to convince him he's wrong. --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: DFSMSdss dump fix after binary transfer
>IMHO it is problem with IBM. Are you deaf? Sometimes it is; sometimes they are. However, not this time. >People really NEED the functionality to simply make single dataset archive, transmit it to PC *with no tricks and black magic* and then upload it to a z/OS and unpack. Know your job. What is difficult about running two programs one after the other to get the desired result? >What would be wrong with "DUMP DS() OUDATASET(some.PS) *TRANSMITTABLE*" ? >Output format should be FB (with no blocksize harcoded, any LRECL), ... Nothing would be wrong, except the fact that the person uploading that thing to z/OS again would still need to understand to FTP in binary mode *and* to make sure the target data set *is* FB (and correct LRECL). Again, know your job. I'm not against the desire to have an option added to DSS. My point is, you can always find a new situation where you need to combine programs to get the desired result. You naturally will use scripting (aka JCL), don't you? This is what I meant by "know your job". -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: Where do I find a list of world timezones in z/OS USS notation?
>I totally agree, but we can't even get this country, USA to agree on a BAN on >DST, should have saved this discussion for Friday :) Politicians and managers in Europe seem to begin to accept the uselessness of DST, and the discussion about getting rid of it has started in the EU. It will of course take eons to come to a common understanding, not speaking about realizing the outcome. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
