Re: exit add in progxx for cnz_wtomdbexit and setprog
The problem that I described is not a coding problem in the exit. I said that it was not called when initialized from IPL, no problem after issuing the setprog commands. From IPL : IPO4 13075 11:17:34.93 0290 IEE252I MEMBER PROGEX FOUND IN SYS1.PARMLIB IPO4 13075 11:18:02.09 0290 IEA549I SYSTEM CONSOLE FUNCTIONS AVAILABLE 311 Is there any possiblity that the console function needed to implement the exit is not available during IPL when the PROGxx member is processed ? I would have expect that the D PROG,EXIT saying that is is inactive. But the display in CSV464I was OK EXIT CNZ_WTOMDBEXIT MODULESTATE EPADDRLOADPTLENGTHJOBNAME PARAM WMXEXIT1A 94AD3920 14AD3920 16E0 * Bernard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: exit add in progxx for cnz_wtomdbexit and setprog
Does it work if you add the exit via COMMNDxx (later in the IPL) rather than PROGxx? Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernard Coeytaux Sent: Tuesday, 19 March 2013 4:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: exit add in progxx for cnz_wtomdbexit and setprog The problem that I described is not a coding problem in the exit. I said that it was not called when initialized from IPL, no problem after issuing the setprog commands. From IPL : IPO4 13075 11:17:34.93 0290 IEE252I MEMBER PROGEX FOUND IN SYS1.PARMLIB IPO4 13075 11:18:02.09 0290 IEA549I SYSTEM CONSOLE FUNCTIONS AVAILABLE 311 Is there any possiblity that the console function needed to implement the exit is not available during IPL when the PROGxx member is processed ? I would have expect that the D PROG,EXIT saying that is is inactive. But the display in CSV464I was OK EXIT CNZ_WTOMDBEXIT MODULESTATE EPADDRLOADPTLENGTHJOBNAME PARAM WMXEXIT1A 94AD3920 14AD3920 16E0 * Bernard -- 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: exit add in progxx for cnz_wtomdbexit and setprog
Hmmm, after seeing Anthony's question, I wonder if your exit is waiting for a subsystem or console or something to complete during the IPL? But still, I don't know what product is that exit? Elardus, Bernard said he wrote his own exit routine for a dynamic exit defined to the system by z/OS (consoles, to be specific). The only thing I can imagine is that something had happened when that exit was activated early in IPL. After all, the doc states that the exit would get deactivated at the first sign of trouble. If there is nothing visible that may have happened, then I would open a PMR to the consoles group and ask IBM. Unfortunately no one from the consoles group (or Peter Relson, who would know about exceptions in exit prcessing) here on ibmmain has answered. Yet. One can still hope. Best regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: exit add in progxx for cnz_wtomdbexit and setprog
Thanks Barbara, I will do big test next week-end. Depending on the results, I will open a PMR. Regards Bernard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: exit add in progxx for cnz_wtomdbexit and setprog
Barbara Nitz wrote: Elardus, Bernard said he wrote his own exit routine for a dynamic exit defined to the system by z/OS (consoles, to be specific). Thanks. I finally found the documentation and samples about that exit. The underscore in the name caught me out in my searches. Now I'm also puzzled by the problem of Bernard. The only thing I can imagine is that something had happened when that exit was activated early in IPL. After all, the doc states that the exit would get deactivated at the first sign of trouble. SMF [dynamic] exits also do that. No dump, no message, nothing. If there is nothing visible that may have happened, then I would open a PMR to the consoles group and ask IBM. Unfortunately no one from the consoles group (or Peter Relson, who would know about exceptions in exit prcessing) here on ibmmain has answered. Yet. One can still hope. I find it strange too that no-one responded at all. Perhaps there is already a PMR and no-one at IBM will reply on a public forum until that is finished. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Q re attaching COBOL program
On Mon, 18 Mar 2013 15:29:47 -0500, Victor Gil wrote: We have a need to call a COBOL subroutine by attaching it as a subtask, so the call is done through an Assembler stub that issues the Attach, Waits on the termination ECB and Detaches the subtask. I'm just curious. Why do you need to ATTACH the program if it is not to run asynchronously? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Q re attaching COBOL program
On Tue, 19 Mar 2013 06:49:00 -0500, Tom Marchant wrote: I'm just curious. Why do you need to ATTACH the program if it is not to run asynchronously? Doesn't task termination automatically free some resources that the programmer would need to free specifically after a LINK? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Q re attaching COBOL program
On 19/03/2013 9:01 PM, Paul Gilmartin wrote: On Tue, 19 Mar 2013 06:49:00 -0500, Tom Marchant wrote: I'm just curious. Why do you need to ATTACH the program if it is not to run asynchronously? Doesn't task termination automatically free some resources that the programmer would need to free specifically after a LINK? Also if the attached program abends it doesn't sink the entire ship. -- 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: Q re attaching COBOL program
Because these programs connect to DB2 using *different* front ends for call-attachment facility [not to mention different DB2 plans and different ways the plan names are determined during run time]. So, each program essentially needs its own DB2 connection. -Victor- === I'm just curious. Why do you need to ATTACH the program if it is not to run asynchronously? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Q re attaching COBOL program
On Tue, 19 Mar 2013 21:08:03 +0800, David Crayford wrote: On 19/03/2013 9:01 PM, Paul Gilmartin wrote: On Tue, 19 Mar 2013 06:49:00 -0500, Tom Marchant wrote: I'm just curious. Why do you need to ATTACH the program if it is not to run asynchronously? Doesn't task termination automatically free some resources that the programmer would need to free specifically after a LINK? Also if the attached program abends it doesn't sink the entire ship. I suspect that can be covered with an ESTAE in either case. But it's easier with ATTACH. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Setting the OSA Speed and Mode on IBM 2818
Hi Can anyone assist me is setting determining how to set up the OSA Speed and Mode for the OSA card on the IBM 2818 processor. We are trying to define the speed and duplex for the OSA Express4S Gbe LX (card 0404) using the HMC and the SE Advanced Facilities tool. Nowhere is there the ability to make a change. The OSA Implementation manual didn’t help either, maybe because this OSA is 1 step up from what was writte.n Domenic Cifani Technology Consultant III Network Software Canada HP Enterprise Services Telephone (905) 383-7864 HP Cell (905) 869-3279 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Q re attaching COBOL program
On 19/03/2013 9:27 PM, Paul Gilmartin wrote: On Tue, 19 Mar 2013 21:08:03 +0800, David Crayford wrote: On 19/03/2013 9:01 PM, Paul Gilmartin wrote: On Tue, 19 Mar 2013 06:49:00 -0500, Tom Marchant wrote: I'm just curious. Why do you need to ATTACH the program if it is not to run asynchronously? Doesn't task termination automatically free some resources that the programmer would need to free specifically after a LINK? Also if the attached program abends it doesn't sink the entire ship. I suspect that can be covered with an ESTAE in either case. But it's easier with ATTACH. It's certainly easier when you don't *own* the attached program, which is usually when I've seen this technique used. -- 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: BPXBATCH copy to mvs-ds FSUM6259
Hello Group, thank's to everybody for replying. Michael, the same effect happend if the dataset was preallocated or allocated in a previous step. The trick for me was to work with an intermediate Dataset. Assuming that //STEP01 does a cp /user/tmp.txt //'TEST.DATASET1'. //STEP01 EXEC PGM=BPXBATCH //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDPARM DD * SH /user/copy.sh /* //STEP02 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //MYDS DD DSN=TEST.DATASET, // DISP=(,CATLG,DELETE),UNIT=3390,BLKSIZE=27998, // SPACE=(CYL,(10,30),RLSE),RECFM=VB,LRECL=256 //SYSIN DD * REPRO IDS(TEST.DATASET1) OUTFILE(MYDS) /* //STEP03 EXEC PGM=IEFBR10 //SYSPRINT DD SYSOUT=* //DD01DD DSN=TEST.DATASET,DISP=SHR // With best regards, thank you so much Monika snip In JES3 this works as designed: With MDS [JES3 Main Device Scheduler], the resources (data sets, devices, and volumes) that a job requires are already set up when the job is passed to MVS for execution. (cmp. chapter 4.3.1.2 of JES3 Initialization and Tuning Guide). JCL DISP=SHR indicates that the data set exists before this step (cmp MVS JCL Reference). Assuming TEST.DATASET does not exist prior to job submit. Then, JES3 MDS has to allocate the data set before the job starts in order to fulfill DISP=SHR. So, did you try adding STEP00 with IEFBR14 to allocate DSN=TEST.DATASET with DISP=(NEW,CATLG,DELETE) instead of predefining (how exactly??) it in the shell script? Cheers Michael Von:Monika Amiss monika.am...@arcor.de An: IBM-MAIN@LISTSERV.UA.EDU Datum: 2013-03-15 16:34 Betreff:BPXBATCH copy to mvs-ds FSUM6259 Gesendet von: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Dear Group, I have a strange behavior. In the first step I call an Shellscript which does a cp /user/tmp.txt //'TEST.DATASET'. The TEST.DATASET ist predefined and empty. If I run only Step01 everything is Okay, the TEST.DATASET is filled with the data. But if I run it with STEP01 and STEP02, I get in STEP01 () the following error message: cp: FSUM6259 target file //'TEST.DATASET': EDC5061I An error occurred when attempting to define a file to the system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Q re attaching COBOL program
On Tue, 19 Mar 2013 21:50:15 +0800, David Crayford wrote: Doesn't task termination automatically free some resources that the programmer would need to free specifically after a LINK? Also if the attached program abends it doesn't sink the entire ship. I suspect that can be covered with an ESTAE in either case. But it's easier with ATTACH. It's certainly easier when you don't *own* the attached program, which is usually when I've seen this technique used. I know some programmers worry (excessively?) about task overhead, even to the extent of developing alternatives (JES? CICS?), or keeping a stable of idle tasks to be dispatched when needed. I think there are better uses for development resources. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXBATCH copy to mvs-ds FSUM6259
On Tue, 19 Mar 2013 14:55:39 +0100, Monika Amiss wrote: cp /user/tmp.txt //'TEST.DATASET1'. /* ... /* //STEP03 EXEC PGM=IEFBR10 //SYSPRINT DD SYSOUT=* //DD01DD DSN=TEST.DATASET,DISP=SHR // Might you yet shortcut this whole thing with: //DD01DD PATH='/user/tmp.txt',PATHOPTS=ORDONLY,FILEDATA=TEXT ??? IEFBR10? (Probably better than IEFBR15.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Q re attaching COBOL program
On 19/03/2013 10:05 PM, Paul Gilmartin wrote: On Tue, 19 Mar 2013 21:50:15 +0800, David Crayford wrote: Doesn't task termination automatically free some resources that the programmer would need to free specifically after a LINK? Also if the attached program abends it doesn't sink the entire ship. I suspect that can be covered with an ESTAE in either case. But it's easier with ATTACH. It's certainly easier when you don't *own* the attached program, which is usually when I've seen this technique used. I know some programmers worry (excessively?) about task overhead, even to the extent of developing alternatives (JES? CICS?), or keeping a stable of idle tasks to be dispatched when needed. I think there are better uses for development resources. I'm not quite sure if I understand what your point is Paul. Are you saying that a task (thread) pool scheduler is a bad design? -- 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: Q re attaching COBOL program
Answering my own question [for the archives] - LE expects a COBOL MAIN entry [subtasked or not] to be invoked via the EXEC PARM=... convention. So, in the Assembler middleman I had to take the original pointer in R1 and save it as the only passing parm in an EXEC_PARMS area, then Attach with R1 pointing to A(EXEC_PARMS). The opposite conversion into the CALL pgm USING parms format is taking place in the COBOL MAIN stub. Unfortunately, the COBOL stub needs to know the NUMBER of such parameters to be able to issue a respective CALL, so for now I am settling just for one such parm. -Victor- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Query for Destination z article -- mainframes back to the future
On Fri, 2013-03-15 at 09:34 -0500, John Gilmore wrote: Semiconductor memory was introduced to the market as somewhat cheaper and more reliable than ferrite-core memory (although the greater reliability did not really obtain originally) Indeed. I recall turning on ECC corrected-bit reporting on our /145 running VS1, and it kept the console annoyingly busy. This was circa 1974. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SyncSort sortin different record length
Micheal, Syncsort does not support SORTIN01/SORTIN02/... , but we do support SORTMI01/SORTMI02/... - see chapter 12 on MULTIIN in the PG. This is used to support logically concatenated VSAM files, IBM does not support concatenated VSAM, or VSAM and other types of files. All non-VSAM files must have the same record type. If you are talking about RECFM=F type files, then the MULTIIN feature does not support multiple record lengths. If you are talking about RECFM=V type files, then the MULTIIN feature supports multiple LRECL specifications. The manual goes into it in more detail. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Burn Sent: Monday, March 18, 2013 5:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SyncSort sortin different record length Hi Would anyone know if SyncSort accepts Sortinn (multiple sortins) With different record lengths Thanks Sent from my iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Q re attaching COBOL program
Hello: When a COBOL CALL or ENTRY is compiled, each item in the USING is used to create code to process a parameter list of full words equal in number to the number of items in that USING clause. So the CALL parameter list will have two full words. The ENTRY code will only process one full word. So, the CALL to COB#SYNC builds two fullwords of addresses, but the PROCEDURE DIVISION USING is only going to load one BLL cell. The BLL cell for item TPTAPI-COMMAREA will be loaded with the address of the caller's item WS-TPTAPI. The second item WS-TPTAPI-COMMAREA is not addressible by the subroutine (unless the second item is contiguous in storage to WS-TPTAPI and the TPTAPI-COMMAREA item describes both areas, a somewhat unorthodox way of passing parameters). I would have coded two items in the subroutines ENTRY USING clause. CALL-TPTAPI. DISPLAY WS-TPTAPI-COMMAREA CALL COB#SYNC USING WS-TPTAPI WS-TPTAPI-COMMAREA. - - - - - - - - - - - - - 2 Line(s) no DISPLAY WS-TPTAPI-COMMAREA. The subroutine's PROCEDURE USING: PROCEDURE DIVISION USING TPTAPI-COMMAREA. regards, Joe D'Alessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SyncSort sortin different record length
All VB files can be concatenated under SORTIN. As lrecl is irrelevant for VB It's all in the RDW Correct ? Thanks Sent from my iPhone On Mar 19, 2013, at 12:21 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: Micheal, Syncsort does not support SORTIN01/SORTIN02/... , but we do support SORTMI01/SORTMI02/... - see chapter 12 on MULTIIN in the PG. This is used to support logically concatenated VSAM files, IBM does not support concatenated VSAM, or VSAM and other types of files. All non-VSAM files must have the same record type. If you are talking about RECFM=F type files, then the MULTIIN feature does not support multiple record lengths. If you are talking about RECFM=V type files, then the MULTIIN feature supports multiple LRECL specifications. The manual goes into it in more detail. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Burn Sent: Monday, March 18, 2013 5:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SyncSort sortin different record length Hi Would anyone know if SyncSort accepts Sortinn (multiple sortins) With different record lengths Thanks Sent from my iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- 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: SyncSort sortin different record length
Yes, all VB can be concatenated. You can also concatenate VB and VBS. All F type files have to have the same LRECL. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Burn Sent: Tuesday, March 19, 2013 12:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SyncSort sortin different record length All VB files can be concatenated under SORTIN. As lrecl is irrelevant for VB It's all in the RDW Correct ? Thanks Sent from my iPhone ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Q re attaching COBOL program
Joe, thanks for the post. When a caller calls COB#SYNC it indeed passes 2 parms, but the first one is just a name of the program to attach, so it's internal to COB#SYNC logic. The second parm is the one actually passed to the subtask on the ATTACH, so it does match the PROCEDURE USING on the callee. As was explained in a prior post such parm has to conform to the EXEC PARM='...' convention. -Victor- Hello: When a COBOL CALL or ENTRY is compiled, each item in the USING is used to create code to process a parameter list of full words equal in number to the number of items in that USING clause. So the CALL parameter list will have two full words. The ENTRY code will only process one full word. So, the CALL to COB#SYNC builds two fullwords of addresses, but the PROCEDURE DIVISION USING is only going to load one BLL cell. The BLL cell for item TPTAPI-COMMAREA will be loaded with the address of the caller's item WS-TPTAPI. The second item WS-TPTAPI-COMMAREA is not addressible by the subroutine (unless the second item is contiguous in storage to WS-TPTAPI and the TPTAPI-COMMAREA item describes both areas, a somewhat unorthodox way of passing parameters). I would have coded two items in the subroutines ENTRY USING clause. CALL-TPTAPI. DISPLAY WS-TPTAPI-COMMAREA CALL COB#SYNC USING WS-TPTAPI WS-TPTAPI-COMMAREA. - - - - - - - - - - - - - 2 Line(s) no DISPLAY WS-TPTAPI-COMMAREA. The subroutine's PROCEDURE USING: PROCEDURE DIVISION USING TPTAPI-COMMAREA. regards, Joe D'Alessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Resolved: Why is GRS ENQ needed in SMFDUMP program?
Hi to all, In thread 'Why is GRS ENQ needed in SMFDUMP program?' I described the GRS ENQ in SMFDUMP and the resulting START PENDING problem. That was in June 2012 and there was a very interesting discussion lasted a while. This problem is now resolved at all. Thanks to all who replied, all replies were very helpful. I would like to share it in case someone needs it. I'm now using IEFU29 just as it is supplied in SYS1.SAMPLIB with little modifications (WTO white space eliminated and command string 'S SMFDUMP,' changed to 'S something,...' The STC, residing in a single SysPlex-wide Proclib, is using Symbolic names to resolve actual datasets in the JCL. All and every datasets used are unique per LPAR, so absolutely NO ENQ can take place as far as those dumping goes. Since IEE391A is suppressed, no automation software is kicking off SMFDUMP anymore, but on messages IEE366*, IEE985A, etc, the usual SMFDUMP program is started by automation software. This is because the IEFU29 (and the STC submitted) cannot handle situations where more than one MANx is in 'DUMP REQUIRED status. This is fine with me because it is a seldom event. I can now use automation software to issue 'I SMF' on all my dozen plus LPARS simultaneausly. No ENQ, no START PENDING, etc are experienced at all. I do that 'RO *ALL,I SMF' after midnight, 06:00 and 22:00 - 23:00 on all LPARS without causing any delays or problems. Even our nightly backup jobs are running faster. Of course the IEEU29 as supplied by IBM has still that same ENQ macro with the same keywords as used by the SMFDUMP program, but the wall-clock duration of that ENQ is just a second or two. The important difference between IEFU29 and SMFDUMP regarding that ENQ is - IEFU29 ENQ is after the actual 'I SMF', while SMFDUMP is using the ENQ during the whole story of 'I SMF' and finishing off all those MANx datasets and then release that ENQ. I see also the advantage of using a STC to do the dump - no JES2 initiators, higher WLM priority and it seemed to me (or I imagined :-D ) the dumping/emptying of MANx is going somewhat faster. Since I don't have to stagger my SMFDUMP jobs about 30 minutes on all LPARS, all our batch jobs depending on those SMF data can be run earlier in the morning - thus releasing extra CPU cycles to our impatient users. ;-) That is all folks! Many thanks to all who replied to me last year! I'm very grateful of your kind help. Now off to another quest. ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long Passwords
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Toole, Michael Sent: Monday, March 18, 2013 12:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Long Passwords So you're only using them for TSO? I thought you would have to use them for everything if you turned them on? A user with a pass phrase must also have a password. When RACF is called to validate either, it uses the length of the data to determine which it is validating. Consequently, a user with a pass phrase need not ever use it. The password will always work. (I imagine the password authentication exits could be used to prohibit using the password.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Lost datagrams on z/OS 1.12?
I've got a problem that is defying my ability to find it. I have a product that uses sendto() to send UDP messages (datagrams). At one and perhaps two z/OS 1.12 customers I have seen a problem in which what appear to be perfectly good sendto()'s send a datagram that never arrives at its destination. (Of course, the lack of error feedback is a known characteristic of UDP.) Version x.1 of my product does not exhibit this behavior. Version x.2 does. There is relatively little difference between how the two issue sendto(). I have never seen the problem on my development machine, including under z/OS 1.12. It is definitely not a firewall or other external issue because Version x.1 works fine. You bring it down and bring Version x.2 up with the same parameters and it works for a little while and then 100% of the messages start disappearing. You bring it down and bring x.1 back up and all is well. Similar TCP/IP code does not seem to have the same problem. Yes, obviously it could be your basic program bug and I am of course working the heck out of that angle. I'm not asking this list to debug code it has not seen. The code is way too complex to post here meaningfully. But does this problem ring a bell with anyone? I am not the most skilled in the world at searching for APARs. Does anyone else want to spend 5 minutes and see if you can find anything? Thanks much, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long Passwords
On 19 March 2013 15:07, EXT-Schwarz, Barry barry.schw...@boeing.com wrote: A user with a pass phrase must also have a password. When RACF is called to validate either, it uses the length of the data to determine which it is validating. Depends which it you mean. RACF doesn't provide a facility to treat a pass-thing as a password or phrase depending on its length. It's up to the calling application program/subsystem, e.g. TSO to determine how to pass the string to RACF. Consequently, a user with a pass phrase need not ever use it. The password will always work. (I imagine the password authentication exits could be used to prohibit using the password.) That might have some problems; not that you can't do it, but explaining what's gone wrong to the end user is tricky. It's almost certainly too late to reprompt in a way that will make the application accept a phrase at that point. But maybe TSO does get it right... There is at least one password sync product (the one I work on - Beta's SAM Password) that can set the password to a random value as part of synchronizing passwords with other systems, so that it is not known to either the user or the administrators. It seems strange that this should be necessary or useful, but it is. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Mainframe (1980's) on You tube
Thanks. I had assume common to mean that it was common across vendors. Apparently it is common only across IBM platforms. From: Todd Arnold arno...@us.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Sunday, March 17, 2013 7:32 PM Subject: Re: IBM Mainframe (1980's) on You tube I've only found ICSF and CCA for Linux on IBM System z. Since CCA is meant to be common I was wondering if it was implemented by anyone outside of IBM itself. I don't know of any non-IBM products that are designed to support CCA, but it is common to all the IBM platforms. You've apparently only found it for the mainframe (ICSF (z/OS) and Linux), but it is also supported - with the same crypto cards - on Power systems running either AIX or IBM i, and on x86 servers running Linux or Windows (although Windows is by special contract these days). You can find some info on the cards and CCA for those systems starting at http://www.ibm.com/security/cryptocards. - Todd Arnold -- 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: Lost datagrams on z/OS 1.12?
Charles, My instinct would be to run a packet trace. Use PROT=UDP,PORTNUM=port and DISCARD=ALL. (DISCARD is a newish feature that will trace packets that are about to be dropped by the stack.) Good luck, Steven St.Jean -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, March 19, 2013 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Lost datagrams on z/OS 1.12? I've got a problem that is defying my ability to find it. I have a product that uses sendto() to send UDP messages (datagrams). At one and perhaps two z/OS 1.12 customers I have seen a problem in which what appear to be perfectly good sendto()'s send a datagram that never arrives at its destination. (Of course, the lack of error feedback is a known characteristic of UDP.) Version x.1 of my product does not exhibit this behavior. Version x.2 does. There is relatively little difference between how the two issue sendto(). I have never seen the problem on my development machine, including under z/OS 1.12. It is definitely not a firewall or other external issue because Version x.1 works fine. You bring it down and bring Version x.2 up with the same parameters and it works for a little while and then 100% of the messages start disappearing. You bring it down and bring x.1 back up and all is well. Similar TCP/IP code does not seem to have the same problem. Yes, obviously it could be your basic program bug and I am of course working the heck out of that angle. I'm not asking this list to debug code it has not seen. The code is way too complex to post here meaningfully. But does this problem ring a bell with anyone? I am not the most skilled in the world at searching for APARs. Does anyone else want to spend 5 minutes and see if you can find anything? Thanks much, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long Passwords
On Mon, 18 Mar 2013 15:12:33 -0700, Skip Robinson wrote: As for SSO, those folks who logon to mainframe and some other platform can easily chose an 8 character password with mixed case for Windows, Unix, etc., and use the same password on mainframe with no ill effects because mainframe logon will translate the entered password into upper case transparently. I wouldn't be smug about that. If auditors discover it's happening (it's easy to test for), they might deem it a failure. Of course, the implementations were wrong from the very beginning. Applications (e.g. logon) should _always_ have passed on passwords as entered; it should be solely RACF's prerogative to treat them as case-sensitive or insensitive, and to enforce other site rules on password construction. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
On Tue, Mar 19, 2013 at 12:16 PM, Charles Mills charl...@mcn.org wrote: I've got a problem that is defying my ability to find it. I have a product that uses sendto() to send UDP messages (datagrams). At one and perhaps two z/OS 1.12 customers I have seen a problem in which what appear to be perfectly good sendto()'s send a datagram that never arrives at its destination. (Of course, the lack of error feedback is a known characteristic of UDP.) UDP does not guarantee delivery of packets or the order in which packets are received. It is up to the application to manage those issues. Version x.1 of my product does not exhibit this behavior. Version x.2 does. There is relatively little difference between how the two issue sendto(). I have never seen the problem on my development machine, including under z/OS 1.12. It is definitely not a firewall or other external issue because Version x.1 works fine. You bring it down and bring Version x.2 up with the same parameters and it works for a little while and then 100% of the messages start disappearing. You bring it down and bring x.1 back up and all is well. Similar TCP/IP code does not seem to have the same problem. Yes, obviously it could be your basic program bug and I am of course working the heck out of that angle. I'm not asking this list to debug code it has not seen. The code is way too complex to post here meaningfully. But does this problem ring a bell with anyone? I am not the most skilled in the world at searching for APARs. Does anyone else want to spend 5 minutes and see if you can find anything? Thanks much, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Mainframe (1980's) on You tube
Not holding my breath. I just know that we communicate with other systems (VisaNet, MasterCard etc.) and hardware (NCR ATMs) that are non-CCA compliant, and while sharing keys with these systems is supported under CCA it is fairly minimally documented. So I was just curious if there were systems outside of those by IBM that supported what I might call CCA conforming sharing of keys. From: Phil Smith p...@voltage.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Sunday, March 17, 2013 7:43 PM Subject: Re: IBM Mainframe (1980's) on You tube Frank Swarbrick wrote: I don't mean the applications that use it, but rather the implementations of CCA itself. I've only found ICSF and CCA for Linux on IBM System z. Since CCA is meant to be common I was wondering if it was implemented by anyone outside of IBM itself. Ah. I don't see the argument for that for the vendor: it's a lot of work, and they're unlikely to need all the functions, so they're doing more work to enable other folks to be able to port their products to that platform more easily. And since (as Todd notes) IBM supports CCA on the four main platforms, this would also mean implementing it for some rare system like HP/UX or Stratus or something. So the net would be a lot of work on a platform that isn't mainstream to support something that helps others. I wouldn't hold my breath! ...phsiii -- 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: jj$lwa - list of allocated userids
If you could tolerate the pain/overhead of creating an ISPF environment for your batch rexx to run within (or are you already doing this anyway, if you expect to VPUT items?), then you could use the builtin QUERYENQ ISPF service. http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.f54rs00%2Fqueryenq.htm On 15 March 2013 05:15, Farley, Peter x23353 peter.far...@broadridge.comwrote: Yes, you are correct. I was not thinking clearly when I wrote that. Thanks for the correction. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Thursday, March 14, 2013 3:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: jj$lwa - list of allocated userids In 985915eee6984740ae93f8495c624c6c21f399c...@jscpcwexmaa1.bsg.ad.adp.com, on 03/13/2013 at 07:01 PM, Farley, Peter x23353 peter.far...@broadridge.com said: If you can find one that just displays the data by writing to SYSPRINT/SYSOUT/etc., you might be able to capture the data with OUTTRAP In that case you wouldn't need OUTTRAP. Did you mean that it displays the data with PUTLINE or PUTGET? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long Passwords
On 3/19/2013 12:07 PM, EXT-Schwarz, Barry wrote: So you're only using them for TSO? I thought you would have to use them for everything if you turned them on? A user with a pass phrase must also have a password. When RACF is called to validate either, it uses the length of the data to determine which it is validating. Consequently, a user with a pass phrase need not ever use it. The password will always work. (I imagine the password authentication exits could be used to prohibit using the password.) No. RACROUTE REQUEST=VERIFY has two mutually-exclusive sets of keywords: a) PASSWRD= and NEWPASS= and b) PHRASE= and NEWPHRASE=. If the issuer of RACROUTE chooses to implement passphrases, then passwords need not be supported at all. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
