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
al_chu...@optusnet.com.au 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 with the message: GET IBM-MAIN INFO
Search the archives at
Re: Migrating from z/OS V1.4 to z/OS V1.11
I guess I'm just getting mellow. ;) 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
Yeahhh that must be the reason. Now why didn't I think of that ?. Shane ... On Sun, May 9th, 2010 at 7:42 PM, Brian Westerman wrote: I guess I'm just getting mellow. ;) -- 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 7 May 2010 15:32:13 -0700, in bit.listserv.ibm-main you 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. How often have you found the Microsoft update site or knowledge base unavailable? In my admittedly limited experience both have always been available. -- 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: GSE Enterprise Security Meeting - 30th June 2010 - UK
All, resent with the correct URL later in the email. Mark 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.uk 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: Amazing article - Info on Collecting GDGs
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: Found an very elementary ALC program to do it and cleaned it and added some ways to understand what was happening along with making it cleaner. Plus I generate IDCAMS DELETE records that can be passed to a later step to get rid of the GDG files processed. We use it here when we can have a number of inbound data transmissions and the application needs to process the collection at night. We collect all the GDGs, put them into a backup GDG, and then process the file. If people are interested, let me know. thanks jim -- 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?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman -snip- 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. -unsnip 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! That must have been before the national debt grew to 95% of GDP. :-( -jc- -- 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?
In of505c9b75.fb50f3fa-on8525771c.005963db-8525771c.005a9...@tsys.com, on 05/07/2010 at 12:28 PM, Kirk Talman rkueb...@tsys.com said: I agree w/Shmuel. This is a display issue. ? I wrote that it is a numeric conversion issue, *not* a display issue. The problems were detected because the old machine was CDC 1604 which had the same precision as a 7094. The 7094 was 36 bits. The 1604 was 48 bits. The exponent may have been larger on the 1604, but not large enough for the mantissa to be the same as on the 7094. large CDC machine with I think 60/120 bit words. That would have been the 6600, at 60 bits. It was 4 bits shorter than the IBM 7030. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Member name format for z/OS directory as simulated PDS?
In g2la3a2b85f1005061653z25bec9a8h1ef64e95415ab...@mail.gmail.com, on 05/06/2010 at 07:53 PM, Tony Harminc t...@harminc.net said: It's been that way forever. Since before there were catalogues, I believe. AFAIK catalogs were there ab initio. Maybe this predates PDSs, or are they primordial? Primordial. -- 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...@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.
In a6b9336cdb62bb46b9f8708e686a7ea005c021b...@nrhmms8p02.uicnrh.dom, on 05/08/2010 at 07:11 AM, McKown, John john.mck...@healthmarkets.com said: Not any from IBM that I am aware of. IBM's method implys a stack of GDGs, There is no IBM's method, only IBM's method*s*; as Larry Wall claims, TMTOWTDI. In particular, you can read the catalog, extract the GDS names and process them individually. You can even maintain a record of what you've done with which. There is not an IBM way to process them from oldest to youngest. Sure there is; use, e.g., CSI, then allocate each GDS that is of interest and do what you want with it. If you're writing in Perl, use file globs. you could do it with their catsearch program. Is that a wrapper for CSI? -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Member name format for z/OS directory as simulated PDS?
In listserv%201005061635047352.0...@bama.ua.edu, on 05/06/2010 at 04:35 PM, Paul Gilmartin paulgboul...@aim.com said: Strange rule; I wonder what motivated it? CVOL. -- 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...@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.
In h2z4e2421a41005070416ra34dd776g2e8c933c79bbe...@mail.gmail.com, on 05/07/2010 at 12:16 PM, Sam Siegel s...@pscsi.net said: I'm commenting from the perspective of a developer. I'm not sure that I understand the distinctions being made. The SYSCATLG and CVOL[1] infrastructure that existed before VSAM maintained a tree with 8 character node names. The original VSAM catalog, and the ICF catalog that replaced it, used the entire name as a key and had no tree at all, other than the balanced tree used to implement keys in VSAM. It is my understanding that regardless of the type of catalog (discounting hfs and zfs file systems) mvs dataset names are just that. They are now; that wasn't always true. The restriction to 8 character index level was due to SYSCTLG and CVOL, and is still with us now that CVOL's are gone. And that while being similar to a unix/windows file name, They aren't. E.g., MVS does not allow you to catalog a name with imbedded blanks. Please explain in more detail so I can understand the distinction being made. The major difference is that the periods have special significance, even after the demise of CVOL's. There's not only the 8 character limit on index levels, there's also the handling of multi-level aliases (MLA's). [1] SYSCTLG was basically just a special CVOL at the root. -- 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...@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.
On Sat, 8 May 2010 20:45:54 -0400, Shmuel Metz (Seymour J.) wrote: They are now; that wasn't always true. The restriction to 8 character index level was due to SYSCTLG and CVOL, and is still with us now that CVOL's are gone. ... They aren't. E.g., MVS does not allow you to catalog a name with imbedded blanks. My understanding, from discussions here a couple years ago, is that several releases ago most such restrictions were removed from catalog services, but remained in JCL and other archaic APIs. A subsequent release introduced a PARMLIB option to control the facility in catalog services, making the default new-style (few restrictions). A yet subsequent release changed the default to be old-style (restricted). Apparently abhorrence of liberty is the modal attitude of z/OS programmers. -- 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: Amazing article.
Apparently abhorrence of liberty is the modal attitude of z/OS programmers. Why do you work on a platform you hate so much? Every one has some restriction that users of same don't like! Find another field and stop b*tching! - 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
Re: Amazing article.
On Sun, May 9, 2010 at 5:20 PM, Ted MacNEIL eamacn...@yahoo.ca wrote: Apparently abhorrence of liberty is the modal attitude of z/OS programmers. Why do you work on a platform you hate so much? Every one has some restriction that users of same don't like! Find another field and stop b*tching! Hear, hear. - 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 -- 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: Member name format for z/OS directory as simulated PDS?
On Sat, 8 May 2010 20:27:33 -0400, Shmuel Metz (Seymour J.) wrote: Strange rule; I wonder what motivated it? CVOL. The thread, which you trimmed excessively, as is your bad custom, concerned, for example, why, when the programmer codes: //SYSUT2 DD DISP=(,CATLG),DSN=FOO.BAR ... the data set is catalogued, whereas for: //SYSUT2 DD DISP=(,CATLG),DSN='FOO.BAR' ... the JCL C/I changes the disposition to KEEP. In both cases, identical data set names are created. In each case the name was acceptable to CVOL. Why should the C/I make the distinction? CVOL can't be the explanation. Cui bono? -- 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: Passing parameter(s) between IPCS verbexits
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 05/06/2010 09:16:02 AM: Any way to pass user parameters (addresses) between different IPCS verbexit routines ? On verbexit routine could use the Equate Symbol function of the Symbol Service to create a symbol in the dump directory, and another verbexit routine could use the Get Symbol function to retrieve the symbol. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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.
On Sun, 9 May 2010 16:20:53 +, Ted MacNEIL wrote: Apparently abhorrence of liberty is the modal attitude of z/OS programmers. The Dog in the Manger comes to mind. Why do you work on a platform you hate so much? I enjoy it greatly, twice a month. -- 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: Migrating from z/OS V1.4 to z/OS V1.11
In ofb84cb24f.4e30fca9-on8625771c.0055533e-8625771c.0055b...@rsh.net, on 05/07/2010 at 10:36 AM, Pat Mihalec pat_miha...@rush.edu said: I am running z/OS 1.4 and think of just jumping to z/OS 1.11, if they finally let me upgrade the software. Unless you have the tapes for intermediate releases in house, you have no choice but to make the big jump. Put the necessary work into planning and testing to minimize problems. Get everyone involved in the testing. -- 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...@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?)
In 1649177411-1273336230-cardhu_decombobulator_blackberry.rim.net-7911814...@bda026.bisx.prod.on.blackberry, on 05/08/2010 at 04:30 PM, Ted MacNEIL eamacn...@yahoo.ca said: What is (coded in the JCL): //SYSIN DD * /* Something other than an empty generated SYSIN DD *. The Devil is in the details, and the word generated in the question is an important detail. I realize that you don't believe that details are important. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEBCOP Y losing A PF authori sation in middle of JOB - etc
In snt113-w23320ee4efd864cf3534e3c6...@phx.gbl, on 04/20/2010 at 09:18 PM, john gilmore john_w_gilm...@msn.com said: An authorized step cannot load a member from an unauthorized library; and an unauthorized step cannot of course load a member from an authorized library. There is no of course, because unauthorized programs routinely load members from authorized libraries, e.g., SYS1.LINKLIB and the rest of the linklist. They do not, of course, acquire any privileges by doing so. -- 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...@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?)
In 003501caeed4$23ad0720$6b0715...@org, on 05/08/2010 at 10:30 AM, Charles Mills charl...@mcn.org said: 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 would consider it a bug if the following didn't give me an empty SYSIN: //SYSPRINT DD SYSOUT=* /* Certainly there would be no contradiction in having it work as I expect. Ditto on the generated SYSIN DD *. Why SYSIN? Because IBM has had a convention since the early OS/360 days to use that name[1] for utility input. Why not generate //GILMARTN DD * Because that wouldn't have been as useful, given the convention for utility input. 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 *. I doubt that it was gratuitous; it was almost certainly the result of customer requests, either individually or through user groups. [1] Well, one used SYSLIN. -- 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...@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?)
In 201005082105.esp94...@c2beaomr05.btconnect.com, on 05/08/2010 at 10:05 PM, Terry Sambrooks terry.sambro...@btclick.com said: 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. Device Allocation occurs regardless. In both cases the UCB address in the TIOT will be zero, although other fields will differ. -- 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...@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?)
In listserv%201005081120217744.0...@bama.ua.edu, on 05/08/2010 at 11:20 AM, Paul Gilmartin paulgboul...@aim.com said: How can there ever be an empty generated SYSIN DD *? The obvious way, if it works, is to place a /* statement after another JCL statement. The SYSIN DD * is generated only if there's a line in the JCL causing it to be generated, hence it's nonempty. There is no hence as you worded it. If the line causing //SYSIN DD * to be generated is a /* line, then an empty data set is what you should get. And I believe that it has been written here that DFSORT treats SYSIN DD DUMMY differently from an empty non-DUMMY SYSIN. If true it were a grievous fault. That's worse than barfing on an empty SYSLIN. Similarly, DUMMY in a concatenation behaves differently from an empty non-DUMMY data set in the same concatenation. Do you mean only that it's different from an empty data set with the same attributes as the rest of the concatenation, or that it's different from an unlike attributes concatenation not involving DUMMY? If the latter, is there still a difference when the DCB has the unlike attributes bit set? -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: emptiness
On Sat, 8 May 2010 18:14:27 +, john gilmore wrote: 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. Uncharacteristically, three of us are in substantial agreement here. 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. IEBCOPY is distinctive in supplying a default rather than ABENDing when SYSIN is not allocated: IEBC COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT (Peculiar message code; not in MC. Perhaps it's self-explanatory.) Perhaps this could be improved, as you suggest, by adding messages: IEBI Control file SYSINnot allocated. ... or IEBI Control file SYS00042 not allocated. ... indicating that an alternate ddname was processed but the file was not allocated. Otherwise in an execution summary one of: IEBI Control file SYSINcontained 0 records. IEBI Control file SYS00042 contained 0 records. IEBI Control file SYSINcontained 5 records. IEBI Control file SYS00042 contained 5 records. ... indicating what DDNAME was used, and how much was read. This would have considerably helped the OP diagnosing his problem. HLASM, for example, does well in providing all such information in a summary. -- 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: IEBCOP Y losing A PF authori sation in middle of JOB - etc
On Sun, 9 May 2010 11:36:03 -0400, Shmuel Metz (Seymour J.) wrote: In snt113-w23320ee4efd864cf3534e3c6...@phx.gbl, on 04/20/2010 at 09:18 PM, john gilmore said: An authorized step cannot load a member from an unauthorized library; and an unauthorized step cannot of course load a member from an authorized library. There is no of course, because unauthorized programs routinely load members from authorized libraries, e.g., SYS1.LINKLIB and the rest of the linklist. They do not, of course, acquire any privileges by doing so. And that's true regardless that the member is marked AC=1. (That was a lapse entirely uncharacteristic of John G. I'll trust that it was a lapse of attention, not a gap in knowledge.) -- 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?)
On Sun, 9 May 2010 10:52:28 -0400, Shmuel Metz (Seymour J.) wrote: How can there ever be an empty generated SYSIN DD *? The obvious way, if it works, is to place a /* statement after another JCL statement. By experiment, it does not. It might be notionally more consistent if it did. The SYSIN DD * is generated only if there's a line in the JCL causing it to be generated, hence it's nonempty. There is no hence as you worded it. If the line causing //SYSIN DD * to be generated is a /* line, then an empty data set is what you should get. And I believe that it has been written here that DFSORT treats SYSIN DD DUMMY differently from an empty non-DUMMY SYSIN. If true it were a grievous fault. That's worse than barfing on an empty SYSLIN. I misstated; it was ICEGENER, not exactly DFSORT. Linkname: LISTSERV 15.0 - IBM-MAIN Archives URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0801L=ibm-mainamp;P=R69541 From: Frank Yaeger yae...@us.ibm.com Date: Tue, 15 Jan 2008 14:48:05 -0800 (Replying to John McKown) Yes, DUMMY or NULLFILE or no SYSIN DD is required to have ICEGENER use DFSORT copy. ICEGENER does not consider an empty data set to be the same as DUMMY. I suppose it could, but it doesn't and AFAIK you're the first person to ever mention it as a concern. I don't think I'd want to change it at this point because if I did, somebody else would surely complain that it doesn't work the way it used to. :-) Similarly, DUMMY in a concatenation behaves differently from an empty non-DUMMY data set in the same concatenation. Do you mean only that it's different from an empty data set with the same attributes as the rest of the concatenation, or that it's different from an unlike attributes concatenation not involving DUMMY? If the latter, is there still a difference when the DCB has the unlike attributes bit set? Linkname: 12.1.6.8 z/OS V1R10.0 MVS JCL Reference URL: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b680/12.1.6.8 12.1.6.8 Do Not Concatenate Data Sets after a DUMMY Data Set If you define a data set using the DUMMY parameter, do not concatenate other data sets after it. When the processing program asks to read a dummy data set, the system takes an end-of-data set exit immediately and ignores any data set that might be concatenated after the dummy. ... which is not the behavior of an empty non-DUMMY data set, regardless of attributes. -- 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: /usr/lib/nls/charmap/IBM-1047 (plus announcement / ad, so delete if you're offended)
Tony Harminc wrote: On 1 April 2010 12:06, Steve Comstock st...@trainersfriend.com wrote: David Bond at Tachyon software has some terrific pages about codepages on their website. A lot of my current work uses this page as a starting point: http://www.tachyonsoft.com/uc.htm#U00F0 Based on this page I see: UCS-4: 00DE LATIN CAPITAL LETTER THORN Glyph: Ş Lowercase: 00FE UTF-8: C3 9E GB-18030: 8130 8937 ASCII 8D: 00861 ASCII DE: 01252 ISO-8859-1 ISO-8859-10 ISO-8859-15 ASCII E8: 00850 00858 EBCDIC 4A: 00871 01149 EBCDIC AE: 00037 00273 00274 00275 00277 00278 00280 00281 00284 00285 00297 00500 00924 01005 01047 01140 01141 01142 01143 01144 01145 01146 01147 01148 and also: UCS-4: 00FE LATIN SMALL LETTER THORN Glyph: ş Uppercase: 00DE UTF-8: C3 BE GB-18030: 8130 8B36 ASCII 95: 00861 ASCII E7: 00850 00858 ASCII FE: 01252 ISO-8859-1 ISO-8859-10 ISO-8859-15 EBCDIC 8E: 00037 00273 00274 00275 00277 00278 00280 00281 00284 00285 00297 00500 00924 01005 01047 01140 01141 01142 01143 01144 01145 01146 01147 01148 EBCDIC C0: 00871 01149 So it seems 1047 supports both upper case and lower case thorn. Well, ya' never know! :-) It's not so much a matter of CP 1047 supporting them. CP 1047, like CP 037 or CP 819, are encodings of what IBM calls Character Set (CS) 647, and this character set, no matter what codepoints (byte values) are assigned to each character, does contain both cases of thorns. Or put another way, there is no way that CP 1047 can support or not support anything different from what CP 037, 285, 1047, 819, etc. etc. support. Tony H. OK, point well taken. OTOH, focus is usually around CP not CS, so I have focused on this approach for ... And now for something entirely different! Today we are officially announcing our first non-training-related product. Would you be kind enough to pass this email on to the appropriate decision makers in your shop? . It is time to bring the world closer together. The Trainer's Friend is annoucing a new software package, the File RePackager, that is a file to file utility with capabilities to allow the mainframe to work with files from any source platform and / or to prepare files to be sent to any target platform. This software runs on z/OS (on z9 or later hardware) and supports any of these as input and any of these as output: * QSAM Fixed length records * QSAM Variable length records (not VBS, VA, VBA) * z/OS UNIX files + filedata=text - delimiter NL, CR, LF, LFCR, or CRLF + filedata=binary - fixed length records - prefix of 1-, 2-, or 4-byte binary length field + filedata=record (for z/OS 1.11 or later) Copy from any supported format to any supported format Change record length + pad with spaces or user-specified character + truncate trailing blanks + truncate trailing non-blanks with warning + prevent truncation of trailing non-blanks by skipping records that would be truncated or by stopping the run For files will all character data, translate codepage from any supported code page to any supported codepage + Supported code pages: - EBCDIC 037, 924, 1047, 1140 - ASCII 367, 819 (ISO-8859-1), 923 (ISO-8859-15) For z/OS UNIX files, change record delimiter License File RePackager for 1-, 2-, 3-, 4-, or 5-years for any site (any number of processors, any MIPS / MSU ratings, unlimited usage at that site). Support automatically included for the duration of a license. A 30-day free trial offering is available. Also included is a free upgrade to version 2 for licenses for 1- or 2- years and free upgrade to versions 2 and 3 for license for 3-, 4-, or 5- years. (Big picture: version 2 adds Unicode support (UTF-8, UTF-16 and UTF-32) and version 3 adds markup support to enable creation of XML, HTML, and XHTML files from flat files.) Visit http://www.trainersfriend.com/TTFUtils/FRP-home.html for more details. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * z/OS application programmer training + Instructor-led on-site classroom based classes + Course materials licensing + Remote contact training + Roadshows + Course development -- 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
Accessing Cross Memory Storage in REXX
The October 2001 issue of the Xephon MVS Update 181 contained REXX Cross Memory assembler subroutine code allowing access to information in other memory spaces by ASID. I was never able to get this to operate properly. Has anyone had any success with this or do you have some equivalent code that you can share ??? Regards Lorne Dudley Queen's University Kingston, Ontario Canada -- 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: Accessing Cross Memory Storage in REXX
On Sun, May 9, 2010 at 9:16 PM, Lorne Dudley dudl...@queensu.ca wrote: The October 2001 issue of the Xephon MVS Update 181 contained REXX Cross Memory assembler subroutine code allowing access to information in other memory spaces by ASID. I was never able to get this to operate properly. Has anyone had any success with this or do you have some equivalent code that you can share ??? Highly unlikely unless I'm missing something obvious. The only LEGAL way to access memory in some other address space is via an SRB. You need to be in sup state and key zero to schedule an SRB and REXX runs key 8 and problem state. But if we're allowed to cheat then I'll play :-) PS I didn't know there were any mainframe people at Queens... -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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
