Retireiving DCB information for migrated datasets
Hi, Is it possible to retreive DCB information (LRECL, BLKSIZE, RECFM, DSORG) for migrated datasets, without recalling the dataset? I looked in the record layouts for decollect, and couldn't find it. If it matters, the system is question is running OS/390 v2.8 Thanks Gadi לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retireiving DCB information for migrated datasets
Hi In the mcds (migration control dataset) you can find the DCB information, ARCMCD macro. On 30.07.2014 08:56, גדי בן אבי wrote: Hi, Is it possible to retreive DCB information (LRECL, BLKSIZE, RECFM, DSORG) for migrated datasets, without recalling the dataset? I looked in the record layouts for decollect, and couldn't find it. If it matters, the system is question is running OS/390 v2.8 Thanks Gadi לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- 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: Retireiving DCB information for migrated datasets
Hi, Where should I look for this macro? Gadi From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari [miklos.szigetv...@isis-papyrus.com] Sent: 30 July 2014 10:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Retireiving DCB information for migrated datasets Hi In the mcds (migration control dataset) you can find the DCB information, ARCMCD macro. On 30.07.2014 08:56, גדי בן אבי wrote: Hi, Is it possible to retreive DCB information (LRECL, BLKSIZE, RECFM, DSORG) for migrated datasets, without recalling the dataset? I looked in the record layouts for decollect, and couldn't find it. If it matters, the system is question is running OS/390 v2.8 Thanks Gadi לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- 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
z/OS V2.1 and System Symobls and JCL
Hello there, I find the last sample provided by Peter very effective, because it does not involve any programs and use pure, sole JCL. However, I don't understand why you need to EXPORT and SET the variables first. Let me explain. On a z/OS 2.1 this works: //H2PC EXEC PGM=FTP,PARM='(EXIT' //OUTPUT DD SYSOUT=* //SYSIN DD *,SYMBOLS=EXECSYS mypc mypw put MY.DSNAME myfile_sysname..txt Symbol sysname is resolved, no need to code EXPORT or SET in JCL. The same work for another variable like jday. But the same does NOT work if I code put MY.DSNAME myfile_ldate..ltime..txt Both ldate and ltime do not get resolved. Grateful if someone can explain why. Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS V2.1 and System Symobls and JCL
Hello again, Peter's sample would work coding: //H2PC EXEC PGM=FTP,PARM='(EXIT' //MYFILE DD DISP=SHR,DSN=MY.DATASET //OUTPUT DD SYSOUT=* //SYSIN DD *,SYMBOLS=EXECSYS mypc mypw put DD://MYFILE test.file.LYYMMDD..LHHMMSS..txt no EXPORT, no SET. The z/OS 2.1 Initialization and Tuning Reference claims DATE, LDATE, TIME and LTIME as old sysmbols. Maybe this is the reason why they do not get resolved when used in the JCL above. Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Numeric Part of PC Number in linkage state entry
Thanks - that actually makes sense. You lose one bit for the difference between PC versus branch. On Wed, 30 Jul 2014 01:41:39 -0400 Jim Mulder d10j...@us.ibm.com wrote: : The PC number is 00180305 : : Bytes 148-151 show 00080305 : : The leading 001 is missing.. : : In your PC number, bit 44 is one, so you need to read that :Principles of Operation paragraph very carefully. The leading :001 is not missing. Bit 44 has been discarded, and the leading :001 has been shifted 1 bit to the right, so it is transformed into :0008. To reconstruct the PC number from bytes 148-151, you need to :first examine bits 1-12 of bytes 148-151. If any of those bits :are one, then bit 44 must have been one in the PC number, and :then you reconstruct the rest of the PC number by reversing the :logic described in the Principles of Operation paragraph :which explains what is stored in 148-151 when bit 44 of the :PC number is one. If Bits 1-12 of bytes 148-151 are all zero, :then the bit 44 was zero in the PC number, and you reconstruct the :PC number by reversing the logic for when bit 44 is zero in the PC number. : : And if I miscounted some bits there, well, it is late at night, and :Peter Relson can correct me, or we can find the z/OS code to do the :PC number reconstruction that Peter must have written in z.OS 1.6 :when he implemented ASN-and-LX Reuse (because in order for RTM2 :to find an ARR address, we need to reconstruct the PC number :from the linkage stack entry, so we can use it to locate the :Entry Table Entry for the PC number, which contains the ARR address). : : : On Tue, 29 Jul 2014 17:39:44 -0400 Jim Mulder d10j...@us.ibm.com :wrote: : : : The issued PC is 16 bit linkage index (24 bit total with the entry : :number) but : : the linkage state entry at offset +x'94' (decimal 148) has bits 0-11 : : :zero. It : : is described as the Numeric Part of PC Number. Can the entire :value be : : returned from the linkage state entry? : : : : Principles of Operation says: : : : :Numeric Part of PC Number: In a program-call : :state entry, bit positions 1-31 of bytes 148-151 contain : :the numeric part of the PC number used by the : :stacking PROGRAM CALL instruction that formed : :the entry. When ASN-and-LX reuse is not enabled, or : :when it is and bit 44 of the effective address used by : :stacking PROGRAM CALL is zero, stacking PROGRAM : :CALL places bits 44-63 of the effective : :address, with 11 zeros appended on the left, in bit : :positions 1-31 of bytes 148-151. When ASN-and-LX : :reuse is enabled and bit 44 of the effective address is : :one, stacking PROGRAM CALL places bits 45-63 of : :the effective address, with bits 32-43 of the effective : :address appended on the left, in bit positions 1-31 of : :bytes 148-151. In any case, stacking PROGRAM : :CALL places a zero in bit position 0 of the bytes if the : :resulting addressing mode is the 24-bit or 31-bit : :mode or a one in bit position 0 if the resulting : :addressing mode is the 64-bit mode. : :Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY : :-- :For IBM-MAIN subscribe / signoff / archive access instructions, :send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retireiving DCB information for migrated datasets
Hi It is a good question, as I wanted to give the library name, but I didn't find . Now I find in my source library , as far as I can remember , there was no MACRO , map in the time I wrote the MCDS program , I can send you if you need, but currently I can't find . On 30.07.2014 09:57, גדי בן אבי wrote: Hi, Where should I look for this macro? Gadi From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari [miklos.szigetv...@isis-papyrus.com] Sent: 30 July 2014 10:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Retireiving DCB information for migrated datasets Hi In the mcds (migration control dataset) you can find the DCB information, ARCMCD macro. On 30.07.2014 08:56, גדי בן אבי wrote: Hi, Is it possible to retreive DCB information (LRECL, BLKSIZE, RECFM, DSORG) for migrated datasets, without recalling the dataset? I looked in the record layouts for decollect, and couldn't find it. If it matters, the system is question is running OS/390 v2.8 Thanks Gadi לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retireiving DCB information for migrated datasets
Hi, If you can send it to me, it would be great. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari Sent: Wednesday, July 30, 2014 12:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Retireiving DCB information for migrated datasets Hi It is a good question, as I wanted to give the library name, but I didn't find . Now I find in my source library , as far as I can remember , there was no MACRO , map in the time I wrote the MCDS program , I can send you if you need, but currently I can't find . On 30.07.2014 09:57, גדי בן אבי wrote: Hi, Where should I look for this macro? Gadi From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari [miklos.szigetv...@isis-papyrus.com] Sent: 30 July 2014 10:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Retireiving DCB information for migrated datasets Hi In the mcds (migration control dataset) you can find the DCB information, ARCMCD macro. On 30.07.2014 08:56, גדי בן אבי wrote: Hi, Is it possible to retreive DCB information (LRECL, BLKSIZE, RECFM, DSORG) for migrated datasets, without recalling the dataset? I looked in the record layouts for decollect, and couldn't find it. If it matters, the system is question is running OS/390 v2.8 Thanks Gadi לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. - - 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 -- 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: New Survey - Please SHARE Your Experience!
Just a reminder about the MVS Survey that Cheryl sent out; it will be wrapping up Friday, so if you haven't taken it yet, we'd very much appreciate your input. https://www.surveymonkey.com/s/MR59B5Q If you're attending SHARE in Pittsburgh next week, please find me and introduce yourself. I'll be speaking on Monday at 11:15 in the MVSE Project Opening, room 406. Thanks! Mary Anne Matyaz MVS Core Technologies Project Manager, SHARE www.share.org/mvs On Wed, 2 Jul 2014 15:58:59 -0400, Cheryl Walker cwwalke...@gmail.com wrote: Sorry, folks, but I made an error about saving the survey. You can only return to the survey if it's sent to a specific email address. When you use the link below, you may only change results until you exit the survey. But if you've completed just a portion of the survey, you can start a new one and simply ignore the questions you've already answered. But to submit the 'page' you're working on, you must move to the next 'page'. == Cheryl Watson Watson Walker, Inc. www.watsonwalker.com cell text: 941-266-6609 == On Jul 2, 2014, at 10:53 AM, Cheryl Walker cwwalke...@gmail.com wrote: The SHARE MVS program is conducting a survey of System z hardware and z/OS software enhancements, and are requesting your help. The SHARE MVS Program community is providing this survey to gather information that will help in planning sessions and presentations for future conferences. Our intention is to determine which z/OS enhancements have been exploited by the MVS community, and which need additional training or support through SHARE conferences or other offerings. All of the questions are optional. The survey is set up so that you can save it and update or complete your answers later. The first section refers to System z hardware, and the second refers to System z software (primarily z/OS). The results of the survey will be made available to SHARE members after it's completed (August 1), and also presented at SHARE in Pittsburgh at session 15567: Exploiting z/OS - Tales From the MVS Survey (Friday at 9:30 am). Even if you aren't a member of SHARE, you can register to access the materials. This is a long survey and may require input from several people. There are four Pages - an introduction page, a Hardware section (about 7 pages if printed out), a Software section (about 7 pages if printed out), and a thank you page. We recommend that you print out the Hardware section and the Software section, use them to collect the information, and then enter the results all at once. You may save and return to the survey to resume it. We appreciate your time and effort! If you have any problems or questions, please contact che...@watsonwalker.com. Here is a link to the survey: https://www.surveymonkey.com/s/MR59B5Q Thanks for your participation! == Cheryl Watson Watson Walker, Inc. www.watsonwalker.com cell text: 941-266-6609 == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Retireiving DCB information for migrated datasets
Hi, do a listdsi (REXX by Gilbert Saint-Flour) against the migrated dataset in ispf 3.4, that should give you all the information needed. Christian -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von ??? ?? ??? Gesendet: Mittwoch, 30. Juli 2014 08:56 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Retireiving DCB information for migrated datasets Hi, Is it possible to retreive DCB information (LRECL, BLKSIZE, RECFM, DSORG) for migrated datasets, without recalling the dataset? I looked in the record layouts for decollect, and couldn't find it. If it matters, the system is question is running OS/390 v2.8 Thanks Gadi לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- 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: z/OS V2.1 and System Symobls and JCL
Yes, you're right - I have used my example for cases in which the variables CURRDATE and CURRTIME are substituted more than once. Thanks. On Wed, 30 Jul 2014 01:56:32 -0700, Walter Marguccio walter_marguc...@yahoo.com wrote: Hello again, Peter's sample would work coding: //H2PC EXEC PGM=FTP,PARM='(EXIT' //MYFILE�� DD DISP=SHR,DSN=MY.DATASET //OUTPUT�� DD SYSOUT=* //SYSIN��� DD *,SYMBOLS=EXECSYS mypc mypw put DD://MYFILE test.file.LYYMMDD..LHHMMSS..txt no EXPORT, no SET. The z/OS 2.1 Initialization and Tuning Reference claims DATE, LDATE, TIME and LTIME as old sysmbols. Maybe this is the reason why they do not get resolved when used in the JCL above. � Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- 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: Retrieving DCB information for migrated datasets
Subject text was corrected. Miklos Szigetvari wrote: It is a good question, as I wanted to give the library name, but I didn't find. Now I find in my source library , as far as I can remember , there was no MACRO , map in the time I wrote the MCDS program , I can send you if you need, but currently I can't find [ARCMCD macro]. Neither me. The name ARCMCD is new to me, but ARCMCDS (note extra character 'S') has other meaning in terms of HSM and GRS. From where did that program or macro obtain its information? From DCOLLECT or other HSM macros? However, I find that ISMF can also give [limited] DCB info for migrated dataset. Just curious. 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: IEAMSCHD question
The code must be addressable by the target address space. z/OS will not do this for you. Therefore, do _not_ try to schedule an SRB in a different address space which uses code in your private address space. You will likely get beat abruptly about the head and shoulders by your customers. Especially the sysprogs whose systems you (might) have crashed. On Tue, Jul 29, 2014 at 8:03 PM, Micheal Butz michealb...@comcast.net wrote: Hi Using this macro instead of schedule Does the SRB routine have to be in common or addressable by the target address space or does Z/OS take care of that 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 -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Retireiving DCB information for migrated datasets
Hi, apologies, I was wrong, listdsi does racall the dataset, sorry Christian -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Christian Birr Gesendet: Mittwoch, 30. Juli 2014 13:37 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: AW: Retireiving DCB information for migrated datasets Hi, do a listdsi (REXX by Gilbert Saint-Flour) against the migrated dataset in ispf 3.4, that should give you all the information needed. Christian -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von ??? ?? ??? Gesendet: Mittwoch, 30. Juli 2014 08:56 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Retireiving DCB information for migrated datasets Hi, Is it possible to retreive DCB information (LRECL, BLKSIZE, RECFM, DSORG) for migrated datasets, without recalling the dataset? I looked in the record layouts for decollect, and couldn't find it. If it matters, the system is question is running OS/390 v2.8 Thanks Gadi לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- 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: IEAMSCHD question
John McKown wrote: The code must be addressable by the target address space. z/OS will not do this for you. Therefore, do _not_ try to schedule an SRB in a different address space which uses code in your private address space. Interesting. Just curious, but where is that documented? You will likely get beat abruptly about the head and shoulders by your customers. Especially the sysprogs whose systems you (might) have crashed. If the OP survived that far... ;-D Survivers wil be promoted to pavement sweeping... 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: Beginners question about SHARE
For the record let me state that I am not badmouthing SHARE. I love this platform and I like SHARE because it is the best we've got. I'm not some bystander bashing SHARE: I have presented at half a dozen (?) SHAREs, exhibited at half a dozen (?) more, and I'm on the Security Project with Carla. My comments were constructive. I think SHARE would be better off with a little less of an old boys' club approach to attendance. (And Yes, old boys come in both genders.) That's my opinion. Anyone is free to have a different opinion, but that does not make my constructive suggestion badmouthing. SHARE is not a religion where any critical discussion equals sacrilege or blasphemy. Shmuel said maybe it's just the Web site. Well, yes, my first suggestion was: There should be a big banner on the Web site welcome to YOUR first SHARE. I didn't start this thread. If you think that newcomers having to ask on a forum how the heck do I go to my first SHARE? is satisfactory, then I guess all is well with how SHARE does things today. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SNA Sense code 0824089E
Hi, All, Anybody have a clue what SNA sense code 0824089E is trying to tell me? The manual (z/OS 1.13) only covers 0824 and 08240001. All we know for certain is that a CICS LU6.2 session had a remote program abend, and no dump was produced. Message: DFHAC2261 System sysid sent message (sense code 0824089E). 'DFHAC2206 time of day remote appl id Transaction tran id failed with abend abend code. Updates to local recoverable resources backed out.' TIA, -jc- ** 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: IEAMSCHD question
Elardus You are right on target with your comment the examples show A adcon used for the pointer to the SRB routine though most the examples are for SRB s in the same Address space, I refer to example 4 which is for another address Space i.e the targetstoken parm Is used and epaddr is pointed to by a Adcon as well Very misleading Sent from my iPhone On Jul 30, 2014, at 8:02 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: John McKown wrote: The code must be addressable by the target address space. z/OS will not do this for you. Therefore, do _not_ try to schedule an SRB in a different address space which uses code in your private address space. Interesting. Just curious, but where is that documented? You will likely get beat abruptly about the head and shoulders by your customers. Especially the sysprogs whose systems you (might) have crashed. If the OP survived that far... ;-D Survivers wil be promoted to pavement sweeping... 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beginners question about SHARE
For a trip down memory lane from 11 years ago and multiple SHARE conferences since then , GOOGLE: Confessions of a first-time SHARE attendee Your comments about the website have some merit, especially for a first timer. I like your banner idea a lot. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, July 30, 2014 8:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Beginners question about SHARE For the record let me state that I am not badmouthing SHARE. I love this platform and I like SHARE because it is the best we've got. I'm not some bystander bashing SHARE: I have presented at half a dozen (?) SHAREs, exhibited at half a dozen (?) more, and I'm on the Security Project with Carla. My comments were constructive. I think SHARE would be better off with a little less of an old boys' club approach to attendance. (And Yes, old boys come in both genders.) That's my opinion. Anyone is free to have a different opinion, but that does not make my constructive suggestion badmouthing. SHARE is not a religion where any critical discussion equals sacrilege or blasphemy. Shmuel said maybe it's just the Web site. Well, yes, my first suggestion was: There should be a big banner on the Web site welcome to YOUR first SHARE. I didn't start this thread. If you think that newcomers having to ask on a forum how the heck do I go to my first SHARE? is satisfactory, then I guess all is well with how SHARE does things today. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT JCL
Ron, I am not sure how you can compare the results of SORT FIELDS=(1,4,CH,A,26,9,CH,A),EQUALS with SORT FIELDS=(26,9,CH,A,71,4,BI,A),EQUALS. In the first case you are sorting on the ASIS first followed by the field at position 26 and in the second case you are sorting on the contents at position 26 first and then followed by the equivalent value of ASIS which is now in binary format. Assuming your character data in position 1 thru 4 is now presented in position 71 thru 74 but now in binary format, you need to use the following control cards SORT FIELDS=(71,4,BI,A,26,9,CH,A),EQUALS Which will give you the desired results 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 07/29/2014 09:15:04 PM: From: Ron Thomas ron5...@gmail.com To: IBM-MAIN@listserv.ua.edu Date: 07/29/2014 09:15 PM Subject: Re: SORT JCL Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Thanks Kolusu. Here is the sort card i used SORT FIELDS=(1, 4,CH,A,26,9,CH,A),EQUALS which is in the ASIS case where in the modified sort card SORT FIELDS=(26,9,CH,A,71,4,BI,A),EQUALS. The issue is data in the ASIS the 1-4 bytes is same as in the TOBE the only change is the data is in binary. Now when we does the sort the sequence number get disturbed . Please let me know where the issue is ? 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: IEAMSCHD question
On Wed, Jul 30, 2014 at 7:02 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: John McKown wrote: The code must be addressable by the target address space. z/OS will not do this for you. Therefore, do _not_ try to schedule an SRB in a different address space which uses code in your private address space. Interesting. Just curious, but where is that documented? Which? That the code needs to be addressable by the target address space? Or that it will not cause it to be addressable? I find it interesting that this information is not where I expected. But I did find this: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a2b0/35.1.17 quote Note that in this example, the SRB routine is running in a different address space from the scheduling code. To run an SRB routine in a different address space from the scheduling code, the SRB routine must be either in a different program that is accessible from the target address space, or in the common storage together with the scheduling code. /quote I guess that I just ASSuMEd that z/OS did not try to copy something into the target address space. Seems most unlikely to me. But the above certainly _implies_ that it is the responsibility of the issuer of the SCHEDULE to make sure that the routine is addressable in the target address space. You will likely get beat abruptly about the head and shoulders by your customers. Especially the sysprogs whose systems you (might) have crashed. If the OP survived that far... ;-D Survivers wil be promoted to pavement sweeping... Groete / Greetings Elardus Engelbrecht -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SNA Sense code 0824089E
Frome the NetView SENSE command NLDM.SENSSENSE CODE DESCRIPTION PAGE1 -- SENSE DATA: CATEGORY - (08) Logical unit of work abnormally terminated: The current MODIFIER - (24) unit of work has been abnormally terminated; when sync BYTE 2 - (08) point protocols are in use, both sync point managers are BYTE 3 - (9E) to revert to the previously committed sync point. Bytes 2 and 3 following the sense code contain sense-code-specific information. It doesn't say so, but I wonder if 089E is the SNA sequence number for the most recent message related to the SYNC point. Look up the STSN SNA command and TH sequence number. 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 Chase, John Sent: 30 July 2014 13:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: SNA Sense code 0824089E Hi, All, Anybody have a clue what SNA sense code 0824089E is trying to tell me? The manual (z/OS 1.13) only covers 0824 and 08240001. All we know for certain is that a CICS LU6.2 session had a remote program abend, and no dump was produced. Message: DFHAC2261 System sysid sent message (sense code 0824089E). 'DFHAC2206 time of day remote appl id Transaction tran id failed with abend abend code. Updates to local recoverable resources backed out.' TIA, -jc- ** 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 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 by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SNA Sense code 0824089E
Hi John, did you GOOGLE for that sensecode? One hit will be http://www-01.ibm.com/support/docview.wss?uid=swg21037540 Problem(Abstract) You have a CICS transaction that is shipped from a terminal owning region (TOR) to an application owning region (AOR). The transaction returns reporting an abend AZI6 with sense code 0824 089E. You are trying to determine the meaning of the sense code. Cause The remote transaction abended and passed back information in the sense code. Resolving the problem Look at the first two bytes separately from the second two bytes: The first two byes are the system sense code which are documented by VTAM. A x'0824' means that the Logical Unit Of Work has been aborted. The second two bytes are the user sense code. The remote CICS occasionally will put the message number being generated at the time of the error in these two bytes. Sometimes this message number is in decimal, such as 3426. At other times it is in hexadecimal, as it is here. Hex 089E is decimal 2206. The 2206 is from message DFHAC2206 indicating the transaction failed with abend AZI6. This is passed on to the terminal to let the end user know that the remote task has abended. Product Alias/Synonym CICS/TS CICS TS CICS Transaction Server there are some more ... maybe that helps you reghards Juergen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEAMSCHD question
John McKown wrote: Interesting. Just curious, but where is that documented? Which? All of your comments, but your explanation is enough for me. Just like you, I also found the info in another [unexpected] book. This is why I asked. Thanks for providing the answer. Much appreciated. Micheal Butz wrote: A adcon used for the pointer to the SRB routine though most the examples are for SRB s in the same Address space, I refer to example 4 which is for another address Space i.e the targetstoken parm Is used and epaddr is pointed to by a Adcon as well Very misleading Indeed, especially the line 'The invoker of IEAMSCHD will be suspended ...' as pointed by John is scary enough. Thanks for your comment. Your posts were interesting. I learned something new. But the above certainly _implies_ that it is the responsibility of the issuer of the SCHEDULE to make sure that the routine is addressable in the target address space. Another responsibility: these fields are to be properly initialized. This is not for the faint hearted programmers... 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: SNA Sense code 0824089E
Here's what QuickRef displays: Sense code 089E Identified data object already exists. Bytes 2 and 3 following the sense code contain sense-code-specific information. 0001 A request to create a new data object has failed because the identified data-object already exists at the target node. 0002 A request to replace a data object has failed because it specifies a to-be-deleted data object different from the to-be-stored data object; however, the to-be-stored data object already exists. *George Rodriguez* *Specialist II - IT Solutions* *IT Enterprise Applications* *PX - 47652* *(561) 357-7652 (office)* *(561) 707-3496 (mobile)* *School District of Palm Beach County* *3348 Forest Hill Blvd.* *Room B-251* *West Palm Beach, FL. 33406-5869* *Florida's Only A-Rated Urban District For Eight Consecutive Years* On Wed, Jul 30, 2014 at 8:41 AM, Juergen Keller keller-ibmm...@web.de wrote: Hi John, did you GOOGLE for that sensecode? One hit will be http://www-01.ibm.com/support/docview.wss?uid=swg21037540 Problem(Abstract) You have a CICS transaction that is shipped from a terminal owning region (TOR) to an application owning region (AOR). The transaction returns reporting an abend AZI6 with sense code 0824 089E. You are trying to determine the meaning of the sense code. Cause The remote transaction abended and passed back information in the sense code. Resolving the problem Look at the first two bytes separately from the second two bytes: The first two byes are the system sense code which are documented by VTAM. A x'0824' means that the Logical Unit Of Work has been aborted. The second two bytes are the user sense code. The remote CICS occasionally will put the message number being generated at the time of the error in these two bytes. Sometimes this message number is in decimal, such as 3426. At other times it is in hexadecimal, as it is here. Hex 089E is decimal 2206. The 2206 is from message DFHAC2206 indicating the transaction failed with abend AZI6. This is passed on to the terminal to let the end user know that the remote task has abended. Product Alias/Synonym CICS/TS CICS TS CICS Transaction Server there are some more ... maybe that helps you reghards Juergen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The *Summer Learning Inspirations http://www.palmbeachschools.org/Students/SummerLearning.asp* website offers ideas and suggestions for parents and students to sustain learning throughout the summer. * Follow us on * [image: Facebook] http://www.palmbeachschools.org/links/facebook.html[image: Twitter] http://www.palmbeachschools.org/links/twitter.html *Disclaimer: *Under Florida law, e-mail addresses are public records. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beginners question about SHARE
Ed Jaffe wrote: Hopefully, Shmuel's reference was to Ed Gould and not Ed Finnell, Ed Long or gulp Ed Jaffe... LOL! I'm having an identity crisis! How many 'Ed' and 'John' are on this IBM-MAIN discussion list? Possible estimate: perhaps in the range of of x'' (unsigned)? :-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT JCL
i have done the same , that too also when we do compare the 2 o/p files there is order difference comming. 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: SAVING FORWARDING POSTS FROM IBM ARCHVIE
John, IBM main topics can be found via google groups at https://groups.google.com/forum/#!forum/bit.listserv.ibm-main This also offers a wide variety of search options. For example if I want to list all the topics that contains john dawes in bit.listserv.ibm-main then you can have it https://groups.google.com/forum/#!topicsearchin/bit.listserv.ibm-main/john$20dawes Scrolling down I was able to browse the topics all the way to May 2nd of 2006 like this one https://groups.google.com/forum/#!topicsearchin/bit.listserv.ibm-main/john$20dawes/bit.listserv.ibm-main/jPFMgP6nAFU Thanks, Kolusu IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 07/28/2014 09:13:23 AM: From: John Dawes jhn_da...@yahoo.com.au To: IBM-MAIN@listserv.ua.edu Date: 07/28/2014 09:14 AM Subject: SAVING FORWARDING POSTS FROM IBM ARCHVIE Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu G'Day, Is there a way of saving (in my YAhoo email INBOX) and forwarding posts to my colleagues while browsing the ARCHIVES? 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
Ron, What are the DCB properties of the input file? Can you show us a sample of input data ? Does the new data in binary format contain negative numbers? Thanks, Kolusu IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 07/30/2014 06:11:23 AM: From: Ron Thomas ron5...@gmail.com To: IBM-MAIN@listserv.ua.edu Date: 07/30/2014 06:12 AM Subject: Re: SORT JCL Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu i have done the same , that too also when we do compare the 2 o/p files there is order difference comming. 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: SNA Sense code 0824089E
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Juergen Keller Hi John, did you GOOGLE for that sensecode? Uh, no; I'm not that smart yet. :-) One hit will be http://www-01.ibm.com/support/docview.wss?uid=swg21037540 Problem(Abstract) You have a CICS transaction that is shipped from a terminal owning region (TOR) to an application owning region (AOR). The transaction returns reporting an abend AZI6 with sense code 0824 089E. You are trying to determine the meaning of the sense code. Cause The remote transaction abended and passed back information in the sense code. Resolving the problem Look at the first two bytes separately from the second two bytes: The first two byes are the system sense code which are documented by VTAM. A x'0824' means that the Logical Unit Of Work has been aborted. The second two bytes are the user sense code. The remote CICS occasionally will put the message number being generated at the time of the error in these two bytes. Sometimes this message number is in decimal, such as 3426. At other times it is in hexadecimal, as it is here. Hex 089E is decimal 2206. The 2206 is from message DFHAC2206 indicating the transaction failed with abend AZI6. This is passed on to the terminal to let the end user know that the remote task has abended. Product Alias/Synonym CICS/TS CICS TS CICS Transaction Server there are some more ... Thanks kindly. That is precisely what I was wanting to know. It would be nice of CICS to document that in the explanation for message DFHAC2261. -jc- ** 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: z/OS V2.1 and System Symobls and JCL
On Tue, 29 Jul 2014 21:27:36 -0500, Peter X. DeFabritus wrote: // SET CURRDATE=LYR4LMONLDAY // SET CURRTIME=LHRLMINLSEC In: Defining and nullifying JCL symbols z/OS MVS JCL Reference SA23-1385-00 http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.ieab600/jdefine.htm I read: o Do not specify JCL symbols within other JCL symbols. The results can be unpredictable, especially if the imbedded JCL symbol is not previously defined. Is your suggestion in violation of this, or does the restriction not apply to use of system symbols or PROC parameters within JCL symbols? Does within apply to the assigned value or to the name? I have tried both constructs with no reported syntax error. I much prefer a reported syntax error to results can be unpredictable, but an IBM employee has averred here that many undocumented constructs are reserved for use within IBM and can not be reported as syntax errors. Here, and in some other cases in JCL, particularly the IF statement, I'm skeptical and find indolence on the part of JCL developers a more plausible explanation. -- gil -- 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, The DCB parameter is same FB 80 bytes LRECL. Here is the sortout data comming in both the cases 6558140714150557LAPOELA 641547059W...DF00WCOH56 .. DCDDCDC44FE000300030044CCFFECDCFF4001900 65581407141505573176531006415470596000D005C000C008C4600636856C009E00 -- 6558140714163020LAPOELA 642065239WDT00WCOH52 .. DCDDCDC44FE000100290010CEFFECDCFF4001900 65581407141630203176531006420652396000D002C000C045C4300636852C009E00 -- 6558140714150636LAPOELA 642191799W...*DF00WCOH56 .. DCDDCDC44FE000100050068CCFFECDCFF4001900 65581407141506363176531006421917996000D005C000C004C4600636856C009E00 -- 6558140714152553LAHOXTE 642391539W...*VR729515WW73583.. DCCDEEC44FE000100050002EDFFEEF0002001900 65581407141525533186735006423915396000D000C000C017C597295156673583017C009E00 -- 6558140714150626LAPOELA 642473069W...@...DF00WCOH56 .. DCDDCDC44FE000200070058CCFFECDCFF4001900 65581407141506263176531006424730696000D002C000C000C4600636856C009E00 Below one is with the modified sort card where the same data is in 71'th 4 byte binary data 6558140714150557LAPOELA 641547059W...DF00WCOH56 .. DCDDCDC44FE000300030044CCFFECDCFF4001900 65581407141505573176531006415470596000D005C000C008C4600636856C009E00 -- 6558140713175118BWGILBE 641547059W...DF00WCOH56 .. CECCDCC44FE000200090044CCFFECDCFF4001900 65581407131751182679325006415470596000D006C000C008C4600636856C009E00 -- 6558140714163020LAPOELA 642065239WDT00WCOH52 .. DCDDCDC44FE000100290010CEFFECDCFF4001900 65581407141630203176531006420652396000D002C000C045C4300636852C009E00 -- 6558140714150636LAPOELA 642191799W...*DF00WCOH56 .. DCDDCDC44FE000100050068CCFFECDCFF4001900 65581407141506363176531006421917996000D005C000C004C4600636856C009E00 Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
I SMF Processing
Hi, We have six MAN datasets spread across three volumes; I notice that the ‘I SMF’ command switches between only the first and second MAN datasets. Is there any doc, explaining how SMF processes the MAN datasets? On our two production systems a ‘Z EOD’ command is issued when the system comes down for an IPL, when will SMF write to MAN3, 4, etc.? On our systems programming LPAR, where no ‘Z EOD’ is issued, I do see SMF writing to MAN datasets beyond MAN2, when the system is IPL’d. Thanks, Dean Dean Montevago (212) 460 – 4943 (work) (516) 710 – 5341 (cell) monteva...@coned.com 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: SORT JCL
Ron, Are you sure you are running the 2 sorts with the SAME INPUT Files? The first sort has +1+2+3+4+ 6558 641547059W But the output from the 2nd sort has 2 records for the same key combination. +1+2+3+ 6558 641547059W 6558 641547059W so how did you get 2 records for 1 sort and just 1 record for 1 sort? Thanks, Kolusu IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 07/30/2014 07:44:03 AM: From: Ron Thomas ron5...@gmail.com To: IBM-MAIN@listserv.ua.edu Date: 07/30/2014 07:45 AM Subject: Re: SORT JCL Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Kolusu, The DCB parameter is same FB 80 bytes LRECL. Here is the sortout data comming in both the cases 6558140714150557LAPOELA 641547059W...DF00WCOH56 .. DCDDCDC44FE000300030044CCFFECDCFF4001900 65581407141505573176531006415470596000D005C000C008C4600636856C009E00 -- 6558140714163020LAPOELA 642065239WDT00WCOH52 .. DCDDCDC44FE000100290010CEFFECDCFF4001900 65581407141630203176531006420652396000D002C000C045C4300636852C009E00 -- 6558140714150636LAPOELA 642191799W...*DF00WCOH56 .. DCDDCDC44FE000100050068CCFFECDCFF4001900 65581407141506363176531006421917996000D005C000C004C4600636856C009E00 -- 6558140714152553LAHOXTE 642391539W...*VR729515WW73583.. DCCDEEC44FE000100050002EDFFEEF0002001900 65581407141525533186735006423915396000D000C000C017C597295156673583017C009E00 -- 6558140714150626LAPOELA 642473069W...@...DF00WCOH56 .. DCDDCDC44FE000200070058CCFFECDCFF4001900 65581407141506263176531006424730696000D002C000C000C4600636856C009E00 Below one is with the modified sort card where the same data is in 71'th 4 byte binary data 6558140714150557LAPOELA 641547059W...DF00WCOH56 .. DCDDCDC44FE000300030044CCFFECDCFF4001900 65581407141505573176531006415470596000D005C000C008C4600636856C009E00 -- 6558140713175118BWGILBE 641547059W...DF00WCOH56 .. CECCDCC44FE000200090044CCFFECDCFF4001900 65581407131751182679325006415470596000D006C000C008C4600636856C009E00 -- 6558140714163020LAPOELA 642065239WDT00WCOH52 .. DCDDCDC44FE000100290010CEFFECDCFF4001900 65581407141630203176531006420652396000D002C000C045C4300636852C009E00 -- 6558140714150636LAPOELA 642191799W...*DF00WCOH56 .. DCDDCDC44FE000100050068CCFFECDCFF4001900 65581407141506363176531006421917996000D005C000C004C4600636856C009E00 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: z/OS physical memory usage with multiple copies of same load module at different virtual addresses
I think that z/OS and its immediate predecessors already make most of what is needed available. Only in special circumstances do I see or, if I see them, read Shmuel's posts; but I found one---It is one of his characteristic Nonsense! posts---in this thread. It was directed at an earlier post of mine, and it is therefore a convenient starting point for discussion. My comment that elicited his Nonsense! response suggested very briefly that the device of making and marking a load module or program object reentrant or, better, refreshable could be used to share code across LPAR boundaries. His response was that things do not work that way. If he had instead written that they do not always work that way, I should have passed over his post silently, as banal but correct and certainly inoffensive; but he elected to go for the jugular even though, as he must know, his knife-fighting skills are now much diminished. For many years, since OS/390 V4, I have used a scheme that adds sets of refreshable modules to the LPA dynamically in order to share them among several LPARs. It has always worked well; it continues to work under z/OS 2.1 as it has worked in the past; and the facilities of CSVQUERY remain available for ensuring that a dynamic LPA addition has succeeded. Multiple resident copies of an excecutable can sometimes be highly problematic. From perhaps 20 years ago I recall a situation in which an intellectually challenged client programmer had replaced an old, very simple but heavily used assembly-language data-vetting AP used under CICS with one of his own devising written in RPG, which could not then be made even quasi-reentrant under CICS, with truly disastrous results. Such problems are ordinarily easy to remedy individually when, for whatever reason, they occur; and when they do occur they cannot be ignored. That said, Timothy Sipples is clearly right in general: The use of significant system-software resources to identify and share bit-equivalent pages, even big ones, dynamically is not likely to pay for itself in a z/OS environment. The major optimizations are already in place. The z/OS ASM does not, for example, page out unaltered pages after doing so once initially; and it is able to make this distinction efficiently because there is hardware support for distinguishing altered/stored-into pages from unaltered ones. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I SMF Processing
#1. Read MVS System Management Facilities manual, it tells you how to run the programs that Dump the MAN data sets #2. Issue the MVS command, D SMF this will tell you which data sets are in ACTIVE, ALTERNATE, or DUMP REQUIRED, the data sets in DUMP REQUIRED status will not be used until the data is dumped and cleared from it, this Is done using one of the programs documented in #1 above to clear out the data set and change it from DUMP REQUIRED to ALTERNATE. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dno Sent: Wednesday, July 30, 2014 11:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: I SMF Processing Hi, We have six MAN datasets spread across three volumes; I notice that the ‘I SMF’ command switches between only the first and second MAN datasets. Is there any doc, explaining how SMF processes the MAN datasets? On our two production systems a ‘Z EOD’ command is issued when the system comes down for an IPL, when will SMF write to MAN3, 4, etc.? On our systems programming LPAR, where no ‘Z EOD’ is issued, I do see SMF writing to MAN datasets beyond MAN2, when the system is IPL’d. Thanks, Dean Dean Montevago (212) 460 – 4943 (work) (516) 710 – 5341 (cell) monteva...@coned.com 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I SMF Processing
I would look in the SMF manual. The current version for z/OS 2.1 is SA38-0667-02 Without looking it up: The system will attempt to write to SYS1.MAN1 (as specified in SMFPRM00). If SYS1.MAN1 is not available (full or otherwise), SYS1.MAN2-n are used in sequence, If SYS1.MAN1 is made available while SYS1.MAN2-n are in use, the system will return to SYS1.MAN1 at the next SMF switch. ZEOD writes the current set of SMF buffers and closes the current MANx. If ZEOD is not issued, SMF will resume writing to the current MANx dataset (be it 2 , 3, 9, 10 or whatever) until full and then will behave as described above. HTH, snip We have six MAN datasets spread across three volumes; I notice that the ‘I SMF’ command switches between only the first and second MAN datasets. Is there any doc, explaining how SMF processes the MAN datasets? On our two production systems a ‘Z EOD’ command is issued when the system comes down for an IPL, when will SMF write to MAN3, 4, etc.? On our systems programming LPAR, where no ‘Z EOD’ is issued, I do see SMF writing to MAN datasets beyond MAN2, when the system is IPL’d. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I SMF Processing
Dean Montevago wrote: We have six MAN datasets spread across three volumes; I notice that the ‘I SMF’ command switches between only the first and second MAN datasets. Is there any doc, explaining how SMF processes the MAN datasets? Yes. Look in 'MVS System Management Facilities'. quote When the SMF data set that is currently being recording on becomes full, SMF does the following: - Automatically closes the full data set, making it available for dumping. - Locates the new data set to open by starting at the top of the list of data sets specified on the DSNAME parameter of the SMFPRMxx member and looking for the first completely empty data set. end quote On our two production systems a ‘Z EOD’ command is issued when the system comes down for an IPL, when will SMF write to MAN3, 4, etc.? When the first two datasets are full or you do a 'I SMF' and switch FROM those first two datasets. That happens anytime, not only when 'Z EOD' is issued. On our systems programming LPAR, where no ‘Z EOD’ is issued, I do see SMF writing to MAN datasets beyond MAN2, when the system is IPL’d. This is WAD. What problem are you trying to resolve? 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: I SMF Processing
Thanks. I will check again, I missed this. The reusing of MAN1, is what I needed clarification on. Sent from my iPhone On Jul 30, 2014, at 11:14 AM, Staller, Allan allan.stal...@kbmg.com wrote: I would look in the SMF manual. The current version for z/OS 2.1 is SA38-0667-02 Without looking it up: The system will attempt to write to SYS1.MAN1 (as specified in SMFPRM00). If SYS1.MAN1 is not available (full or otherwise), SYS1.MAN2-n are used in sequence, If SYS1.MAN1 is made available while SYS1.MAN2-n are in use, the system will return to SYS1.MAN1 at the next SMF switch. ZEOD writes the current set of SMF buffers and closes the current MANx. If ZEOD is not issued, SMF will resume writing to the current MANx dataset (be it 2 , 3, 9, 10 or whatever) until full and then will behave as described above. HTH, snip We have six MAN datasets spread across three volumes; I notice that the ‘I SMF’ command switches between only the first and second MAN datasets. Is there any doc, explaining how SMF processes the MAN datasets? On our two production systems a ‘Z EOD’ command is issued when the system comes down for an IPL, when will SMF write to MAN3, 4, etc.? On our systems programming LPAR, where no ‘Z EOD’ is issued, I do see SMF writing to MAN datasets beyond MAN2, when the system is IPL’d. /snip -- 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: Retireiving DCB information for migrated datasets
On 30/07/2014 4:56 PM, גדי בן אבי wrote: Is it possible to retreive DCB information (LRECL, BLKSIZE, RECFM, DSORG) for migrated datasets, without recalling the dataset? Check out the $HMLIST command in CBT file 134. It reads the MCDS directly. Output can go to the terminal or a data set. Cheers, Greg -- 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. See the below , the number of records is same in both the cases , only the sequence is the issue Old one 6558140713175118BWGILBE 641547059W...DF00WCOH56 .. 6558140714150557LAPOELA 641547059W...DF00WCOH56 .. 6558140714163020LAPOELA 642065239WDT00WCOH52 .. 6558140714150636LAPOELA 642191799W...*DF00WCOH56 .. New One 6558140714150557LAPOELA 641547059W...DF00WCOH56 .. 6558140713175118BWGILBE 641547059W...DF00WCOH56 .. 6558140714163020LAPOELA 642065239WDT00WCOH52 .. 6558140714150636LAPOELA 642191799W...*DF00WCOH56 .. 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
Ron, If the order of the records is different , then it probably has to do with EQUALS parm. Can you please confirm the following. 1. Are you using the same input for both jobs? 2. Do you have EQUALS parm on both jobs? Please add the following to your jobs so I can see the diagnostic mesages: //SORTDIAG DD DUMMY Then rerun both jobs and send the complete JES log including the //SYSOUT messages to dfs...@us.ibm.com Thanks, Kolusu 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 07/30/2014 08:42:14 AM: From: Ron Thomas ron5...@gmail.com To: IBM-MAIN@listserv.ua.edu Date: 07/30/2014 08:42 AM Subject: Re: SORT JCL Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Kolusu. See the below , the number of records is same in both the cases , only the sequence is the issue Old one 6558140713175118BWGILBE 641547059W...DF00WCOH56 .. 6558140714150557LAPOELA 641547059W...DF00WCOH56 .. 6558140714163020LAPOELA 642065239WDT00WCOH52 .. 6558140714150636LAPOELA 642191799W...*DF00WCOH56 .. New One 6558140714150557LAPOELA 641547059W...DF00WCOH56 .. 6558140713175118BWGILBE 641547059W...DF00WCOH56 .. 6558140714163020LAPOELA 642065239WDT00WCOH52 .. 6558140714150636LAPOELA 642191799W...*DF00WCOH56 .. 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
AW: Retireiving DCB information for migrated datasets
Hi Greg, I remembered you piece of code this afternoon, too. Due to some 'important' meetings I just came to assemble it, put in the TSO command table and tried it in one of my sandboxes. It came back with an RC of 4, contact your system support, which is mainly me and myself. I haven't the time to inspect the code more deeply, but could it be, there's a mismatch between you home grown MCD DSECT and the current one? The listing of the DESCT is right beside me and I'll look into it tomorrow, or might it be an error on my side? Greetings from lower Bavaria Christian -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Greg Price Gesendet: Mittwoch, 30. Juli 2014 17:27 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: Retireiving DCB information for migrated datasets On 30/07/2014 4:56 PM, גדי בן אבי wrote: Is it possible to retreive DCB information (LRECL, BLKSIZE, RECFM, DSORG) for migrated datasets, without recalling the dataset? Check out the $HMLIST command in CBT file 134. It reads the MCDS directly. Output can go to the terminal or a data set. Cheers, Greg -- 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: z/OS V2.1 and System Symobls and JCL
Most excellent! I wondered if such a thing existed, but I had not heard of it nor could I find it. From: Peter X. DeFabritus pxdef...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, July 29, 2014 8:27 PM Subject: Re: z/OS V2.1 and System Symobls and JCL I haven't had a chance to respond to this thread, but here is a much simpler way involving no programming: // EXPORT SYMLIST=* // SET CURRDATE=LYR4LMONLDAY // SET CURRTIME=LHRLMINLSEC //TRANSMIT EXEC PGM=FTP //SYSPRINT DD SYSOUT=* //SYSIN DD *,SYMBOLS=JCLONLY put DD://MYFILE test.file.CURRDATE..CURRTIME..txt The symbols beginning with L are system symbols, specified in the z/OS 2.1 Initialization and Tuning Reference. On Tue, 29 Jul 2014 16:10:00 -0700, Frank Swarbrick frank.swarbr...@yahoo.com wrote: I don't have a z/OS 2.1 system to test this on, but the following seems workable to me: //FTPTEST� JOB //SETDATE� EXEC PGM=SETTSSYM,PARM='CURRDATE=MMDD'� CURRDATE WILL BE SET TO THE CURRENT DATE //SETTIME� EXEC PGM=SETTSSYM,PARM='CURRTIME=HHMMSS'��� CURRTIME WILL BE SET TO THE CURRENT TIME //TRANSMIT EXEC PGM=FTP //SYSIN��� DD *,SYMBOLS=JCLONLY put DD://MYFILE test.file.CURRDATE..CURRTIME..txt /* SETTSSYM (Set Timestamp Symbol) would be a program that uses the IAZSYMBL service to set the symbol(s?) named in the parm to the date and/or time. Given a system time of 23:42:59 the SYSIN line would be converted to: put DD://MYFILE test.file.20140729.234959.txt If that works that's pretty cool! Now we just need to get to 2.1 (we're at 1.12 with only 1.13 coming soon! :-( ) Someone out there can feel free to work on this SETTSSYM program and release it to the general public!� :-) Frank Swarbrick FirstBank Lakewood, CO� USA From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, July 29, 2014 7:42 AM Subject: z/OS V2.1 and System Symobls and JCL I just noticed the following changes in JCL for System Symbols in V2.1 A number of enhancements in the symbol processing have been implemented in z/OS V2R1 to provide long sought after flexibility in the described areas. They include: ��� . Exporting JCL symbols-A new JCL statement EXPORT has been added, that defines a list of JCL symbols that should be made available to the application at execution time. A subsequent SET statement, and only SET statement, will assign values to the exported symbols and will pass necessary control information to the job execution phase. (Note that the order of EXPORT statement and corresponding SET statements is important.) The scope of a value of the exported symbol is all job steps starting from the location of the SET statement, so each step of the same job can have different values for the same symbol if necessary. For an application to programmatically access the JCL symbols exported in this way, it should use a new API-JCL Symbol Service IEFSJSYM. ��� . In-stream symbol substitution-V2R1 now allows symbol substitution in the records of the in-stream data sets, including those used in catalogued JCL procedures. Substitution of symbols in the in-stream data is performed at execution time-more precisely, at the moment when an application reads a record from the in-stream data set. To allow symbols to be used in the in-stream data, two things must be done: 1. Relevant EXPORT and SET JCL statements must be added to allow required symbols to be visible during execution time. 2. New keyword SYMBOLS must be added to the DD statement that defines the in-stream dataset. By default, there is no change in behavior compared to the prior releases and no substitution is performed. Several types of symbols can be substituted by this new function: ��� o JCL symbols made available via EXPORT function ��� ��� o System symbols, such as SYSNAME. Note that V2R1 now allows using system symbols from a conversion system in JCL - something that was not allowed in prior releases. ��� ��� o New JES symbols which will be explained later The SYMBOLS keyword controls which symbols will be substituted: ��� ��� o SYMBOLS=JCLONLY causes substitution of all symbols except for system symbols ��� ��� o SYMBOLS=EXECSYS causes substitution of all symbols including system symbols. System symbols are taken from the system the job is running on. ��� ��� o SYMBOLS=CNVTSYS is the same as SYMBOLS=EXECSYS except for the origin of system symbols-they are taken from the system where the job had been converted. This makes in-stream system symbols consistent with symbol substitution performed during conversion. During an in-stream symbol substitution, an attempt is made to preserve the alignment of all non-blank character sequences (tokens) in the record. If necessary, blanks are added or removed between non-blank tokens (at least one blank is
Re: z/OS V2.1 and System Symobls and JCL
FWIW, if anyone is interested in integrating batch jobs containing z/OS Unix shell scripts with z/OS 2.1 JES Symbols, search the archives for the thread: Want your feedback on shell command interface to V2R1 IAZSYMBL Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Jul 30, 2014 at 10:55 AM, Frank Swarbrick 002782105f5c-dmarc-requ...@listserv.ua.edu wrote: Most excellent! I wondered if such a thing existed, but I had not heard of it nor could I find it. From: Peter X. DeFabritus pxdef...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, July 29, 2014 8:27 PM Subject: Re: z/OS V2.1 and System Symobls and JCL I haven't had a chance to respond to this thread, but here is a much simpler way involving no programming: // EXPORT SYMLIST=* // SET CURRDATE=LYR4LMONLDAY // SET CURRTIME=LHRLMINLSEC //TRANSMIT EXEC PGM=FTP //SYSPRINT DD SYSOUT=* //SYSINDD *,SYMBOLS=JCLONLY put DD://MYFILE test.file.CURRDATE..CURRTIME..txt The symbols beginning with L are system symbols, specified in the z/OS 2.1 Initialization and Tuning Reference. On Tue, 29 Jul 2014 16:10:00 -0700, Frank Swarbrick frank.swarbr...@yahoo.com wrote: I don't have a z/OS 2.1 system to test this on, but the following seems workable to me: //FTPTEST� JOB //SETDATE� EXEC PGM=SETTSSYM,PARM='CURRDATE=MMDD'� CURRDATE WILL BE SET TO THE CURRENT DATE //SETTIME� EXEC PGM=SETTSSYM,PARM='CURRTIME=HHMMSS'��� CURRTIME WILL BE SET TO THE CURRENT TIME //TRANSMIT EXEC PGM=FTP //SYSIN��� DD *,SYMBOLS=JCLONLY put DD://MYFILE test.file.CURRDATE..CURRTIME..txt /* SETTSSYM (Set Timestamp Symbol) would be a program that uses the IAZSYMBL service to set the symbol(s?) named in the parm to the date and/or time. Given a system time of 23:42:59 the SYSIN line would be converted to: put DD://MYFILE test.file.20140729.234959.txt If that works that's pretty cool! Now we just need to get to 2.1 (we're at 1.12 with only 1.13 coming soon! :-( ) Someone out there can feel free to work on this SETTSSYM program and release it to the general public!� :-) Frank Swarbrick FirstBank Lakewood, CO� USA From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, July 29, 2014 7:42 AM Subject: z/OS V2.1 and System Symobls and JCL I just noticed the following changes in JCL for System Symbols in V2.1 A number of enhancements in the symbol processing have been implemented in z/OS V2R1 to provide long sought after flexibility in the described areas. They include: ��� . Exporting JCL symbols-A new JCL statement EXPORT has been added, that defines a list of JCL symbols that should be made available to the application at execution time. A subsequent SET statement, and only SET statement, will assign values to the exported symbols and will pass necessary control information to the job execution phase. (Note that the order of EXPORT statement and corresponding SET statements is important.) The scope of a value of the exported symbol is all job steps starting from the location of the SET statement, so each step of the same job can have different values for the same symbol if necessary. For an application to programmatically access the JCL symbols exported in this way, it should use a new API-JCL Symbol Service IEFSJSYM. ��� . In-stream symbol substitution-V2R1 now allows symbol substitution in the records of the in-stream data sets, including those used in catalogued JCL procedures. Substitution of symbols in the in-stream data is performed at execution time-more precisely, at the moment when an application reads a record from the in-stream data set. To allow symbols to be used in the in-stream data, two things must be done: 1. Relevant EXPORT and SET JCL statements must be added to allow required symbols to be visible during execution time. 2. New keyword SYMBOLS must be added to the DD statement that defines the in-stream dataset. By default, there is no change in behavior compared to the prior releases and no substitution is performed. Several types of symbols can be substituted by this new function: ��� o JCL symbols made available via EXPORT function ��� ��� o System symbols, such as SYSNAME. Note that V2R1 now allows using system symbols from a conversion system in JCL - something that was not allowed in prior releases. ��� ��� o New JES symbols which will be explained later The SYMBOLS keyword controls which symbols will be substituted: ��� ��� o SYMBOLS=JCLONLY causes substitution of all symbols except for system symbols ��� ��� o SYMBOLS=EXECSYS causes substitution of all symbols including system symbols. System symbols are taken from the system the job is running on. ��� ��� o SYMBOLS=CNVTSYS is the same as SYMBOLS=EXECSYS except for the origin of system symbols-they are taken from the system where the job had been converted.
Re: z/OS physical memory usage with multiple copies of same load module at different virtual addresses
jwgli...@gmail.com (John Gilmore) writes: That said, Timothy Sipples is clearly right in general: The use of significant system-software resources to identify and share bit-equivalent pages, even big ones, dynamically is not likely to pay for itself in a z/OS environment. The major optimizations are already in place. The z/OS ASM does not, for example, page out unaltered pages after doing so once initially; and it is able to make this distinction efficiently because there is hardware support for distinguishing altered/stored-into pages from unaltered ones. page replacement started out being only writting changed pages ... but big pages appeared in 80s used with 3380s in 80s as attempt to compensate for lack of appropriate paging devices. idea was doing a full track (10 page) transfer in one operation (leveraging the 3380 transfer speed increase by factor of four ... from 3330 800kbytes/sec to 3mbytes/sec ... but didn't have corresponding increase in arm access throughput). pages for same address space were removed from memory in groups of ten ... and written as single transfer to disk. a fetch for any page in the group resulted in full track read for all ten pages (amortizing single arm access across ten page transfer). the write was always done to a new location ... basically first available location closest to moving arm algorithm. to make this effective, it had to ignore whether a page had been changed or not ... and remove groups of ten associated pages in one operation (whether changed or not) all to the same track. additional overhead of writting unchanged pages and potentially fetching unncessary pages (wouldn't be used) in groups of ten ... was deamed to be more than offset by the savings of one arm access for ten page transfer (along with strategies for optimizing arm movement). additional motivation was there were some non-IBM fixed-head simulation paging disks that other vendors were offerring using electronic memory ... eliminating arm access rotational delay. the sales argument was that big pages only had to do one arm access rotational delay per ten page transfer (in theory, negating the benefits of electronic simulated disks). about the same time, there was 3880-11 and 3880-13 controller caches. 3880-11 was 8mbyte of 4k block cache targeted at paging operations and 3880-13 was 8mbyte of full track cache targeted at file operations. the 3880-13 marketing was that the cache had 90% hit rate. however, the scenario was sequential file read of 4k records, 10/track. The first record read from track would be miss, but the next 9 records read would all be hits. if the application was changed to do sequential full track buffered reads, cache hit rate would drop to zero. I got into dustup with the 3880-11 product group that unless they changed the mainframe software, the 3880-11 provided almost no benefit. the issue was most configuration had about the same or more paged mainframe memory (32mbyte 3081) than 3880-11 cache. The effective result was that it would be highly improbably that there would be a record in the the 3880-11 cache that wasn't in mainframe memory (duplicates). As a result, a page fault for something that wasn't in mainframe memory wouldn't also be in 3880-11 cache (since the 3880-11 were totally full of stuff that was also in mainframe memory). It was possible to do CCW that would eliminate duplicates (increasing probability that there was record in 3880-11 that wasn't also in mainframe), but that required changing mainframe software. I had earlier gotten into dustup with the VS2 group (early, pre-announce SVS) over their myopic decision that when selecting pages for replacement, that non-changed pages were selected before changed pages (since it reduced work, memory location was immediately available because it didn't require write). It wasn't well into the MVS release cycle ... that it dawned on them that they were selecting non-changed, shared, high-use linkpack pages for replacement before selecting lower use, application private data pages. past posts on page replacement algorithms and strategies http://www.garlic.com/~lynn/subtopic.html#wsclock -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS V2.1 and System Symobls and JCL
On Wed, 30 Jul 2014 11:14:18 -0500, Kirk Wolf wrote:
FWIW, if anyone is interested in integrating batch jobs containing z/OS
Unix shell scripts with z/OS 2.1 JES Symbols, search the archives for the
thread:
Want your feedback on shell command interface to V2R1 IAZSYMBL
For convenience, that began 2013-10-23 14:09.
I see a lot of subjunctive mood in there. Has it come to pass?
( ... Also: you need set -o pipecurrent when piping jessym output into
read
or . )
Or, redirect to a temp file and read that file? Or pipe into a { list ... }?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SORT JCL
Ok Kolusu. I have send the details. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS V2.1 and System Symobls and JCL
Try it with a period at the end of each variable. On Wed, Jul 30, 2014 at 10:34 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On Wed, 30 Jul 2014 08:49:36 -0500, Peter X. DeFabritus wrote: I suspect they mean something like // SET ABCLYR2=10 but I could be wrong. That's a sufficient degree of uncertainty that I submitted a RCF. On Wed, 30 Jul 2014 08:33:35 -0500, Paul Gilmartin wrote: http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.ieab600/jdefine.htm ... Does within apply to the assigned value or to the name? I have tried both constructs with no reported syntax error. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beginners question about SHARE
In 0ae001cfabef$444bb760$cce32620$@mcn.org, on 07/30/2014 at 08:10 AM, Charles Mills charl...@mcn.org said: I think SHARE would be better off with a little less of an old boys' club approach to attendance. I can't recall a time when Share management wasn't actively seeking new blood, but they can't force people to volunteer nor can they compel members to support employees who wish to volunteer. I didn't start this thread. If you think that newcomers having to ask on a forum how the heck do I go to my first SHARE? is satisfactory, then I guess all is well with how SHARE does things today. I don't recall anybody suggesting that it was satisfactory, just that it doesn't support the claim that Share is trying to exclude new members. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS physical memory usage with multiple copies of same load module at different virtual addresses
In cae1xxdhjs_8hfezdeb9la9-ppazqpniusxkdkjpyvcf0yyo...@mail.gmail.com, on 07/30/2014 at 11:11 AM, John Gilmore jwgli...@gmail.com said: My comment that elicited his Nonsense! response suggested very briefly that the device of making and marking a load module or program object reentrant or, better, refreshable could be used to share code across LPAR boundaries. No, it suggested more than that. Had that been your comment then I would have silently agreed. As written, If 1) the execution loader has brought a load module or program object into storage and 2) that executable is marked refreshable and/or reentrant, the execution loader will not bring second or subseq, it was clearly false. The distinction between into storage and into shared storage is an important one. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS physical memory usage with multiple copies of same load module at different virtual addresses
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Shmuel Metz In cae1xxdhjs_8hfezdeb9la9-ppazqpniusxkdkjpyvcf0yyo...@mail.gmail.com, on 07/30/2014 at 11:11 AM, John Gilmore jwgli...@gmail.com said: My comment that elicited his Nonsense! response suggested very briefly that the device of making and marking a load module or program object reentrant or, better, refreshable could be used to share code across LPAR boundaries. No, it suggested more than that. Had that been your comment then I would have silently agreed. As written, If 1) the execution loader has brought a load module or program object into storage and 2) that executable is marked refreshable and/or reentrant, the execution loader will not bring second or subseq, it was clearly false. The distinction between into storage and into shared storage is an important one. Easy enough to share code across address space boundaries within one LPAR (placing the program in the LPA seems simplest), but how does one share code across LPAR boundaries? I'm not aware of any real storage (memory) that can be accessed concurrently by two or more LPARs, such that a program in memory within LPAR A can be executed in LPAR B without B having to load its own copy of it into its own memory. -jc- ** 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: z/OS physical memory usage with multiple copies of same load module at different virtual addresses
Anne Lynn Wheeler wrote: begin extract It wasn't [until, jg] well into the MVS release cycle ... that it dawned on them that they were selecting non-changed, shared, high-use linkpack pages for replacement before selecting lower use, application private data pages . . . /end extract and it I think can be agreed out of hand that this was not smart. Avoiding the operation of rewriting an unaltered page, however selected, to the page data set is nevertheless highly desirable. Page selection and selective page rewriting operations are, or at least should be, entirely separable operations. Moreover gather-write channel programs are in my experience 1) as efficient as connected-block ones and 2) not notably more difficult to write and test. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Fwd: Mainframe users love their computer artifacts - share yours
I'm the messenger -- follow links and respond as suggested below. You might have to register on Destination z website to post there. Original Message Subject:Mainframe users love their computer artifacts - share yours Date: Thu, 24 Jul 2014 11:39:54 -0600 From: Destination z destinati...@destinationz.org To: g...@gabegold.com To view this email as a web page, go here. http://cl.exct.net/?qs=bce3392b2230df75094a81d5810b4d2be9ece3955e0fc340852b69fd5394ee04 http://cl.exct.net/?qs=bce3392b2230df752815bf63eca50edfc1f31ea0a67442c181ecbd8da9ae9d0f July 24, 2014 How passionate are you about your chosen profession? Many mainframers have some pretty old and unique mainframe artifacts. Sharing your items from the past with the Destination z community could earn you one of two $50 prepaid Visa gift cards. Participation is open to all Destination z members. To enter, head to the forums for the most unique artifacts http://cl.exct.net/?qs=bce3392b2230df75a145cb105b2b28040fbfca7cf3209e3adbbe5005574bc578 and oldest artifacts http://cl.exct.net/?qs=bce3392b2230df75328b8682f5f4fead0a8ff8c77505fb44a275f1e1d1acc0eb. There, you can upload a picture of your item and explain what makes it unique, the timeframe it is from and why you have held on to it or the story behind it. http://www.destinationz.org/Community/Forums?forumid=10threadid=253 http://www.destinationz.org/Community/Forums?forumid=10threadid=252 Submissions are due by Sept. 19 at midnight Central time. Judges will decide the winners in each category, and winners will be announced at the end of September. Read more about the contest here. http://cl.exct.net/?qs=bce3392b2230df751c248cdab3dc4f78ed01ea83da6f7991d9f8dfdcd8c77c68 http://www.destinationz.org/Mainframe-Solution/Trends/Join-the-Computer-Artifacts-Contest Get inspiration from others in the field by reading our recent stories Holding on to History http://cl.exct.net/?qs=bce3392b2230df7504b486ee1c2282ebbde38914640ad17786cf359d332cde85 and Cherished Computer Memories http://cl.exct.net/?qs=bce3392b2230df75cb5c834967fe362b98ee4fbadf25b0771f61c0ed31d9c6a4. http://www.destinationz.org/Mainframe-Solution/Trends/Holding-on-to-History http://www.destinationz.org/Mainframe-Solution/Trends/Cherished-Computer-Memories Because you're a valuable member of Destination z, I'd like to personally invite you to join us and share your favorite computer artifacts and the stories behind them. Good luck! Valerie Dennis Destinationz.org Editor Forward to a colleague » http://cl.exct.net/?qs=bce3392b2230df75c684816b4d823e9194311c521a18d69a358f64688b8d40d6 This email was sent by: MSP TechMedia 220 South 6th St. Suite 500 Minneapolis, MN, 55402, USA We respect your right to privacy - view our policy http://cl.exct.net/?qs=bce3392b2230df75d3ad4e3cf9a8fe27c45c5149a65573bbe4e0f046fa4c4dfb http://cl.exct.net/?qs=bce3392b2230df7539dfefb70a7a94e5e524fd53ac0a3c7e123af659fb99e44d -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: IEAMSCHD question
Another responsibility: these fields are to be properly initialized. This is not for the faint hearted programmers... When your code is able to schedule an SRB, your code runs authorized. When you code authorized stuff, it is a must to understand the system. It's not a question of faint-heartedness but of responsibility. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retireiving DCB information for migrated datasets
Did you look at DCOLLECT? That has all the fields you want. This is a z/OS2.1 link to the fields, but i am sure you have access to your own appropriate docs. http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idai200/dgt3i294.htm On 30 July 2014 16:50, Christian Birr christian.b...@birrconsulting.de wrote: Hi Greg, I remembered you piece of code this afternoon, too. Due to some 'important' meetings I just came to assemble it, put in the TSO command table and tried it in one of my sandboxes. It came back with an RC of 4, contact your system support, which is mainly me and myself. I haven't the time to inspect the code more deeply, but could it be, there's a mismatch between you home grown MCD DSECT and the current one? The listing of the DESCT is right beside me and I'll look into it tomorrow, or might it be an error on my side? Greetings from lower Bavaria Christian -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Greg Price Gesendet: Mittwoch, 30. Juli 2014 17:27 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: Retireiving DCB information for migrated datasets On 30/07/2014 4:56 PM, גדי בן אבי wrote: Is it possible to retreive DCB information (LRECL, BLKSIZE, RECFM, DSORG) for migrated datasets, without recalling the dataset? Check out the $HMLIST command in CBT file 134. It reads the MCDS directly. Output can go to the terminal or a data set. Cheers, Greg -- 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: Beginners question about SHARE
Well, wasn't a first time or a confession but I had a session scheduled in the Marquee Marriott(NYC) in the 'fashion room' with mirrored walls and ceilings. I had a session penciled in for the Hilton across the street, but it was raining so just parked in the 'fashion room'. The session was about Fonts and Font design. Probably one of the most knowledgeable presenters I'd ever heard. Knew optics, physics, biometrics just everything that goes into Font presentation. Great graphics and super slides everything just flowed together. Think I wrote it up as accidental learning. Probably 'old boys club' is exacerbated by shrinking demographics and economic downturn. There's still lots of life left in MVS with new features in hardware and software. SHARE can help you or your company exploit these features and integrate them into your enterprise. There's other OS's too! Guess what to keep and what to throw away as trends come and go is another important benefit. There was a time when Cross system products was the rage. SHARE reorged and by the next Major it was pretty much dead. Anyway life and times... In a message dated 7/30/2014 7:26:26 A.M. Central Daylight Time, robert.richa...@opm.gov writes: Confessions of a first-time SHARE attendee -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
another question about TSO edit command
I am O.K. editing data with line numbers. But when I get data with no line numbers, my commands are not working. i.e. change find etc. Example: ,EDIT, list ,//MSTJCL01 JOB MSGLEVEL=(1,1),TIME=1440, ,// EXEC PGM=IEEMB860,DPRTY=(15,15), ,//STCINRDR DD SYSOUT=(A,INTRDR), ,//TSOINRDR DD SYSOUT=(A,INTRDR), ,//IEFPDSI DD DSN=SYS1.PROCLIB,DISP=SHR, ,// DD DSN=CPAC.PROCLIB,DISP=SHR, ,// DD DSN=SYS1.IBM.PROCLIB,DISP=SHR, ,//IEFJOBS DD DSN=SYS1.JCLLIB,DISP=SHR, ,IKJ52500I END OF DATA, ,EDIT, f STC == ,IKJ52506I TEXT NOT FOUND, ,EDIT, Any help would be appreciated. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another question about TSO edit command
You're off the bottom; the current line pointer is at the next-to-be-added line. You need to go back up. Use a L 0 or TOP subcommand. Read all about EDIT here: http://publibz.boulder.ibm.com/epubs/pdf/ikj2l200.pdf === Date: Wed, 30 Jul 2014 21:44:39 + From: jcnorga...@ucdavis.edu Subject: another question about TSO edit command To: IBM-MAIN@LISTSERV.UA.EDU I am O.K. editing data with line numbers. But when I get data with no line numbers, my commands are not working. i.e. change find etc. Example: ,EDIT, list ,//MSTJCL01 JOB MSGLEVEL=(1,1),TIME=1440, ,// EXEC PGM=IEEMB860,DPRTY=(15,15), ,//STCINRDR DD SYSOUT=(A,INTRDR), ,//TSOINRDR DD SYSOUT=(A,INTRDR), ,//IEFPDSI DD DSN=SYS1.PROCLIB,DISP=SHR, ,// DD DSN=CPAC.PROCLIB,DISP=SHR, ,// DD DSN=SYS1.IBM.PROCLIB,DISP=SHR, ,//IEFJOBS DD DSN=SYS1.JCLLIB,DISP=SHR, ,IKJ52500I END OF DATA, ,EDIT, f STC == ,IKJ52506I TEXT NOT FOUND, ,EDIT, Any help would be appreciated. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another question about TSO edit command
After entering l 0, got l 0 ,IKJ52502I DATA SET NOT LINE NUMBERED, Which makes sense since the data is not line numbered. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J R Sent: Wednesday, July 30, 2014 3:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: another question about TSO edit command You're off the bottom; the current line pointer is at the next-to-be-added line. You need to go back up. Use a L 0 or TOP subcommand. Read all about EDIT here: http://publibz.boulder.ibm.com/epubs/pdf/ikj2l200.pdf === Date: Wed, 30 Jul 2014 21:44:39 + From: jcnorga...@ucdavis.edu Subject: another question about TSO edit command To: IBM-MAIN@LISTSERV.UA.EDU I am O.K. editing data with line numbers. But when I get data with no line numbers, my commands are not working. i.e. change find etc. Example: ,EDIT, list ,//MSTJCL01 JOB MSGLEVEL=(1,1),TIME=1440, ,// EXEC PGM=IEEMB860,DPRTY=(15,15), ,//STCINRDR DD SYSOUT=(A,INTRDR), ,//TSOINRDR DD SYSOUT=(A,INTRDR), ,//IEFPDSI DD DSN=SYS1.PROCLIB,DISP=SHR, ,// DD DSN=CPAC.PROCLIB,DISP=SHR, ,// DD DSN=SYS1.IBM.PROCLIB,DISP=SHR, ,//IEFJOBS DD DSN=SYS1.JCLLIB,DISP=SHR, ,IKJ52500I END OF DATA, ,EDIT, f STC == ,IKJ52506I TEXT NOT FOUND, ,EDIT, Any help would be appreciated. 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: another question about TSO edit command
Yep, line mode. If you do a find and get no hits you're at the bottom. l * will show where you are. For change, Verify on is good to have. NUM, RENUM, UNNUM should be used with caution on SMP/E controlled members. Some still use IEBUPTDT for change control. In a message dated 7/30/2014 5:41:06 P.M. Central Daylight Time, jayare...@hotmail.com writes: Use a L 0 or TOP subcommand. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another question about TSO edit command
On Wed, 30 Jul 2014 18:57:04 -0400, Ed Finnell wrote: Yep, line mode. If you do a find and get no hits you're at the bottom. That is one of the dumbest, most hostile behaviors I have ever seen in an editor (but TSO edit isn't unique here). If I do a find and get no hits (very possibly because I mistyped the search target) a well-behaved editor should leave the file position unchanged. (Poll: How many of you XEDIT users SET STAY OFF? Why?) l * will show where you are. For change, Verify on is good to have. NUM, RENUM, UNNUM should be used with caution on SMP/E controlled members. Some still use IEBUPTDT for change control. In a message dated 7/30/2014 5:41:06 P.M. Central Daylight Time, jayarelim writes: Use a L 0 or TOP subcommand. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Monitoring Solution for mainframe
A couple years back I noticed that the TSSO writing was pretty much on the wall as to support, so I started to try to duplicate the functionality within our automation suite. While the Syzygy Automation suite isn't free, it's extremely inexpensive. I think that all of the functions which TSSO is (or was) capable of, is now implemented. I didn't see the logic in trying to use the AOP module for console message processing since the way SyzMPF/z already processed the messages was more usable, and easier to manage. I do still have TSSO working on z/OS 1.13 and 2.1, but I have made so many changes that most of the code is now running with portions of our automation software replacing the non-working areas. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: another question about TSO edit command
On Jul 30, 2014, at 6:40 PM, Paul Gilmartin wrote: On Wed, 30 Jul 2014 18:57:04 -0400, Ed Finnell wrote: Yep, line mode. If you do a find and get no hits you're at the bottom. That is one of the dumbest, most hostile behaviors I have ever seen in an editor (but TSO edit isn't unique here). If I do a find and get no hits (very possibly because I mistyped the search target) a well- behaved editor should leave the file position unchanged. Paul: I disagree and I did live with it for several years and learned to like it. When we got FSE it was like heaven. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
