Re: RSU APPLY ISSUE GIM23911E
I was getting errors while doing apply check for these HOLDERROR, so, I used by pass to move ahead for apply.Is there any issues you see in this. Do you suggest to change acceptable value for CEEPLPKA or any other clue. On Fri, Sep 5, 2014 at 10:39 AM, Lizette Koehler stars...@mindspring.com wrote: There were two things in the job run I was able to see. Let me know if this might be part of the issue First - should you code BYPASS(HOLDS(...) HOLDE(...) )?? I always thought you should let HOLDERROR alone unless you have a fixing PTF from IBM. Though I could be wrong. BYPASS(HOLDSYS(DOC,IPL,RESTART,ACTION,ENH,DEP,AO,MSGSKEL,MULTSYS, DYNACT,EC,DB2BIND,EXIT,DELETE,DDDEF) HOLDERROR(AA45207,AA45706,AA45113,AA44153,AA45166,AA44844,AA45744)) Second IEW2322I 1220 923NAME CEEPLPKA(R) MAX ACCEPTABLE RC=00 IEW2454W 9203 SYMBOL CEEARLU UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL CEEBLLST UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL STRFTIME UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL LOCALECO UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. I think the fact that CEEPLPKA sets max cc as 0 is the issue for UI18451 Let me know if I am closer to the resolution. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, September 04, 2014 9:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E On Thu, 4 Sep 2014 21:55:32 +0530, Mainframe Mainframe wrote: I see some more warning message before this error message like ... GIM23913WLINK-EDIT PROCESSING FOR SYSMOD UA72482 WAS SUCCESSFUL FOR MODULE CBRICMMN IN LMOD CBRINIT0 IN THE LPALIB LIBRARY. THE RETURN CODE WAS 04. DATE 14.247 - TIME 02:35:21 - SEQUENCE NUMBER 87 SYSPRINT FILE SMP00040. ... That's from SMPOUT, not Binder SYSPRINT. Are you viewing your output with SDSF? If so, open the job with ? rather than S and go directly to SMP00040 (I believe (E)JES has a similar feature, perhaps different syntax). Try FIND p'IEWW' (IIRC correctly the ISPF syntax -- help!?) On Thu, Sep 4, 2014 at 9:44 PM, Paul Gilmartin wrote: On Thu, 4 Sep 2014 21:13:31 +0530, Mainframe Mainframe wrote: Hello Rob, In my case LKED entry in SMPE is set to 04. Binder SYSPRINT (perhaps in your case SMP00030) should tell you: Oops! I meant SMP00040. o The maximum RC specified on the NAME statement (IIRC, SMP/E converts that to a comment). o The actual return code from the bind operation (look near the bottom). o Message codes, , of Warning severity. Search backward for IEWW. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
You should never (unless told by IBM who probably never will) BYPASS error holds. They have the hold because they are in error. The error could be minor or it could crash your entire system. Use EXCLUDE of the PTF with the error if you wish to get a successful APPLY. INMO. you shouldn't be APPLY without having achieved a successful APLYCHECK run, but other here just run and let the PTFs with error holds fail. But, either way, intentionally putting broken software on your system is not a good practice. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Thursday, September 04, 2014 11:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I was getting errors while doing apply check for these HOLDERROR, so, I used by pass to move ahead for apply.Is there any issues you see in this. Do you suggest to change acceptable value for CEEPLPKA or any other clue. On Fri, Sep 5, 2014 at 10:39 AM, Lizette Koehler stars...@mindspring.com wrote: There were two things in the job run I was able to see. Let me know if this might be part of the issue First - should you code BYPASS(HOLDS(...) HOLDE(...) )?? I always thought you should let HOLDERROR alone unless you have a fixing PTF from IBM. Though I could be wrong. BYPASS(HOLDSYS(DOC,IPL,RESTART,ACTION,ENH,DEP,AO,MSGSKEL,MULTSYS, DYNACT,EC,DB2BIND,EXIT,DELETE,DDDEF) HOLDERROR(AA45207,AA45706,AA45113,AA44153,AA45166,AA44844,AA45744)) Second IEW2322I 1220 923NAME CEEPLPKA(R) MAX ACCEPTABLE RC=00 IEW2454W 9203 SYMBOL CEEARLU UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL CEEBLLST UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL STRFTIME UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL LOCALECO UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. I think the fact that CEEPLPKA sets max cc as 0 is the issue for UI18451 Let me know if I am closer to the resolution. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, September 04, 2014 9:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E On Thu, 4 Sep 2014 21:55:32 +0530, Mainframe Mainframe wrote: I see some more warning message before this error message like ... GIM23913WLINK-EDIT PROCESSING FOR SYSMOD UA72482 WAS SUCCESSFUL FOR MODULE CBRICMMN IN LMOD CBRINIT0 IN THE LPALIB LIBRARY. THE RETURN CODE WAS 04. DATE 14.247 - TIME 02:35:21 - SEQUENCE NUMBER 87 SYSPRINT FILE SMP00040. ... That's from SMPOUT, not Binder SYSPRINT. Are you viewing your output with SDSF? If so, open the job with ? rather than S and go directly to SMP00040 (I believe (E)JES has a similar feature, perhaps different syntax). Try FIND p'IEWW' (IIRC correctly the ISPF syntax -- help!?) On Thu, Sep 4, 2014 at 9:44 PM, Paul Gilmartin wrote: On Thu, 4 Sep 2014 21:13:31 +0530, Mainframe Mainframe wrote: Hello Rob, In my case LKED entry in SMPE is set to 04. Binder SYSPRINT (perhaps in your case SMP00030) should tell you: Oops! I meant SMP00040. o The maximum RC specified on the NAME statement (IIRC, SMP/E converts that to a comment). o The actual return code from the bind operation (look near the bottom). o Message codes, , of Warning severity. Search backward for IEWW. --gil - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: YA silly LISTSERV WWW question -- monospace
Paul Gilmartin wrote: When I post via the Web interface, is it possible to see what I'm composing in a monospaced font, the better to preview code excerpts, and to avoid the wrap at ... Even with 'Show Advanced', it seemed it is not possible. I did not have time to change my browser's default font / code page settings... Perhaps later. What I'm now seeing while editing in a web interface: MMM iii Above is three letters 'M' in uppercase followed by next line of lower case iii. By EYEBALL, I can see those 3 'i' just fit nicely under a 'M'. Copy and paste those 6 letters to monospaced editor (NotePad or ISPF) and you will see all arranged so that last 'i' is below 'M'. Usually what I do, I use my e-mail client, NotePad, ISPF edit to compose something with monospaced font. Copy/Paste and review. Then post it under web interface. Another way of handling those wraps is, I simply press ENTER when starting a paragraph and continue typing. When finished with the last character of a paragraph, then only then I enter ENTER. In this way, my text flow is hopefully neat and readable. Some posters simply enter ENTER after a few words and continue the next line, but their editors automatically make the first characters UPPERCASE on all those lines. Each to his own... Groete / Greetings Elardus Engelbrecht (Above was typed on IBM-MAIN web interface using Internet Exploder 10) Friday Joke: The old uncle and his wife are sitting outside and relaxing drinking some coffee. Uncle's cellphone makes a BRR noise and he looks at it. 'Damn! It is that old b*tch Betty Louw again! I don't know her!' he complains to his wife. Later his cell again make a BRR. 'Again that old Betty Louw!' His wife says 'give me the phone, let me have a look.' After looking at it, she screamed at him: 'You stupid *sshole! It is 'Battery Low!'. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C compiler substituting for macros inside literals?
Hi Glen! For the benefit of others, KR = The C Programming Language by Kernighan Ritchie. Appendix A C REFERENCE MANUAL, section 12.1 Token Replacement is on page 207 in the original 1978 edition. Section 12.1 explicitly deals with both #define identifier token-string and #define identifier( identifier , ... , identifier ) token-string [that is, simple #define constants and the almost-as-simple macro functions]. It says Text inside a string or a character constant is not subject to replacement. This 1978 KR is prior to the November 15, 1978 extensions to C regarding Structure Assignment and Enumeration types. (I say this just to establish that the above indeed relates to the earliest widely-circulated definition of C.) The KR book's Appendix A C Reference Manual was often reprinted as part of the ATT UNIX manuals. I wonder if those few early C Macro Preprocessors that broke this rule did so knowingly (as a feature to get inside a string before this was provided for) or unknowingly (simplistic coding). I could forgive this for something like the early Portable C Compiler where the focus was on providing a simple C compiler that could compile a more sophisticated one. Then again, the C Macro Preprocessor was a separate program in those days, so the Portable C Compiler could just as easily have used a copy of a production C Preprocessor, so its logic should have been correct. (I'm not saying the Portable C Compiler had the bug - just wildly speculating as to where the coding error may have come from.) -- dap On Thu, 4 Sep 2014 02:36:51 -0700, glen herrmannsfeldt g...@ugcs.caltech.edu wrote: it must be bug with the macro preprocessor used by USS's cc comand. Even KR's 1978 definition of C makes it clear that arguments inside ... strings are not to be substituted. Two different questions. If you: #define d 5 printf(%d, 3); the d won't be replaced. That is, in preprocessor terms, a very different question from: #define S(d) printf(%d, d) The person writing a macro with arguments has full control over the names, and can choose them to match or not. This allows for: #define debug(x) printf(x=%d\n, x) ANSI added the stringizing operation, and then removed the replacement inside strings. While not explicitly stated in KR1, it is the normal case for non-ANSI preprocessors. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C compiler substituting for macros inside literals?
So tell me, if one wanted to achieve this apparently non-standard effect how WOULD one go about it? Not that I want to but it HAD to be asked. :-) Thanks, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: David Price da...@bigpond.net.au To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/09/2014 09:54 Subject:Re: IBM C compiler substituting for macros inside literals? Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi Glen! For the benefit of others, KR = The C Programming Language by Kernighan Ritchie. Appendix A C REFERENCE MANUAL, section 12.1 Token Replacement is on page 207 in the original 1978 edition. Section 12.1 explicitly deals with both #define identifier token-string and #define identifier( identifier , ... , identifier ) token-string [that is, simple #define constants and the almost-as-simple macro functions]. It says Text inside a string or a character constant is not subject to replacement. This 1978 KR is prior to the November 15, 1978 extensions to C regarding Structure Assignment and Enumeration types. (I say this just to establish that the above indeed relates to the earliest widely-circulated definition of C.) The KR book's Appendix A C Reference Manual was often reprinted as part of the ATT UNIX manuals. I wonder if those few early C Macro Preprocessors that broke this rule did so knowingly (as a feature to get inside a string before this was provided for) or unknowingly (simplistic coding). I could forgive this for something like the early Portable C Compiler where the focus was on providing a simple C compiler that could compile a more sophisticated one. Then again, the C Macro Preprocessor was a separate program in those days, so the Portable C Compiler could just as easily have used a copy of a production C Preprocessor, so its logic should have been correct. (I'm not saying the Portable C Compiler had the bug - just wildly speculating as to where the coding error may have come from.) -- dap On Thu, 4 Sep 2014 02:36:51 -0700, glen herrmannsfeldt g...@ugcs.caltech.edu wrote: it must be bug with the macro preprocessor used by USS's cc comand. Even KR's 1978 definition of C makes it clear that arguments inside ... strings are not to be substituted. Two different questions. If you: #define d 5 printf(%d, 3); the d won't be replaced. That is, in preprocessor terms, a very different question from: #define S(d) printf(%d, d) The person writing a macro with arguments has full control over the names, and can choose them to match or not. This allows for: #define debug(x) printf(x=%d\n, x) ANSI added the stringizing operation, and then removed the replacement inside strings. While not explicitly stated in KR1, it is the normal case for non-ANSI preprocessors. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C compiler substituting for macros inside literals?
On 5/09/2014 4:56 PM, Martin Packer wrote: So tell me, if one wanted to achieve this apparently non-standard effect how WOULD one go about it? Write your own preprocessor! Not that I want to but it HAD to be asked. :-) Thanks, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: David Price da...@bigpond.net.au To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/09/2014 09:54 Subject:Re: IBM C compiler substituting for macros inside literals? Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi Glen! For the benefit of others, KR = The C Programming Language by Kernighan Ritchie. Appendix A C REFERENCE MANUAL, section 12.1 Token Replacement is on page 207 in the original 1978 edition. Section 12.1 explicitly deals with both #define identifier token-string and #define identifier( identifier , ... , identifier ) token-string [that is, simple #define constants and the almost-as-simple macro functions]. It says Text inside a string or a character constant is not subject to replacement. This 1978 KR is prior to the November 15, 1978 extensions to C regarding Structure Assignment and Enumeration types. (I say this just to establish that the above indeed relates to the earliest widely-circulated definition of C.) The KR book's Appendix A C Reference Manual was often reprinted as part of the ATT UNIX manuals. I wonder if those few early C Macro Preprocessors that broke this rule did so knowingly (as a feature to get inside a string before this was provided for) or unknowingly (simplistic coding). I could forgive this for something like the early Portable C Compiler where the focus was on providing a simple C compiler that could compile a more sophisticated one. Then again, the C Macro Preprocessor was a separate program in those days, so the Portable C Compiler could just as easily have used a copy of a production C Preprocessor, so its logic should have been correct. (I'm not saying the Portable C Compiler had the bug - just wildly speculating as to where the coding error may have come from.) -- dap On Thu, 4 Sep 2014 02:36:51 -0700, glen herrmannsfeldt g...@ugcs.caltech.edu wrote: it must be bug with the macro preprocessor used by USS's cc comand. Even KR's 1978 definition of C makes it clear that arguments inside ... strings are not to be substituted. Two different questions. If you: #define d 5 printf(%d, 3); the d won't be replaced. That is, in preprocessor terms, a very different question from: #define S(d) printf(%d, d) The person writing a macro with arguments has full control over the names, and can choose them to match or not. This allows for: #define debug(x) printf(x=%d\n, x) ANSI added the stringizing operation, and then removed the replacement inside strings. While not explicitly stated in KR1, it is the normal case for non-ANSI preprocessors. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: RSU APPLY ISSUE GIM23911E
On Fri, 5 Sep 2014 09:18:39 +0530, Mainframe Mainframe
mainframe1...@gmail.com wrote:
Below Output,
LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF
00060001
* M O D U L E S U M M A R Y *
MEMBER NAME: EDC@@248
LIBRARY: SCEELKED
** ALIASES ** ENTRY POINTAMODE
** STRXFRM 31
ATTRIBUTES OF MODULE
** BIT STATUS BIT STATUS BIT STATUS
0 RENT 1 REUS 2 NOT-OVLY
4 NOT-OL 5 BLOCK6 EXEC
8 NOT-DC 9 ZERO-ORG 10 EP-ZERO
12 EDIT 13 NO-SYMS 14 F-LEVEL
MODULE SSI:NONE
APFCODE:
RMODE: ANY
LONGPARM: NO
This output is incomplete as you cut off the part to the right of bits 2,6,10
and 14 (that part that is cut of shows bits 3,7,11, and 15.)
Doug
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Sorry, Please find correct output. 1 J E S 2 J O B L O G -- S Y S T E M M V S 9 -- N O D E J E S S U P 0 20.47.06 JOB00311 THURSDAY, 04 SEP 2014 20.47.06 JOB00311 IRR010I USERID DEVP001 IS ASSIGNED TO THIS JOB. 20.47.06 JOB00311 ICH70001I DEVP001 LAST ACCESS AT 20:31:59 ON THURSDAY, SEPTEMBER 4, 2014 20.47.06 JOB00311 $HASP373 AMBLIST STARTED - INIT BASE - CLASS A - SYS MVS9 20.47.06 JOB00311 IEF403I AMBLIST - STARTED - TIME=20.47.06 20.47.07 JOB00311 - -TIMINGS (MINS.)-- -PAGING COUNTS 20.47.07 JOB00311 -STEPNAME PROCSTEPRC EXCP CONN TCB SRB CLOCK SERV WORKLOAD PAGE SWAP VIO SWAPS 20.47.07 JOB00311 -LIST 00 1966292 .00 .00 .0 16719 SYSTEM 0 0 0 0 20.47.07 JOB00311 IEF404I AMBLIST - ENDED - TIME=20.47.07 20.47.07 JOB00311 -AMBLIST ENDED. NAME- TOTAL TCB CPU TIME= .00 TOTAL ELAPSED TIME=.0 20.47.07 JOB00311 $HASP395 AMBLIST ENDED 0-- JES2 JOB STATISTICS -- - 04 SEP 2014 JOB EXECUTION DATE -6 CARDS READ - 78 SYSOUT PRINT RECORDS -0 SYSOUT PUNCH RECORDS -5 SYSOUT SPOOL KBYTES - 0.01 MINUTES EXECUTION TIME 1 //AMBLIST JOB 'MAINFRAME',CLASS=A,MSGCLASS=A,NOTIFY=SYSUID JOB00311 IEFC653I SUBSTITUTION JCL - 'MAINFRAME',CLASS=A,MSGCLASS=A,NOTIFY=DEVP001 2 //LIST EXEC PGM=AMBLIST 00020001 3 //SYSPRINT DD SYSOUT=* 00030001 4 //SCEELKED DD DSN=SYS1.SCEELKED,DISP=SHR,VOL=SER=RES001,UNIT=3390 00040001 5 //SYSINDD * 00050001 ICH70001I DEVP001 LAST ACCESS AT 20:31:59 ON THURSDAY, SEPTEMBER 4, 2014 IEF236I ALLOC. FOR AMBLIST LIST IEF237I JES2 ALLOCATED TO SYSPRINT IEF237I 376A ALLOCATED TO SCEELKED IEF237I JES2 ALLOCATED TO SYSIN IEF142I AMBLIST LIST - STEP WAS EXECUTED - COND CODE IEF285I DEVP001.AMBLIST.JOB00311.D102.? SYSOUT IEF285I SYS1.SCEELKEDKEPT IEF285I VOL SER NOS= RES001. IEF285I DEVP001.AMBLIST.JOB00311.D101.? SYSIN IEF373I STEP/LIST/START 2014247.2047 IEF032I STEP/LIST/STOP 2014247.2047 CPU: 0 HR 00 MIN 00.02 SECSRB: 0 HR 00 MIN 00.01 SEC VIRT: 4096K SYS: 308K EXT:4K SYS:11800K ATB- REAL:12K SLOTS: 0K VIRT- ALLOC: 2M SHRD: 0M IEF375I JOB/AMBLIST /START 2014247.2047 IEF033I JOB/AMBLIST /STOP 2014247.2047 CPU: 0 HR 00 MIN 00.02 SECSRB: 0 HR 00 MIN 00.01 SEC 1 LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF 00060001 1 * M O D U L E S U M M A R Y * 0MEMBER NAME: EDC@@248 MAIN ENTRY POINT: 0LIBRARY: SCEELKED AMODE OF MAIN ENTRY POINT: 31 0** ALIASES ** ENTRY POINTAMODE ** STRXFRM 31 - 0 ATTRIBUTES OF MODULE 0** BIT STATUS BIT STATUS BIT STATUS BIT STATUS ** 0 0 RENT 1 REUS 2 NOT-OVLY 3 NOT-TEST 4 NOT-OL 5 BLOCK6 EXEC 7 1-TXT 8 NOT-DC 9 ZERO-ORG 10 EP-ZERO 11 NO-RLD 12 EDIT 13 NO-SYMS 14 F-LEVEL 15 NOT-REFR 0 -MODULE SSI:NONE APFCODE: RMODE: ANY LONGPARM: NO 0 *LOAD MODULE PROCESSED EITHER BY VS LINKAGE EDITOR OR BINDER 1 NUMERICAL MAP AND CROSS-REFERENCE LIST OF LOAD MODULE EDC@@248PAGE 0001 - CONTROL SECTION ENTRY LMOD LOC NAME LENGTH TYPE LMOD LOC CSECT LOC NAME 0 00STRXFRM 0A SD 0LENGTH OF LOAD MODULE 10 1ALPHABETICAL MAP OF LOAD MODULE EDC@@248 PAGE 0002 - CONTROL SECTIONENTRY NAME LMOD LOC LENGTH TYPE NAME LMOD LOC CSECT LOC CSECT NAME 0 STRXFRM 000A SD -**END OF MAP AND CROSS-REFERENCE LISTING
Re: RSU APPLY ISSUE GIM23911E
On Fri, 5 Sep 2014 11:36:46 +0530, Mainframe Mainframe wrote: I was getting errors while doing apply check for these HOLDERROR, It is not essential to have RC=0 from an APPLY. RC=4 is usually ok, but you do need to ascertain the reasons for it. PTFs that do not apply because there is an ERROR hold is not a problem, unless those PTFs are critical for your system. There has to be a specific problem that you have with your system. so, I used by pass to move ahead for apply. IF you have researched the APARs for these error holds, And IF you have determined that the PTF(s) that are held resolve a problem that you have been experiencing, And IF you have decided that the problem that you have that is corrected by the PTFs is more critical in your environment than the problems described by the APARs, Then, and only then, does it make sense to bypass the errors. Is there any issues you see in this. Yes. BYPASS(HOLDERROR(...)) tells SMP/E to introduce new errors to your system. Don't do it unless you REALLY know what you are doing. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On Fri, 5 Sep 2014 19:21:41 +0530, Mainframe Mainframe mainframe1...@gmail.com wrote: Sorry, Please find correct output. ... 0 ATTRIBUTES OF MODULE 0** BIT STATUS BIT STATUS BIT STATUS BIT STATUS ** 0 0 RENT 1 REUS 2 NOT-OVLY 3 NOT-TEST 4 NOT-OL 5 BLOCK6 EXEC 7 1-TXT 8 NOT-DC 9 ZERO-ORG 10 EP-ZERO 11 NO-RLD 12 EDIT 13 NO-SYMS 14 F-LEVEL 15 NOT-REFR Not refreshable. That's what the Binder told you. You need to find out why. You may need to contact IBM. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I don't think, this could be a issue. Because, I tried this AMBLIST with my OTHER RES volume as well and bit 15 is NOT-REFR and system is running with this. On Fri, Sep 5, 2014 at 8:17 PM, Doug Henry doug_he...@usbank.com wrote: On Fri, 5 Sep 2014 19:21:41 +0530, Mainframe Mainframe mainframe1...@gmail.com wrote: Sorry, Please find correct output. 1 LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF 00060001 1 * M O D U L E S U M M A R Y * 0MEMBER NAME: EDC@@248 MAIN ENTRY POINT: 0LIBRARY: SCEELKED AMODE OF MAIN ENTRY POINT: 31 0** ALIASES ** ENTRY POINTAMODE ** STRXFRM 31 - 0 ATTRIBUTES OF MODULE 0** BIT STATUS BIT STATUS BIT STATUS BIT STATUS ** 0 0 RENT 1 REUS 2 NOT-OVLY 3 NOT-TEST 4 NOT-OL 5 BLOCK6 EXEC 7 1-TXT 8 NOT-DC 9 ZERO-ORG 10 EP-ZERO 11 NO-RLD 12 EDIT 13 NO-SYMS 14 F-LEVEL 15 NOT-REFR 0 So the problem is caused by bit 15 being not-refr instead of the proper setting for the module of bit 15 being refr. I am not sure how you broke your system. I noticed that you improperly bypass a lot of apars and that may be the source of the problem. I suggest you go back to the backup of your smpe/system environment and reapply correctly. Doug -- 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: RSU APPLY ISSUE GIM23911E
You do not know if your system is good or not. It is better to open a case with IBM and ask for Language Environment to check. If you do not want to do this, then start over. That means you should have 1) Backed up your SMPE Environment (Both Tlibs, Dlibs and all associated SMPE libraries) before starting maintenance. 2) If not, you may need to delete your environment and start from scratch. Basically you have put your SMP/E environment in a bad state. I am sure many on this list has done this at one time or another. Therefore you need to get back to a good point in time and then start again. Do not bypass any HOLDERRORs in the future. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Friday, September 05, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020-dmarc- requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C compiler substituting for macros inside literals?
On Fri, 5 Sep 2014 07:00:24 -0700, Charles Mills wrote: Not sure if your question is intended to be serious but on an ANSI C compiler there is no way to do substitution inside a literal string. However, what could have been accomplished with this: #define debug(a) printf(the value of a is %d\n, a) that is, a macro that would print the value of foo is 27 can be accomplished with ANSI stringification: #define debug(a) printf(the value of %s is %d\n, #a, a) The preprocessor turns #a into foo (including the quotes) Or, even: #define debug(a) printf(the value of #a is %d\n, a) (I believe.) At times I've needed to do such as: #define STRINGIFY(x) #x #define TOSTRING(x) STRINGIFY(x) #define WHEREAMI ( __FILE__:TOSTRING(__LINE__) ) ... to accomplish a double substitution. I only understand it while I'm staring at a web page. GIYF. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Demonstrating Moore's law
Robert Wessel robertwess...@yahoo.com writes: If you actually tested, cut and packaged the chips on the other wafers, you'd get a higher number, but you would not, of course. And unlike airline seats, mainframe chips are not salable by themselves - you have to put them in an expensive box full of other electronics before you can do that. Unlike the airline seat which is there and ready anyway, whether or not you get a butt into it for a given flight. re: http://www.garlic.com/~lynn/2014j.html#93 Demonstrating Moore's law airline seat is in an infrastructure that has fairly high/expensive run rate ... but gets reused over and over (isn't like corner busstop bench) however, presumably the financial industry representing the majority of mainframe sales ... getting rolled over every new generation ... their one generation old machines will show up somehow in the market. however there is the issue of maintaining premium pricing for the majority of the revenue flow ... while still being able to have incremental revenue for remaining (both ibm chips and airline seats) ... a simpler analogy is termsconditions for IBM's mainframe emulator running on PCs not allowed to be used for production work. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
xmitip txt2pdf
Does anyone use Lionel Dycks txt2pdf process on z/os to create multipage pdfs Attempting to create 2 page pdf but result is just 1 page. IN dd:report OUT dd:pdfs IFEMPTY ERROR ORIENT port LM .25 TM .25 RM .25 BM .25 FONT 7 + PAPER 8.5x11 IMAGE load/page1/'TEST.PAGE1.IMAGE' IMAGE load/page2/'TEST.PAGE2.IMAGE' IMAGE draw/ page1/0/0/100/0/36/36/0/0/1 last digit page #1 IMAGE draw/ page2/0/0/100/0/36/36/0/0/2 last digit page #2 Am I missing something? Tim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: xmitip txt2pdf
I use it all the time to spool job listings, assembly listing, etc for various reasons. Don't have a problem with it at all. Unfortunately, I had nothing to do with the current installation so I don't know if there were ever any problems with multi page PDFs. Charles (Chuck) Hardee Senior Systems Engineer/Database Administration CCG Information Technology Thermo Fisher Scientific 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230 chuck.har...@thermofisher.com | www.thermofisher.com WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent of a system responsible for delivering the message to the intended recipient, is prohibited. If you are not the intended recipient, please inform the sender and delete all copies. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tim Brown Sent: Friday, September 05, 2014 12:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: xmitip txt2pdf Does anyone use Lionel Dycks txt2pdf process on z/os to create multipage pdfs Attempting to create 2 page pdf but result is just 1 page. IN dd:report OUT dd:pdfs IFEMPTY ERROR ORIENT port LM .25 TM .25 RM .25 BM .25 FONT 7 + PAPER 8.5x11 IMAGE load/page1/'TEST.PAGE1.IMAGE' IMAGE load/page2/'TEST.PAGE2.IMAGE' IMAGE draw/ page1/0/0/100/0/36/36/0/0/1 last digit page #1 IMAGE draw/ page2/0/0/100/0/36/36/0/0/2 last digit page #2 Am I missing something? Tim -- 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: RSU APPLY ISSUE GIM23911E
I would be VERY wary of restoring the SMPE environment. Unless it was backed up exactly right with every single SMPE-related data set, restoring over the current environment could result in a mess bigger than the one that (seems to) exist now. Instead I would recommend a 'fix forward' approach. 1. Check and recheck that every DDDEF points to the correct data set. This will take time. Don't shortcut. 2. RESTORE all PTFs that were applied since the ZONE EDIT exercise already noted. This will also take time. Crank through it. 3. Pull the latest HOLD data. 4. Reapply maintenance following the new and improved process: use only BYPASS(HOLDSYS) and nothing else. 5. Expect RC 8 on APPLY CHECK. Look at the CAUSER section. Missing sysmods are OK; ignore them. Any other error must be dealt with. 6. Expect RC 8 on the real APPLY. Once again check the CAUSER section. You should see only the same 'missing sysmod' messages that you saw in APPLY CHECK. Any other error must be dealt with. I agree with those who point out that conflicting LKED attributes are not necessarily a run-time problem, but you should consult IBM via SR to verify. The bigger problem here, as noted, is that your result differs from others (including me) who applied (more or less) the same PTFs. That fact is unsettling. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Doug Henry doug_he...@usbank.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/05/2014 08:37 AM Subject:Re: RSU APPLY ISSUE GIM23911E Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Fri, 5 Sep 2014 19:21:41 +0530, Mainframe Mainframe mainframe1...@gmail.com wrote: Sorry, Please find correct output. 1 LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF 00060001 1 * M O D U L E S U M M A R Y * 0MEMBER NAME: EDC@@248 MAIN ENTRY POINT: 0LIBRARY: SCEELKED AMODE OF MAIN ENTRY POINT: 31 0** ALIASES ** ENTRY POINTAMODE ** STRXFRM 31 - 0 ATTRIBUTES OF MODULE 0** BIT STATUS BIT STATUS BIT STATUS BIT STATUS ** 0 0 RENT 1 REUS 2 NOT-OVLY 3 NOT-TEST 4 NOT-OL 5 BLOCK6 EXEC 7 1-TXT 8 NOT-DC 9 ZERO-ORG 10 EP-ZERO 11 NO-RLD 12 EDIT 13 NO-SYMS 14 F-LEVEL 15 NOT-REFR 0 So the problem is caused by bit 15 being not-refr instead of the proper setting for the module of bit 15 being refr. I am not sure how you broke your system. I noticed that you improperly bypass a lot of apars and that may be the source of the problem. I suggest you go back to the backup of your smpe/system environment and reapply correctly. Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
This is exactly how you resolve this issue. Don't deliberately put broken software on your system. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Friday, September 05, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020-dmarc- requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
While I also would not trust is system, I do trust SMP/E. After running the APPLY EXCLUDING the PTF(s) with errors, he can run the SMP/E report of errors on his system. He can research the errors and possibly RESTORE those he just put on if they sound like they cause aprolem he is likely to encounter, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, September 05, 2014 8:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E You do not know if your system is good or not. It is better to open a case with IBM and ask for Language Environment to check. If you do not want to do this, then start over. That means you should have 1) Backed up your SMPE Environment (Both Tlibs, Dlibs and all associated SMPE libraries) before starting maintenance. 2) If not, you may need to delete your environment and start from scratch. Basically you have put your SMP/E environment in a bad state. I am sure many on this list has done this at one time or another. Therefore you need to get back to a good point in time and then start again. Do not bypass any HOLDERRORs in the future. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Friday, September 05, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020- dmarc- requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Or what Skip says :) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Friday, September 05, 2014 9:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I would be VERY wary of restoring the SMPE environment. Unless it was backed up exactly right with every single SMPE-related data set, restoring over the current environment could result in a mess bigger than the one that (seems to) exist now. Instead I would recommend a 'fix forward' approach. 1. Check and recheck that every DDDEF points to the correct data set. This will take time. Don't shortcut. 2. RESTORE all PTFs that were applied since the ZONE EDIT exercise already noted. This will also take time. Crank through it. 3. Pull the latest HOLD data. 4. Reapply maintenance following the new and improved process: use only BYPASS(HOLDSYS) and nothing else. 5. Expect RC 8 on APPLY CHECK. Look at the CAUSER section. Missing sysmods are OK; ignore them. Any other error must be dealt with. 6. Expect RC 8 on the real APPLY. Once again check the CAUSER section. You should see only the same 'missing sysmod' messages that you saw in APPLY CHECK. Any other error must be dealt with. I agree with those who point out that conflicting LKED attributes are not necessarily a run-time problem, but you should consult IBM via SR to verify. The bigger problem here, as noted, is that your result differs from others (including me) who applied (more or less) the same PTFs. That fact is unsettling. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Doug Henry doug_he...@usbank.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/05/2014 08:37 AM Subject:Re: RSU APPLY ISSUE GIM23911E Sent by:IBM Mainframe Discussion List IBM- m...@listserv.ua.edu On Fri, 5 Sep 2014 19:21:41 +0530, Mainframe Mainframe mainframe1...@gmail.com wrote: Sorry, Please find correct output. 1 LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF 00060001 1 * M O D U L E S U M M A R Y * 0MEMBER NAME: EDC@@248 MAIN ENTRY POINT: 0LIBRARY: SCEELKED AMODE OF MAIN ENTRY POINT: 31 0** ALIASES ** ENTRY POINTAMODE ** STRXFRM 31 -- --- 0 ATTRIBUTES OF MODULE 0** BIT STATUS BIT STATUS BIT STATUS BIT STATUS ** 0 0 RENT 1 REUS 2 NOT- OVLY 3 NOT-TEST 4 NOT-OL 5 BLOCK6 EXEC 7 1-TXT 8 NOT-DC 9 ZERO-ORG 10 EP- ZERO 11 NO-RLD 12 EDIT 13 NO-SYMS 14 F- LEVEL 15 NOT-REFR 0- --- So the problem is caused by bit 15 being not-refr instead of the proper setting for the module of bit 15 being refr. I am not sure how you broke your system. I noticed that you improperly bypass a lot of apars and that may be the source of the problem. I suggest you go back to the backup of your smpe/system environment and reapply correctly. Doug -- 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: Demonstrating Moore's law
t...@harminc.net (Tony Harminc) writes: Which is why I've wondered here why IBM doesn't try to find some market for those chips that's different enough from the traditional mainframe one that it won't bite into it, but still lets them sell the chips for at least something. Well, maybe they have tried, and maybe there just isn't any such market, given the characteristics of the chips: ho-hum price/performance, not massively parallel, but extreme on-chip reliability. Presumably market segments that need reliability have already worked around flaky chips by using other (higher layer) approaches. re: http://www.garlic.com/~lynn/2014j.html#93 Demonstrating Moore's law by 30yrs ago, hardware reliability got to the point that majority of service outages were no longer hardware and shifting to human mistake and environemtal (power, storms, flooding, fires, etc) ... as a result next incremental improvement service availability required geographic replication. once you have geographic replication for high service availability ... then the replicated systems would also mask any incidental hardware failure. in the late 80s and early 90s we did ibm's ha/cmp (high availability) and we demonstrating superior operational characteristics against pure hardware fault tolerant. At the time out marketing, I coin'ed the terms disaster survivability and geographic survivabilty Anyway, as a result I got asked to write a section for the ibm corporate continuous strategy document ... but then it got pulled when both rochester (as/400) and pok (mainframe) complained they couldn't meet the objectives. Then the cluster scaleup part of ha/cmp was transferred, we were told we couldn't work on anything with more than four processors, and announced as ibm supercomputer for technical and scientific *ONLY*. old reference to meeting Ellison's conference room first part of january1992 http://www.garlic.com/~lynn/95.html#13 within a month of that meeting it had been announced as ibm supercomputer ... some old email http://www.garlic.com/~lynn/lhwemail.html#medusa past ha/cmp posts http://www.garlic.com/~lynn/subtopic.html#hacmp past continuous availability posts http://www.garlic.com/~lynn/submain.html#available Jim Gray was major person at ibm san jose research creating the original relational/sql database. When he left for tandem, he palmed a lot of stuff on me. While at tandem he did a lot of studiessurveys for availabilityoutages ... and also the prime mover behind TPC benchmarks. http://www.tpc.org/information/who/gray.asp old gray presentation on service outages http://www.garlic.com/~lynn/grayft84.pdf -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I've been watching this exchange from a distance. Are we now confusing 2 issues here? We have the original problem of CEEPLPKA and the secondary one of his running apply jobs bypassing holderrors without knowing what he was bypassing. The OP has gotten an apply check to run with RC=0 after removing the BYPASS(HOLDERROR) by eliminating the PTFs that were held by the error. This doesn't do anything about the original problem of the apply returning RC=4 on CEEPLPKA on the actual apply. Unless the OP eliminated additional PTFs from the apply (one at least of which would need to be installing a fix into CEEPLPKA), he will still have the issue with language environment. Unless I missed a part of the conversation, I believe he still needs to find out how to get the load module flags set correctly. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, September 05, 2014 11:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E This is exactly how you resolve this issue. Don't deliberately put broken software on your system. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Friday, September 05, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020-dmarc- requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this
Re: RSU APPLY ISSUE GIM23911E
On 2014-09-05, at 10:33, Gibney, Dave wrote: He can research the errors and possibly RESTORE those he just put on if they sound like they cause aprolem he is likely to encounter, I have once, perhaps twice, got in a situation where an attempt to APPLY a defective, perhaps chimeric, PTF left the CSI so damanged that an attempt to RESTORE failed. Subsequent attempts to APPLY REDO failed because SMP/E noted that the RESTORE had failed; further attempts to RESTORE failed because the PTF was not recorded as APPLYed. I re-installed. But I'm not our customer; we made the PTF right before it went to field. No one has much noted my suggestion to inspect the Binder SYSPRINT (SMP00040) for IEWW messages, or have we got beyond that point? GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. BYPASS(PRE) is not a solution; it usually makes things much worse. As does BYPASS(MODID). We have had competent customers review HOLDDATA comments; conclude correctly that the documented introduced defect was not relevant to their configurations; and APPLY BYPASS(HOLDERR(aparnum)) beneficially. Be informed, and be specific about the aparnum(s). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
And potentially a third problem that was mentioned by Anthony Thompson that has been overlooked as well. The OP posted an AMBLIST of module STRXFRM showing it as an ALIAS of EDC@@248. Anthony pointed out that on his 2.1 system, both STRXFRM and EDC@@248 are aliases of EDC4$09E. My 1.13 system matches Anthony's 2.1 system. Is the fact that the OP's system appears to be different in SCEELKED another problem? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Friday, September 05, 2014 11:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I've been watching this exchange from a distance. Are we now confusing 2 issues here? We have the original problem of CEEPLPKA and the secondary one of his running apply jobs bypassing holderrors without knowing what he was bypassing. The OP has gotten an apply check to run with RC=0 after removing the BYPASS(HOLDERROR) by eliminating the PTFs that were held by the error. This doesn't do anything about the original problem of the apply returning RC=4 on CEEPLPKA on the actual apply. Unless the OP eliminated additional PTFs from the apply (one at least of which would need to be installing a fix into CEEPLPKA), he will still have the issue with language environment. Unless I missed a part of the conversation, I believe he still needs to find out how to get the load module flags set correctly. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, September 05, 2014 11:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E This is exactly how you resolve this issue. Don't deliberately put broken software on your system. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Friday, September 05, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020-dmarc- requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. -- Tom Marchant
Re: IBM C compiler substituting for macros inside literals?
It could also be done by taking advantage of the fact that adjacent string literals are combined during compilation: #define debug(a) printf(the value of #a is %d\n, a) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, September 05, 2014 7:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM C compiler substituting for macros inside literals? Not sure if your question is intended to be serious but on an ANSI C compiler there is no way to do substitution inside a literal string. However, what could have been accomplished with this: #define debug(a) printf(the value of a is %d\n, a) that is, a macro that would print the value of foo is 27 can be accomplished with ANSI stringification: #define debug(a) printf(the value of %s is %d\n, #a, a) The preprocessor turns #a into foo (including the quotes) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: Friday, September 05, 2014 1:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM C compiler substituting for macros inside literals? So tell me, if one wanted to achieve this apparently non-standard effect how WOULD one go about it? Not that I want to but it HAD to be asked. :-) -- 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: RSU APPLY ISSUE GIM23911E
On 09/05/14 13:19, Paul Gilmartin wrote: On 2014-09-05, at 10:33, Gibney, Dave wrote: He can research the errors and possibly RESTORE those he just put on if they sound like they cause aprolem he is likely to encounter, I have once, perhaps twice, got in a situation where an attempt to APPLY a defective, perhaps chimeric, PTF left the CSI so damanged that an attempt to RESTORE failed. Subsequent attempts to APPLY REDO failed because SMP/E noted that the RESTORE had failed; further attempts to RESTORE failed because the PTF was not recorded as APPLYed. I re-installed. But I'm not our customer; we made the PTF right before it went to field. No one has much noted my suggestion to inspect the Binder SYSPRINT (SMP00040) for IEWW messages, or have we got beyond that point? GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. BYPASS(PRE) is not a solution; it usually makes things much worse. As does BYPASS(MODID). We have had competent customers review HOLDDATA comments; conclude correctly that the documented introduced defect was not relevant to their configurations; and APPLY BYPASS(HOLDERR(aparnum)) beneficially. Be informed, and be specific about the aparnum(s). -- gil That's why Systems Programming is as much an art as it is a science. Knowing why you do things or even more importantly why you don't do something, has to be learned from experience. -- Mark Jacobs Time Customer Service Tampa, FL The standard you walk past is the standard you accept. Lt. Gen. David Morrison, Australian Army Chief -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocation in CYLinder increments (UNCLASSIFIED)
True for some value of basically, but not true always. Keyed searches cannot be executed in ECKD mode, so a PDS directory, VTOC, or keyed BDAM or BSAM file that has lots of keyed searches done against it should be allocated on a cylinder boundary for a small improvement in elapsed time of the I/O. Bill Fairchild - Original Message - From: Ted MacNEIL eamacn...@yahoo.ca To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, September 4, 2014 12:45:39 PM Subject: Re: Allocation in CYLinder increments (UNCLASSIFIED) Since ECKD came out in the 1990's, the need to worry about the cylinder vs track allocation basically went away with define extent. - -teD - Original Message From: Storr, Lon A CTR USARMY HRC (US) Sent: Thursday, September 4, 2014 13:30 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Allocation in CYLinder increments (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE Hello List, I'd be interested in feedback regarding allocation in tracks versus cylinders for certain types of high-usage datasets. I believe that there may be certain instances when allocation in units of CYL is beneficial. One example, I believe, is a PDS that has a multi-track directory: a single channel program can search up to a CYLinder at a time. Another example, I believe, is a VSAM dataset allocated in CYLinders will receive a CA-size of one CYLinder. A benefit similar to the first, if it even exists, would be achieved by caching the PDS directory in some way (e.g. BLDL), as I'm sure many system software applications already do (e.g. LLA and ISPF). Are there still pertinent benefits to allocating certain types of datasets in CYLinder increments? Thanks, Alan Classification: UNCLASSIFIED Caveats: NONE -- 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: RSU APPLY ISSUE GIM23911E
I would also, having done this awhile, be comfortable with APPLY BYPASS(HOLDERR(specificapar)) is and only if I was 1. Actually experiencing the problem fixed by the PTF and 2. Confident the reason for error wasn't worse. At the beginning of my systems programmer career, I might have been naïve enough to try BYPSSS(HOLDERR but I had the benefit of more experienced mentors. Mr. Mainframe Mainframe is trying hard, but it is clear he has been tossed in the deep end without sufficient support and training. We have had competent customers review HOLDDATA comments; conclude correctly that the documented introduced defect was not relevant to their configurations; and APPLY BYPASS(HOLDERR(aparnum)) beneficially. Be informed, and be specific about the aparnum(s). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
I think I saw a comment to the effect that the error in the PTF that needed to be excluded related to the rc=4, but I could be wrong. Actually, I don't know how far this system has evolved/mutated since the Serverpac install. I an stongly inclined to recommending a do over starting with a fresh order/install of a new Serverpac :) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Friday, September 05, 2014 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I've been watching this exchange from a distance. Are we now confusing 2 issues here? We have the original problem of CEEPLPKA and the secondary one of his running apply jobs bypassing holderrors without knowing what he was bypassing. The OP has gotten an apply check to run with RC=0 after removing the BYPASS(HOLDERROR) by eliminating the PTFs that were held by the error. This doesn't do anything about the original problem of the apply returning RC=4 on CEEPLPKA on the actual apply. Unless the OP eliminated additional PTFs from the apply (one at least of which would need to be installing a fix into CEEPLPKA), he will still have the issue with language environment. Unless I missed a part of the conversation, I believe he still needs to find out how to get the load module flags set correctly. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, September 05, 2014 11:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E This is exactly how you resolve this issue. Don't deliberately put broken software on your system. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Mainframe Mainframe Sent: Friday, September 05, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E Thanks all for reply. Now to resolve this issue, I tried running below more steps. 1) I run APPLY CHECK Job without HOLDERROR included in it. Job failed with RC 08 GIM69168E ** HFSCOPY PROCESSING TO THE SIZUFSC LIBRARY FAILED FOR HFS IZUGNAAC IN SYSMOD UI16044. THE RETURN CODE (12) EXCEEDED THE ALLOWABLE VALUE. DATE 14.247 - TIME 23:39:39 - SEQUENCE NUMBER 25. GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD UI16044. SYSTEM UTILITY PROCESSING FAILED FOR AN ELEMENT IN UI16044. GIM30219E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER PRE OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16025. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16026. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16027. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16028. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16029. PROCESSING FAILED FOR SYSMOD UI16044, WHICH WAS SPECIFIED ON THE ++VER REQ OPERAND. GIM30221E ** APPLY PROCESSING FAILED FOR SYSMOD UI16030. PROCESSING FAILED FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . Then I tried looking at UI16044 PTF in SMPPTS and this is basically for z/OSMF and we are not using this product.So, I tried EXCLUDING and run Job again. This time it failed with GIM30204E ** APPLY PROCESSING FAILED FOR SYSMOD UI18572. REQUIRED SYSMODS WERE EXCLUDED. GIM35905IPREREQUISITE SYSMOD UI16044 WAS EXCLUDED. And UI18572 also belongs to z/OS MF. So, I EXCLUDED this as well from APLLY CHeck Job and run with RC00. Is it good way to bypass the issue, I am facing or Do I have to solve it now before moving forward. Suggestion Please. On Fri, Sep 5, 2014 at 7:36 PM, Tom Marchant 000a2a8c2020- dmarc- requ...@listserv.ua.edu wrote: On Fri, 5 Sep 2014 06:56:17 -0700, Lizette Koehler wrote: Do not change the CEEPLPKA. IBM sets that and probably requires it to be a 0 max cc. So, try the apply without the BYPASS HOLDERROR and see if it works. We don't know the state of his system. Those APARs are likely not for LE, but for some other component. His APPLY failed, but we don't know what was done when he ran the APPLY with BYPASS (HOLDERROR). The PTF(S) with the error holds may or may not have been applied. At this point, I wouldn't trust his system. --
Re: xmitip txt2pdf
Actually Leland Lucius Is the author of TXT2PDF. I use it all the time also and currently running; v09.336 I may have the same problem as you, if the DD:REPORT points to a DUMMY file, I would only get 1 page also with the first image, but if I pointed REPORT to a data set that would produce multiple pages, it printed the first image on the first page and then the second on the second page. On the IMAGE command, there is one more parm after the PAGE#, which is how many pages after the page to put the image on, a 0 (zero) value will put it on one page. My config input looked like this: CONFIRM V MSGID Y IN DD:REPORT OUT DOC.IVP$DOC.PDF ifempty BLANK orient port CC No LM .25 TM .25 RM .25 BM .25 FONT 12 PAPER Letter IMAGE load/page1/'AJNIMS.TXT2PDF.PDS(testjpg)' IMAGE load/page2/'AJNIMS.VOLCANO.JPG' IMAGE draw/page1/0/0/100/0/100/100/0/0/1/0 IMAGE draw/page2/0/0/025/0/100/100/0/0/2/0 Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tim Brown Sent: Friday, September 05, 2014 12:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: xmitip txt2pdf Does anyone use Lionel Dycks txt2pdf process on z/os to create multipage pdfs Attempting to create 2 page pdf but result is just 1 page. IN dd:report OUT dd:pdfs IFEMPTY ERROR ORIENT port LM .25 TM .25 RM .25 BM .25 FONT 7 + PAPER 8.5x11 IMAGE load/page1/'TEST.PAGE1.IMAGE' IMAGE load/page2/'TEST.PAGE2.IMAGE' IMAGE draw/ page1/0/0/100/0/36/36/0/0/1 last digit page #1 IMAGE draw/ page2/0/0/100/0/36/36/0/0/2 last digit page #2 Am I missing something? Tim -- 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: xmitip txt2pdf
On 09/05/2014 11:16 AM, Tim Brown wrote: Does anyone use Lionel Dycks txt2pdf process on z/os to create multipage pdfs Attempting to create 2 page pdf but result is just 1 page. IN dd:report OUT dd:pdfs IFEMPTY ERROR ORIENT port LM .25 TM .25 RM .25 BM .25 FONT 7 + PAPER 8.5x11 IMAGE load/page1/'TEST.PAGE1.IMAGE' IMAGE load/page2/'TEST.PAGE2.IMAGE' IMAGE draw/ page1/0/0/100/0/36/36/0/0/1 last digit page #1 IMAGE draw/ page2/0/0/100/0/36/36/0/0/2 last digit page #2 Am I missing something? Tim We used to regularly generate multi-page pdf attachments. Do you have enough text data supplied to txtpdf for text to need to flow to a 2nd page with given margins and font? If not, I wouldn't expect a 2nd page even though you have defined a different appearance for it. I never experimented with multiple page formats within the same multi-page pdf, so can't speak from direct experience. Is the imbedded space shown in draw/ page acceptable? The last txt2pdf manual I had doesn't make it clear that this is permitted syntax. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DEBs and DCBs and friends
Under what circumstances can the JS TCB DEB pointer (TCBDEB) be zero? I have at least one open DCB, and previously I've seen a DEB on that chain for each open DCB or ACB. Put another way, how can I reliably find an open DCB/ACB for a given DDNAME? I've previously (while the program is running) gone through the DEB chain, DEB-DCB, DCB-TIOT entry, and match the DDNAME. Clearly if there's no DEB chain this won't work. This is a dump where one TCB in this multi-task STC is abending (S878); could I/O cleanup have already zeroed TCBDEB by this point, even though the DCB is still open and the DEB still seems to exist? The open DCB in this case is for a subsystem dataset (JES3 SYSOUT), so I suppose it logically doesn't really need a DEB, but I've never seen it not there before. Maybe a JES3 thing? And yes, I know there'll be an ACB in the middle of things in this case. I found the DCB in question by brute-force search, and its DEB pointer DCBDEBAD points to a DEB-looking thing that passes several tests: it points to the TCB, DEBECBAD points back to the DCB, and DEBDCBAD points to an ACB. But if I hadn't been able to find the DCB on my own... Trying another route, I went to look at the DEB table from JSCBDBTB. But this seems to have gone OCO at some point, and certainly isn't PI. And it doesn't look like the simple table of 4-byte pointers that it once did. :-( Is there anything in IPCS to format the DEB table, or to some extent duplicate the DEBCHK service? And yet another route, SCTSIOT/IEFDDSUM from the 6i option in IPCS show three allocated DDs, all of which I expect to be open. Is there a path from the SIOT to the DCB/ACB? (In passing, the SIOT addresses shown by IEFDDSUM are rejected when used as input to SIOTPLUS/IEFSIOTP in the same panel. Looks as though the eyecatcher validation is failing, but they look right in storage. Strange...) Thanks for any (heh) pointers... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
On Fri, 5 Sep 2014 17:32:19 +, Pommier, Rex rpomm...@sfgmembers.com wrote: And potentially a third problem that was mentioned by Anthony Thompson that has been overlooked as well. The OP posted an ?AMBLIST of module STRXFRM showing it as an ALIAS of EDC@@248. Anthony pointed out that on his 2.1 system, both STRXFRM and EDC@@248 are aliases of EDC4$09E. My 1.13 system matches Anthony's 2.1 system. Is the fact that the OP's system appears to be different in SCEELKED another problem? Rex Hi Rex, Using the wrong verion of SCEELKED is the entire problem of getting a return code 4 on the binder when the OP applied UI18451. As you noticed he is not using a z/OS V2R1 or a z/os V1R13 SCEELKED. I am not sure how far you have to back to get one like he is using. He is lucky that the apply required a return code of 0 to be successful ! Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU APPLY ISSUE GIM23911E
Dave, I guess we will have to disagree on what holds can be bypassed. There are examples that IBM tells you in the hold why to do that its OK to bypass. Usually IME: action or others they tell you that you must do this ie link it outside of SMPE with special parms. Granted its not often but that is why its important to do as IBM instructs. SYSGEN (you wont see that now days) was another one that there was something special you had to do after applying the PTF. I know when I used to do SMP work by bypass was always on 2 lines. Yes I checked every PTF that was on the hold report to see anything I might need to do after those PTF's went on with an apply. A LONG time ago I was putting on a CBPDO there were 13000 PTF's going on and the hold list (IIRC 150 were held) was well researched. In fact IBM had not shipped all the PTF's on the tape and I finally got to do a full apply of those 13000 PTF's and it seemed to take forever (12+ hours). In summary I think its OK to bypass *SOME* hold errors of course not all. Ed On Sep 5, 2014, at 2:03 AM, Gibney, Dave wrote: You should never (unless told by IBM who probably never will) BYPASS error holds. They have the hold because they are in error. The error could be minor or it could crash your entire system. Use EXCLUDE of the PTF with the error if you wish to get a successful APPLY. INMO. you shouldn't be APPLY without having achieved a successful APLYCHECK run, but other here just run and let the PTFs with error holds fail. But, either way, intentionally putting broken software on your system is not a good practice. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Thursday, September 04, 2014 11:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E I was getting errors while doing apply check for these HOLDERROR, so, I used by pass to move ahead for apply.Is there any issues you see in this. Do you suggest to change acceptable value for CEEPLPKA or any other clue. On Fri, Sep 5, 2014 at 10:39 AM, Lizette Koehler stars...@mindspring.com wrote: There were two things in the job run I was able to see. Let me know if this might be part of the issue First - should you code BYPASS(HOLDS(...) HOLDE(...) )?? I always thought you should let HOLDERROR alone unless you have a fixing PTF from IBM. Though I could be wrong. BYPASS(HOLDSYS(DOC,IPL,RESTART,ACTION,ENH,DEP,AO,MSGSKEL,MULTSYS, DYNACT,EC,DB2BIND,EXIT,DELETE,DDDEF) HOLDERROR(AA45207,AA45706,AA45113,AA44153,AA45166,AA44844,AA45744)) Second IEW2322I 1220 923NAME CEEPLPKA(R) MAX ACCEPTABLE RC=00 IEW2454W 9203 SYMBOL CEEARLU UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL CEEBLLST UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL STRFTIME UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. IEW2454W 9203 SYMBOL LOCALECO UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. I think the fact that CEEPLPKA sets max cc as 0 is the issue for UI18451 Let me know if I am closer to the resolution. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, September 04, 2014 9:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSU APPLY ISSUE GIM23911E On Thu, 4 Sep 2014 21:55:32 +0530, Mainframe Mainframe wrote: I see some more warning message before this error message like ... GIM23913WLINK-EDIT PROCESSING FOR SYSMOD UA72482 WAS SUCCESSFUL FOR MODULE CBRICMMN IN LMOD CBRINIT0 IN THE LPALIB LIBRARY. THE RETURN CODE WAS 04. DATE 14.247 - TIME 02:35:21 - SEQUENCE NUMBER 87 SYSPRINT FILE SMP00040. ... That's from SMPOUT, not Binder SYSPRINT. Are you viewing your output with SDSF? If so, open the job with ? rather than S and go directly to SMP00040 (I believe (E)JES has a similar feature, perhaps different syntax). Try FIND p'IEWW' (IIRC correctly the ISPF syntax -- help!?) On Thu, Sep 4, 2014 at 9:44 PM, Paul Gilmartin wrote: On Thu, 4 Sep 2014 21:13:31 +0530, Mainframe Mainframe wrote: Hello Rob, In my case LKED entry in SMPE is set to 04. Binder SYSPRINT (perhaps in your case SMP00030) should tell you: Oops! I meant SMP00040. o The maximum RC specified on the NAME statement (IIRC, SMP/E converts that to a comment). o The actual return code from the bind operation (look near the bottom). o Message codes, , of Warning severity. Search backward for IEWW. --gil - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive
Re: RSU APPLY ISSUE GIM23911E
On Sep 5, 2014, at 9:01 AM, Tom Marchant wrote: -SNIP Not refreshable. That's what the Binder told you. You need to find out why. You may need to contact IBM. Tom, I agree. the module somehow got linked incorrectly either from the last PTF that hit it or it got linked outside of SMPE. What the author should do is look at what the last PTF that hit the module and see what the link parms were. There may have been a PTF that did it by mistake and no ones caught it untillthe PTF that was going on was caught. In either case make sure through SMPE what the last PTF went on and look at retain to see if it was in error and do the research on previous PTF's to see eho caused the problem and open a PMR if everything is Kosher. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Command Prefixes
Somewhere in MVS there's a table of 'recognized' command prefixes used to route a command to the appropriate task. In our case, we use 'SA' for commands to Netview System Automation. This is not working in our z/OS 2.1. (We have an open SR.) Is there a commonly available tool for displaying the command prefix table? Something might jump out or at least provide additional doc for IBM. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Command Prefixes
Wow. That's for sure 'commonly available'. Thanks! . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Alan Field alan.fi...@bluecrossmn.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/05/2014 01:36 PM Subject:Re: Command Prefixes Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU D OPDATA? Alan Field Technical Engineer Principal BCBS Minnesota Phone: 651.662.3546 Mobile: 651.428.8826 From: Skip Robinson jo.skip.robin...@sce.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/05/2014 15:34 Subject:Command Prefixes Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Somewhere in MVS there's a table of 'recognized' command prefixes used to route a command to the appropriate task. In our case, we use 'SA' for commands to Netview System Automation. This is not working in our z/OS 2.1. (We have an open SR.) Is there a commonly available tool for displaying the command prefix table? Something might jump out or at least provide additional doc for IBM. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Command Prefixes
D OPDATA,PREFIX or D O,PREFIX Thanks Bill Bishop Specialist Mainframe Support Group Server Development Support Toyota Motor Engineering Manufacturing North America, Inc. bill.bis...@tema.toyota.com (502) 570-6143 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Friday, September 05, 2014 4:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Command Prefixes Somewhere in MVS there's a table of 'recognized' command prefixes used to route a command to the appropriate task. In our case, we use 'SA' for commands to Netview System Automation. This is not working in our z/OS 2.1. (We have an open SR.) Is there a commonly available tool for displaying the command prefix table? Something might jump out or at least provide additional doc for IBM. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
abend code BB7 ?
Abend code BB7 does not seem to be documented in the System Codes manual, even at the z.os 2.1 level. As in: IEC615I ABEND=000BB7-1101 OCCURRED IN THE (nameremoved) EXIT MODULE FOR DYNAMIC EXIT IGGPRE00_EXIT The IEC615I message only indicates that abend 000BB7-110 occured in exit routine (nameremoved) . Is this not documented on purpose, or has the manual not caught up with Dynamic Exits? Does anyone know what the BB7 abend is caused by? Thank you. Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Dynalloc with FREE=CLOSE,SPIN=UNALLOC
I have a Started Task with a log file. I'd like to SPIN off the log files from my C program and allow the users to delete them when there is too much spool output or the log file is no longer needed. The C program is calling dynalloc() to allocate the file but I don't see any flags for SPIN=UNALLOC. I am currently using ip.__misc_flags = __RELEASE __CONTIG __CLOSE; but that leaves the DD associated with the running step and not purgable/deletable. Does anyone know whether dynalloc() supports FREE=CLOSE,SPIN=UNALLOC? Janet Graff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynalloc with FREE=CLOSE,SPIN=UNALLOC
Look at the assembler service guide. Dynalloc () is just a wrapper which calls svc99. On Sep 5, 2014 6:55 PM, Janet Graff 004dc9e91b6d-dmarc-requ...@listserv.ua.edu wrote: I have a Started Task with a log file. I'd like to SPIN off the log files from my C program and allow the users to delete them when there is too much spool output or the log file is no longer needed. The C program is calling dynalloc() to allocate the file but I don't see any flags for SPIN=UNALLOC. I am currently using ip.__misc_flags = __RELEASE __CONTIG __CLOSE; but that leaves the DD associated with the running step and not purgable/deletable. Does anyone know whether dynalloc() supports FREE=CLOSE,SPIN=UNALLOC? Janet Graff -- 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: Dynalloc with FREE=CLOSE,SPIN=UNALLOC
On Fri, 5 Sep 2014 18:54:59 -0700, Janet Graff janet.gr...@yahoo.com wrote: I have a Started Task with a log file. I'd like to SPIN off the log files from my C program and allow the users to delete them when there is too much spool output or the log file is no longer needed. The C program is calling dynalloc() to allocate the file but I don't see any flags for SPIN=UNALLOC. I am currently using ip.__misc_flags = __RELEASE __CONTIG __CLOSE; but that leaves the DD associated with the running step and not purgable/deletable. Does anyone know whether dynalloc() supports FREE=CLOSE,SPIN=UNALLOC? Janet, If you are at z/OS 1.13 or higher, you could use 'Spin any Spin' and add an additional operand to SPIN=UNALLOC specification in your long running started task jcl to do one of the following - 1. spin the dataset at a specified time; 2. spin the dataset at a specified interval; 3. spin every nnn records; 4. spin dataset on command Hope that helps. Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
