Re: Q re attaching COBOL program
Well, if you're anxious to see the code, here it is - COB#SYNC ATENTRY 'Run ASYNC task from COBOL',TRACE=NO * ST R1,R1_ON_ENTRY * LA R4,DYN_PCT USING MTCT_TASK,R4 LR5,0(,R1) <-- FIRST PARM = PROGRAM NAME MVC MTCT_TASK_PROG,0(R5) - - - - - - - - - - - - - - - - 10 Line(s) not Displayed MVC DYN_ATCH(L_ATCH_LST),ATCH_LST XC MTCT_TASK_TECB,MTCT_TASK_TECB LA R2,MTCT_TASK_TECB LA R15,DYN_ATCH LA R1,4(0,R1) PASS THE REST OF PARMS * ATTACH EPLOC=MTCT_TASK_PROG, X ECB=(R2), X SZERO=NO, X SF=(E,(R15)) * LTR R15,R15 DID ATTACH WORK? BZ ATTACHEDYES - LOG$MSG 'Unable to Attach . Abending...',MTCT_TASK_PROG DC H'0' * ATTACHED DC 0H STR1,MTCT_TASK_TCB SAVE TCB UNPK DWORK(9),MTCT_TASK_TCB(5) MVZ DWORK,ZONE_ZERO TRDWORK,HEXTAB LOG$MSG 'Prog Attached. TCB=',X MTCT_TASK_PROG,DWORK * LA R2,MTCT_TASK_TECB WAIT 1,ECB=(R2) * LOG$MSG 'Prog terminated',MTCT_TASK_PROG * DETACH MTCT_TASK_TCB * B COB#SYNC_EXIT The call in COBOL caller follows. Notice that the commarea gets displayed before and after the call [this is how we know that the response is NOT passed back] 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. -- 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 3/18/2013 4:36 PM, Victor Gil wrote: As I said, the subroutine response via a field in the passed comarea. The commarea is just ONE parm and the resopnse field is part of the commarea, not the RETURN REGISTER 03 TPTAPI-RETURN-PARAMETERS. 05 TPTAPI-RETURN-CODE PIC X(02). 88 TPTAPI-SUCCESSFULVALUE '00'. 88 TPTAPI-WARNING VALUE '04'. 88 TPTAPI-INVALID-PARM VALUE '08'. -Victor- Hey, chill, man. You still have not given us enough info. 1. show us your ATTACH(X) invocation 2. show us the code where your Assembler routine is looking at the return value 3. show us your procedure division header 4. show us where your COBOL program sets the return code we may need more to see the problem, but this is a start (and, no, LE is not making local copies of your parameter). -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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
Re: Q re attaching COBOL program
As I said, the subroutine response via a field in the passed comarea. The commarea is just ONE parm and the resopnse field is part of the commarea, not the RETURN REGISTER 03 TPTAPI-RETURN-PARAMETERS. 05 TPTAPI-RETURN-CODE PIC X(02). 88 TPTAPI-SUCCESSFULVALUE '00'. 88 TPTAPI-WARNING VALUE '04'. 88 TPTAPI-INVALID-PARM VALUE '08'. -Victor- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long Passwords
We ESPed the release that introduced mixed case passwords and phrases; 1.7 I believe. We tested on our sandbox under controlled conditions and were satisfied that the new features worked as expected. However, we never went to production for reasons already suggested: 1 No support *at that time* from CA TPX. We never found any other application that would not have worked, but TPX was enough. 2 Difficulty of falling back to old password rules once a password had been changed to mixed case. We would have had to manually set the password back to upper case in order to be usable. TPX apparently now supports mixed case and phrases. Number 2 is still a major buzz kill. Given the huge number of possible upper case password permutations including letters, numbers, and nationals, and given the severe limit on password tries before revocation, we could not justify such a sizable risk. 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. . . JO.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: Don Poitras To: IBM-MAIN@LISTSERV.UA.EDU, Date: 03/18/2013 12:43 PM Subject:Re: Long Passwords Sent by:IBM Mainframe Discussion List We added to SAS. It will be in the next release. In article you wrote: > This is VERY true. The application will have to support it. However, the > world seems to be moving to SSO and if it is to get there... then z/os will > have to play on the long password field. I expect most, if not all, > standard IBM products will use either in time. > On Mon, Mar 18, 2013 at 3:23 PM, R.S. wrote: > > W dniu 2013-03-18 20:16, Toole, Michael pisze: > > > >> So you're only using them for TSO? I thought you would have to use them > >> for everything if you turned them on? > >> > > > > It CANNOT be used "for everything". > > Reason: some of "everything" do not support long passwords. > > > > IMHO it is an issue for "unwashed masses" of regular users, not technical > > staff. And most of regular users use ONE application (CICS or IMS), so they > > are not interested in ftp, TSO, NETVIEW or JCL. > > > > > > > > -- > > Radoslaw Skorupka > > Lodz, Poland -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
GDPS PPRC Vs GDPS HyperSwap manager
Hi list, We are looking into GDPS and I have a few questions regarding the differences between the solutions. We have 2 adjecnt sites, each have a CPC and a storage controller (PPRC replication). The production environment is crossed between the sites in a parallel sysplex data sharing configuration. As I understand implementing basic hyperswap / GDPS hyperswap offerings will provide storage controller HA and DR solutions so what are the advantages of implementing GDPS/PPRC offering? What extra benefits will we receive ? I looked in the redbook "GDPS Family: An Introduction to Concepts and Capabilities" and found that the main differences are: "Production system automation" and "GDPS Scripting" what does it mean ? What I won't be able to do ? When I'll want to add 3rd site to the configuration would it matter ? (beside that I'll then need to implement automation and GDPS scripting... but this can be done at a later time...) Many thanks in advanced. Nir -- 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 3/18/2013 2:29 PM, 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. The subroutine gets the parms, does what it's job and returns back with an RCfield which is a part of the passed structure. However, the caller *does not* see this RC! Is the LE making a local copy of the parms? And if yes - how to workaround this issue? TIA, -Victor- Sounds like you possiblye are not passing and receiving the structure in the same way. If your COBOL program is moving the return code value into the RC field in your structure, but on return you do not see the value: are you passing by reference or by content? are you receiving by reference or by content? On the other hand, if your COBOL program is just setting the RETURN-CODE special register, that value is not passed back in your passed structure automatically. So it would help to see some code: how your Assembler routine sets up the passed parms and how it examines these after the CALL; then how your COBOL routine sees the passed parms (show us the linkage section, the using statement, and the point in the code where you think RC is getting set. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Q re attaching COBOL program
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. The subroutine gets the parms, does what it's job and returns back with an RC field which is a part of the passed structure. However, the caller *does not* see this RC! Is the LE making a local copy of the parms? And if yes - how to workaround this issue? TIA, -Victor- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long Passwords
We added to SAS. It will be in the next release. In article you wrote: > This is VERY true. The application will have to support it. However, the > world seems to be moving to SSO and if it is to get there... then z/os will > have to play on the long password field. I expect most, if not all, > standard IBM products will use either in time. > On Mon, Mar 18, 2013 at 3:23 PM, R.S. wrote: > > W dniu 2013-03-18 20:16, Toole, Michael pisze: > > > >> So you're only using them for TSO? I thought you would have to use them > >> for everything if you turned them on? > >> > > > > It CANNOT be used "for everything". > > Reason: some of "everything" do not support long passwords. > > > > IMHO it is an issue for "unwashed masses" of regular users, not technical > > staff. And most of regular users use ONE application (CICS or IMS), so they > > are not interested in ftp, TSO, NETVIEW or JCL. > > > > > > > > -- > > Radoslaw Skorupka > > Lodz, Poland -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long Passwords
This is VERY true. The application will have to support it. However, the world seems to be moving to SSO and if it is to get there... then z/os will have to play on the long password field. I expect most, if not all, standard IBM products will use either in time. On Mon, Mar 18, 2013 at 3:23 PM, R.S. wrote: > W dniu 2013-03-18 20:16, Toole, Michael pisze: > >> So you're only using them for TSO? I thought you would have to use them >> for everything if you turned them on? >> > > It CANNOT be used "for everything". > Reason: some of "everything" do not support long passwords. > > IMHO it is an issue for "unwashed masses" of regular users, not technical > staff. And most of regular users use ONE application (CICS or IMS), so they > are not interested in ftp, TSO, NETVIEW or JCL. > > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > -- > Tre tej wiadomo ci mo e zawiera informacje prawnie chronione Banku > przeznaczone wy cznie do u ytku s u bowego adresata. Odbiorc mo e by > jedynie jej adresat z wy czeniem dost pu osób trzecich. Je eli nie jeste > adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej > przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, > rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie > zabronione i mo e by karalne. Je eli otrzyma e t wiadomo omy kowo, > prosimy niezw ocznie zawiadomi nadawc wysy aj c odpowied oraz trwale > usun t wiadomo w czaj c w to wszelkie jej kopie wydrukowane lub > zapisane na dysku. > > This e-mail may contain legally privileged information of the Bank and is > intended solely for business use of the addressee. This e-mail may only be > received by the addressee and may not be disclosed to any third parties. If > you are not the intended addressee of this e-mail or the employee > authorised to forward it to the addressee, be advised that any > dissemination, copying, distribution or any other similar activity is > legally prohibited and may be punishable. If you received this e-mail by > mistake please advise the sender immediately by using the reply facility in > your e-mail software and delete permanently this e-mail including any > copies of it either printed or saved to hard drive. > BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, > fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl > S d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego > Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP: > 526-021-50-88. Wed ug stanu na dzie 01.01.2013 r. kapita zak adowy BRE > Banku SA (w ca o ci wp acony) wynosi 168.555.904 z otych. > > > --**--**-- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Keith Smith Engineer-Enterprise Sys Sr.-IT Capacity & Performance Shaw Industries Inc. Subsidiary of Berkshire Hathaway 616 E Walnut Ave Dalton, GA 30721 Email: keith.sm...@shawinc.com Office: 706.275.3244 Please consider the environment before printing. -- ** Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail. If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender. Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company or its subsidiaries. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Long Passwords
Well if we are talking the same thing either works. Password or Password Phrase. USER=xx NAME=yyy OWNER= CREATED=09.300 DEFAULT-GROUP=SYS1 PASSDATE=13.036 PASS-INTERVAL= 90 PHRASEDATE=13.073 ATTRIBUTES=PASSPHRASE after adding passphrase to the ID and changing SYS1.PARMLIB(IKJTSO00) to add: LOGON /* LOGON PARMS */ + PASSPHRASE(ON) /* TURN ON LOG PASSWORDS */ We can no log-on with either the original 8 digit max password or the new passphrase of up to 100 characters. I have not tested up to 100, but the field seems to hold it wrapping to the next line. I tested a 21 character password. Regards, Keith On Mon, Mar 18, 2013 at 3:16 PM, Toole, Michael wrote: > So you're only using them for TSO? I thought you would have to use them > for everything if you turned them on? > > Mike > Michael K. Toole > Sr. I.T. Consultant > The Auto Club Group > 1 Auto Club Drive > Dearborn, Mi. 48126 > 313-336-1783 > mto...@aaamichigan.com > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Keith Smith > Sent: Monday, March 18, 2013 3:13 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Long Passwords > > We are just getting started. It seems to work okay. It was a simple change > to implement it for TSO. Looks like FTP will only work 1.13 and higher and > I have not looked at CICS yet. I am interested to hear from others as well. > > On Mon, Mar 18, 2013 at 3:04 PM, Toole, Michael >wrote: > > > Is anybody using password phrases or in some other way using passwords > > longer than 8 characters on z/OS? > > > > If so, could you share your experience? > > > > Mike > > Michael K. Toole > > Sr. I.T. Consultant > > The Auto Club Group > > 1 Auto Club Drive > > Dearborn, Mi. 48126 > > 313-336-1783 > > mto...@aaamichigan.com > > > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > Keith Smith > Engineer-Enterprise Sys Sr.-IT Capacity & Performance Shaw Industries Inc. > Subsidiary of Berkshire Hathaway > 616 E Walnut Ave > Dalton, GA 30721 > Email: keith.sm...@shawinc.com Office: 706.275.3244 > > Please consider the environment before printing. > > -- > ** > Privileged and/or confidential information may be contained in this > message. If you are not the addressee indicated in this message (or are not > responsible for delivery of this message to that person) , you may not copy > or deliver this message to anyone. In such case, you should destroy this > message and notify the sender by reply e-mail. > If you or your employer do not consent to Internet e-mail for messages of > this kind, please advise the sender. > Shaw Industries does not provide or endorse any opinions, conclusions or > other information in this message that do not relate to the official > business of the company or its subsidiaries. > ** > > > -- > 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 > -- Keith Smith Engineer-Enterprise Sys Sr.-IT Capacity & Performance Shaw Industries Inc. Subsidiary of Berkshire Hathaway 616 E Walnut Ave Dalton, GA 30721 Email: keith.sm...@shawinc.com Office: 706.275.3244 Please consider the environment before printing. -- ** Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail. If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender. Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company or its subsidiaries. ** -- 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
The longer it takes to figure out the problem, the more likely it will be bloody obvious once it is found :( Dave Gibney Information Technology Services Washington State University > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gross, Randall [PRI-1PP] > Sent: Monday, March 18, 2013 11:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Query for Destination z article -- mainframes back to the future > > We used to call this the "any idiot" theory of debugging: > > After working a trans-finite amount of time trying to debug a program, > any idiot will walk up and immediately point out your error. > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > Behalf Of Richards, Robert B. > Sent: Monday, March 18, 2013 10:19 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Query for Destination z article -- mainframes back to the > future > > I have to echo your last line from personal experience: > > If you have looked at a bug for 30 or more minutes, get that second set > of eyes to look at it pronto. > > Chances are they will spot it in under 30 seconds! :-) > > Bob > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > Behalf Of Elardus Engelbrecht > Sent: Monday, March 18, 2013 9:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Query for Destination z article -- mainframes back to the > future > > Shmuel Metz (Seymour J.) wrote: > > Have a plan B. > > And C and D, etc... ;-D > > > Document first, then keep your documentation up to date. > > And have someone else review it. > > And document all and every exits. (source, logic flow and installation > methods) > > > Don't update the running system. > > Some people did that - at their own risk. > > And P L E A S E Don't INIT a live IPL volser! > > > Use vendor-provided mappings rather than rolling your own. > > Good suggestion, that is, if supplied mapping is available in the first > place. Think OCO. > > (It took me a long time to obtain SMF mappings from IBM for a certain > product for which I need to extract accounting info for usage > analysis... So I ended used both version - vendor and my own.) > > >A few coding techniques for newbies to learn: > > The use of UNPK and TR for converting to hexadecimal. > > And do that in RENT and REUS modes too. ;-) > > I wish to add something too: If you're having trouble debugging > something, an extra pair(s) of eyes is a welcome investment. > > > -- > 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: Long Passwords
W dniu 2013-03-18 20:16, Toole, Michael pisze: So you're only using them for TSO? I thought you would have to use them for everything if you turned them on? It CANNOT be used "for everything". Reason: some of "everything" do not support long passwords. IMHO it is an issue for "unwashed masses" of regular users, not technical staff. And most of regular users use ONE application (CICS or IMS), so they are not interested in ftp, TSO, NETVIEW or JCL. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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? Mike Michael K. Toole Sr. I.T. Consultant The Auto Club Group 1 Auto Club Drive Dearborn, Mi. 48126 313-336-1783 mto...@aaamichigan.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Keith Smith Sent: Monday, March 18, 2013 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Long Passwords We are just getting started. It seems to work okay. It was a simple change to implement it for TSO. Looks like FTP will only work 1.13 and higher and I have not looked at CICS yet. I am interested to hear from others as well. On Mon, Mar 18, 2013 at 3:04 PM, Toole, Michael wrote: > Is anybody using password phrases or in some other way using passwords > longer than 8 characters on z/OS? > > If so, could you share your experience? > > Mike > Michael K. Toole > Sr. I.T. Consultant > The Auto Club Group > 1 Auto Club Drive > Dearborn, Mi. 48126 > 313-336-1783 > mto...@aaamichigan.com > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Keith Smith Engineer-Enterprise Sys Sr.-IT Capacity & Performance Shaw Industries Inc. Subsidiary of Berkshire Hathaway 616 E Walnut Ave Dalton, GA 30721 Email: keith.sm...@shawinc.com Office: 706.275.3244 Please consider the environment before printing. -- ** Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail. If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender. Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company or its subsidiaries. ** -- 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
We are just getting started. It seems to work okay. It was a simple change to implement it for TSO. Looks like FTP will only work 1.13 and higher and I have not looked at CICS yet. I am interested to hear from others as well. On Mon, Mar 18, 2013 at 3:04 PM, Toole, Michael wrote: > Is anybody using password phrases or in some other way using passwords > longer than 8 characters on z/OS? > > If so, could you share your experience? > > Mike > Michael K. Toole > Sr. I.T. Consultant > The Auto Club Group > 1 Auto Club Drive > Dearborn, Mi. 48126 > 313-336-1783 > mto...@aaamichigan.com > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Keith Smith Engineer-Enterprise Sys Sr.-IT Capacity & Performance Shaw Industries Inc. Subsidiary of Berkshire Hathaway 616 E Walnut Ave Dalton, GA 30721 Email: keith.sm...@shawinc.com Office: 706.275.3244 Please consider the environment before printing. -- ** Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail. If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender. Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company or its subsidiaries. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Long Passwords
Is anybody using password phrases or in some other way using passwords longer than 8 characters on z/OS? If so, could you share your experience? Mike Michael K. Toole Sr. I.T. Consultant The Auto Club Group 1 Auto Club Drive Dearborn, Mi. 48126 313-336-1783 mto...@aaamichigan.com -- 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
We used to call this the "any idiot" theory of debugging: After working a trans-finite amount of time trying to debug a program, any idiot will walk up and immediately point out your error. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Monday, March 18, 2013 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Query for Destination z article -- mainframes back to the future I have to echo your last line from personal experience: If you have looked at a bug for 30 or more minutes, get that second set of eyes to look at it pronto. Chances are they will spot it in under 30 seconds! :-) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, March 18, 2013 9:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Query for Destination z article -- mainframes back to the future Shmuel Metz (Seymour J.) wrote: > Have a plan B. And C and D, etc... ;-D > Document first, then keep your documentation up to date. And have someone else review it. And document all and every exits. (source, logic flow and installation methods) > Don't update the running system. Some people did that - at their own risk. And P L E A S E Don't INIT a live IPL volser! > Use vendor-provided mappings rather than rolling your own. Good suggestion, that is, if supplied mapping is available in the first place. Think OCO. (It took me a long time to obtain SMF mappings from IBM for a certain product for which I need to extract accounting info for usage analysis... So I ended used both version - vendor and my own.) >A few coding techniques for newbies to learn: > The use of UNPK and TR for converting to hexadecimal. And do that in RENT and REUS modes too. ;-) I wish to add something too: If you're having trouble debugging something, an extra pair(s) of eyes is a welcome investment. -- 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: Strange Behaviour with DFRMM and catalog
Jerome, Call IBM and report the problem. Seems similar to apar OA35183 There may already be a fix. With UNCATALOG(Y) or UNCATALOG(S) you should expect data sets to be uncataloged if still in the catalog at time of return to scratch. Mike Wood -- 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 Mon, 18 Mar 2013 09:05:57 -0700, Donald J. wrote: >> I suspect that in your case, the data set was not allocated >> statically in JCL, as in Monika's case, but dynamically >> by the temsnote script. >No, one static dataset. Tivoli situation alerts kick off started >tasks (all single threaded through same started task name) >and all use the same .TEMSNOTE z/OS file. $mfile is a 1 line >single record OMVS file. > I still doubt that you test closely resembles Monika's? I have no idea beyond what you state what Tivoli does. It's easy to suspect that there more players in the game than you've describe -- concurrent started tasks, etc. Are you willing to exhibit the JCL that incurred the error? Did your JCL contain a static allocation (DD statement) of the problem data set in a step _after the BPXBATCH step? Instead, I have simplified Monika's sample JCL: // //MONIKAJOB 505303JOB,'Paul Gilmartin', // MSGLEVEL=(1,1),REGION=0M //* //USERCOUTPUT JESDS=ALL,DEFAULT=YES, // CLASS=R,PAGEDEF=V0648Z,CHARS=GT12 //* //STEP01 EXEC PGM=BPXBATCH //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDPARM DD * SH cp /etc/services "//TEMP.TEST.DATASET"; sleep 2 /* //STDENV DD * _BPX_SHAREAS=YES _BPX_SPAWN_SCRIPT=YES /* //STEP02 EXEC PGM=IEFBR14 //SYSPRINT DD SYSOUT=* //DD01DD DSN=&SYSUID..TEMP.TEST.DATASET,DISP=SHR // :w ! submit $MVS_HOST The output: -sh:0+ cp /etc/services //TEMP.TEST.DATASET cp: FSUM6259 target file "//TEMP.TEST.DATASET": EDC5061I An error occurred when -sh:0+ sleep 2 I replaced the script with inline commands. Do you believe that makes a difference? I used an existing UNIX file instead of creating one. Do you believe that makes a difference? If you care to modify the JCL above until it displays the behavior you report, I'll test it. Your move, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe DASD
Rex, It doesn't matter since all I wrote applies to HDS and EMC as well. -- Radoslaw Skorupka Lodz, Poland W dniu 2013-03-18 17:28, Pommier, Rex R. pisze: Hey Radoslaw, I read the original request much the same way you did, that Fred is looking to get info from EMC (corporate), Hitachi (corporate), and IBM (business partners instead of corporate). In fact, Fred is looking for business partners for each of the vendors. I sent him the name of an IBM BP that I've worked with in the past and he is also looking for BPs for the other two as well. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, March 18, 2013 11:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe DASD W dniu 2013-03-18 16:20, Fred Lupher pisze: We are preparing an RFP for a mainframe DASD upgrade, and we'd like to send the RFP to EMC, Hitachi & IBM business partners. Does anyone know where I might find a list of business partners? I think, you don't need the list, otherwise you would be interested in polish partners - are you? ;-) I would suggest to simply ask IBM about 2-3 business partners from your region with proper authorisation. BTW: in such RFP you ask business partner, but in fact you play with IBM, the prices are set there. Business partner's "value added" is marginal IMHO. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- 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 e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. J
Re: exit add in progxx for cnz_wtomdbexit and setprog
A couple of things to watch out for : (1) Did you check LOGREC for any abends in your exit? (2) Did you remember to use branch-entry WTO for your message? I must admit issuing a WTO from with CNZ_WTOMDBEXIT would make me nervous about an endless loop if the code logic was not water-tight. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernard Coeytaux Sent: 18 March 2013 16:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: exit add in progxx for cnz_wtomdbexit and setprog Elardus, IBM® has defined the CNZ_WTOMDBEXIT exit to the dynamic exits facility. I wrote my own code. There is no difference in the display, before I deleted it, and after I added it via the setprog command. I know that it was not called , because it contains a WTO to signal the beginnig of the code. Thanks, Regards 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
Elardus, IBM® has defined the CNZ_WTOMDBEXIT exit to the dynamic exits facility. I wrote my own code. There is no difference in the display, before I deleted it, and after I added it via the setprog command. I know that it was not called , because it contains a WTO to signal the beginnig of the code. Thanks, 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
Bernard Coeytaux wrote: >The lmod WMXEXIT1 is located in SYS1.BPER.LINKLIB What is the product? Do you have any sources? >However the exit is not called ! How do you know it? Do you expect results when exit is called eventually? >After having done s MVS command setprog exit,delete and setprog exit,add the >exit was really called. How do the 'D PROG ' displays differ between each stage? >Is there a chance that this particulary exit cannot be specified in a prog >member used only at IPL ? Depending on your product, is the exit defined as static or dynamic (think of SMF exits for example)? What calling conventions are used upon entry of that exit? For SMF: nearly all SMF Exits are dynamic, unless you don't want it that way. For RACF: only one exit is dynamic, rest are static and only loadable with IPL. etc. So, it depends on what product and what are any limits, if any, are imposed on it. 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: mainframe DASD
Hey Radoslaw, I read the original request much the same way you did, that Fred is looking to get info from EMC (corporate), Hitachi (corporate), and IBM (business partners instead of corporate). In fact, Fred is looking for business partners for each of the vendors. I sent him the name of an IBM BP that I've worked with in the past and he is also looking for BPs for the other two as well. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, March 18, 2013 11:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe DASD W dniu 2013-03-18 16:20, Fred Lupher pisze: > We are preparing an RFP for a mainframe DASD upgrade, and we'd like to > send the RFP to EMC, Hitachi & IBM business partners. Does anyone > know where I might find a list of business partners? I think, you don't need the list, otherwise you would be interested in polish partners - are you? ;-) I would suggest to simply ask IBM about 2-3 business partners from your region with proper authorisation. BTW: in such RFP you ask business partner, but in fact you play with IBM, the prices are set there. Business partner's "value added" is marginal IMHO. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- 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 e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe DASD
W dniu 2013-03-18 16:20, Fred Lupher pisze: We are preparing an RFP for a mainframe DASD upgrade, and we'd like to send the RFP to EMC, Hitachi & IBM business partners. Does anyone know where I might find a list of business partners? I think, you don't need the list, otherwise you would be interested in polish partners - are you? ;-) I would suggest to simply ask IBM about 2-3 business partners from your region with proper authorisation. BTW: in such RFP you ask business partner, but in fact you play with IBM, the prices are set there. Business partner's "value added" is marginal IMHO. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- 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
> I suspect that in your case, the data set was not allocated > statically in JCL, as in Monika's case, but dynamically > by the temsnote script. No, one static dataset. Tivoli situation alerts kick off started tasks (all single threaded through same started task name) and all use the same .TEMSNOTE z/OS file. $mfile is a 1 line single record OMVS file. -- Donald J. dona...@4email.net On Mon, Mar 18, 2013, at 07:55 AM, Paul Gilmartin wrote: > On Mon, 18 Mar 2013 07:37:25 -0700, Donald J. wrote: > > >I was getting same error in a TEMS script I wrote. > >The sleep fixed it (much of the time, but not every time). > > > I doubt that it was "the same error". > > ># > ># Invoke Alert Script & set RC to 1 if email is to be sent > >/u/appl/temsnote/sh/$1.sh $1 "$2" > >returncode=$? > ># > I suspect that in your case, the data set was not allocated > statically in JCL, as in Monika's case, but dynamically > by the temsnote script. > > ># Wait for de-allocation, then copy file > >sleep 2 > >cp $mfile "//'UTIL.OMS.V420.OMS1.TEMSNOTE'" > >sleep 2 > > > The sleep before the cp may have helped; I doubt that the > sleep after the cp made any difference; seems to violate > causality. > > >I still get the error on a very small percent of the time: > >cp: FSUM6259 target file "//'UTIL.OMS.V420.OMS1.TEMSNOTE'": > >EDC5061I An error occurred when attempting to define a file to the > >system.-- > > > (For coloro che sanno: Is it possible for DYNALLOC FREE to return > to its caller before the DEQ is complete? If so, I'd consider it an > APARable defect; otherwise Donald's code is deficient in performing > the FREE in the background and returning to its caller without > waiting for completion.) > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/help/overview_quotes.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
exit add in progxx for cnz_wtomdbexit and setprog
I use in my progxx member : SYSLIB LINKLIB(SYS1.BPER.LINKLIB) EXIT ADD EXITNAME(CNZ_WTOMDBEXIT) MODNAME(WMXEXIT1) The lmod WMXEXIT1 is located in SYS1.BPER.LINKLIB After ipl is finished, the command "D PROG,EXIT,EX=CNZ_WTOMDBEXIT,DIAG" shows all good ! CSV464I 11.39.53 PROG,EXIT DISPLAY 803 EXIT CNZ_WTOMDBEXIT MODULESTATE EPADDRLOADPTLENGTHJOBNAME PARAM WMXEXIT1A 94AD3920 14AD3920 16E0 * However the exit is not called ! After having done s MVS command setprog exit,delete and setprog exit,add the exit was really called. Is there a chance that this particulary exit cannot be specified in a prog member used only at IPL ? Thanks and regards Bernard Coeytaux -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: smpe receive issue IKJ56228I
No, it won't unless you insert IBM. after DB.CFED in your data set names. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: smpe receive issue IKJ56228I
Does this work? RECEIVE SYSMODS RFPREFIX(DB.CFED). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
mainframe DASD
We are preparing an RFP for a mainframe DASD upgrade, and we'd like to send the RFP to EMC, Hitachi & IBM business partners. Does anyone know where I might find a list of business partners? Thanks -- 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 Mon, 18 Mar 2013 07:37:25 -0700, Donald J. wrote: >I was getting same error in a TEMS script I wrote. >The sleep fixed it (much of the time, but not every time). > I doubt that it was "the same error". ># ># Invoke Alert Script & set RC to 1 if email is to be sent >/u/appl/temsnote/sh/$1.sh $1 "$2" >returncode=$? ># I suspect that in your case, the data set was not allocated statically in JCL, as in Monika's case, but dynamically by the temsnote script. ># Wait for de-allocation, then copy file >sleep 2 >cp $mfile "//'UTIL.OMS.V420.OMS1.TEMSNOTE'" >sleep 2 > The sleep before the cp may have helped; I doubt that the sleep after the cp made any difference; seems to violate causality. >I still get the error on a very small percent of the time: >cp: FSUM6259 target file "//'UTIL.OMS.V420.OMS1.TEMSNOTE'": >EDC5061I An error occurred when attempting to define a file to the >system.-- > (For coloro che sanno: Is it possible for DYNALLOC FREE to return to its caller before the DEQ is complete? If so, I'd consider it an APARable defect; otherwise Donald's code is deficient in performing the FREE in the background and returning to its caller without waiting for completion.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Strange Behaviour with DFRMM and catalog
Hi, Freshly migrated from TLMS to DFRMM, everything work perfectly except one thing : Logical tapes(VTS) that have been scratched due to VRS, if a check the Usercatalog, the dataset belonging to scratched tapes are still cataloged !!! I can't explain why, this sound weird to me, maybe i use some wrong option ? Note that we are at Zos1.9 and we share usercatalog beetween several LPAR. If someone as an idea to explain that ? I feel alone with my redbooks Regards, Jérôme RMM LISTCONTROL ALL Control record: Type = MASTERCreate date = 12/03/2013 Create time = 11:49:30 Update date = 18/03/2013 Update time = 13:47:17 Journal: Utilization = 0% (75% threshold) STATUS: = ENABLED CDS: Utilization = 5% Exit status:Options: EDGUX100 = ENABLED Stacked Volumes = ENABLED EDGUX200 = NONE Extended Bin= ENABLED EDGUX300 = NONE Common Time = DISABLED CDSID ENQ name = ENABLED System options: PARMLIB Suffix = R0 Operating mode = PRetention period: Default = 7 Maximum = NOLIMIT Catalog = 1 hours Control data set name = RMM.CDS Journal file data set name = .RMM.JRNL Journal threshold = 75% Catalog SYSID = * Scratch procedure name = EDGXPROC Backup procedure name = EDGBCKUP IPL date check = NDate format= E RACF support = N SMF audit = 248 SMF security = 249 CDS id = MASTER MAXHOLD value = 100 Lines per page = 54 System ID = SYSA BLP = RMM TVEXT purge= RELEASE Notify = Y Uncatalog = YVRS job name = 2 Message case = M MASTER overwrite= LAST Accounting = J VRS selection = NEW VRS change = INFO VRSMIN action = WARNVRSMIN count = 100 Disp DD name= LOANDD Disp msg ID= EDG4054I Retain by = VOLUME Move by= VOLUME CMDAUTH Owner = YES PREACS = NO SMSACS = NO CMDAUTH Dsn= NO Reuse bin = STARTMOVE Media name = 3490 Local tasks= 10 PDA: OFF Block count= 255 Block size = 31 Log= OFF Update scratch = YES Update command = YES Update exits = YES Purge = YES Rack Prefix Access type --- --- *NONE -- 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
I was getting same error in a TEMS script I wrote. The sleep fixed it (much of the time, but not every time). # # Invoke Alert Script & set RC to 1 if email is to be sent /u/appl/temsnote/sh/$1.sh $1 "$2" returncode=$? # # Wait for de-allocation, then copy file sleep 2 cp $mfile "//'UTIL.OMS.V420.OMS1.TEMSNOTE'" sleep 2 I still get the error on a very small percent of the time: cp: FSUM6259 target file "//'UTIL.OMS.V420.OMS1.TEMSNOTE'": EDC5061I An error occurred when attempting to define a file to the system.-- Donald J. dona...@4email.net On Mon, Mar 18, 2013, at 07:12 AM, Paul Gilmartin wrote: > On Mon, 18 Mar 2013 05:12:59 -0700, Donald J. wrote: > > >Try putting a "sleep 2" after the cp. > > > Are you a betting man? > > > >On Fri, Mar 15, 2013, at 08:33 AM, Monika Amiss wrote: > >> Dear Group, > >> > >> 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. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- http://www.fastmail.fm - Choose from over 50 domains or use your own -- 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 Mon, 18 Mar 2013 09:26:55 -0500, Kirk Wolf wrote: >Using "/DD:" when running BPXBATCH? (the shell runs in a separate address >space) > >If you use a tool that runs the shell script in the same address space, >then you can use either a DD or a DSN (dynamic allocation in the same >address space won't conflict with the initiator ENQ since it is the same >address space). > I stand corrected. I had my Rexx glasses on and was envisioning BPXWDYN; _BPX_SHAREAS=YES; cp ... "DD:...". Again, I counsel against using unsupported argument forms. Caveat emptor. -- 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
Using "/DD:" when running BPXBATCH? (the shell runs in a separate address space) If you use a tool that runs the shell script in the same address space, then you can use either a DD or a DSN (dynamic allocation in the same address space won't conflict with the initiator ENQ since it is the same address space). Kirk Wolf Dovetailed Technologies http://dovetail.com PS> the mvs-oe forum used to be nearly completely dedicated to problems like this, search the archives ;-) On Mon, Mar 18, 2013 at 9:20 AM, Paul Gilmartin wrote: > On Mon, 18 Mar 2013 15:01:34 +0100, Michael Klaeschen wrote: > > >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? > > > Still won't work as long as the "cp" runs in a different address space. > Kirk's suggestion is promising, but proliferates prerequisites. > > I thought MDS would fail the job if a required data set did not exist. > So, I conclude that Monika is using JES2. > > Can Monika try a separate IEFBR14 step between STEP01 and STEP02? > > Using the "//DD..." construct as an argument to "cp" is reported to > work, but is undocumented and unsupported. > > -- 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
On Mon, 18 Mar 2013 15:01:34 +0100, Michael Klaeschen wrote: >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? > Still won't work as long as the "cp" runs in a different address space. Kirk's suggestion is promising, but proliferates prerequisites. I thought MDS would fail the job if a required data set did not exist. So, I conclude that Monika is using JES2. Can Monika try a separate IEFBR14 step between STEP01 and STEP02? Using the "//DD..." construct as an argument to "cp" is reported to work, but is undocumented and unsupported. -- gil -- 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
I have to echo your last line from personal experience: If you have looked at a bug for 30 or more minutes, get that second set of eyes to look at it pronto. Chances are they will spot it in under 30 seconds! :-) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, March 18, 2013 9:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Query for Destination z article -- mainframes back to the future Shmuel Metz (Seymour J.) wrote: > Have a plan B. And C and D, etc... ;-D > Document first, then keep your documentation up to date. And have someone else review it. And document all and every exits. (source, logic flow and installation methods) > Don't update the running system. Some people did that - at their own risk. And P L E A S E Don't INIT a live IPL volser! > Use vendor-provided mappings rather than rolling your own. Good suggestion, that is, if supplied mapping is available in the first place. Think OCO. (It took me a long time to obtain SMF mappings from IBM for a certain product for which I need to extract accounting info for usage analysis... So I ended used both version - vendor and my own.) >A few coding techniques for newbies to learn: > The use of UNPK and TR for converting to hexadecimal. And do that in RENT and REUS modes too. ;-) I wish to add something too: If you're having trouble debugging something, an extra pair(s) of eyes is a welcome investment. -- 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 Mon, 18 Mar 2013 05:12:59 -0700, Donald J. wrote: >Try putting a "sleep 2" after the cp. > Are you a betting man? >On Fri, Mar 15, 2013, at 08:33 AM, Monika Amiss wrote: >> Dear Group, >> >> 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. -- 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
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 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 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. //STEP01 EXEC PGM=BPXBATCH //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDPARM DD * SH /user/copy.sh /* //STDENV DD * _BPX_SHAREAS=YES _BPX_SPAWN_SCRIPT=YES /* //STEP02 EXEC PGM=TESTLEER //SYSPRINT DD SYSOUT=* //DD01DD DSN=TEST.DATASET,DISP=SHR // We're running z/OS1.12 & JES3. Somebody has an idea? Any hint appreciated. With best regards Monika -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ Basler Securitas Versicherungs-Aktiengesellschaft | Sitz der Gesellschaft: Bad Homburg v.d.H. | Amtsgericht Bad Homburg v.d.H., HRB 9357 | USt-ID-Nr. DE 276021973 | Vorstand: Jan De Meulder - Vorsitzender, Markus Jost, Axel Obermayr, Dr. Jürg Schiltknecht, Dr. Alexander Tourneau, Dr. Christoph Wetzel | Aufsichtsratsvorsitzender: Dr. Martin Strobel | Basler Straße 4, 61345 Bad Homburg v.d.H. | Basler Lebensversicherungs-AG | Sitz der Gesellschaft: Hamburg | Amtsgericht Hamburg, HRB 4659 | Ust-ID-Nr. DE 276021973 | Vorstand: Jan De Meulder - Vorsitzender, Markus Jost, Axel Obermayr, Dr. Jürg Schiltknecht, Dr. Alexander Tourneau, Dr. Christoph Wetzel | Aufsichtsratsvorsitzender: Dr. Martin Strobel | Ludwig-Erhard-Straße 22, 20459 Hamburg Basler Leben AG | Aktiengesellschaft nach Schweizer Recht | Deutsche Zweigniederlassung: Basler Leben AG Direktion für Deutschland | Amtsgericht Bad Homburg v.d.H., HRB 1229 | Ust-ID-Nr. DE 281452875 | Hauptbevollmächtigter für Deutschland: Jan De Meulder | Basler Straße 4, 61345 Bad Homburg v.d.H. | Basler Versicherung AG | Aktiengesellschaft nach Schweizer Recht | Deutsche Zweigniederlassung: Basler Versicherung AG Direktion für Deutschland | Amtsgericht Bad Homburg v.d.H., HRB 1228 | USt-ID-Nr. DE 281452875 | Hauptbevollmächtigter für Deutschland: Jan De Meulder | Basler Straße 4, 61345 Bad Homburg v.d.H. | Deutscher Ring Sachversicherungs-AG | Amtsgericht Hamburg, HRB 7144 | USt-ID-Nr. 276021973 | Vorstand: Jan De Meulder - Vorsitzender, Markus Jost, Axel Obermayr, Dr. Jürg Schiltknecht, Dr. Alexander Tourneau, Dr. Christoph Wetzel | Aufsichtsratsvorsitzender: Dr. Martin Strobel | Ludwig-Erhard-Straße 22, 20459 Hamburg __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ -- 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
Shmuel Metz (Seymour J.) wrote: > Have a plan B. And C and D, etc... ;-D > Document first, then keep your documentation up to date. And have someone else review it. And document all and every exits. (source, logic flow and installation methods) > Don't update the running system. Some people did that - at their own risk. And P L E A S E Don't INIT a live IPL volser! > Use vendor-provided mappings rather than rolling your own. Good suggestion, that is, if supplied mapping is available in the first place. Think OCO. (It took me a long time to obtain SMF mappings from IBM for a certain product for which I need to extract accounting info for usage analysis... So I ended used both version - vendor and my own.) >A few coding techniques for newbies to learn: > The use of UNPK and TR for converting to hexadecimal. And do that in RENT and REUS modes too. ;-) I wish to add something too: If you're having trouble debugging something, an extra pair(s) of eyes is a welcome investment. 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: BPXBATCH copy to mvs-ds FSUM6259
Try putting a "sleep 2" after the cp. -- Donald J. dona...@4email.net On Fri, Mar 15, 2013, at 08:33 AM, Monika Amiss wrote: > 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. > > //STEP01 EXEC PGM=BPXBATCH > //STDOUT DD SYSOUT=* > //STDERR DD SYSOUT=* > //STDPARM DD * > SH /user/copy.sh > /* > //STDENV DD * > _BPX_SHAREAS=YES > _BPX_SPAWN_SCRIPT=YES > /* > //STEP02 EXEC PGM=TESTLEER > //SYSPRINT DD SYSOUT=* > //DD01DD DSN=TEST.DATASET,DISP=SHR > // > > We're running z/OS1.12 & JES3. > Somebody has an idea? Any hint appreciated. > With best regards > Monika > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- http://www.fastmail.fm - The way an email service should be -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Netview Script Not authorized -CNM424I
CNM424I COMMAND LIST TIMEMNGR - ACCESS TO COMMAND IS NOT AUTHORIZED *-* 'purge timer='f.i',op=ppt' +++ RC(-3) +++ I suspect your NetView command security rules do not allow you to purge timers scheduled in the NetView PPT. Look in CNMSCAT2. BNH229I CMDAUTH TABLE 03/13/13 02:17:52 INITIALIZATION BNH229I TBLNAME CNMSCAT2 03/13/13 02:17:52 INITIALIZATION Mike Wawiorko Please consider the environment before printing this e-mail -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of saurabh khandelwal Sent: 18 March 2013 05:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Netview Script Not authorized -CNM424I Hello, I am trying running netview script from Netview Main panel but getting below error. CNM424I COMMAND LIST TIMEMNGR - ACCESS TO COMMAND IS NOT AUTHORIZED *-* 'purge timer='f.i',op=ppt' +++ RC(-3) +++ This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised and regulated by the Financial Services Authority. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Netview Script Not authorized -CNM424I
You might want to join the NetView discussion group on Yahoo Groups and post your question there. To Subscribe: netview-subscr...@yahoogroups.com Or to Unsubscribe: netview-unsubscr...@yahoogroups.com Thanks, Mark Regan <>< From: saurabh khandelwal To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, March 18, 2013 1:57 AM Subject: Netview Script Not authorized -CNM424I Hello, I am trying running netview script from Netview Main panel but getting below error. CNM424I COMMAND LIST TIMEMNGR - ACCESS TO COMMAND IS NOT AUTHORIZED *-* 'purge timer='f.i',op=ppt' +++ RC(-3) +++ CNM424I COMMAND LIST TIMEMNGR - ACCESS TO COMMAND IS NOT AUTHORIZED *-* 'purge timer='f.i',op=ppt' +++ RC(-3) +++ DSI204I TIMER REQUEST ID NOT UNIQUE ID = 'DC39' DSI202I TIMER REQUEST FAILED TO BE SCHEDULED FOR EXECUTION 'ID=DC39 DSI204I TIMER REQUEST ID NOT UNIQUE ID = 'DC40' DSI202I TIMER REQUEST FAILED TO BE SCHEDULED FOR EXECUTION 'ID=DC40 CNM424I COMMAND LIST TIMEMNGR - ACCESS TO COMMAND IS NOT AUTHORIZED *-* 'purge timer='f.i',op=ppt' +++ RC(-3) +++ CNM424I COMMAND LIST TIMEMNGR - ACCESS TO COMMAND IS NOT AUTHORIZED *-* 'purge timer='f.i',op=ppt' Then, I have checked couple of thing in my SYSTEM for netview definition. some of them are below. 1) list secopts O/P BNH228I OPTION VALUE LAST UPDATED UPDATE ID BNH229I --- - -- BNH229I OPERSEC NETVPW 03/13/13 02:17:52 INITIALIZATION BNH229I OPSPAN NETV 03/13/13 02:17:52 INITIALIZATION BNH229I CMDAUTH TABLE 03/13/13 02:17:52 INITIALIZATION BNH229I TBLNAME CNMSCAT2 03/13/13 02:17:52 INITIALIZATION BNH229I AUTHCHK SOURCEID 03/13/13 02:17:52 INITIALIZATION BNH229I SPANAUTH NONE 03/13/13 02:17:49 INITIALIZATION BNH229I SPANCHK SOURCEID 03/13/13 02:17:52 INITIALIZATION BNH229I CATAUDIT NONE 03/13/13 02:17:49 INITIALIZATION BNH229I AUTOSEC BYPASS 03/13/13 02:17:53 INITIALIZATION BNH229I SURROGAT NO 03/13/13 02:17:52 INITIALIZATION BNH229I RMTSEC NONE 03/13/13 02:17:54 INITIALIZATION BNH229I RMTAUTH SENDER 03/13/13 02:17:52 INITIALIZATION BNH229I WEBAUTH PASS 03/13/13 02:17:52 INITIALIZATION In NETVIEW.DSIPARM(CSTYLE) we have NETVPW active, as we have defined operator in SECOPTS.OPERSEC = NETVPW *SECOPTS.OPERSEC = SAFCHECK *SECOPTS.OPERSEC = SAFPW *SECOPTS.OPERSEC = SAFDEF *SECOPTS.OPERSEC = MINIMAL NETVIEW.DSIPARM(DSIOPFU) TEST OPERATOR PASSWORD= PROFILEN MASTER Then, I created MASTER profile under NETVIEW.DSIPRF, because I am not able to find other profiles DSIPROFB in my any members. MASTER PROFILE IC=LOGPROF2 AUTH MSGRECVR=NO,CTL=GLOBAL,NGMFADMN=YES END Now, I have two issues to address here. 1) Why I am not able to run scripts using netview main panel and getting authorization issue. 2) I also want to convert my operator defination from DSIOPFU member to RACF. So that NETIVEW can use RACF secuirty for accessing NETVIEW DOMAIN rather then DSIOPFU member in DSIPARM. For doing this, I tried reading Security refrence for NETVIEW book and followed below stpes to create new operator for accessing NEWVIEW. Change SECOPTS.OPERSEC = SAFDEF in DAIPARM and commented NETVPW line 1) SETROPTS CLASSACT(APPL) 2)RDEFINE APPL NETM9 UACC(NONE) 3) ADDUSER TEST1 PASSWORD(NEWOPER) 4) PERMIT NETM9 CLASS(APPL) ID(TEST1) ACCESS(READ) 5) and added below detail for TEST1 user id NETVIEW INFORMATION --- CTL= GLOBAL MSGRECVR= YES NGMFADMN= YES but still when I am trying to access Netview using SKHAND2 user id , then I am getting below error on netview panel. 1) DSI021A INVALID OPERATOR IDENTIFICATION, REENTER 2) I also noticed that, my netview start was failing and seen below error message on SYSLOG. ICH408I USER(NETM9PPT) GROUP( ) NAME(??? ) 354 LOGON/JOB INITIATION - USER AT TERMINAL NOT RACF-DEFINED IRR012I VERIFICATION FAILED. USER PROFILE NOT FOUND. I am not able to find this user in my NETM9PPT RACF . Please suggest. Regards Saurabh -- 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: Parameter list changes between calling and called program
On 18.03.2013 09:38, jan de decker wrote: Hi, In the copy/paste from my preious mail, I skipped the line: LR RB,RF so that RB points to the top of my CSECT Sorry about that. Best regards, j@n -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN A SLIP SA trap would be a possibility to DUMP at storage alternation (as already suggested) -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research& Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parameter list changes between calling and called program
Hi, In the copy/paste from my preious mail, I skipped the line: LR RB,RF so that RB points to the top of my CSECT Sorry about that. Best regards, j@n -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parameter list changes between calling and called program
Hi, Sorry about the error in the copy/paste from my previous mail. I skipped the line -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
