HDTenEightyP/NetNews huggingface dataset:
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 16 Nov 1992 14:06:00 EST
From:         "Bill Rodatz 656-0264" <RODATZ@CLEMSON.BITNET>
Subject:      DFHSM and the SETSYS MONITOR Control Parm

In the process of expanding DFHSM's Migration Control Data Set (MCDS),
I have been reviewing the SETSYS MONITOR control parm which we have
incorporated into the HSM initialization deck.  This parm causes
DFHSM to send informational messages to the system console.  We
currently use
                SETSYS MONITOR(MCDS(100,20))
to direct DFHSM to generate WTOs to the system console when the 20th
extent of the MCDS (which is a VSAM data set) is 100% full.  The MONITOR
control parameter has another optional parm called, NEWCOPY, which is
briefly mentioned on page 300 of the System Programmer's Command
Reference for release 2.6.  Does anyone know what this parm is and when
it is appropriate to use it?  The command reference is too vague on this
matter.

Also, the System Programmer's Command Reference indicates that
when used, NEWCOPY updates the DFHSM Multiple-Processing-Unit Control
Record.  I can find no reference of such a record in the DFHSM
Diagnosis Reference for Data Areas and Control Blocks manual.  There is
however, a reference to a Multiple-Host Processor Control Record which
contains space usage data about the various control data sets, but I
receive a DFHSM error message when I attempt to display this record.
Are these records the same?

I would greatly appreciate any information.  Thankyou.

Bill Rodatz
Systems Programmer                 BITNET:  RODATZ@CLEMSON
Clemson University               INTERNET:  RODATZ@CLEMSON.EDU
From: ah739@cleveland.Freenet.Edu (Leslie J. Somos)
Newsgroups: bit.listserv.ibm-main
Subject: Re: Deleting messages in SYS1.BRODCAST
Date: 18 Nov 1992 16:28:26 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: ah739@cleveland.Freenet.Edu (Leslie J. Somos)
NNTP-Posting-Host: slc10.ins.cwru.edu


In a previous article, ASMIDCC@VM7CG.HQ.AF.MIL (Dennis Caffi) says:

>  I have what I hope is a simple question. Is there a way to delete mail
>for a specific userid from SYS1.BRODCAST ?  I don't want to log on to the
>userids in question. One userid has over 1400 messages queued and another
>userid is no longer in use because the person has left but the id is
>still around. Thanks in advance for the help !
>
>-------------------------------------------------------------------------
>Dennis Caffi                                IP: asmidcc@vm7cg.hq.af.mil
>Senior MVS Systems Programmer
>Grumman Data Systems / U.S. Air Force
>Pentagon, Washington, D.C.
>-------------------------------------------------------------------------
>

The proper way to get rid of TSO userids is through the TSO ACCOUNT command
DELETE subcommand.  I once had a large group of userids to delete, so
I used ISPF 3.1 on SYS1.SYSUADS to delete them.  Bad idea.  After strange
symptoms (messages not reaching valid userids, etc.) and an unscheduled
IPL, we issued the SYNC (synchronize) command, and everything was OK
from then on.  SYNC compares the UADS and BRODCAST data sets, and cleans
out messages for users who no longer exist.  (We would have been OK if
I had issued SYNC immediately after using ISPF 3.1 to delete userids.)

So: for the userid no longer in use, go ahead and delete it with the
TSO ACCOUNT command DELETE subcommand.  This will not affect their
data sets on disk, but will clean up BRODCAST for you.

For the other userid, do an ACCOUNT command LIST subcommand to see how
they are defined.  Then delete it (which cleans up BRODCAST), and
re-define it.

--
Leslie J. Somos    ah739@cleveland.Freenet.edu

Newsgroups: bit.listserv.ibm-main
From: j-grout@uxa.cso.uiuc.edu (grout john robert)
Subject: Re: How to expand SYS1.LOGREC
Reply-To: j-grout@uiuc.edu
Organization: University of Illinois at Urbana
Date: Wed, 18 Nov 1992 15:23:38 GMT

Leonard D Woren <LDW@USCMVSA.BITNET> writes:

>As someone else already replied, you can just rename the existing one,
>allocate and initialize a new one, and IPL.  Don't forget to dump the
>data from the old one before you scratch it.  And yes, don't scratch
>the old one before IPLing.  It's opened only at IPL time.  Also note
>that you can't move SYS1.LOGREC because it has absolute disk addresses
>in it.  I heard a story of one site that reorganized sysres and ended
>up with logrec data in the middle of an SMP dataset because they
>didn't re-init logrec.

So one should allocate SYS1.LOGREC with DSORG=PSU (for physical
sequential unmovable) to tell the system (and any helpful
reorganization utilities) that it can't be moved.
-- 
John R. Grout						j-grout@uiuc.edu
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
From: kashyap@enuxhb.eas.asu.edu (Praveen Kashyap)
Subject: IEW and ADW
Keywords: I-CASE, IEW and ADW
Organization: Arizona State University
Date: Mon, 16 Nov 1992 15:35:23 GMT



 I have a few questions about the Information engineering and AD
 workbench tools. They are:
1.	How are they different from Integrated CASE tools?
2.	Can you give few examples of these tools?
3.	I would like some information on these tools. Any information
	would be highly appreciated.



Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Fri, 20 Nov 1992 16:19:56 EDT
From:         Zoltan Forray <SSTSZXF@VCUVM1.BITNET>
Subject:      Re: How to expand SYS1.LOGREC
              17 Nov 1992 10:35:32 GMT from <ost@UNI-MUENSTER.DE>

In my manual MVS/XA SPL: SYS1.LOGREC Error Recording GC28-1162-2 on page
2-4 under "Changing Space Allocation for SYS1.LOGREC" it states (and shows an
example) that all you have to do is run a batch job that does an IEHPROGM
to SCRATCH and UNCATLG the SYS1.LOGREC d/s and then runs PGM=IFCDIP00 to
allocate the new SYS1.LOGREC and initialize it.

However, you must read the caveats, which make statements like "If you use the
preceding procedure and an uncorrectable channel error occurs after the
SYS1.LOGREC dataset has been scratched but before it has been reallocated, the
system is marked ineligible for IPL procedures"

The book then goes on to explain about doing stand-alone restores of the SYSRES
pack to get back the SYS1.LOGREC dataset. Of course, it also says that you must
immediately IPL after you create or restore the SYS1.LOGREC d/s.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Date: Sat, 21 Nov 1992 18:41:07 EST
From: Jerry Bryan <BRYAN@wvnvm.wvnet.edu>
Newsgroups: bit.listserv.ibm-main
Subject: Re: IEFBR14


In article <IBM-MAIN%92112020533595@RICEVM1.RICE.EDU>, Leonard D Woren
<LDW@USCMVSA.BITNET> says:
>
>On Fri, 20 Nov 1992 10:18:54 PST,
>   "Mark C. Lawrence" <M.Lawrence@STANFORD.BITNET> said:
>> (lots of detailed explanation deleted)
>> Now, suppose that you specified UNIT and VOL on the DD statement.  Since
>> volume information is available, MOD is treated (for allocation/disposition
>> purposes) like OLD.
>
>Interesting.  I'm glad I tested this before replying.  I was going to
>claim that this was incorrect, but now I think that MVS is just
>broken.  I got interesting results from the tests.  In both batch and
>TSO, with or without a SPACE specification, it cataloged the dataset
>WITHOUT CREATING IT when MOD,CATLG was used for a non-existant dataset
>and a specific volume was coded.
>

I am not sure why you consider this behavior of MVS to be broken.
It is exactly what would happen if you said (OLD,CATLG) and did not
open the data set, for example by running IEFBR14.


Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 17 Nov 1992 01:47:00 PST
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: MVS/XA 2.2.3 External Writer Documentation?

I don't remember if MVS/XA has "SPL: System Modifications", or if that
manual started in MVS/ESA.  There is a chapter in System Modifications
on the External Writer.

/Leonard
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 17 Nov 1992 00:17:40 EST
From:         "Wayne S. Mery" <wsm0@LEHIGH.EDU>
Subject:      re: where is VSE-L?
Comments: To: vm-util@ohstvm1.bitnet, ibm-main@ricevm1.bitnet

Someone on VM-UTIL asked, 'where is VSE-L?'

Reporting from a rather cool GUIDE conference in Atlanta ...

We are no longer on BITNET, LEHIIBM1 does not exist.  But DOSVSE-L is alive
and well.

DOSVSE-L@lehigh.edu is the correct address (not VSE-L).  For those of you not
on the internet you can get to us through your favorite bitnet<>internet
gateway.  In any event you should be able to get to us as:
    dosvse-l%lehigh.edu@cunyvm.bitnet

Likewise, you will see most if not all of our outgoing mail to bitnet come out
as:
    userid%name@CUNYVM.BITNET


To subscribe to DOSVSE-L send mail (you cannot use 'TELL') to:
    listserv@lehigh.edu
with the command line:
    sub DOSVSE-L your-name

Call, write to me direct or on VM-UTIL or IBM-MAIN so I will know
if you had trouble.

Regards,
Wayne
DOSVSE-L list owner  (215) 758-3983

-------------------------------------------------------------------------------
Wayne S. Mery           Systems Programmer      Lehigh University Computing Ctr
WSM0@Lehigh.edu  (Unix)                         LUWSM@IBM1.cc.lehigh.edu  (VM)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Fri, 20 Nov 1992 13:13:51 CST
From:         Barry Finkel <B19141@ANLVM.CTD.ANL.GOV>
Subject:      IEFBR14 - Extra Credit

>(a)  Originally, IEFBR14 did only a "BR  14".  It did not set a
>     return code of any kind in register 15.  Therefore, a PTF
>     was issued to add the "SR  15,15" prior to the "BR 14".  Thus,
>     the size of IEFBR14 was doubled overnight. :-)
Yes and no -- The size of the IEFBR14 code increased from two bytes
to four, but the size of the load module remained at the minimum 8
bytes.

>(b)  It was not originally link-edited as being refreshable and
>     reusuable.  Another PTF was issued (or so the story goes) to
>     relink-edit IEFBR14 with those attributes.
I had not heard that.  I will see if I can check that.
----------------------------------------------------------------------------
Barry S. Finkel
Computing and Telecommunications Division
Argonne National Laboratory               BITNET:   B19141@ANLVM
9700 South Cass Avenue                    Internet: B19141@ANLVM.CTD.ANL.GOV
Building 221, Room B223                   Phone:    (708) 252-7277
Argonne, IL   60439-4844                  Facsimile:(708) 252-5983
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Fri, 20 Nov 1992 16:07:36 EDT
From:         Zoltan Forray <SSTSZXF@VCUVM1.BITNET>
Subject:      Re: Do you know any quick and easy way to transfer files

Since PS/2's come with serial ports, you could do something simple like
getting LAPLINK (or any software similar to it....there are hundreds of them
around....even free/shareware) and then get a NULL-MODEM cable. That way you
would be transfering at the cable/serial port speed and not concerned about
modems/phone lines/etc.

In fact, if you decide to get LAPLINK (I think the company is called Traveling
Software), they will sell you a null-modem cable, too. Just tell them the
machine type. They should know what you need.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 17 Nov 1992 13:50:44 -0500
From:         "C. Christopher Maurizio" <maurizio@MGH.COM>
Subject: Re: How to expand SYS1.LOGREC
Comments: To: IBM-MAIN@vm.gmd.de

One way to expand the SYS1.LOGREC dataset is to create a second IPL pack with
an expanded SYS1.LOGREC dataset and then IPL from that pack.  That is the way
we would do it.

:
/exit
/
 J





 9 9 9 9  9 9
 9 9
 9 9
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Fri, 20 Nov 1992 14:24:05 PST
From:         "Mark C. Lawrence" <M.Lawrence@STANFORD.BITNET>
Subject:      IEFBR14, or, Much Ado About Nothing
Comments: To: ibm-main@ricevm1.bitnet

REPLY TO 11/20/92 10:59 FROM IBM-MAIN@RICEVM1.BITNET "IBM Mainframe Discussion
list": Re: IEFBR14

On FRI 11/20/92, Dave Ulrick <A01DGU1@NIU.BITNET> said,
>Subject:      Re: IEFBR14
>
>I've heard of two bugs, actually:
>
>(a)  Originally, IEFBR14 did only a "BR  14".  It did not set a
>     return code of any kind in register 15.  Therefore, a PTF
>     was issued to add the "SR  15,15" prior to the "BR 14".  Thus,
>     the size of IEFBR14 was doubled overnight. :-)

Right.  Just think, if they ever put in their standard copyright
notice, the size will increase by a factor of at least 10.  Or is this
a public domain program? :-)

>(b)  It was not originally link-edited as being refreshable and
>     reusuable.  Another PTF was issued (or so the story goes) to
>     relink-edit IEFBR14 with those attributes.

I hadn't heard that one.  But actually, it is re-enterable (and the
current version is so marked).  After all, you wouldn't want to clog
up precious core with several copies of this enormous program :-)

Mark C. Lawrence
Systems Programmer     Internet: M.Lawrence@Forsythe.Stanford.edu
Stanford Data Center     Bitnet: M.Lawrence@STANFORD
Stanford, CA 94305-4136     Tel: (415) 723-4976

To:  IBM-MAIN@RICEVM1.BITNET
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Sun, 22 Nov 1992 01:04:00 PST
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: IEFBR14

On Sat, 21 Nov 1992 18:41:07 EST,
   Jerry Bryan <BRYAN@WVNVM.WVNET.EDU> said:
> I am not sure why you consider this behavior of MVS to be broken.
> It is exactly what would happen if you said (OLD,CATLG) and did not
> open the data set, for example by running IEFBR14.

(If you open the dataset, you'll abend S213, however this is
irrelevant to what follows.)

I consider it broken because MOD will be treated as NEW if the dataset
doesn't exist, OLD-Extend if it does exist, unless you point to a
specific volume, in which case it's only treated as OLD-Extend.  (And
on Tuesday with a full moon you need a full fizbin.  {*})
Specifically, why will MOD create the dataset on a generic/esoteric
unit, but not on a specific volume???  The only other organization
that can write arcane rules like that is the IRS, and we know
*they're* unreasonable.  This behaviour is a *perfect* example of why
users consider MVS too complicated.

/Leonard

{*}  For those non-Trekkers, in "A Piece of the Action", Kirk is
making up rules of the game as he goes along, just to confound the bad
guys.  Each time they think they understand his rules, he invents
another exception.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Fri, 20 Nov 1992 19:05:00 PST
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: IEFBR14

On Fri, 20 Nov 1992 12:56:00 CST,
   Dave Ulrick <A01DGU1@NIU.BITNET> said:
> I've heard of two bugs, actually:
>
> (a)  Originally, IEFBR14 did only a "BR  14".  ... Therefore, a PTF
>      was issued to add the "SR  15,15" prior to the "BR 14".  Thus,
>      the size of IEFBR14 was doubled overnight. :-)

I doubt if it was overnight, even though it only required adding one
instruction.  Most of us could have done it overnight...  IBM
probably closed it "Sugg", then upon appeal marked it "Under Study",
then eventually changed it to "Long Range Consideration", and
eventually fixed it in release n+2.  If you think I'm joking, call up
and open an incident over TRANSMIT and RECEIVE having BLKSIZE=3120
hard-coded for the LOG files.  That's closed SUGG.  It will not be
fixed in TSO/E V2R4, scheduled for delivery 1Q93.

> (b)  It was not originally link-edited as being refreshable and
>      reusuable.  Another PTF was issued (or so the story goes) to
>      relink-edit IEFBR14 with those attributes.
>
> I heard all of this second-hand, of course, so I will happily
> stand corrected.  If I'm right, though, there have been a total
> of *two* bugs in IEFBR14.

I think this topic pops up on this list periodically.  And I also have
some recollection of someone claiming there's now a new problem with
IEFBR14 -- it's not marked RMODE(ANY) AMODE(ANY).  Anyone wanna try
for another APAR?  ;-)

Suppose that you're running AMODE31, and you LOAD and BASSM to
IEFBR14.  Won't you get control back in AMODE24?  This is a "rock and
a hard place" problem, and as such it's probably not APAR-able.  If
IEFBR14 were changed to return via BSM, then someone else would APAR
the fact that if you call it via BALR, it fails, and they'd have to
mark the PTF PE and change the code back.  Anyway, IEFBSM14 doesn't
have the same ring...

/Leonard
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 16 Nov 1992 13:19:43 CST
From:         Barry Finkel <B19141@ANLVM.CTD.ANL.GOV>
Subject:      MVS/XA 2.2.3 External Writer Documentation?

Where in the MVS/XA 2.2.3 documentation will I find information about
the MVS External Writer (modules IASxxxxx)?  I could not find a reference
manual nor a logic manual, but I could have missed it in the multitude of
SRLs and PLMs.
----------------------------------------------------------------------------
Barry S. Finkel
Computing and Telecommunications Division
Argonne National Laboratory               BITNET:   B19141@ANLVM
9700 South Cass Avenue                    Internet: B19141@ANLVM.CTD.ANL.GOV
Building 221, Room B223                   Phone:    (708) 252-7277
Argonne, IL   60439-4844                  Facsimile:(708) 252-5983
Xref: sparky bit.listserv.ibm-main:2666 bit.listserv.asm370:174
From: ac413@cleveland.Freenet.Edu (Thomas C. Hance)
Newsgroups: bit.listserv.ibm-main
Subject: Re: problem opening a vsam file
Date: 19 Nov 1992 03:41:16 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc10.ins.cwru.edu


All they need to do is Delete/Define the cluster, write a Low-
value record to the base cluster, define the AIX and path, 
do the BLDINDEX, and then run their program.
-- 
Laws to suppress tend to strengthen what they would prohibit.
This is the fine point on which all the legal professions in
history have based their job security.
                                            Frank Herbert
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Organization: University of Louisville
qqstribution: local
Date:         Fri, 20 Nov 1992 13:50:51 EST
Comments:     Warning -- original Sender: tag was NNEWS@ULKYVM
From:         "Donald S. Teiser" <DSTEIS01@ULKYVM.BITNET>
Subject:      Re: XYPLEX-KERMIT ) a little more info provided

I worked with Xyplex several months ago to help them upgrade their
terminal server software to support transparent mode.  They succeeded
and supplied us with the new code.  If you do not yet have this version
of their code (I don't know the version number, since it was pre-release),
contact their technical support people and request it.

*********************************************************************
    **    Donald S. Teiser                 voice: (502) 588-7994     *
    **    Tech Support for VMS & Ultrix    fax:   (502) 588-8896     *
    **    University of Louisville         Louisville, KY 40292      *
    **    dsteis01@ulkyvm.louisville.edu                             *
*********************************************************************
Organization: Bar-Ilan University Computing Center, Israel
Date: Sun, 22 Nov 1992 16:30:30 IST
From: Doron Shikmoni <P85025@BARILVM.BITNET>
Newsgroups: bit.listserv.ibm-main
Subject: Re: KERMIT CMS/XYPLEX/MODEM/PC Communication trouble ! HELP!

In article <168A4E6E4.SYSDMCKE@VM.UWP.EDU>, SYSDMCKE@VM.UWP.EDU says:
>
>Hello, I have a problem with KERMIT CMS v4.2.3 talkin to another KERMIT thru
>a ZYPLEX (TCP/IP terminal server) and out to a modem.  If anyone has a
>similiar
>configuration, please let me know.

If you are using the TN3270 option of the Xyplex, then this indeed is
problem (of the Xyplex 3270 code). Let Xyplex know your sentiments; they
should have a solution to this problem.

Doron
Newsgroups: bit.listserv.ibm-main
From: vjh21@cas.org (Vince Herried ext 2877)
Subject: Re:      DFHSM Recalls & Batch
Organization: Chemical Abstracts Service
Date: Fri, 20 Nov 1992 12:46:23 GMT

We've been running v2.6.0 and have not had the problem you mentioned.
Please re-post with the jcl of one of the failing jobs included.
(By the way, pgm=iefbr14 will have trouble ending with anything but
rc=0 since it only consists of two instructions <sr r15,r15; br r14>).

You may wish to consider using GDGs instead, they seem to be more
convienent in may cases.

By the way, just because you don't have access to IBMLINK doesn't mean
you can't call them up at 1-800-237-5511.

The number to call is BR 549.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
				 |     Vincent Herried  (614) 447-3600 x 2877
				 |     Chemical Abstracts Service
 _____________________           |     P.O. Box 3012
(_)________________   \          |     Columbus, OH 43210-0012
  ________________|\   \         |
 (_)______________\_\   \        |     Current thought: People who cannot be
   ______________________\       |     understood are geniuses, so management
  (_)____________________|       |     assigns them the toughest projects.
				 |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 23 Nov 1992 16:37:00 PST
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: Need help patching executable load module or unloaded module

You need to update the module in place.  There is special directory
information for load modules that you must be losing when you read the
module, update it, and write a new copy.  Even if you patch an unloaded
copy, you must be sure to preserve the block structure that IEBCOPY
writes -- it's marked RECFM=VS, but you must not allow data to be
moved from one block to another, split, or combined.

My recommendation would be for you to have a separate CSECT, or at
least an external entry point for the expiration date (encoded), and
supply AMASPZAP statements to update it.  This is the safest way to
do it, and is (unfortunately) quite common.  (Unfortunately because I
think that expiration dates in code is tacky.)


/Leonard
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Fri, 20 Nov 1992 12:56:00 CST
From:         Dave Ulrick <A01DGU1@NIU.BITNET>
Subject:      Re: IEFBR14

On Fri, 20 Nov 1992 10:18:54 PST "Mark C. Lawrence" <M.Lawrence@STANFORD.BITNET>
   said:
>ever ABEND.  [for extra credit:  IEFBR14 is the only program to have had only
>one bug in its entire history.  What was it?]

I've heard of two bugs, actually:

(a)  Originally, IEFBR14 did only a "BR  14".  It did not set a
     return code of any kind in register 15.  Therefore, a PTF
     was issued to add the "SR  15,15" prior to the "BR 14".  Thus,
     the size of IEFBR14 was doubled overnight. :-)

(b)  It was not originally link-edited as being refreshable and
     reusuable.  Another PTF was issued (or so the story goes) to
     relink-edit IEFBR14 with those attributes.

I heard all of this second-hand, of course, so I will happily
stand corrected.  If I'm right, though, there have been a total
of *two* bugs in IEFBR14.

Dave

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Ulrick                        Bitnet:    A01DGU1@NIU   (MVS/ESA)
Northern Illinois University                  A01DGU1@NIUCS (VM/SP)
DeKalb, IL, USA                    Internet:  a01dgu1@mvs.niu.edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU