Re: Dummy dataset
On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote: We have an exit for DFSORT that scans TIOT to see if someone concatenated a DUMMY dataset as input. Here is what I believe to be the relevant snippet of code: ... * CHECK FOR DUMMY DD STATEMENT * NOTE: COULD ALSO BE DD * DDCHKCLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ? BEDDBAD A. NO, BAD DD ... How does this behave for DD PATH=...? Is the UCB address nonzero for zFS files? Are you unwittingly prohibiting use of zFS in the SORTIN concatenation? That would be imprisoning your users in the twentieth century. Prohibiting DD * is also unduly harsh. A similar question applies to Shmuel's suggestion of DEVTYPE. The definitive test should be for DSNAME='NULLFILE'. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
No, we have users sorting data with path names as input. Just ran a test. Single path input, concatenated, all work fine, unless they add a DD DUMMY between them. As a side note, DFSORT doesn’t do a good job with dynamic sortwk allocations with PATH input because it cannot accurately determine the input filesize. I had opened a ticket with IBM on this, and all I got was this is the way it is. My only option was to tell my developers to hardcode sorkwk datasets in their job. //DFSORT EXEC PGM=SORT //SORTINDD PATHDISP=KEEP, // PATHOPTS=ORDONLY, // FILEDATA=TEXT, // RECFM=VB,LRECL=255,BLKSIZE=25496, // PATH='/etc/httpd1443.conf' // DD DUMMY // DD PATHDISP=KEEP, // PATHOPTS=ORDONLY, // FILEDATA=TEXT, // RECFM=VB,LRECL=255,BLKSIZE=25496, // PATH='/etc/httpd1443.conf' -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, February 04, 2014 8:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote: We have an exit for DFSORT that scans TIOT to see if someone concatenated a DUMMY dataset as input. Here is what I believe to be the relevant snippet of code: ... * CHECK FOR DUMMY DD STATEMENT * NOTE: COULD ALSO BE DD * DDCHKCLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ? BEDDBAD A. NO, BAD DD ... How does this behave for DD PATH=...? Is the UCB address nonzero for zFS files? Are you unwittingly prohibiting use of zFS in the SORTIN concatenation? That would be imprisoning your users in the twentieth century. Prohibiting DD * is also unduly harsh. A similar question applies to Shmuel's suggestion of DEVTYPE. The definitive test should be for DSNAME='NULLFILE'. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
On Tue, Feb 4, 2014 at 7:44 AM, Jousma, David david.jou...@53.com wrote: No, we have users sorting data with path names as input. Just ran a test. Single path input, concatenated, all work fine, unless they add a DD DUMMY between them. As a side note, DFSORT doesn’t do a good job with dynamic sortwk allocations with PATH input because it cannot accurately determine the input filesize. I had opened a ticket with IBM on this, and all I got was this is the way it is. My only option was to tell my developers to hardcode sorkwk datasets in their job. Normally, I praise the DFSORT people. But it cannot accurately determine the input filesize is _ignorant_. stat() on the file returns the size of the file in bytes. Of course, this doesn't for UNIX files which are not really files. Such as named pipes, or /dev/fd/? type files for open file descriptors. Which are not useful in batch anyway, so forget I mentioned them. //DFSORT EXEC PGM=SORT //SORTINDD PATHDISP=KEEP, // PATHOPTS=ORDONLY, // FILEDATA=TEXT, // RECFM=VB,LRECL=255,BLKSIZE=25496, // PATH='/etc/httpd1443.conf' // DD DUMMY // DD PATHDISP=KEEP, // PATHOPTS=ORDONLY, // FILEDATA=TEXT, // RECFM=VB,LRECL=255,BLKSIZE=25496, // PATH='/etc/httpd1443.conf' -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? 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: Dummy dataset
David, The use of DD DUMMY in a concatenation ends the processing of input data. The following is from the JCL Reference Manual: Data sets concatenated to dummy data sets: The system treats data sets concatenated to a DUMMY data set as dummy data sets in that I/O operations are bypassed. However, the system performs disposition processing and allocates devices and storage for any concatenated data sets. So, in your example you only read the file once. Without the DD DUMMY it would read the file twice. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Tuesday, February 04, 2014 8:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset No, we have users sorting data with path names as input. Just ran a test. Single path input, concatenated, all work fine, unless they add a DD DUMMY between them. As a side note, DFSORT doesn’t do a good job with dynamic sortwk allocations with PATH input because it cannot accurately determine the input filesize. I had opened a ticket with IBM on this, and all I got was this is the way it is. My only option was to tell my developers to hardcode sorkwk datasets in their job. //DFSORT EXEC PGM=SORT //SORTINDD PATHDISP=KEEP, // PATHOPTS=ORDONLY, // FILEDATA=TEXT, // RECFM=VB,LRECL=255,BLKSIZE=25496, // PATH='/etc/httpd1443.conf' // DD DUMMY // DD PATHDISP=KEEP, // PATHOPTS=ORDONLY, // FILEDATA=TEXT, // RECFM=VB,LRECL=255,BLKSIZE=25496, // PATH='/etc/httpd1443.conf' -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, February 04, 2014 8:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote: We have an exit for DFSORT that scans TIOT to see if someone concatenated a DUMMY dataset as input. Here is what I believe to be the relevant snippet of code: ... * CHECK FOR DUMMY DD STATEMENT * NOTE: COULD ALSO BE DD * DDCHKCLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ? BEDDBAD A. NO, BAD DD ... How does this behave for DD PATH=...? Is the UCB address nonzero for zFS files? Are you unwittingly prohibiting use of zFS in the SORTIN concatenation? That would be imprisoning your users in the twentieth century. Prohibiting DD * is also unduly harsh. A similar question applies to Shmuel's suggestion of DEVTYPE. The definitive test should be for DSNAME='NULLFILE'. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access
Re: Dummy dataset
Chris, Yes, I am aware of that. This thread started from an exit we run that detects this type of concatenation in a DFSORT SORTIN due to fallout encountered years ago involving the use of symbolics to override dataset names in the concatenation at runtime. The fallout that occurred was because it took days for the affected app groups to determine that the concatenated datasets after the DUMMY dataset were never included in the SORTOUT. I was not at this job when it occurred, but we are a bank, some maybe the affect was that someone's bank accounts were not accurate(I don’t know). Some here call it a feature, some call it a shortcoming, regardless, it is the way the system operates. The problem for us then was that the job ended RC(0), and it took a long time to figure out that the input data was ignored. That’s why the exit came to life. I know that the same behavior exits using IEBGENER, and IDCAMS REPRO copying and we don’t have exits for those, and no one has complained. Why do we have the ICE EXIT? Politics. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Blaicher, Christopher Y. Sent: Tuesday, February 04, 2014 10:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset David, The use of DD DUMMY in a concatenation ends the processing of input data. The following is from the JCL Reference Manual: Data sets concatenated to dummy data sets: The system treats data sets concatenated to a DUMMY data set as dummy data sets in that I/O operations are bypassed. However, the system performs disposition processing and allocates devices and storage for any concatenated data sets. So, in your example you only read the file once. Without the DD DUMMY it would read the file twice. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Tuesday, February 04, 2014 8:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset No, we have users sorting data with path names as input. Just ran a test. Single path input, concatenated, all work fine, unless they add a DD DUMMY between them. As a side note, DFSORT doesn’t do a good job with dynamic sortwk allocations with PATH input because it cannot accurately determine the input filesize. I had opened a ticket with IBM on this, and all I got was this is the way it is. My only option was to tell my developers to hardcode sorkwk datasets in their job. //DFSORT EXEC PGM=SORT //SORTINDD PATHDISP=KEEP, // PATHOPTS=ORDONLY, // FILEDATA=TEXT, // RECFM=VB,LRECL=255,BLKSIZE=25496, // PATH='/etc/httpd1443.conf' // DD DUMMY // DD PATHDISP=KEEP, // PATHOPTS=ORDONLY, // FILEDATA=TEXT, // RECFM=VB,LRECL=255,BLKSIZE=25496, // PATH='/etc/httpd1443.conf' -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, February 04, 2014 8:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote: We have an exit for DFSORT that scans TIOT to see if someone concatenated a DUMMY dataset as input. Here is what I believe to be the relevant snippet of code: ... * CHECK FOR DUMMY DD STATEMENT * NOTE: COULD ALSO BE DD * DDCHKCLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ? BEDDBAD A. NO, BAD DD ... How does this behave for DD PATH=...? Is the UCB address nonzero for zFS files? Are you unwittingly prohibiting use of zFS in the SORTIN concatenation? That would be imprisoning your users in the twentieth century. Prohibiting DD * is also unduly harsh. A similar question applies to Shmuel's suggestion of DEVTYPE. The definitive test should be for DSNAME='NULLFILE'. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error
Re: Dummy dataset
Suggestion: Add DD keyword SKIP. Similar to DUMMY, but will continue with the next concatenated DD statement. On Tue, Feb 4, 2014 at 9:09 AM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: David, The use of DD DUMMY in a concatenation ends the processing of input data. The following is from the JCL Reference Manual: Data sets concatenated to dummy data sets: The system treats data sets concatenated to a DUMMY data set as dummy data sets in that I/O operations are bypassed. However, the system performs disposition processing and allocates devices and storage for any concatenated data sets. So, in your example you only read the file once. Without the DD DUMMY it would read the file twice. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Tuesday, February 04, 2014 8:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset No, we have users sorting data with path names as input. Just ran a test. Single path input, concatenated, all work fine, unless they add a DD DUMMY between them. As a side note, DFSORT doesn't do a good job with dynamic sortwk allocations with PATH input because it cannot accurately determine the input filesize. I had opened a ticket with IBM on this, and all I got was this is the way it is. My only option was to tell my developers to hardcode sorkwk datasets in their job. //DFSORT EXEC PGM=SORT //SORTINDD PATHDISP=KEEP, // PATHOPTS=ORDONLY, // FILEDATA=TEXT, // RECFM=VB,LRECL=255,BLKSIZE=25496, // PATH='/etc/httpd1443.conf' // DD DUMMY // DD PATHDISP=KEEP, // PATHOPTS=ORDONLY, // FILEDATA=TEXT, // RECFM=VB,LRECL=255,BLKSIZE=25496, // PATH='/etc/httpd1443.conf' -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, February 04, 2014 8:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote: We have an exit for DFSORT that scans TIOT to see if someone concatenated a DUMMY dataset as input. Here is what I believe to be the relevant snippet of code: ... * CHECK FOR DUMMY DD STATEMENT * NOTE: COULD ALSO BE DD * DDCHKCLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ? BEDDBAD A. NO, BAD DD ... How does this behave for DD PATH=...? Is the UCB address nonzero for zFS files? Are you unwittingly prohibiting use of zFS in the SORTIN concatenation? That would be imprisoning your users in the twentieth century. Prohibiting DD * is also unduly harsh. A similar question applies to Shmuel's suggestion of DEVTYPE. The definitive test should be for DSNAME='NULLFILE'. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received
Re: Dummy dataset
This triggers a memory from my wayback machine. Back then when symbolic references first became available this little annoyance was noticed by several application developers. Our local circumvention was to code a symbolic reference one of several datasets that were created at various lrecls, kept empty, and used instead of DUMMY. Crude, but effective. On 2/4/2014 9:24 AM, Jousma, David wrote: Chris, Yes, I am aware of that. This thread started from an exit we run that detects this type of concatenation in a DFSORT SORTIN due to fallout encountered years ago involving the use of symbolics to override dataset names in the concatenation at runtime. The fallout that occurred was because it took days for the affected app groups to determine that the concatenated datasets after the DUMMY dataset were never included in the SORTOUT. I was not at this job when it occurred, but we are a bank, some maybe the affect was that someone's bank accounts were not accurate(I don’t know). Some here call it a feature, some call it a shortcoming, regardless, it is the way the system operates. The problem for us then was that the job ended RC(0), and it took a long time to figure out that the input data was ignored. That’s why the exit came to life. I know that the same behavior exits using IEBGENER, and IDCAMS REPRO copying and we don’t have exits for those, and no one has complained. Why do we have the ICE EXIT? Politics. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Blaicher, Christopher Y. Sent: Tuesday, February 04, 2014 10:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset David, The use of DD DUMMY in a concatenation ends the processing of input data. The following is from the JCL Reference Manual: Data sets concatenated to dummy data sets: The system treats data sets concatenated to a DUMMY data set as dummy data sets in that I/O operations are bypassed. However, the system performs disposition processing and allocates devices and storage for any concatenated data sets. So, in your example you only read the file once. Without the DD DUMMY it would read the file twice. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Tuesday, February 04, 2014 8:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset No, we have users sorting data with path names as input. Just ran a test. Single path input, concatenated, all work fine, unless they add a DD DUMMY between them. As a side note, DFSORT doesn’t do a good job with dynamic sortwk allocations with PATH input because it cannot accurately determine the input filesize. I had opened a ticket with IBM on this, and all I got was this is the way it is. My only option was to tell my developers to hardcode sorkwk datasets in their job. //DFSORT EXEC PGM=SORT //SORTINDD PATHDISP=KEEP, // PATHOPTS=ORDONLY, // FILEDATA=TEXT, // RECFM=VB,LRECL=255,BLKSIZE=25496, // PATH='/etc/httpd1443.conf' // DD DUMMY // DD PATHDISP=KEEP, // PATHOPTS=ORDONLY, // FILEDATA=TEXT, // RECFM=VB,LRECL=255,BLKSIZE=25496, // PATH='/etc/httpd1443.conf' -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, February 04, 2014 8:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote: We have an exit for DFSORT that scans TIOT to see if someone concatenated a DUMMY dataset as input. Here is what I believe to be the relevant snippet of code: ... * CHECK FOR DUMMY DD STATEMENT * NOTE: COULD ALSO BE DD * DDCHKCLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ? BEDDBAD A. NO, BAD DD ... How does this behave for DD PATH=...? Is the UCB address nonzero for zFS files? Are you unwittingly prohibiting use of zFS in the SORTIN concatenation? That would be imprisoning your users in the twentieth century. Prohibiting DD * is also unduly harsh. A similar question applies to Shmuel's suggestion of DEVTYPE. The definitive test should be for DSNAME='NULLFILE'. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e
Re: Dummy dataset
On 2/4/2014 8:37 AM, Paul Gilmartin wrote: Prohibiting DD * is also unduly harsh. A similar question applies to Shmuel's suggestion of DEVTYPE. The definitive test should be for DSNAME='NULLFILE'. If the code is intended for general use (e.g., a SORT invoked dynamically), then flag TIOSLTYP needs to be tested, as well as several bits in TIOELINK. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
Sorry for being dense...Never heard of it? What is SKIP? I just looked in JCL reference, don't see anything? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Tuesday, February 04, 2014 11:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset Suggestion: Add DD keyword SKIP. Similar to DUMMY, but will continue with the next concatenated DD statement. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
On Tue, Feb 4, 2014 at 11:45 AM, Jousma, David david.jou...@53.com wrote: Sorry for being dense...Never heard of it? What is SKIP? I just looked in JCL reference, don't see anything? There is no SKIP parameter in JCL. Gil was wanting IBM to create such a beasty just for this type of problem. How to null out a DD in the midst of a concatenation, short of creating an empty data set with the correct DCB information. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? 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: Dummy dataset
On Tue, 4 Feb 2014 10:25:32 -0600, Mike Schwab wrote: Suggestion: Add DD keyword SKIP. Similar to DUMMY, but will continue with the next concatenated DD statement. No good: user@HOST: rexx say bpxwdyn( 'alloc skip msg(wtp)' ) -22 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
On Tue, 4 Feb 2014 12:20:21 -0600, John McKown wrote: On Tue, Feb 4, 2014 at 11:45 AM, Jousma, David wrote: Sorry for being dense...Never heard of it? What is SKIP? I just looked in JCL reference, don't see anything? There is no SKIP parameter in JCL. Gil was wanting IBM to create such a beasty just for this type of problem. How to null out a DD in the midst of a concatenation, short of creating an empty data set with the correct DCB information. Gil who? It was Mike's idea. Perhaps he has a user exit. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
In 5284287024729817.wa.paulgboulderaim@listserv.ua.edu, on 02/04/2014 at 07:37 AM, Paul Gilmartin paulgboul...@aim.com said: Is the UCB address nonzero for zFS files? The UCB address in the TIOT entry is zero for anything not allocated to a device; that includes not only Unix files but also subsytem files and TSO terminals. Back in the day it also included TCAM. There are flag bits in, e.g., TIOELINK, to determine who did what to whom. -- 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: Dummy dataset
Gil, This exit has been around on our systems for many years. It abends the job if Dummy is anywhere in SORTIN or SYSUT1(ICEGENER). I didn’t show the message text, but it indicates that the user needs to replace DUMMY with a real dataset - SYS2.DUMMY that is allocated as RECFM=U, LRECL=0, BLKSIZE=0, and occupies 1 track. This behavior is also documented in the SORT manual too. I get what you say about a sophisticated programmer doing it on purpose, but the problem outweighs the benefits if use was unintentional. I had questioned DFSORT development group a couple years ago trying to argue my point that DFSORT shouldn’t end with RC0, maybe a RC4 or RC8 with a warning message. Or maybe a configurable option on desired SORT behavior. It's an exit that I am afraid will be on my systems long after I retire. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, January 30, 2014 7:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset On 2014-01-30 14:04, Jousma, David wrote: We had some enterprising programmers that coded jobs something like: //SORTIN DD DSN=a.data.set.name,disp=shr // dd dd1,disp=shr // dd DD2,disp=shr // dd dsn=another.data.set.name,disp=shr And in the proc defaulted DD1, and DD2 to DUMMY so that they could dynamically change the input datasets. Problem was when they didn’t use them or only one of them, DFSORT stops reading input and the real datasets beyond the dummy ones never got read, and the JOB finished with RC(0), so it was obvious there was missing data. With the exit we abend the job. Much as I detest that behavior (I'd much prefer that DUMMY behaved as DD SPACE=0), it's documented in JCL Ref. or Using Data Sets or somewhere, so WAD. Implementing DWIM, as you appear to be trying to do is an endless and mostly thankless task. And a sophisticated programmer who knowingly codes DUMMY (perhaps to disable some catenands for a test) has much reason to complain when experiencing behavior not only unexpected but also contrary to OS documentation. Have you tried (or suggested) using DD SPACE=0 in place of DUMMY? Even worse (also documented) Allocation substitutes DUMMY for PATH='/dev/null' or PATH='//dev/null', which I deem a colossal misapplication of DWIM by the OS designers. There was *no* reason to do that. They might as well, and with similar rationale substitute DUMMY for SPACE=0. Fortunately, Allocation is sufficiently dumb that it fails to recognize and override the otherwise equivalent PATH='/dev//null'. Do you ABEND only if DUMMY is followed by a non-dummy data set? There should be no problem if DUMMY (or several) is/are the last catenand(s). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
In 3460c7b7-246b-4ae5-811f-f3d8939c5...@optonline.net, on 01/30/2014 at 03:01 PM, Micheal Butz michealb...@optonline.net said: If a dataset has been dummied out DEVTYPE is the obvious way, but scanning the TIOT will also do it. -- 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: Dummy dataset
On Thu, 30 Jan 2014 15:01:48 -0500, Micheal Butz wrote: Would anyone know if there is a way For example scanning the TIOT If a dataset has been dummied out I get the following, without resorting to a TIOT scan: user@HOST: rexx say BPXWDYN( 'alloc dd(FOO) dummy' ); say BPXWDYN( 'info dd(FOO) inrtdsn(X)' ); say x 0 0 NULLFILE -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
We have an exit for DFSORT that scans TIOT to see if someone concatenated a DUMMY dataset as input. Here is what I believe to be the relevant snippet of code: *-* * THIS ROUTINE WAS ADDED TO CIRCUMVENT A PROBLEM CREATED BY DUMMY * * FILES SPECIFIED FOR SORTIN. * *-* DDSCAN DS0H EXTRACT FW,'S',FIELDS=(TIOT),MF=(E,EXTRACTL) L R5,FW USING IEFTIOT1,R5 MVC DDNAME,=CL8'SORTIN' SET DEFAULT DDNAME TMILEXF2A,ILEXFCPYQ. COPY APPLICATION ? BZDDSRCH A. NO, SEARCH FOR SORTIN MVC DDNAME,=CL8'SYSUT1' A. YES, SEARCH FOR SYSUT1 DDSRCH CLC TIOEDDNM,DDNAMEQ. DDNAME MATCH BEDDCON A. YES, CHECK IT OUT SRR0,R0 CLEAR REGISTER ICR0,TIOELNGHGET LENGTH OF THIS ENTRY ARR5,R0 BUMP TO NEXT ENTRY CLI TIOELNGH,X'00' Q. END OF TIOT ? BERETURN A. YES, GET OUT B DDSRCH A. NO, KEEP LOOKING DDCONDS0H CHECK FOR CONCATENATION * IF NOT CONCATENATION, THEN SKIP SRR0,R0 CLEAR REGISTER ICR0,TIOELNGHGET LENGTH OF THIS ENTRY ARR5,R0 BUMP TO NEXT ENTRY CLI TIOELNGH,X'00' Q. END OF TIOT ? BERETURN A. YES, GET OUT CLC TIOEDDNM,=CL8' ' Q. SORTIN CONCATENATED? BNE RETURN A. NO, FORGET IT SRR5,R0 A. YES, RESTORE DSECT POINTER * CHECK FOR DUMMY DD STATEMENT * NOTE: COULD ALSO BE DD * DDCHKCLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ? BEDDBAD A. NO, BAD DD SRR0,R0 CLEAR REGISTER ICR0,TIOELNGHGET LENGTH OF THIS ENTRY ARR5,R0 BUMP TO NEXT ENTRY CLI TIOELNGH,X'00' Q. END OF TIOT ? BERETURN A. YES, GET OUT CLC TIOEDDNM,=CL8' ' Q. SORTIN CONCATENATED? BEDDCHK A. YES, CHECK AGAIN B RETURN -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Butz Sent: Thursday, January 30, 2014 3:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dummy dataset Hi, Would anyone know if there is a way For example scanning the TIOT If a dataset has been dummied out Thanks Sent from my iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote: We have an exit for DFSORT that scans TIOT to see if someone concatenated a DUMMY dataset as input. Here is what I believe to be the relevant snippet of code: Comments inline. *-* * THIS ROUTINE WAS ADDED TO CIRCUMVENT A PROBLEM CREATED BY DUMMY * * FILES SPECIFIED FOR SORTIN. * *-* This PROBLEM sounds like a bug, which ought to be subject to APAR. DDSCAN DS0H EXTRACT FW,'S',FIELDS=(TIOT),MF=(E,EXTRACTL) L R5,FW USING IEFTIOT1,R5 MVC DDNAME,=CL8'SORTIN' SET DEFAULT DDNAME TMILEXF2A,ILEXFCPYQ. COPY APPLICATION ? BZDDSRCH A. NO, SEARCH FOR SORTIN MVC DDNAME,=CL8'SYSUT1' A. YES, SEARCH FOR SYSUT1 DDSRCH CLC TIOEDDNM,DDNAMEQ. DDNAME MATCH BEDDCON A. YES, CHECK IT OUT SRR0,R0 CLEAR REGISTER ICR0,TIOELNGHGET LENGTH OF THIS ENTRY ARR5,R0 BUMP TO NEXT ENTRY CLI TIOELNGH,X'00' Q. END OF TIOT ? BERETURN A. YES, GET OUT B DDSRCH A. NO, KEEP LOOKING DDCONDS0H CHECK FOR CONCATENATION * IF NOT CONCATENATION, THEN SKIP SRR0,R0 CLEAR REGISTER ICR0,TIOELNGHGET LENGTH OF THIS ENTRY ARR5,R0 BUMP TO NEXT ENTRY CLI TIOELNGH,X'00' Q. END OF TIOT ? BERETURN A. YES, GET OUT CLC TIOEDDNM,=CL8' ' Q. SORTIN CONCATENATED? BNE RETURN A. NO, FORGET IT SRR5,R0 A. YES, RESTORE DSECT POINTER * CHECK FOR DUMMY DD STATEMENT * NOTE: COULD ALSO BE DD * Does this mean that DD * (also DD DATA?) is problematic, even as DUMMY? What about DD PATH='...'? DDCHKCLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ? BEDDBAD A. NO, BAD DD Where's label DDBAD? SRR0,R0 CLEAR REGISTER ICR0,TIOELNGHGET LENGTH OF THIS ENTRY ARR5,R0 BUMP TO NEXT ENTRY CLI TIOELNGH,X'00' Q. END OF TIOT ? BERETURN A. YES, GET OUT CLC TIOEDDNM,=CL8' ' Q. SORTIN CONCATENATED? BEDDCHK A. YES, CHECK AGAIN B RETURN -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dummy dataset
We had some enterprising programmers that coded jobs something like: //SORTIN DD DSN=a.data.set.name,disp=shr // dd dd1,disp=shr // dd DD2,disp=shr // dd dsn=another.data.set.name,disp=shr And in the proc defaulted DD1, and DD2 to DUMMY so that they could dynamically change the input datasets. Problem was when they didn’t use them or only one of them, DFSORT stops reading input and the real datasets beyond the dummy ones never got read, and the JOB finished with RC(0), so it was obvious there was missing data. With the exit we abend the job. DDBADMVC SAVWTO(WTOLST1L),WTOLIST1 MVC SAVWTO+12(6),DDNAME SRR0,R0 LAR1,SAVWTO WTO MF=(E,(R1)) MVC SAVWTO(WTOLST2L),WTOLIST2 SRR0,R0 LAR1,SAVWTO WTO MF=(E,(R1)) ABENDLAR0,WORKLEN LOAD LENGTH OF WORKAREA LRR1,R11 LOAD ADDRESS OF WORKAREA FREEMAIN R,LV=(R0),A=(R1) FREE WORKAREA ABEND 53 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, January 30, 2014 3:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dummy dataset On Thu, 30 Jan 2014 20:18:05 +, Jousma, David wrote: We have an exit for DFSORT that scans TIOT to see if someone concatenated a DUMMY dataset as input. Here is what I believe to be the relevant snippet of code: Comments inline. *-* * THIS ROUTINE WAS ADDED TO CIRCUMVENT A PROBLEM CREATED BY DUMMY * * FILES SPECIFIED FOR SORTIN. * *-* This PROBLEM sounds like a bug, which ought to be subject to APAR. DDSCAN DS0H EXTRACT FW,'S',FIELDS=(TIOT),MF=(E,EXTRACTL) L R5,FW USING IEFTIOT1,R5 MVC DDNAME,=CL8'SORTIN' SET DEFAULT DDNAME TMILEXF2A,ILEXFCPYQ. COPY APPLICATION ? BZDDSRCH A. NO, SEARCH FOR SORTIN MVC DDNAME,=CL8'SYSUT1' A. YES, SEARCH FOR SYSUT1 DDSRCH CLC TIOEDDNM,DDNAMEQ. DDNAME MATCH BEDDCON A. YES, CHECK IT OUT SRR0,R0 CLEAR REGISTER ICR0,TIOELNGHGET LENGTH OF THIS ENTRY ARR5,R0 BUMP TO NEXT ENTRY CLI TIOELNGH,X'00' Q. END OF TIOT ? BERETURN A. YES, GET OUT B DDSRCH A. NO, KEEP LOOKING DDCONDS0H CHECK FOR CONCATENATION * IF NOT CONCATENATION, THEN SKIP SRR0,R0 CLEAR REGISTER ICR0,TIOELNGHGET LENGTH OF THIS ENTRY ARR5,R0 BUMP TO NEXT ENTRY CLI TIOELNGH,X'00' Q. END OF TIOT ? BERETURN A. YES, GET OUT CLC TIOEDDNM,=CL8' ' Q. SORTIN CONCATENATED? BNE RETURN A. NO, FORGET IT SRR5,R0 A. YES, RESTORE DSECT POINTER * CHECK FOR DUMMY DD STATEMENT * NOTE: COULD ALSO BE DD * Does this mean that DD * (also DD DATA?) is problematic, even as DUMMY? What about DD PATH='...'? DDCHKCLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ? BEDDBAD A. NO, BAD DD Where's label DDBAD? SRR0,R0 CLEAR REGISTER ICR0,TIOELNGHGET LENGTH OF THIS ENTRY ARR5,R0 BUMP TO NEXT ENTRY CLI TIOELNGH,X'00' Q. END OF TIOT ? BERETURN A. YES, GET OUT CLC TIOEDDNM,=CL8' ' Q. SORTIN CONCATENATED? BEDDCHK A. YES, CHECK AGAIN B RETURN -- gil
Re: Dummy dataset
On 2014-01-30 14:04, Jousma, David wrote: We had some enterprising programmers that coded jobs something like: //SORTIN DD DSN=a.data.set.name,disp=shr // dd dd1,disp=shr // dd DD2,disp=shr // dd dsn=another.data.set.name,disp=shr And in the proc defaulted DD1, and DD2 to DUMMY so that they could dynamically change the input datasets. Problem was when they didn’t use them or only one of them, DFSORT stops reading input and the real datasets beyond the dummy ones never got read, and the JOB finished with RC(0), so it was obvious there was missing data. With the exit we abend the job. Much as I detest that behavior (I'd much prefer that DUMMY behaved as DD SPACE=0), it's documented in JCL Ref. or Using Data Sets or somewhere, so WAD. Implementing DWIM, as you appear to be trying to do is an endless and mostly thankless task. And a sophisticated programmer who knowingly codes DUMMY (perhaps to disable some catenands for a test) has much reason to complain when experiencing behavior not only unexpected but also contrary to OS documentation. Have you tried (or suggested) using DD SPACE=0 in place of DUMMY? Even worse (also documented) Allocation substitutes DUMMY for PATH='/dev/null' or PATH='//dev/null', which I deem a colossal misapplication of DWIM by the OS designers. There was *no* reason to do that. They might as well, and with similar rationale substitute DUMMY for SPACE=0. Fortunately, Allocation is sufficiently dumb that it fails to recognize and override the otherwise equivalent PATH='/dev//null'. Do you ABEND only if DUMMY is followed by a non-dummy data set? There should be no problem if DUMMY (or several) is/are the last catenand(s). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
