Re: SORT JCL
On Sun, 14 Sep 2014 22:21:21 -0500, Ron Thomas wrote: I have tried this control card and not getting the correct result. below is the one i got, the 2'nd field is not getting reflected . 1 - 4043 04045 - 4060 04062 - 4108 04110 - 4700 04705 - 4706 04708 04714 04719 04723 OUTREC IFTHEN=(WHEN=INIT,BUILD=(1,5,UFF,M1,6,2,8,5,UFF,M1,80:X)), IFTHEN=(WHEN=(9,5,ZD,EQ,0),OVERLAY=(9:5X)) Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumb IARCP64 question
Follow-up question: what the heck, then, does EXPAND=NO signify? Make it any size you like, but for gosh sakes don't make it any bigger than that? The documentation reads like transistor radio instructions from the fifties: ,EXPAND=NO This parameter does not try expanding. The documentation is REALLY deficient IMHO: 1. Apparently nada in the Services Guide. No overview. No usage. The example in the reference is just a rehash of the parameters. 2. Documentation appears to be 100% duplicated between Services and Authorized Services. If there is a reason for it being in both places the reason escapes me. I don't see any special parameters documented only in Authorized Services. 3. If the size works as Dave suggests -- and I have no reason to doubt him -- that rather counterintuitive point would be worth mentioning in the doc. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dave Day Sent: Saturday, September 13, 2014 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dumb IARCP64 question There aren't any. I asked the same question some time back, and was told that this is 64 bit stg. No need for these types of parameters. My gut tells me it gets stg to back the cell pool in 1 meg increments, but have not done anything to verify that. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumb IARCP64 question
EXPAND=NO will keep the cell pool limited to 1MB (approx. size as it is possible that any related housekeeping control blocks will eat into the total data available) EXPAND=YES will allow IARCP64 to chain multiple 1MB memory objects together to increase the logical cell pool size beyond 1Mb 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 Charles Mills Sent: 15 September 2014 13:41 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dumb IARCP64 question Follow-up question: what the heck, then, does EXPAND=NO signify? Make it any size you like, but for gosh sakes don't make it any bigger than that? The documentation reads like transistor radio instructions from the fifties: ,EXPAND=NO This parameter does not try expanding. The documentation is REALLY deficient IMHO: 1. Apparently nada in the Services Guide. No overview. No usage. The example in the reference is just a rehash of the parameters. 2. Documentation appears to be 100% duplicated between Services and Authorized Services. If there is a reason for it being in both places the reason escapes me. I don't see any special parameters documented only in Authorized Services. 3. If the size works as Dave suggests -- and I have no reason to doubt him -- that rather counterintuitive point would be worth mentioning in the doc. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dave Day Sent: Saturday, September 13, 2014 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dumb IARCP64 question There aren't any. I asked the same question some time back, and was told that this is 64 bit stg. No need for these types of parameters. My gut tells me it gets stg to back the cell pool in 1 meg increments, but have not done anything to verify that. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumb IARCP64 question
Thanks for doing IBM's documentation for them. g Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Monday, September 15, 2014 5:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dumb IARCP64 question EXPAND=NO will keep the cell pool limited to 1MB (approx. size as it is possible that any related housekeeping control blocks will eat into the total data available) EXPAND=YES will allow IARCP64 to chain multiple 1MB memory objects together to increase the logical cell pool size beyond 1Mb 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 Charles Mills Sent: 15 September 2014 13:41 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dumb IARCP64 question Follow-up question: what the heck, then, does EXPAND=NO signify? Make it any size you like, but for gosh sakes don't make it any bigger than that? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT JCL
Ron, It is quite simple to pad the leading zeros. Here is a sample. I assumed that you have a 6 byte field //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD * - PAD 6 ZEROES 1 - PAD 5 ZEROES 12 - PAD 4 ZEROES 123 - PAD 3 ZEROES 1234 - PAD 2 ZEROES 12345 - PAD 1 ZEROES 123456 - NO PADDING //SORTOUT DD SYSOUT=* //SYSINDD * OPTION COPY INREC OVERLAY=(1,6,UFF,M11,LENGTH=6) //* The output from this is 00- PAD 6 ZEROES 01 - PAD 5 ZEROES 12 - PAD 4 ZEROES 000123 - PAD 3 ZEROES 001234- PAD 2 ZEROES 012345 - PAD 1 ZEROES 123456 - NO PADDING Further if you have any questions please let me know Thanks, Sri Hari Kolusu DFSORT Development IBM Corporation Email: skol...@us.ibm.com Phone: 408-927-2187 Tie Line: 457-2187 IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 09/13/2014 10:29:11 PM: From: Ron Thomas ron5...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 09/13/2014 10:29 PM Subject: SORT JCL Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi. We have a file which is of the below layout LRECL = 80 0001 - 4043 4045 - 4060 4062 - 4108 4110 - 4700 4705 - 4706 47088 4714 4719 4723 6 Here we need to make this file as below by appending zeros to the 1'st byte of each number only if the length of the number is 4 . This being a parmcard if someone entered a 5 digit then no need to apend a zero . Could some one let me know how to do the same in sort? 1 - 04043 04045 - 04060 04062 - 04108 04110 - 04700 04705 - 04706 04708 88 04714 04719 04723 67 Thanks Ron T -- 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: SORT JCL
Hello The below control card is working, but in some cases where there is a word CHAIN , it is setting to zeros. We need this to be copied as it is. If the input length is 5 then copy as it is else if it is 4 or less than 54 append zeros to it. OUTREC IFTHEN=(WHEN=INIT,BUILD=(1,5,UFF,M1,6,2,8,5,UFF,M1,80:X)), IFTHEN=(WHEN=(9,5,ZD,EQ,0),OVERLAY=(9:5X)) 1 –43 343-999 CHAIN 4062 - 4108 4110 - 4700 4705 - 4706 4708 4714 4719 4723 1 – 00043 00343 -00999 CHAIN 04062 - 04108 04110 - 04700 04705 - 04706 04708 04714 04719 04723 Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT JCL
I agree that Sort may not be as easy as a programming language. For example, with REXX you can do LEFT(var,5,'0') or RIGHT(var,5,'0') and that will place zeros up to the number of positions. In Unix, or Perl, or COBOL, or EASYTRIEVE, or Assembler, not hard to do. Lizette, I have to disagree on that. In this case OP showed an complicated cards which are quite unnecessary as the solution is just as simple as a rexx LEFT/RIGHT command. ( see my solution which was posted earlier) *only if the length of the number is 4 * What about 3 or 2 or 1 digits ?. Shane, The solution I have shown will account for lengths 1 thru 6 and will pad the necessary zeroes. Without wishing to appear a die hard defender of DFSORT :-) I would expect DFSORT's I/O speed to be better than that of a program (even with decent Sequential File tuning). But that quite possibly DOESN'T matter. Thanks Martin and I agree with your statement as I am indeed a die hard defender of DFSORT. :) The OP, like many others here, does not appear to want or even to have considered writing a programmed resolution of his problem. He wants to use sort control statements instead. He can certainly do so too, but why? John, I agree with you but there are instances where a 40-50 line COBOL program work is done with a single keyword in DFSORT. Just like in programming there are many people who just complicate a simple task. In this case OP just needed a simple Overlay but instead chose an IFTHEN statement making it complicated. Over the past few years DFSORT has evolved and now can do a lot more than simple sorting. Thanks Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT JCL
On 9/15/2014 9:38 AM, Sri h Kolusu wrote: I agree that Sort may not be as easy as a programming language. For example, with REXX you can do LEFT(var,5,'0') or RIGHT(var,5,'0') and that will place zeros up to the number of positions. In Unix, or Perl, or COBOL, or EASYTRIEVE, or Assembler, not hard to do. Lizette, I have to disagree on that. In this case OP showed an complicated cards which are quite unnecessary as the solution is just as simple as a rexx LEFT/RIGHT command. ( see my solution which was posted earlier) *only if the length of the number is 4 * What about 3 or 2 or 1 digits ?. Shane, The solution I have shown will account for lengths 1 thru 6 and will pad the necessary zeroes. Without wishing to appear a die hard defender of DFSORT :-) I would expect DFSORT's I/O speed to be better than that of a program (even with decent Sequential File tuning). But that quite possibly DOESN'T matter. Thanks Martin and I agree with your statement as I am indeed a die hard defender of DFSORT. :) The OP, like many others here, does not appear to want or even to have considered writing a programmed resolution of his problem. He wants to use sort control statements instead. He can certainly do so too, but why? John, I agree with you but there are instances where a 40-50 line COBOL program work is done with a single keyword in DFSORT. Just like in programming there are many people who just complicate a simple task. In this case OP just needed a simple Overlay but instead chose an IFTHEN statement making it complicated. Over the past few years DFSORT has evolved and now can do a lot more than simple sorting. And you can learn most of the new features from the course pointed at from this page: http://www-01.ibm.com/support/docview.wss?rs=0uid=isg3T782 we can teach this, or arrange to have it taught, or you can buy a license for the course for internal teaching. -Steve Comstock Thanks Kolusu -- 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: SORT JCL
Will there be any other words beside CHAIN? Are there any lengths beside 5? It would be helpful to know all of the details of your input. Otherwise the solution will come in pieces only. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron Thomas Sent: Monday, September 15, 2014 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SORT JCL Hello The below control card is working, but in some cases where there is a word CHAIN , it is setting to zeros. We need this to be copied as it is. If the input length is 5 then copy as it is else if it is 4 or less than 54 append zeros to it. OUTREC IFTHEN=(WHEN=INIT,BUILD=(1,5,UFF,M1,6,2,8,5,UFF,M1,80:X)), IFTHEN=(WHEN=(9,5,ZD,EQ,0),OVERLAY=(9:5X)) 1 –43 343-999 CHAIN 4062 - 4108 4110 - 4700 4705 - 4706 4708 4714 4719 4723 1 – 00043 00343 -00999 CHAIN 04062 - 04108 04110 - 04700 04705 - 04706 04708 04714 04719 04723 Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT JCL
No there is nothing besides the word CHAIN Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Bizarre maybe-FTP problem
After uploading some barely changed source files via FTP to z/OS 1.12 today, I got a ton of assembler errors. Some research revealed that the first line of a macro read: STOR membername (where membername was the name of the member, doh). That isn't what it read on the PC side, and looks suspiciously like an FTP command somehow became part of the data! Anyone ever seen anything like that? I know it sounds impossible. Re-FTPing fixed it. But I dislike a mystery like this, especially on a Monday... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bizarre maybe-FTP problem
Actually it wasn't me doing the upload, and now I'm told BlueZone was the emulator used, using FTP. So maybe this is a BZ buglet. From: Phil Smith Sent: Monday, September 15, 2014 12:52 PM To: ibm-m...@bama.ua.edu Subject: Bizarre maybe-FTP problem After uploading some barely changed source files via FTP to z/OS 1.12 today, I got a ton of assembler errors. Some research revealed that the first line of a macro read: STOR membername (where membername was the name of the member, doh). That isn't what it read on the PC side, and looks suspiciously like an FTP command somehow became part of the data! Anyone ever seen anything like that? I know it sounds impossible. Re-FTPing fixed it. But I dislike a mystery like this, especially on a Monday... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT JCL
Ron, Your requirements are still fuzzy. You first started with 1 field and now you have 2 fields to pad with zeros? How did this 343-999 become 000343 00999 ?? Do you need to parse the field for the delimiter of - and split a single field into 2 fields while padding zeros? Thanks, Kolusu IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 09/15/2014 09:24:53 AM: From: Ron Thomas ron5...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 09/15/2014 09:33 AM Subject: Re: SORT JCL Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU No there is nothing besides the word CHAIN Thanks! -- 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: SORT JCL
Kolusu. Apologies for the wrong data put, - is there in the input on col 6. Here is the requirements FROM DEPT -TODEPT 100 - 200 i.e all data FROM DEPT and TODEPT to be made 5 bytes by padding zeros irrespective of what users entered. if the user entered 5 byte dept then make no changes for all other cases pad with zeros to make it as 5 bytes. 1 byte data inputted to be padded with 4 leading zeros and same as in all the other cases. If there is some word like CHAIN in one of the records then leave that record . no need to make any changes. INPUT 1 –43 343-999 CHAIN 4062 - 4108 4110 - 4700 4705 - 4706 4708 4714 4719 4723 OUTPUT 1 – 00043 00343 -00999 CHAIN 04062 - 04108 04110 - 04700 04705 - 04706 04708 04714 04719 04723 Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bizarre maybe-FTP problem
Been using Bluezone FTP for more than a decade, and have never encountered that sort of error. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith Sent: Monday, September 15, 2014 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bizarre maybe-FTP problem Actually it wasn't me doing the upload, and now I'm told BlueZone was the emulator used, using FTP. So maybe this is a BZ buglet. From: Phil Smith Sent: Monday, September 15, 2014 12:52 PM To: ibm-m...@bama.ua.edu Subject: Bizarre maybe-FTP problem After uploading some barely changed source files via FTP to z/OS 1.12 today, I got a ton of assembler errors. Some research revealed that the first line of a macro read: STOR membername (where membername was the name of the member, doh). That isn't what it read on the PC side, and looks suspiciously like an FTP command somehow became part of the data! Anyone ever seen anything like that? I know it sounds impossible. Re-FTPing fixed it. But I dislike a mystery like this, especially on a Monday... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT JCL
Ron, Use the following JCL //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD * +1+2+3+4+5+6+--- 1 43 343 - 999 CHAIN 4062 - 4108 4110 - 4700 4705 - 4706 4708 4714 4719 4723 345 //SORTOUT DD SYSOUT=* //SYSINDD * OPTION COPY INREC IFTHEN=(WHEN=(1,5,CH,NE,C'CHAIN'), OVERLAY=(1:1,5,UFF,M11,LENGTH=5, 7:7,5,UFF,M11,LENGTH=5, 1:1,5,CHANGE=(5,C'0',C' '),NOMATCH=(1,5), 7:7,5,CHANGE=(5,C'0',C' '),NOMATCH=(7,5))) //* The output from this is 1 00043 00343-00999 CHAIN 04062-04108 04110-04700 04705-04706 04708 04714 04719 04723 00345 Thanks, Kolusu IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 09/15/2014 10:18:06 AM: From: Ron Thomas ron5...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 09/15/2014 10:18 AM Subject: Re: SORT JCL Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Kolusu. Apologies for the wrong data put, - is there in the input on col 6. Here is the requirements FROM DEPT -TODEPT 100 - 200 i.e all data FROM DEPT and TODEPT to be made 5 bytes by padding zeros irrespective of what users entered. if the user entered 5 byte dept then make no changes for all other cases pad with zeros to make it as 5 bytes. 1 byte data inputted to be padded with 4 leading zeros and same as in all the other cases. If there is some word like CHAIN in one of the records then leave that record . no need to make any changes. INPUT 1 –43 343-999 CHAIN 4062 - 4108 4110 - 4700 4705 - 4706 4708 4714 4719 4723 OUTPUT 1 – 00043 00343 -00999 CHAIN 04062 - 04108 04110 - 04700 04705 - 04706 04708 04714 04719 04723 Thanks Ron T -- 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: Deleting Cluster Using IEFBR14 or IDCAMS
t...@harminc.net (Tony Harminc) wrote: On 2 September 2014 10:32, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: I use DSLIST, but I assume that invokes IDCAMS. (TSO DELETE also? I haven't tried that.) TSO DELETE has been an IDCAMS command since MVS 2.0; maybe even in SVS, a system I never used. My two comments (or cents) about this thread are: 1. IEFBR14, in addition to being the smallest program in z/OS as far as I know (and only one instruction longer than the smallest possible program), remains the most misused program in z/OS history in my view. Whether DD statements included in a IEFBR14 step are processed as you might wish or not does not affect the apparent success of step execution. IDCAMS, TSO/E (IJEFTxx), and other programs provide far more flexibility and tell you much more about what happened if things don't go as you expect. They also let you conditionally run steps based on success or lack thereof. Very few things require the use of JCL for data set allocation, and even fewer require it for data set deletion. 2. Tony indirectly makes a good point. At the risk of sounding more pedantic than usual, it's sometimes useful, even important, to differentiate between a TSO/E command processor (which can be supplied by anyone) and a TSO/E command, which is for all practical purposes a TSO/E command processor supplied by TSO/E itself. TSO/E command processors look, smell, and feel just like TSO/E commands, but are not necessarily part of TSO/E. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT JCL
Thanks a lot Kolsu.. It worked. Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MSG IKJ56961E LISTBC TERMINATED
Getting this at TSO logon time. This is on a test LPAR which had many volumes eliminated(because of clean-up). Any thoughts as to identifying the volume? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bizarre maybe-FTP problem
Your analysis of what happened sounds totally spot-on and no, nothing is impossible. Does not sound like an unlikely bug, as bugs go. Get the pointers wrong, and send the FTP server command on the wrong session ... Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith Sent: Monday, September 15, 2014 9:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Bizarre maybe-FTP problem After uploading some barely changed source files via FTP to z/OS 1.12 today, I got a ton of assembler errors. Some research revealed that the first line of a macro read: STOR membername (where membername was the name of the member, doh). That isn't what it read on the PC side, and looks suspiciously like an FTP command somehow became part of the data! Anyone ever seen anything like that? I know it sounds impossible. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Another DF/SORT quest. (splice?)
I'm trying to develop a seemingly simple SPLICE operation where all the input comes from a single dataset. I want to combine several records types into 1 record containing the fields from each input record type. For example I have an input file where various types can appear in a header-trailer1 or header-trailer1-trailer2 or header only sequence of records. There is no key, only the type to work with. The input sequence of record can look like any of the following: H02 T21 or H02 T21 T22or H03 T21or H04 T21 H02 T21 T22 T23 or H02only H03 only H04 only My output should look like: H02 fields + t21 fields H02 fields + t21 fields + t22 fields H03 fields + t21 fields H04 fields + t21 fields H02 _ t21 + t22 + t23 H02 H03 H04 No sorting is needed, the records are in the desired sequence already. Only the combining of fields is necessary. I've done quite a bit of reading in the DF/SORT APG but could not find a relevant example. I've considered SPLICE but lack a key. I tried WHEN=GROUP but I don't see a method to create a combined record. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Cluster Using IEFBR14 or IDCAMS
On Mon, 15 Sep 2014 13:39:27 -0400, John Eells wrote: 1. IEFBR14, in addition to being the smallest program in z/OS as far as I know (and only one instruction longer than the smallest possible program), remains the most misused program in z/OS history in my view. Whether DD statements included in a IEFBR14 step are processed as you might wish or not does not affect the apparent success of step execution. PEDANTRY Sometimes. I'm certainly accustomed to seeing JCL ERROR -- DATA SET NOT FOUND. in some cases; other times not. /PEDANTRY ... IDCAMS, TSO/E (IJEFTxx), and other programs provide far more flexibility and tell you much more about what happened if things don't go as you expect. They also let you conditionally run steps based on success or lack thereof. Very few things require the use of JCL for data set allocation, and even fewer require it for data set deletion. Sometimes. Other times a utility converts an error message to what the author assumes is more familiar language, but others find it less precise. I lately ranted in MVS-OE about a vague filesystem error reported by cp(1). Looking at SYSLOG showed an ABEND SD37 trapped and obfuscated by cp. Probably the C RTL. Dammit! They could/should trap the message text and make that also available to the programmer's console. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Question concerning running z/OS LPARs under z/VM
I was quesioned about reconfiguring our current processor. Currently, we are running 6 LPARs - 2 sandbox LPARs , an applicaton/test LPAR, a certification LPAR, a production LPAR and a scheduling LPAR. The sandbox LPARs run under separate monoplexes and separate MASs. The remaining LPARs run under a Base Sysplex and the same MAS. The configuration in question would have the 2 sandbox LPARs, the application/test LPAR and the certification LPAR run as guests under z/VM. The production and scheduling LPARs would still run as separate LPARs but the same MAS. Can the current Base Sysplex and MAS still be used with 2 members running native and the other two runnng as guests under z/VM?Would we need a second MAS? I would also think that there would be extra overhead with PRSM deciding which LPAR gets resources and if it is the z/VM LPAR, then z/VM deciding which guest gets the resources. Seems like a duplication of effort. Then, of course, would JES2 tolerate this as well? Any thoughts, or, has anyone performed this type of configuration. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bizarre maybe-FTP problem
On Mon, 15 Sep 2014 09:54:33 -0700, Phil Smith wrote: Actually it wasn't me doing the upload, and now I'm told BlueZone was the emulator used, using FTP. So maybe this is a BZ buglet. From: Phil Smith Sent: Monday, September 15, 2014 12:52 PM After uploading some barely changed source files via FTP to z/OS 1.12 today, I got a ton of assembler errors. diff (aka SuperC) can sometimes shortcut the research. Of course the first ASMA message line can be very telling. Some research revealed that the first line of a macro read: STOR membername (where membername was the name of the member, doh). That isn't what it read on the PC side, and looks suspiciously like an FTP command somehow became part of the data! Anyone ever seen anything like that? I know it sounds impossible. Re-FTPing fixed it. But I dislike a mystery like this, especially on a Monday... What did it read on the PC side? It appears somewhat as if the data were mistaken for a script, whether by programmer error or BZ internal failure. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another DF/SORT quest. (splice?)
Tony, It is quite simple to create a pseudo key to use as matching key for splice. I assumed that your input is RECFM=FB and LRECL=80. The group starts with H and you can have a max of 3 detailed records which start with T21,T22, T23. However if you have more you can adjust the solution accordingly. Use the following JCL which will give you the desired results. The output will be a 320 byte file with records combined. //STEP0100 EXEC PGM=ICETOOL //TOOLMSG DD SYSOUT=* //DFSMSG DD SYSOUT=* //IN DD * H01 T21 H02 T21 T22 H03 T21 H04 T21 H05 T21 T22 T23 H06 H07 H08 //OUT DD SYSOUT=* //TOOLIN DD * SPLICE FROM(IN) TO(OUT) ON(321,8,CH) WITHANY - WITH(81,80) WITH(161,80) WITH(241,80) USING(CTL1) //* //CTL1CNTL DD * OPTION COPY INREC IFOUTLEN=328,IFTHEN=(WHEN=INIT,BUILD=(331:1,80)), IFTHEN=(WHEN=GROUP,BEGIN=(331,1,CH,EQ,C'H'),PUSH=(321:ID=8)), IFTHEN=(WHEN=(331,1,CH,EQ,C'H'),OVERLAY=(001:331,80)), IFTHEN=(WHEN=(331,3,CH,EQ,C'T21'),OVERLAY=(081:331,80)), IFTHEN=(WHEN=(331,3,CH,EQ,C'T22'),OVERLAY=(161:331,80)), IFTHEN=(WHEN=(331,3,CH,EQ,C'T23'),OVERLAY=(241:331,80)) OUTFIL BUILD=(1,320) //* Further if you have any questions please let me know Thanks, Kolusu DFSORT Development IBM Corporation From: Tony's Basement Computer tbabo...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 09/15/2014 11:32 AM Subject:Another DF/SORT quest. (splice?) Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU I'm trying to develop a seemingly simple SPLICE operation where all the input comes from a single dataset. I want to combine several records types into 1 record containing the fields from each input record type. For example I have an input file where various types can appear in a header-trailer1 or header-trailer1-trailer2 or header only sequence of records. There is no key, only the type to work with. The input sequence of record can look like any of the following: H02 T21 or H02 T21 T22or H03 T21or H04 T21 H02 T21 T22 T23 or H02only H03 only H04 only My output should look like: H02 fields + t21 fields H02 fields + t21 fields + t22 fields H03 fields + t21 fields H04 fields + t21 fields H02 _ t21 + t22 + t23 H02 H03 H04 No sorting is needed, the records are in the desired sequence already. Only the combining of fields is necessary. I've done quite a bit of reading in the DF/SORT APG but could not find a relevant example. I've considered SPLICE but lack a key. I tried WHEN=GROUP but I don't see a method to create a combined record. -- 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: Bizarre maybe-FTP problem
Paul Gilmartin wrote: What did it read on the PC side? It appears somewhat as if the data were mistaken for a script, whether by programmer error or BZ internal failure. It was an assembler macro, so “MACRO blah”, but we do this a lot and the same file re-uploaded with the same options worked. But yeah, maybe something dropped a byte and that led it to misread…only why did it (a) work at all and (b) put the directive in the file, replacing the MACRO line? Mystery! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question concerning running z/OS LPARs under z/VM
On Mon, 15 Sep 2014 18:34:39 +, Mark Yuhas wrote: I would also think that there would be extra overhead with PRSM deciding which LPAR gets resources and if it is the z/VM LPAR, then z/VM deciding which guest gets the resources. Seems like a duplication of effort. Then, of course, would JES2 tolerate this as well? Perhaps even worse, nested paging. Might that be alleviated by either some use of V=R (is this possible?) so only the guests but not CP pages, or by defining an absurdly large virtual storage for the guests so only CP but not the guests page? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question concerning running z/OS LPARs under z/VM
I do not see any gain from the proposed configuration, however, my thoughts are: As I interpret the proposed configuration, you would be processing a total of 3 lpars (production, scheduling, and z/VM). I do not see any unsolvable issues of a configuration nature, with sharing between z/OS guest images and non-guest images. I do, however, see potential performance issues (all solvable) within that configuration. What about z/VM maintenance? Think about a z/VM sandbox LPAR. You did not specify what level of z/VM is to be used. If z/VM with Single System Image (?) is installed, z/VM allows live guest migration. i.e. guests can be moved from One VM image to another without interruption. IIRC this is available w/z/VM 6.3 and later. Certain conditions apply. YMMV. HTH, Disclaimer. I am *NOT* a z/VM expert, although I have some familiarity with the capabilities. Your IBM/IBM partner tech rep should be able to correct anything above that is incorrect. snip Currently, we are running 6 LPARs - 2 sandbox LPARs , an applicaton/test LPAR, a certification LPAR, a production LPAR and a scheduling LPAR. The sandbox LPARs run under separate monoplexes and separate MASs. The remaining LPARs run under a Base Sysplex and the same MAS. The configuration in question would have the 2 sandbox LPARs, the application/test LPAR and the certification LPAR run as guests under z/VM. The production and scheduling LPARs would still run as separate LPARs but the same MAS. Can the current Base Sysplex and MAS still be used with 2 members running native and the other two runnng as guests under z/VM?Would we need a second MAS? I would also think that there would be extra overhead with PRSM deciding which LPAR gets resources and if it is the z/VM LPAR, then z/VM deciding which guest gets the resources. Seems like a duplication of effort. Then, of course, would JES2 tolerate this as well? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question concerning running z/OS LPARs under z/VM
z/VM solved the nested paging issue the late 80's. Usually by making the guest image so large that paging never became an issue. There was also the preferred guest feature. snip I would also think that there would be extra overhead with PRSM deciding which LPAR gets resources and if it is the z/VM LPAR, then z/VM deciding which guest gets the resources. Seems like a duplication of effort. Then, of course, would JES2 tolerate this as well? Perhaps even worse, nested paging. Might that be alleviated by either some use of V=R (is this possible?) so only the guests but not CP pages, or by defining an absurdly large virtual storage for the guests so only CP but not the guests page? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ported Tools (was C language - z/OS 2.1, creating programs 2 run on previous releases .. GNU autoconfigure)
I should add that any issues with the Rocket-supported Ported Tools can be reported by sending an email to portedto...@rocketsoftware.com Bob Shannon Rocket Software Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSG IKJ56961E LISTBC TERMINATED
My first inclination was to say that SYS1.BRODCAST had resided on a volume that was removed. Then I remembered this line in MSTJCLxx: //SYSLBC DD DISP=SHR,DSN=SYS1.BRODCAST which would make IPL pretty dicey. Then it occurred to me that as long as the data set it cataloged, maybe the system doesn't really look for it until LISTBC needs to do I/O. So do LISTCAT on SYS1.BRODCAST . If the volume is missing, that's the problem. Otherwise, check for a personal 'userlog' data set cataloged to a missing volume. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: John Norgauer jcnorga...@ucdavis.edu To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/15/2014 11:03 AM Subject:MSG IKJ56961E LISTBC TERMINATED Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Getting this at TSO logon time. This is on a test LPAR which had many volumes eliminated(because of clean-up). Any thoughts as to identifying the volume? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Bizarre maybe-FTP problem
Could be hardware, could be an attack. Guess start with packet traces. We had a couple of lengthy runs had to put on 'milking machines' before the cable could be replaced. In a message dated 9/15/2014 1:52:56 P.M. Central Daylight Time, p...@voltage.com writes: It was an assembler macro, so “MACRO blah”, but we do this a lot and the same file re-uploaded with the same options worked. But yeah, maybe something dropped a byte and that led it to misread…only why did it (a) work at all and (b) put the directive in the file, replacing the MACRO line? Mystery! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT JCL
Based on stats I have had, command chaining or similar seems to be what they do. Did that years ago in a bunch of programs for tape spooling and subsequent processing. -Original Message- From: Tom Brennan Sent: Sunday, September 14, 2014 5:25 PM Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SORT JCL I remember I needed some quick changes to a very large PS dataset, and not wanting to struggle with DFSORT syntax I wrote a quick assembler program (QSAM with a large block size and extra buffers). Nothing could be faster than an assembled program, right? Later I figured out how to do the same work with DFSORT or ICETOOL, and was surprised when the SORT job ran in about 25% less clock time than my own simple program. All I could guess is that DFSORT has some DASD tricks to speed things up, like you say. Martin Packer wrote: Without wishing to appear a die hard defender of DFSORT :-) I would expect DFSORT's I/O speed to be better than that of a program (even with decent Sequential File tuning). But that quite possibly DOESN'T matter. Cheers, Martin -- 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
Contractor Help Wanted: SMP/E Enablement
I am looking for someone on a short-term contract basis to enable a vendor z/OS product for SMP/E installation and maintenance. The product is currently installed with TSO RECEIVE, etc., etc. It is a fairly simple product with relatively few components. Please send qualifications and desired contract terms to the undersigned privately at charlesm at mcn dot org. Obviously, the successful candidate will have at a minimum extensive experience with SMP/E usage and probably experience with SMP/E enablement. This is a totally legitimate contract opportunity. I am not an agent; I am an employee of the principal. We would expect to pay actual money for this. (I requested permission from Darren to post this and have not heard back one way or the other so I am taking Admiral Grace's advice: http://www.brainyquote.com/quotes/quotes/g/gracehoppe170166.html ) Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT JCL
Thanks a lot Kolsu.. It worked. Thanks! Now that this has finally been put to bed, the length of the thread illustrates vividly the issue I have with using DF/SORT. It has grown (and changed) over the years in an apparent attempt to be all things to all men - and is damn near unusable as a quick solution. Unless you already have a job set up somewhere that is close enough and can be quickly modified, or can find something in the smart tricks papers. Works a treat when it works though ... Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JoAT (was: SORT JCL)
On Mon, 15 Sep 2014 17:47:03 -0500, Shane Ginnane wrote: Now that this has finally been put to bed, the length of the thread illustrates vividly the issue I have with using DF/SORT. It has grown (and changed) over the years in an apparent attempt to be all things to all men - and is damn near unusable as a quick solution. Unless you already have a job set up somewhere that is close enough and can be quickly modified, or can find something in the smart tricks papers. Works a treat when it works though ... Emacs is like that. Web browsers are like that, nowadays (and emacs embeds its own browser). Any utility that embeds its own editor rather than allowing a pluggable replacement is like that. (ISPF for CMS allows a choice of PDF or XEDIT although 2 is not one of the only three nice numbers. ISPF for z/OS allows no such flexibility (or does it? some ISPF wizard might jump in and explain how it can be done.) I'd love to be able to select vi as my editor under ISPF (but not all the time.)) The Swiss Army Hammer. There's a famous 1983 paper by Rob Pike(blurb only; copyright prohibits more) : http://harmful.cat-v.org/cat-v/ UNIX Style, or cat -v Considered Harmful ... sympathizing with our view. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JoAT (was: SORT JCL)
Paul Gilmartin wrote: I'd love to be able to select vi as my editor under ISPF (but not all the time.)) Now you made me think: vi using SNA would mean you need to send each individual keypress to the mainframe and get a response. That might be possible by having the terminal emulator tag a PA-key onto every keystroke, sending a couple of bytes to a TGET that is set up to process each character. Crazy... but with the fast networks and mainframes we have these days, it just might be usable. Then you have to find mainframe people who want to use vi. That's probably the bigger issue :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSG IKJ56961E LISTBC TERMINATED
The full IKJ56961E message should have supplied dynalloc return / reason codes, which the OP didn't supply but would have helped. Skip may have it right with regards to SYS1.BRODCAST, but the OP should check his IKJTSO member is see if TSO/E userlogs are being used instead (SEND statement, USERLOG parameter). Given that 'many volumes were eliminated', it may be that his private TSO/E userlog was trashed, and the SMS ACS routines crippled to the point a new one can't be allocated (check the form of the TSO/E USERLOG filename, if used, and throw it through a SMS ACS test case). Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Tuesday, 16 September 2014 5:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MSG IKJ56961E LISTBC TERMINATED My first inclination was to say that SYS1.BRODCAST had resided on a volume that was removed. Then I remembered this line in MSTJCLxx: //SYSLBC DD DISP=SHR,DSN=SYS1.BRODCAST which would make IPL pretty dicey. Then it occurred to me that as long as the data set it cataloged, maybe the system doesn't really look for it until LISTBC needs to do I/O. So do LISTCAT on SYS1.BRODCAST . If the volume is missing, that's the problem. Otherwise, check for a personal 'userlog' data set cataloged to a missing volume. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: John Norgauer jcnorga...@ucdavis.edu To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/15/2014 11:03 AM Subject:MSG IKJ56961E LISTBC TERMINATED Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Getting this at TSO logon time. This is on a test LPAR which had many volumes eliminated(because of clean-up). Any thoughts as to identifying the volume? -- 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: SORT JCL
On Mon, 15 Sep 2014 17:47:03 -0500, Shane Ginnane wrote: Works a treat when it works though ... But nothing explains why results of LOCALE=EN_GB and LOCALE=EN_AU agree well with each other, but differ radically from LOCALE=EN_US. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JoAT (was: SORT JCL)
On Mon, 15 Sep 2014 17:15:09 -0700, Tom Brennan wrote: Paul Gilmartin wrote: I'd love to be able to select vi as my editor under ISPF (but not all the time.)) Now you made me think: vi using SNA would mean you need to send each individual keypress to the mainframe and get a response. That might be possible by having the terminal emulator tag a PA-key onto every keystroke, sending a couple of bytes to a TGET that is set up to process each character. Crazy... but with the fast networks and mainframes we have these days, it just might be usable. I was thinking more of popping up an XTERM window with DISPLAY=Desktop. vi works acceptably under Unix System Services; VTAM (but no SNA?). And there should be a -wait option -- if omitted, maintain an ISPF-style ENQ on the member for the duration, but unlock the 3270 keyboard/ISPF session. Then you have to find mainframe people who want to use vi. That's probably the bigger issue :) Perhaps easier to find vi (or emacs or gedit) people who are required to use the mainframe. There are probably a few on this list. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSG IKJ56961E LISTBC TERMINATED
Oh, another possibility... When volumes were removed from your test LPAR, were the catalogues cleaned up to remove entries that referred to files on those removed volumes? It may be that you have dead catalogue entries that refer to datasets that no longer exist ( general SYS1.BRODCAST or private TSO/E userlogs), which would cause allocation failures. Note also the IKJTSO member can specify an alternate name for SYS1.BRODCAST, as well as a specific volser for it. Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Anthony Thompson Sent: Tuesday, 16 September 2014 9:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MSG IKJ56961E LISTBC TERMINATED The full IKJ56961E message should have supplied dynalloc return / reason codes, which the OP didn't supply but would have helped. Skip may have it right with regards to SYS1.BRODCAST, but the OP should check his IKJTSO member is see if TSO/E userlogs are being used instead (SEND statement, USERLOG parameter). Given that 'many volumes were eliminated', it may be that his private TSO/E userlog was trashed, and the SMS ACS routines crippled to the point a new one can't be allocated (check the form of the TSO/E USERLOG filename, if used, and throw it through a SMS ACS test case). Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Tuesday, 16 September 2014 5:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MSG IKJ56961E LISTBC TERMINATED My first inclination was to say that SYS1.BRODCAST had resided on a volume that was removed. Then I remembered this line in MSTJCLxx: //SYSLBC DD DISP=SHR,DSN=SYS1.BRODCAST which would make IPL pretty dicey. Then it occurred to me that as long as the data set it cataloged, maybe the system doesn't really look for it until LISTBC needs to do I/O. So do LISTCAT on SYS1.BRODCAST . If the volume is missing, that's the problem. Otherwise, check for a personal 'userlog' data set cataloged to a missing volume. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: John Norgauer jcnorga...@ucdavis.edu To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/15/2014 11:03 AM Subject:MSG IKJ56961E LISTBC TERMINATED Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Getting this at TSO logon time. This is on a test LPAR which had many volumes eliminated(because of clean-up). Any thoughts as to identifying the volume? -- 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: SORT JCL
On Mon, 15 Sep 2014 19:50:40 -0500, Ed Gould wrote: To be fair its both SYNCSORT and DFSORT. Probably true - but I've not seen Syncsort for decades. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JoAT (was: SORT JCL)
On Sep 15, 2014, at 10:49 PM, Paul Gilmartin wrote: On Mon, 15 Sep 2014 22:21:12 -0500, Ed Gould wrote: I am not so sure that is the case (ISPF edit) . The issue is as I see it that there is no xedit for MVS . Its relatively easy to change the ISPF primary menu to use another How? Does that percolate through to DSLIST, DDLIST, ..., in which I'm more interested than an alternative to the ISPF Option 2 menu. If I did this, would I need to supply my own member selection logic, etc.? I *think* member selection etc is part and parcel of ispf/pdf. But if it isn't then the replacement would have to do the member selection. I think that no one has done one so you are treading on new territory. Of course there may be one out there. If memory serves me no one heard of FSE until some member of GUIDE did a presentation. Maybe there is an xedit look alike out there hiding in the weeds and just waiting to pop out. Ed editor, but AFAIK there isn't one out there(anyone know of one?) nedit. http://www-03.ibm.com/systems/z/os/zos/features/unix/ library/IBM+Redbooks/index.html#nedit -- 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: JoAT (was: SORT JCL)
On Mon, 15 Sep 2014 22:57:07 -0500, Ed Gould wrote: I *think* member selection etc is part and parcel of ispf/pdf. But if it isn't then the replacement would have to do the member selection. I think that no one has done one so you are treading on new territory. Of course there may be one out there. If memory serves me no one heard of FSE until some member of GUIDE did a presentation. Maybe there is an xedit look alike out there hiding in the weeds and just waiting to pop out. The Hessling Editor. But I don't know; rather I doubt; that it's been ported to z/OS. But I'm less motivated toward any particular editor than to have a pluggable editor interface for DDLIST, DSLIST, SDSF SE, ... editor, but AFAIK there isn't one out there(anyone know of one?) nedit. http://www-03.ibm.com/systems/z/os/zos/features/unix/ library/IBM+Redbooks/index.html#nedit -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JoAT (was: SORT JCL)
On Sep 15, 2014, at 10:57 PM, Ed Gould wrote: -SNIP__ editor, but AFAIK there isn't one out there(anyone know of one?) nedit. http://www-03.ibm.com/systems/z/os/zos/features/unix/ library/IBM+Redbooks/index.html#nedit -- gil Gil: Sorry I was talking about MVS not the others. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JoAT (was: SORT JCL)
On Sep 15, 2014, at 11:43 PM, Paul Gilmartin wrote: On Mon, 15 Sep 2014 22:57:07 -0500, Ed Gould wrote: I *think* member selection etc is part and parcel of ispf/pdf. But if it isn't then the replacement would have to do the member selection. I think that no one has done one so you are treading on new territory. Of course there may be one out there. If memory serves me no one heard of FSE until some member of GUIDE did a presentation. Maybe there is an xedit look alike out there hiding in the weeds and just waiting to pop out. The Hessling Editor. But I don't know; rather I doubt; that it's been ported to z/OS. Sorry is it MVS native (not OE)... and if is Fullscreen and if its not ported maybe you should ask them to? But I'm less motivated toward any particular editor than to have a pluggable editor interface for DDLIST, DSLIST, SDSF SE, ... The SDSF is a little bit harder .. as you would have to take a look at the SDSF source (yea SOURCE) and see how it invokes the editor maybe that would give you an idea. As to ddlist and dslist, I am not familiar with those. Perhaps they are in house??? If so you would have to look at the source and then at the SDSF source to see how to invoke PDF/edit. SDSF has to keep distributing source as most of JES2 is source (exceptions there are) so you can learn from there how to invoke an editor. Let me end this discussion as there is a difference (but its been ages since I was interested) between (I think) ISPF and PDF. I used to care 30 years ago but since IBM bundled everything together its a jumble. I *THINK* IBM used to sell them separately (I never heard of anyone not ordering both) But trying to separate them was a mess and it was just easier to bundle them together and buy them. editor, but AFAIK there isn't one out there(anyone know of one?) nedit. http://www-03.ibm.com/systems/z/os/zos/features/unix/ library/IBM+Redbooks/index.html#nedit -- 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
