Re: ISPF table library cannot be freed
Hi Robert
Wow fantastic, Your suggestion is working!
Your solution makes sense and matches with the manual statement Paul copied
in this email trail earlier -
'Issuing a table service with a LIBRARY parameter containing a ddname that
does not exist causes the previous library to be closed'
Now I can switch the table dataset.
Thanks Robert!
Al
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Robert Birdsall
Sent: Friday, 7 May 2010 9:24 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ISPF table library cannot be freed
Don't give up that easily.
Try this:
address ISPExec "TbStats BADTABLE Library(BADLIB)"
Don't change the BADTABLE and BADLIB unless you really have a library or
table of that name :)
Here are the relevant lines extracted from my code:
address ISPExec
address TSO "Alloc f(arc) dsn('"ArcDSN"')" ArcVol "SHR REUSE"
"TbOpen" LKWMTbl "NOWRITE Library(ARC)"
"TbGet" LKWMTbl
"TbClose" LKWMTbl
"TbStats BADTABLE Library(BADLIB)" /* workaround for ISPF bug */
address TSO "Free f(arc)"
On Thu, 6 May 2010 21:15:32 +1000, Al Chu
wrote:
>Thanks Paul for the information. I was suspecting that but didn't look up
>the manual. :(
>I was trying to use various tables by realloating different table datasets
>to the same table DD name without changing 'supplied rexx' which contains
>TBOPEN/TBCLOSE.
>It seems not possible now.
>Thanks heaps again, you saved my time.
>
>Al
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf
>Of Beesley, Paul
>Sent: Thursday, 6 May 2010 8:56 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: ISPF table library cannot be freed
>
>From the ISPF manual :
>
>IKJ56861I FILE ddname NOT FREED, DATA SET IS OPEN
>
>If the LIBRARY parameter is used with a table service, the user is not
>able to free the ddname for the table library pointed to by the
>LIBRARY parameter. ISPF keeps this library open until a new ddname is
>used in the LIBRARY parameter with another table service. ISPF
>functions in this manner for performance reasons.
>
>Issuing a table service with a LIBRARY parameter containing a ddname
>that does not exist causes the previous library to be closed and
>therefore allows the user to free the previous ddname. Use of CONTROL
>ERRORS RETURN may be used to guard against a severe error as a result
>of a ddname not existing.
>
>Hope this helps
>
>Regards
>Paul
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>Behalf Of Al Chu
>Sent: 06 May 2010 11:49
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: ISPF table library cannot be freed
>
>Hi Binyamin
>
>TBOPEN and TBOPEN have RC=0. FREE FI(AAA) doesn't work once TBOPEN
and
>TBCLOSE on the table were executed.
>If I backout to the READY mode then run ISPF and FREE FI(AAA) before
>running
>TBOPEN/TBCLOSE, the FREE FI works.
>I suspect that ISPF opens the file when TBOPEN is issued and keep it
>open
>even after TBCLOSE is executed. I guess TBCLOSE just flushes out some
>buffers and does some other bits related to the table handling but
>doesn't
>do 'MVS CLOSE' on the DCB.
>Does my guess make sense? If so, any way to 'mvs CLOSE' it?
>
>Thanks in advance
>
>Al
>
>
>___
>
>Atos Origin and Atos Consulting are trading names used by the Atos Origin
>group. The following trading entities are registered in England and Wales:
>Atos Origin IT Services UK Limited (registered number 01245534) and Atos
>Consulting Limited (registered number 04312380). The registered office for
>each is at 4 Triton Square, Regents Place, London, NW1 3HG.The VAT No. for
>each is: GB232327983
>
>This e-mail and the documents attached are confidential and intended solely
>for the addressee, and may contain confidential or privileged information.
>If you receive this e-mail in error, you are not authorised to copy,
>disclose, use or retain it. Please notify the sender immediately and
delete
>this email from your systems. As emails may be intercepted, amended or
>lost, they are not secure. Atos Origin therefore can accept no liability
>for any errors or their content. Although Atos Origin endeavours to
>maintain a virus-free network, we do not warrant that this transmission is
>virus-free and can accept no liability for any damages resulting from any
>virus transmitted. The risks are deemed to be accepted by everyone who
>communicates with Atos Origin by email.
>___
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu wit
Re: JCL continuation lines limit?
Paul Gilmartin pisze: Is there any limit to the number of continuation lines in a JCL statement? I'm unaware of any, and I just tried an EXEC statement where the PARM contained over 1000 continuation lines, and it executed without error. I conclude that there is no practical limit, if any limit whatever. IMHO there is no practical limit. BTW: How did you the above? PARM is limited to 100 characters, did you put empty (0-lcharacter long) continuations? BTW2: In practice it is very hard to exceed 10-20 lines (with exception for multiple volume serials), so 100 or 1000 lines limit can be considered as non-practical one. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Emptiness (was: IEBCOPY ignoring SYSIN override?)
Hi, In thinking about the following Post, they may be similar in our eyes but are surely not the same: What is (coded in the JCL): //SYSIN DD * /* It is similar to: //SYSIN DD DUMMY But, what does IEBCOPY think? It was always my understanding that they would not be the same as the system had made a decision before IEBCOPY gets the opportunity. That decision means that SYSIN DD * will cause Device Allocation to occur, whereas SYSIN DD DUMMY will not. Kind Regards - Terry Director KMS-IT Limited 228 Abbeydale Road South Dore Sheffield S17 3LA UK Reg : 3767263 Outgoing e-mails have been scanned, but it is the recipients responsibility to ensure their anti-virus software is up to date. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Emptiness (was: IEBCOPY ignoring SYSIN override?)
On Sat, 8 May 2010 10:30:22 -0700 Charles Mills wrote: :>Ditto on the generated SYSIN DD *. Why SYSIN? Why not generate //GILMARTN DD :>* -- it's equally valid. For a language (JCL) that can be so d*mned :>persnickety at times, it seems odd to decide gratuitously that some random :>card in the jobstream was meant to be input to SYSIN DD *. Historical reasons. It allowed for placing a card deck without needing to specify a JCL statement. Look at the linkage editor proc and notice a // DD DDNAME=SYSIN to allow card input as well. -- Binyamin Dissen 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Emptiness (was: IEBCOPY ignoring SYSIN override?)
This was rejected by listserv without this line as looking like a command. //SYSPRINT DD SYSOUT=* /* //DD DD DSN=..etc Will produce an empty GENERATED SYSIN I agree I don't like the artifact which I think really stems from the days of cards. Saves one card :) On another internal nostalgic thread I found this old example of a common student style rundeck depending on the feature. //SPITBOL JOB(),'DAVE GIBNEY',NOTIFY=DAG$SD //PROCLIB DD DSN=SYS3.PPROCS,DISP=SHR //SPITBOL EXEC SPITBOL,REGION=1000K,TIME=(,15) > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Charles Mills > Sent: Saturday, May 08, 2010 10:30 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Emptiness (was: IEBCOPY ignoring SYSIN override?) > > Gil's right. I was speaking about a problem described by others not > immediately witnessed by myself and I spoke too hastily. A "generated > SYSIN > DD *" should never produce an empty dataset; that would be a > contradiction. > > I agree with Gil. An empty SYSIN or other input dataset is in most cases a > normal situation. It's nothing to do. After you process everything in the > SYSIN dataset, you exit. If that's right away, so be it. An informative > message would be nice, but not some behavior imagined to be productive. > IEBCOPY could allow commands in the PARM= field. That would simplify life > for those who did not want to set up a control stream in a dataset -- for > example, dynamic callers and PROCs. > > Ditto on the generated SYSIN DD *. Why SYSIN? Why not generate //GILMARTN > DD > * -- it's equally valid. For a language (JCL) that can be so d*mned > persnickety at times, it seems odd to decide gratuitously that some random > card in the jobstream was meant to be input to SYSIN DD *. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf > Of Paul Gilmartin > Sent: Saturday, May 08, 2010 9:20 AM > To: IBM-MAIN@bama.ua.edu > Subject: Emptiness (was: IEBCOPY ignoring SYSIN override?) > > On Sat, 8 May 2010 06:41:11 -0700, Charles Mills wrote: > > > >Small IEBCOPY complaint: it would be nice if IEBCOPY said "ddname EMPTY, > >IGNORING" or something like that. Judging from the replies, a bunch of > folks > >have been burned by an empty generated SYSIN DD *. More clues might help. > > > How can there ever be an "empty generated SYSIN DD *"? The SYSIN DD * > is generated only if there's a line in the JCL causing it to be generated, > hence it's nonempty. > > But, I take a contrary view. I so often generate JCL and SYSIN files > with scripts that I prefer to have the lower boundary condition > treated as unexceptional. Examples: > > Linkage editor given empty SYSLIN used to do nothing and exit with > RC=0. For certain inputs my scripts used to generate empty SYSLIN > and the behavior of linkage editor worked fine. Nowadays, Binder > given empty SYSLIN does nothing useful and terminates with RC=12, > so I must check for empty SYSLIN and bypass the call to Binder. I > am not swayed by performance arguments here; I preferred the simplicity > of linkage editor's behavior. > > SMP/E MCS treates "FILES( 0 )" as a syntax error, so I must check > whether I have generated relfiles and suppress the FILES option > if there are none. > > SuperC comparing two empty files gives a nonzero return code. > > Etc. In such cases it would be simpler for me if that boundary > condition were treated as normal. > > And I believe that it has been written here that DFSORT treats > SYSIN DD DUMMY differently from an empty non-DUMMY SYSIN. Ouch! > This seems to have been done deliberately, but there ought to > be a more intuitive way of conveying the desired information > to DFSORT. > > Similarly, DUMMY in a concatenation behaves differently from an > empty non-DUMMY data set in the same concatenation. Ouch! > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at
Re: IBMLink and CA Support planned outages this weekend
It's my birthday. They all took the day off! znor...@ca.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Brian Peterson Sent: Saturday, May 08, 2010 Saturday 11:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IBMLink and CA Support planned outages this weekend EMC support is *also* down today > The Service Request system will be unavailable on Saturday, May 8 from > 6:00 a.m. to 10:00 p.m. (EDT). EMC apologizes for the inconvenience. Hmmm On Fri, 7 May 2010 17:31:39 -0500, Brian Peterson wrote: >Quite a coincidence > > >Planned IBMLink Outage - May 7 > >5 May 2010 > >This is to inform you that IBMLink will have a planned outage starting on >Friday, May 7th at 9:00 PM Eastern Time through Saturday, May 8th at 9:00 AM >Eastern Time (Saturday, May 8th from 01:00 UTC to 13:00 UTC). > >and > > >Maintenance Outage: > >On Saturday, May 08, 2010, from 08:00 until 10:30 p.m. ET (GMT-4), CA will >be conducting maintenance updates on CA Support Online. CA Support Online >will be unavailable during this time. We apologize for any inconvenience >this may cause. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amazing article.
That's what I was afraid of. Sounds like there's a need for some good GDG
enhancement requests!
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO USA
P: 303-235-1403
On 5/8/2010 at 7:54 AM, in message <4be56d2c.8000...@acm.org>, "Joel C. Ewing"
wrote:
> We had exactly the same issue with user-demand of production jobs where
> users need to stage data for the run and multiple runs with different
> data may need to be queued when the job can't run immediately. Standard
> GDG JCL support which, when you don't know how many generations exist,
> only makes it possible to address the most current generation, or all
> generations concatenated in "backwards" LIFO order, is pretty useless
> for this purpose.
> Our solution was to have a "STAGE" step in the demand process that
> queues the data as the next generation of a job-specific GDG, and a
> "DESTAGE" step for the production job that uses REXX code to locate the
> oldest GDG generation, copy it to a fixed file name for processing by
> the job stream, and delete it. In effect we use this process to turn
> GDG's into a First-In-First-Out stack, which makes them much more
> useful. As long as you know the queue depth can't exceed 255 (max GDG
> limit value), it works quite well.
>
> Another approach that we have taken for some EDI data interchange
> processes to/from other installations is to use some form of timestamp
> as part of the file name to guarantee uniqueness and imply processing
> order. Since JCL doesn't include features to support this approach,
> this generally requires some application on the MVS side that is able to
> do dynamic allocation and catalog query (e.g., REXX in batch TSO) in
> order to work with dynamic dataset names and select which files to process.
>Joel C Ewing
>
> On 05/08/2010 07:12 AM, McKown, John wrote:
>>> -Original Message-
>>> From: IBM Mainframe Discussion List
>>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick
>>> Sent: Friday, May 07, 2010 5:48 PM
>>> To: IBM-MAIN@bama.ua.edu
>>> Subject: Re: Amazing article.
>>>
>>> It is useful to be able to receive the "second" generation
>>> before processing the "first". It is less useful that if
>>> this happens you have to make a JCL change to be able to
>>> process the older generation once a newer generation has been created.
>>>
>>> Are there standard ways of dealing with this?
>>>
>>> Signed, new MVS person.
>>> --
>>>
>>> Frank Swarbrick
>>
>> Not any from IBM that I am aware of. IBM's method implys a "stack" of GDGs,
> where (0) is always the newest one created. So if you're JCL refers to the
> current gen, it gets the youngest. There is not an IBM way to process them
> from oldest to youngest. Now, in a z/OS UNIX paradigm, using DoveTailed
> Technologies (love those people!), you could do it with their "catsearch"
> program. Similar to:
>>
>> #!/bin/sh
>> catsearch MY.GDG.BASE.G* |\
>> while read gdg_entry; do
>>my_program ${gdg_entry}
>> end
>>
>>
>> You could also probably embed this is a REXX program similar to:
>>
>> /* rexx */
>> stdout.0=0
>> stderr.0=0
>> call bpxwunix "/usr/local/bin/catsearch TSH009.PDS.P*",,stdout.,stderr.
>> do i=0 to stdout.0
>>say "Found DSN:"stdout.i
>> end
>> do i=0 to stderr.0
>>say "Error:"stderr.i
>> end
>>
>> Where I have the "found DSN" SAY instruction, run your application.
>>
>> --
>> John McKown
>> Systems Engineer IV
>> IT
>>
>> Administrative Services Group
>>
>> HealthMarkets(r)
> ...
>>>
The information contained in this electronic communication and any document
attached hereto or transmitted herewith is confidential and intended for the
exclusive use of the individual or entity named above. If the reader of this
message is not the intended recipient or the employee or agent responsible for
delivering it to the intended recipient, you are hereby notified that any
examination, use, dissemination, distribution or copying of this communication
or any part thereof is strictly prohibited. If you have received this
communication in error, please immediately notify the sender by reply e-mail
and destroy this communication. Thank you.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: emptiness
As I hope has now been agreed, an empty data set, an empty pool, stack, or queue, an empty whatever is not per se an error. There are circumstances in which the user of a whatever may wish to treat its empty state as an error, but this is for that user, not the whatever, to decide; and as a matter of good design the whatever should provide an indicator, typically a count that may be zero, from which its empty state can be inferred unambiguously. John Gilmore Ashland, MA 01721-1817 USA _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBMLink and CA Support planned outages this weekend
EMC support is *also* down today > The Service Request system will be unavailable on Saturday, May 8 from > 6:00 a.m. to 10:00 p.m. (EDT). EMC apologizes for the inconvenience. Hmmm On Fri, 7 May 2010 17:31:39 -0500, Brian Peterson wrote: >Quite a coincidence > > >Planned IBMLink Outage - May 7 > >5 May 2010 > >This is to inform you that IBMLink will have a planned outage starting on >Friday, May 7th at 9:00 PM Eastern Time through Saturday, May 8th at 9:00 AM >Eastern Time (Saturday, May 8th from 01:00 UTC to 13:00 UTC). > >and > > >Maintenance Outage: > >On Saturday, May 08, 2010, from 08:00 until 10:30 p.m. ET (GMT-4), CA will >be conducting maintenance updates on CA Support Online. CA Support Online >will be unavailable during this time. We apologize for any inconvenience >this may cause. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Emptiness (was: IEBCOPY ignoring SYSIN override?)
Gil's right. I was speaking about a problem described by others not immediately witnessed by myself and I spoke too hastily. A "generated SYSIN DD *" should never produce an empty dataset; that would be a contradiction. I agree with Gil. An empty SYSIN or other input dataset is in most cases a normal situation. It's nothing to do. After you process everything in the SYSIN dataset, you exit. If that's right away, so be it. An informative message would be nice, but not some behavior imagined to be productive. IEBCOPY could allow commands in the PARM= field. That would simplify life for those who did not want to set up a control stream in a dataset -- for example, dynamic callers and PROCs. Ditto on the generated SYSIN DD *. Why SYSIN? Why not generate //GILMARTN DD * -- it's equally valid. For a language (JCL) that can be so d*mned persnickety at times, it seems odd to decide gratuitously that some random card in the jobstream was meant to be input to SYSIN DD *. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Saturday, May 08, 2010 9:20 AM To: IBM-MAIN@bama.ua.edu Subject: Emptiness (was: IEBCOPY ignoring SYSIN override?) On Sat, 8 May 2010 06:41:11 -0700, Charles Mills wrote: > >Small IEBCOPY complaint: it would be nice if IEBCOPY said "ddname EMPTY, >IGNORING" or something like that. Judging from the replies, a bunch of folks >have been burned by an empty generated SYSIN DD *. More clues might help. > How can there ever be an "empty generated SYSIN DD *"? The SYSIN DD * is generated only if there's a line in the JCL causing it to be generated, hence it's nonempty. But, I take a contrary view. I so often generate JCL and SYSIN files with scripts that I prefer to have the lower boundary condition treated as unexceptional. Examples: Linkage editor given empty SYSLIN used to do nothing and exit with RC=0. For certain inputs my scripts used to generate empty SYSLIN and the behavior of linkage editor worked fine. Nowadays, Binder given empty SYSLIN does nothing useful and terminates with RC=12, so I must check for empty SYSLIN and bypass the call to Binder. I am not swayed by performance arguments here; I preferred the simplicity of linkage editor's behavior. SMP/E MCS treates "FILES( 0 )" as a syntax error, so I must check whether I have generated relfiles and suppress the FILES option if there are none. SuperC comparing two empty files gives a nonzero return code. Etc. In such cases it would be simpler for me if that boundary condition were treated as normal. And I believe that it has been written here that DFSORT treats SYSIN DD DUMMY differently from an empty non-DUMMY SYSIN. Ouch! This seems to have been done deliberately, but there ought to be a more intuitive way of conveying the desired information to DFSORT. Similarly, DUMMY in a concatenation behaves differently from an empty non-DUMMY data set in the same concatenation. Ouch! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Emptiness (was: IEBCOPY ignoring SYSIN override?)
On Sat, 8 May 2010 16:30:39 +, Ted MacNEIL wrote: >>How can there ever be an "empty generated SYSIN DD *"? The SYSIN DD * is >>generated only if there's a line in the JCL causing it to be generated, >hence it's nonempty. > >What is (coded in the JCL): > >//SYSIN DD * >/* > That's coded (as you say), not generated. To wit, there's no message: //SYSIN DD * GENERATED STATEMENT (And I consider that behavior a misfeature. It allows jobs to execute and produce undesired results with typos that I'd prefer to see treated as JCL errors.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Emptiness (was: IEBCOPY ignoring SYSIN override?)
>How can there ever be an "empty generated SYSIN DD *"? The SYSIN DD * is >generated only if there's a line in the JCL causing it to be generated, hence it's nonempty. What is (coded in the JCL): //SYSIN DD * /* It is similar to: //SYSIN DD DUMMY But, what does IEBCOPY think? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Emptiness (was: IEBCOPY ignoring SYSIN override?)
On Sat, 8 May 2010 06:41:11 -0700, Charles Mills wrote: > >Small IEBCOPY complaint: it would be nice if IEBCOPY said "ddname EMPTY, >IGNORING" or something like that. Judging from the replies, a bunch of folks >have been burned by an empty generated SYSIN DD *. More clues might help. > How can there ever be an "empty generated SYSIN DD *"? The SYSIN DD * is generated only if there's a line in the JCL causing it to be generated, hence it's nonempty. But, I take a contrary view. I so often generate JCL and SYSIN files with scripts that I prefer to have the lower boundary condition treated as unexceptional. Examples: Linkage editor given empty SYSLIN used to do nothing and exit with RC=0. For certain inputs my scripts used to generate empty SYSLIN and the behavior of linkage editor worked fine. Nowadays, Binder given empty SYSLIN does nothing useful and terminates with RC=12, so I must check for empty SYSLIN and bypass the call to Binder. I am not swayed by performance arguments here; I preferred the simplicity of linkage editor's behavior. SMP/E MCS treates "FILES( 0 )" as a syntax error, so I must check whether I have generated relfiles and suppress the FILES option if there are none. SuperC comparing two empty files gives a nonzero return code. Etc. In such cases it would be simpler for me if that boundary condition were treated as normal. And I believe that it has been written here that DFSORT treats SYSIN DD DUMMY differently from an empty non-DUMMY SYSIN. Ouch! This seems to have been done deliberately, but there ought to be a more intuitive way of conveying the desired information to DFSORT. Similarly, DUMMY in a concatenation behaves differently from an empty non-DUMMY data set in the same concatenation. Ouch! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSAM FILE CATALOGING
--- Hello all, We currently have a z/OS V1.7 that we will be migrating to V1.11. I have 169 volumes that I want to copy to the z/OS V1.11 system and use for testing purposes. These volumes contain our Quality Assurance datasets both VSAM and Sequential. We are not sharing disks or catalogs for obvious reasons. We have a usercat set up on the V1.11 system that contains the alias of these files. I can do a disk to disk copy of the volumes to the V1.11 system then vary those volumes online to the V1.11 system and vary offline to the V1.7 system. Getting the volumes to the V1.11 system for testing isn't the issue. What I need to do is catalog the files that are on those volumes to the V1.11 user catalog. I can do the sequential files via ISPF if I need to, but I'm not sure of the vsam files especially those files that span volumes and not just extents. Has anyone had any experience with cataloging multi extent or multi volume vsam files in this fashion? Any help would really be appreciated, and any gotcha's would be appreciated also. --- If you're MOVING the datasets, rather than copying them, take a good hard look at REPRO MERGECAT in the IDCAMS manual. It will save you a LOT of time and heartache. It'll also work for the NON-VSAM files you're moving. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VVDS references dead catalog. OK?
-- Is there any plus to trying to delete all references to "dead" catalogs from the VVDS on all my volumes? Or is this another, "who cares?" (except for people with OCD). Complete waste of time. If you're suffering from OCD, DELVVR might be the route to go, if you have too much time on your hands. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Output from programs which normally produce reports - an idea
-- OK, the subject sucks. But it is Friday. And this could be considered on topic, I think. I've been doing some DASD cleanup prep work. I've been using T-REX to look at catalogs and VVDSes. T-REX produces some really nice reports. But one thing that I inevitably do is download them to my Linux workstation for massaging and reformatting. I do similar processing of IDCAMS listings as well. I was just thinking that a nice option might be to be able to tell these reporting programs how to format some things for me. In particular, with a report that is line oriented - just give me a single header line and "n" lines of data. I don't wan't any page headers or footers. Also, separate each data element on a line with a user defined separator character (such as a |). Why? I can then easily parse that in REXX or Perl or Python or Java or COBOL or ... . It might even be nice to tell the program which variables that I'm interested in, so it produces only those values in the line. For truly advanced reports, such as where there is a report line for something, then multiple more lines indented under it such as for repeating group subordinate information, then perhaps an XML format would be usable. If a vendor were to adopt this policy for report programs, do you think it would enhance their reputation in the market place and so perhaps enhance their sales? -- IIRC, you can supply an "exit" to IDCAMS that will be permitted to examine each line of output before it goes to SYSPRINT. Look at invoking IDCAMS from another program via LINK or LOAD/CALL/DELETE. You should be able to reformat or delete report lines from the exit. If ISV's were to implement a similar mechanism, it might enhance customer satisfaction, even if it doesn't significantly increase sales. I would have KILLED for that sort of mechanism in the RMF Report Writer many times over, when I had to extract numbers and enter them into a spread sheet for long-term graphing. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: (may o r may not be on topi c) Floatin g point ar ithmetic?
-- It's hardly unusual to have fractional cents in calculations, which are rounded to the nearest cent only for the final, billable number. Doubtless the most common thing - but a very common thing indeed - priced in small fractions of cents is telephone minutes. Lots of carriers will have a price of e.g. 1.63 cents (i.e. $0.0163) per minute to call a particular country. There's big trouble if the numbers are smoothed over too early. - Agricultural commodities and futures are priced in dollars, cents and eighths of cents. As an example, corn could be priced a $5.40 3/8 per bushel. In this instance, the unit traded is a contract of 5,000 bushels, so rounding becomes a non-issue. But precision is VERY important because you're shifting vast amounts of money between bank accounts during the trading day. At one time, CBOT was moving enough money around to pay the National Debt every week! Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: XMIT MANAGER
Right... it was my question/OP about running XMIT Manager on Win7 (64 bit). What I did (at the instruction of another kind list member) was to set up Windows XP Mode in MS Virtual PC. I installed the 32 bit version of XMIT Manager there and it worked gr8. The version of Windows that you are running on the host determines whether you have MS Virtual PC available without additional fees, I believe. All the best, Scott T. Harder Mainframe Services, Inc. Naples, FL > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Hal Merritt > Sent: Thursday, May 06, 2010 9:58 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: XMIT MANAGER > > Part of the discussion a short time ago on this topic included a > suggestion to adjust the proprieties on Windows so that it will run the > program in compatibility mode. There was no response if that worked or > another solution was found. > > HTH and good luck > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of David Cartwright > Sent: Thursday, May 06, 2010 4:50 AM > To: IBM-MAIN@bama.ua.edu > Subject: XMIT MANAGER > > Slightly OT I'm afraid, but does anyone know if there is a 64 bit version > of Xmit > Manager? I no longer have a 32 bit Windows available (talk about dead > media!). > The home website seems to have gone and it won't install from an old > (months) > download. I want to look inside file 172 to find the stuff I did on cache > management which seems to be a hot topic at the moment. > Any ideas? > > TIA > DC > > > NOTICE: This electronic mail message and any files transmitted with it are > intended > exclusively for the individual or entity to which it is addressed. The > message, > together with any attachment, may contain confidential and/or privileged > information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution > is strictly prohibited. If you have received this message in error, please > immediately advise the sender by reply email and delete all copies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VVDS references dead catalog. OK?
I clean them up just to eliminate the possibility of a significant Diagnose error being lost in the clutter. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of McKown, John Sent: Friday, May 07, 2010 11:42 AM To: IBM-MAIN@bama.ua.edu Subject: VVDS references dead catalog. OK? Is there any plus to trying to delete all references to "dead" catalogs from the VVDS on all my volumes? Or is this another, "who cares?" (except for people with OCD). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amazing article.
We had exactly the same issue with user-demand of production jobs where
users need to stage data for the run and multiple runs with different
data may need to be queued when the job can't run immediately. Standard
GDG JCL support which, when you don't know how many generations exist,
only makes it possible to address the most current generation, or all
generations concatenated in "backwards" LIFO order, is pretty useless
for this purpose.
Our solution was to have a "STAGE" step in the demand process that
queues the data as the next generation of a job-specific GDG, and a
"DESTAGE" step for the production job that uses REXX code to locate the
oldest GDG generation, copy it to a fixed file name for processing by
the job stream, and delete it. In effect we use this process to turn
GDG's into a First-In-First-Out stack, which makes them much more
useful. As long as you know the queue depth can't exceed 255 (max GDG
limit value), it works quite well.
Another approach that we have taken for some EDI data interchange
processes to/from other installations is to use some form of timestamp
as part of the file name to guarantee uniqueness and imply processing
order. Since JCL doesn't include features to support this approach,
this generally requires some application on the MVS side that is able to
do dynamic allocation and catalog query (e.g., REXX in batch TSO) in
order to work with dynamic dataset names and select which files to process.
Joel C Ewing
On 05/08/2010 07:12 AM, McKown, John wrote:
>> -Original Message-
>> From: IBM Mainframe Discussion List
>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick
>> Sent: Friday, May 07, 2010 5:48 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: Amazing article.
>>
>> It is useful to be able to receive the "second" generation
>> before processing the "first". It is less useful that if
>> this happens you have to make a JCL change to be able to
>> process the older generation once a newer generation has been created.
>>
>> Are there standard ways of dealing with this?
>>
>> Signed, new MVS person.
>> --
>>
>> Frank Swarbrick
>
> Not any from IBM that I am aware of. IBM's method implys a "stack" of GDGs,
> where (0) is always the newest one created. So if you're JCL refers to the
> current gen, it gets the youngest. There is not an IBM way to process them
> from oldest to youngest. Now, in a z/OS UNIX paradigm, using DoveTailed
> Technologies (love those people!), you could do it with their "catsearch"
> program. Similar to:
>
> #!/bin/sh
> catsearch MY.GDG.BASE.G* |\
> while read gdg_entry; do
>my_program ${gdg_entry}
> end
>
>
> You could also probably embed this is a REXX program similar to:
>
> /* rexx */
> stdout.0=0
> stderr.0=0
> call bpxwunix "/usr/local/bin/catsearch TSH009.PDS.P*",,stdout.,stderr.
> do i=0 to stdout.0
>say "Found DSN:"stdout.i
> end
> do i=0 to stderr.0
>say "Error:"stderr.i
> end
>
> Where I have the "found DSN" SAY instruction, run your application.
>
> --
> John McKown
> Systems Engineer IV
> IT
>
> Administrative Services Group
>
> HealthMarkets(r)
...
--
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEBCOPY ignoring SYSIN override?
Thanks all. Resolved. Stupid programmer trick. Alan hit it the closest. Short version: SYS1 was empty. Longer version: lots of complex layers of code obscured the fact that the combination of calls I was doing led to SYS1 being opened for *input* and then "written" into, resulting in an empty file. Small IEBCOPY complaint: it would be nice if IEBCOPY said "ddname EMPTY, IGNORING" or something like that. Judging from the replies, a bunch of folks have been burned by an empty generated SYSIN DD *. More clues might help. Thanks again everyone who pitched in. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Starr, Alan Sent: Friday, May 07, 2010 4:44 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEBCOPY ignoring SYSIN override? Charles, I've played with this a bit more and I strongly believe that IEBCOPY is picking up DD=SYS1 for SYSIN but that DD=SYS1 is either NOT allocated or it's allocated to DUMMY. Those are the only two conditions that I could find in which "COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT" appears. As I mentioned, try issuing an OPEN against DD=SYS1 before the ATTACH. If that works, then issue a READ to validate that it's not NULL. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBMLink and CA Support planned outages this weekend
On Fri, 7 May 2010 17:31:39 -0500, Brian Peterson wrote: > >On Saturday, May 08, 2010, from 08:00 until 10:30 p.m. ET (GMT-4), CA will > Strange (and slightly ambiguous) mixture of notations. I'd expect to see either: from 8:00 a.m. until 10:30 p.m. or: from 08:00 until 22:30 ... leading zero is rarely used with 12-hour notation. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IBM optim solution
Hi all Is there anyone use IBM optim solution to clone & rename production datasets for UAT/DEV testing environment? includes VSAM & QSAM? Thanks for sharing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amazing article.
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick
> Sent: Friday, May 07, 2010 5:48 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Amazing article.
>
> It is useful to be able to receive the "second" generation
> before processing the "first". It is less useful that if
> this happens you have to make a JCL change to be able to
> process the older generation once a newer generation has been created.
>
> Are there standard ways of dealing with this?
>
> Signed, new MVS person.
> --
>
> Frank Swarbrick
Not any from IBM that I am aware of. IBM's method implys a "stack" of GDGs,
where (0) is always the newest one created. So if you're JCL refers to the
current gen, it gets the youngest. There is not an IBM way to process them from
oldest to youngest. Now, in a z/OS UNIX paradigm, using DoveTailed Technologies
(love those people!), you could do it with their "catsearch" program. Similar
to:
#!/bin/sh
catsearch MY.GDG.BASE.G* |\
while read gdg_entry; do
my_program ${gdg_entry}
end
You could also probably embed this is a REXX program similar to:
/* rexx */
stdout.0=0
stderr.0=0
call bpxwunix "/usr/local/bin/catsearch TSH009.PDS.P*",,stdout.,stderr.
do i=0 to stdout.0
say "Found DSN:"stdout.i
end
do i=0 to stderr.0
say "Error:"stderr.i
end
Where I have the "found DSN" SAY instruction, run your application.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets(r) is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The
MEGA Life and Health Insurance Company.SM
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Migrating from z/OS V1.4 to z/OS V1.11
I'm surprised it took Brian so long to respond; he's constantly berating us that such "non (IBM) sanctioned" upgrades are fine if handled sensibly. Just don't screw it up - guess whose private parts will be on the chopping block. Can't really blame customers for being spooked about N+2. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GSE Enterprise Security Meeting - 30th June 2010 - UK
Hi, I am pleased to announce the next meeting of the GSE Enterprise Security Group on the 30th June 2010. Full details and Agenda can be found at http://www.racf.gse.org.uk/future.html If you wish to attend the meeting please send me an email and I will add you to the list. We are also launching a new Security Group website www.racf.gse.org and I would welcome any feedback or suggestions for content or changes to the current pages. Kind Regards, Mark Mark Wilson | Technical Director RSM Partners Limited t. +44 (0) 7768 617006 | e. ma...@rsmpartners.com www.rsmpartmers.com GSE Information Large Systems Working Group Chairman www.lsx.gse.org.uk GSE UK Conference Manager www.gse.org.uk/tyc e. mark.wil...@gse.org.uk -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: XMIT MANAGER
you don't need a 32bit OS to run Xmit Manager, just to install it with the current setup package. I'm building a new setup package for it that will handle installation under 32bit or 64bit and it should be ready as soon as I finish reading the directions for NSIS. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Migrating from z/OS V1.4 to z/OS V1.11
Hi, There is absolutely no reason to make multiple jumps, especially when you can keep the environments contained as you had originally pointed out. It's a big jump, but no matter which point you picked for your jump point, it would still be a large undertaking. The good news is that it's been done hundreds of times, (well, 1.4 to 1.10 has, but I've found that 1.11 doesn't present any significant installation issues over 1.10). I would suggest that you do get the migration guides for the interim releases and read the changes and procedures. Keep notes and you WILL find that some things are changed multiple times, in which case you might want to think about all of the changes and prepare for things. You didn't say what non-IBM vendors you had to worry about, and in most cases, that's the biggest worry. I've performed hundreds of upgrades and if you have any questions, please feel free to ask. One thing that you might have issues with (and this doesn't matter how many releases you jumped), is that there are some changes to the JES2 exits. If you aren't using any of them, then you can skip my warning. You can share catalogs and volumes, but if you are going to make a habit out of it, them make sure you have GRS or a substitute to protect yourself. If it's a controlled sharing, then you won't have anything to worry about. You can share the RACF database as well, but I have found that it's normally better to create a new one and fill parts of it from the old one instead of just copying the whole thing. it's not very difficult and it will allow you to remove a lot of built up crud from the previous releases. Since you are keeping things in monoplexes, you don't have to worry about the Couple datasets or anything. Your SMS and WLM environments should be audited, but only if you have been quite busy with those environments over the years because there are some slight changes that can bite you, but again, it's nothing major, nothing will die, you just might get some seemingly strange results. Your biggest obstacle will be taking advantage of all of the new stuff that has been added to the system in the newer releases. You may find that things you had to do with vendor software are no longer necessary so be mindful of whether or not you might really need the alternate vendor any more. remember, while it seems like a big deal, it's really just like any other upgrade, if you are careful and pay attention to the details, you will sail right through it. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
AUTO: James Obrizok is out of the office on vacation (returning 05/10/2010)
I am out of the office until 05/10/2010. If you require immediate assistance, please contact my backup Fernando Vega on 1-404-238-4580 or Jon Regitsky on 1-404-238-3134. Thank you. Note: This is an automated response to your message "IBM-MAIN Digest - 6 May 2010 to 7 May 2010 (#2010-127)" sent on 5/8/10 0:00:03. This is the only notification you will receive while this person is away. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
