Re: APF Authorized Code/Libraries.

[Binyamin Dissen]

On Sun, 30 Jul 2006 23:47:00 + "Jeffrey D. Smith"
<[EMAIL PROTECTED]> wrote:

:>From: "Binyamin Dissen" <[EMAIL PROTECTED]>
:>Sent: 7/30/2006 10:13 AM
:>To: "IBM-MAIN@BAMA.UA.EDU" 
:>Subject: Re: APF Authorized Code/Libraries.

:>On Sun, 30 Jul 2006 09:08:00 -0300 "Shmuel Metz (Seymour J.)"
:><[EMAIL PROTECTED]> wrote:

:>:>In <[EMAIL PROTECTED]>, on
:>:>07/28/2006
:>:>   at 05:16 PM, Wayne Driscoll <[EMAIL PROTECTED]> said:

:>:>>While that is true, since non-reentrent code loaded out of an APF
:>:>>authorized library is loaded into KEY 8 storage, there is an
:>:>>integrity exposure if said code is loaded into a multi-user address
:>:>>space, since it is open to being modified (by accident or by intent)
:>:>>by a non-authorized program.

:>:>Authorization is at the address space level. Normally it's impossible
:>:>for authorized and unauthorized programs to run concurrently in the
:>:>same address space. If your authorized code circumvents the normal
:>:>safeguards then you have more serious issues than what key the code is
:>:>loaded under.
 
:>Actually authorization is at the jobstep task level.

:>Some TSO commands can be attached authorized.

TSO starts a parallel TMP as a jobstep task, and runs the command under it.

--
Binyamin Dissen <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Help with ILR035W

[Hal Merritt]

Thanks to all who tried to help. The system in question had been copied
from another unit pair. I'm sure there must have been some comedy of
errors that made the copies defective. 

It turns out that the original pair was still there, and IPL'ed smooth
as silk. 

Again, thanks to all!!

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Shane
Sent: Friday, July 28, 2006 10:15 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Help with ILR035W

On Fri, 2006-07-28 at 18:21 -0500, Hal Merritt wrote:
> Well, now I get 'deleted while in use'. 

I'd be thinking you are paddling around in the wrong catalog.
A *very* careful check of all that you had done so far would be germane.

With regard to the update record in the page dataset, this merely stops
you deleting or using the same dataset on another system whilst it is
active. It can be (re-)used after the using system is deactivated - you
get a warning message about the last system to use that page dataset,
but usage proceeds. At least that was how it happened when I tested this
funtionality at z/OS 1.4

Shane ...

 
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Data set ENQueues and DEQueues in Jobs

[Paul Gilmartin]

In a recent note, Bruce Black said:

> Date: Sun, 30 Jul 2006 18:40:49 -0400
> 
> Sorry, ENQ RET=CHNG only changes a SHR ENQ to EXCL, not the other waqy
> 
And thereby hangs a long and knotted tale of how TSO ALLOCATE
will sometimes create a data set with only a SHR ENQ on the
DSNAME; fail to catalog it because of a duplicate catalog entry,
then fail to delete it because it can't obtain an EXCL ENQ
because another job has a SHR ENQ on the same DSNAME.

I once unwittingly created uncatalogued instances on every
storage volume of several data set names because of this
behavior.

It's a disappointment, for the above reason as well as others,
that IBM has not seen fit to provide an option to downgrade
an ENQ.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Upcoming IBM Redbook Residencies

[Timothy Sipples]

There are some interesting residencies coming up for those of you who'd
like to beef up skills, get deep experience before your own organization's
project, meet developers, and boost your resumes by becoming a published
author of an IBM redbook.  IBM pays for your travel and living expenses.
Also, if you're trying to onboard someone in your organization who is in
the latter stages of developing proficiency, residencies are good
"finishing school" experiences.

Here's the full list:

http://www.redbooks.ibm.com/residents.nsf/ResIndex/

and here are some of the notable ones that are still accepting
applications:

ABCs of z/OS System Programming (# ZS-R200-R01)
CICS Web Services Performance (# SA-Z095-R01)
MLS / DB2 Implementation Update (# ZS-R085-R01)
Enterprise Extender Implementation Guide (# ZS-W064-R01)
Best Practices for Implementing WebSphere Extended Deployment (#
SA-W622-R01)
Update of IBM Tivoli Composite Application Management Family Redbook (#
TI-6M11-R01)
WebSphere for z/OS Security Integration Handbook (# SA-Z609-R01)
zSeries Redbook: WebSphere Process Server and WebSphere ESB Getting Started
(# SA-Z607-R02)

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Zbigniew Skierski : nie ma mnie w pracy.

[Zbigniew Skierski]

Nie będzie mnie w pracy od  2006-07-31 i nie wrócę przed 2006-08-09.

Odpowiem na wiadomości po powrocie.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA SF and IOACMD

[Ted MacNEIL]

>but we would not do people's work for them; this explains his "you are wrong" 
>statements where you expect detailed information on what the error or 
>misunderstanding is. While his approach may seem 
unreasonable, cold, and hurtful,

Insulting! Obnoxious!

A few pointers, rather than holier than thou could be a good thing.

In general, nobody is asking him, or anybody else, to do their work!

>If you haven't found anything useful in his responses, then you haven't read 
>enough of them, yet.

BULL! I have given up on his responses!
If I wanted to hear obnoxious insults, I'd call my ex-wife.

One of the purposes of this forum is to help, not insult!
And, you can help without 'doing the job for them'.

If he is such an expert, why can't he drop a few hints?

PS: I never saw the so-called humour in his postings!

When in doubt.
PANIC!!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: wd4z JES job Monitor

[John S. Giltner, Jr.]

Errno 1115 means that the address in already in use.  I believe here it 
means the port.  You can find it in SYS1.MACLIB member BPXYERNO.


Is the 38 a return code or errno?  I can find two 38's error number. 
One means that the system (TCP/IP) is not ready.


The other means that a socket function was being requested on a 
non-socket connection.

Mary Kay Tubello wrote:
No, port 6715 is free.  The error I get is a return code of 38. Also, 
Bind failed - retry with REUSEADDR option   
Bind2 failed: rc=-1 errno=1115  
JM202I TCP/IP may have failed or been recycled. 
I can't find where these are documented.  (Another problem - the 
documentation is poor.)

thanks

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA SF and IOACMD

[Gerhard Postpischil]

R.S. wrote:
Since I noticed that vast majority (or even all) of Shmuel's mails 
contains only "no, you're wrong" or "USS is not unix" I stopped 
responding him. I put his e-mail in kill-file, so his mails are 
filtered. That's good: no more badgering. I don't loose anything 
valuable, cause usually Shmuel's mails does not contain any help, rather 
malice and badgering instead.


Soemtimes, when browsing archives through web interface (no filter on 
Shmuel) I read his mails  - that convices me it was good decision to 
make a filter.


While Seymour/Shmuel doesn't need an apologist, I would like to comment 
on this. I first met him in the mid sixties, when my employer (Applied 
Data Research) bought out his (ComPass?). Since then we have worked 
together at several employers, and even when we didn't, met once or 
twice a week for dinner and discussion. If I had a dollar for every time 
he has been wrong about published information, I wouldn't be able to buy 
a cup of coffee. We sometimes disagreed on practical applications, where 
I tend to be more pragmatic at solving issues, but we both found rapidly 
that we were approached by coworkers for answers to their problems.


This rapidly led him to adopt the attitude that he would help with real 
problems, but we would not do people's work for them; this explains his 
"you are wrong" statements where you expect detailed information on what 
the error or misunderstanding is. While his approach may seem 
unreasonable, cold, and hurtful, it's better in the long run, as you're 
actually forced to go to the manuals to understand the problem, and 
possible solutions, and thus giving you better preparation when a 
similar problem occurs.


As to the USS issue, we both believe that acronyms should be unique, and 
that IBM should avoid duplication at all costs. To me RAMAC is still the 
tall, spindly arrangement of parallel horizontal platters with a juke 
box style arm that passed for an early IBM DASD device of the fifties, 
rather than the modern one. All the arguments have been presented 
repeatedly, and we see no reason to repeat them each time. If you 
haven't found anything useful in his responses, then you haven't read 
enough of them, yet.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: APF Authorized Code/Libraries.

[Jeffrey D. Smith]

==
-Original Message-
From: "Binyamin Dissen" <[EMAIL PROTECTED]>
Sent: 7/30/2006 10:13 AM
To: "IBM-MAIN@BAMA.UA.EDU" 
Subject: Re: APF Authorized Code/Libraries.

On Sun, 30 Jul 2006 09:08:00 -0300 "Shmuel Metz (Seymour J.)"
<[EMAIL PROTECTED]> wrote:

:>In <[EMAIL PROTECTED]>, on
:>07/28/2006
:>   at 05:16 PM, Wayne Driscoll <[EMAIL PROTECTED]> said:

:>>While that is true, since non-reentrent code loaded out of an APF
:>>authorized library is loaded into KEY 8 storage, there is an
:>>integrity exposure if said code is loaded into a multi-user address
:>>space, since it is open to being modified (by accident or by intent)
:>>by a non-authorized program.

:>Authorization is at the address space level. Normally it's impossible
:>for authorized and unauthorized programs to run concurrently in the
:>same address space. If your authorized code circumvents the normal
:>safeguards then you have more serious issues than what key the code is
:>loaded under.
 
Actually authorization is at the jobstep task level.

--
Binyamin Dissen <[EMAIL PROTECTED]>
==

Some TSO commands can be attached authorized.


Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DR
LONGMONT, CO 80501
303-774-9381 direct
303-709-8153 cell
303-484-6170 fax

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Data set ENQueues and DEQueues in Jobs

[Bruce Black]

I have the impression that the initiator is also smart enough to issue 
a ENQ TYPE=CHNG (to switch from ENQ=EXC to ENQ=SHR) if subsequent 
steps have the DSN as DISP=SHR after the last step that has it as 
DISP=OLD (ie: Exclusive).

Sorry, ENQ RET=CHNG only changes a SHR ENQ to EXCL, not the other waqy

--
Bruce Black
Senior Software Developer
Innovation Data Processing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Message IGD17040I Error

[Bruce Black]

HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
For this code you need to look in the DFSMSdsp Diagnostic Reference.  
You will find that, for CREATE, 0C060090 means


PDSE cannot be VIO.

--
Bruce Black
Senior Software Developer
Innovation Data Processing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: S99RBXLN "Head's Up"

[Edward Jaffe]

Paul Gilmartin wrote:

Despite the "dozens" of errors, do you need to do anything more
than delete the single definition in your macro?  It appears
that the definitions are equivalent.
  


The two definitions are indeed identical in every respect. The only 
required change is to delete my symbol definition, which occurs in every 
program that uses IEFZB4D0. By guessing the name correctly, I saved 
myself the trouble of having to convert those same programs to use the 
"official" symbol -- which I would have done even in the event I had 
chosen a non-conflicting name like S99RBXSZ instead. Some might consider 
that mild OCD. But, that's what I would have done.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: S99RBXLN "Head's Up"

[Paul Gilmartin]

In a recent note, Edward Jaffe said:

> Date: Sun, 30 Jul 2006 15:04:01 -0700
> 
> Hallelujah!!! Happy days!! But ... wait! Was I prescient? The name I've
> been assigning for 20 years to this "user defined" symbol is *exactly*
> the same as that chosen by IBM for the "official" symbol. I now have
> literally dozens of programs that won't compile. They receive a
> "Previously defined symbol" error from the assembler!
> 
Prescient?  Only in a sense.  In retrospect, you've probably
mused that you invited trouble by using, fairly deliberately,
a prefix ("S99") that IBM had informally staked out.  But we
all do it: some years back IBM introduced a hardware instruction
that we had used as a macro name.  (We OPSYNed it away;
we didn't need it.  And IIRC we had to do a little dance of
defining it before we undefined it because the assembler,
contrary to expectation, allows redefining an opcode
previously defined, but not undefining an opcode previously
undefined.)

But IBM laid the trap by not providing the service to customers
of partitioning the namespace, "Ours" and "Theirs".  They
provide a registry of module prefixes; this should be
generalized to other symbols.

45 years ago an IBM assembler provided a HED pseudo-op which
implicitly qualified symbols in a range of statements.  This
was a variant of name scoping; I don't know whether it would
have helped in this case.

> I'm not complaining. I'm editing. Consider yourselves forewarned...
> 
Despite the "dozens" of errors, do you need to do anything more
than delete the single definition in your macro?  It appears
that the definitions are equivalent.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

S99RBXLN "Head's Up"

[Edward Jaffe]

Those of us that routinely work with MVS dynamic allocation have, 
literally for decades, lamented the lack of an EQUated symbol to provide 
the length of the S99RBX data structure. That structure was created back 
in 1986 with the following change to macro IEFZB4D0.


$L1= SMSSTG2 JBB2223 860523 PDM9: STOR MGMT SUBSYS STG2 SUP  @L1A

This oversight forced every programmer wanting to use S99RBX into 
declaring their own symbol in a manner similar to that shown below:


|S99RBX   DSECT ,   Define S99RBX parm list length
| ORG   ,   (same)
|S99RBXLN EQU   *-S99RBX(same)

Now, 20 years later, IBM finally decided to add the missing symbol to 
the z/OS 1.8 version of the macro. See below:


$P3= ME05532 HBB7730 060131 PDHV: Add S99RBXLN   @P3A

Hallelujah!!! Happy days!! But ... wait! Was I prescient? The name I've 
been assigning for 20 years to this "user defined" symbol is *exactly* 
the same as that chosen by IBM for the "official" symbol. I now have 
literally dozens of programs that won't compile. They receive a 
"Previously defined symbol" error from the assembler!


I'm not complaining. I'm editing. Consider yourselves forewarned...

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM Redbook: "Introduction to the New Mainframe: z/OS Basics"

[Bill Seubert]

On Sat, 29 Jul 2006 18:46:50 +1000, Shane <[EMAIL PROTECTED]> wrote:

>Excuse my sceptocity, but such "customers" exist ???

Yup.  Not like they did when I started in the 80s, but they do.  Early this
year, I was presenting to a customer, and a colleague was asking some "z/OS
trivia" questions.  There was a guy in there who was green out of college -
around 22 - my colleague said "hey, you're probably a distributed systems
guy, do you know the answer?"  They guy says "I'm a z/OS Sysprog". (I about
shot Mt. Dew out my nose...)  That's an anecdotal report, and I don't have
comprehensive stats, but I see it on more than rare occasion.

>From my perspective, seems that customers are more willing to hire
>expertise than assist its growth. Whilst good for me and others with the
>requisite experience/expertise, it is a stone wall for those attempting
>to enter the industry.

That's been a problem since day 0.  I remember when I was a rookie, thinking
"gee, I can't wait 'til I have 5 or so years experience so I can find a
better-paying job, since everyone wants experience!

>Bloody short sighted.

Yep.

>Then there is the issue of off-shoring the whole kit and caboodle ...

Not a whole lot any of us can do about that, unfortunately.

>Good luck, but I empathise with the earlier comment about turning (such)
>a big boat.

You're right - I occasionally think the same thing about our initiative to
build a new pipeline of skilled mainframe folks.  It's a hard thing to do,
but I am very encouraged at the attention it's getting, all through the
hierarchy at IBM.  Yeah, we dropped the ball in years past, but it's back in
play now.  Has the situation been harmed by past indifference and inaction?
 Yes, I'm sure it has.  But neither I nor my colleagues are willing to just
give up and throw in the towel.  The platform is much too important to
customers and to IBM to do that.  The more of us who tug on the wheel of the
boat, the better job we're gonna do in turning it.

>
>Shane ...


Bill Seubert
System z Software I/T Architect
IBM Corporation
[EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Message IGD17040I Error

[Stephen Mednick]

Try the following link:

http://www.teradataforum.com/ibm_pdf/gc28-1788-15.pdf


Stephen Mednick
Computer Supervisory Services
Sydney, Australia 

> -Original Message-
> What book will I find message IGD17040I Error.  I have looked 
> in every book I can think of in bookmanager.
> 
> IGD101I SMS ALLOCATED TO DDNAME (ISPLST3 )
>  DSN (SYS06211.T001632.RA000.PEMLA0UL.R0138929)
>  STORCLAS (SCSTAND) MGMTCLAS () DATACLAS ()
>  VOL SER NOS= VIO
>  IGD101I SMS ALLOCATED TO DDNAME (ISPLSTA )
>  DSN (SYS06211.T001632.RA000.PEMLA0UL.R0138930)
>  STORCLAS (SCSTAND) MGMTCLAS () DATACLAS ()
>  VOL SER NOS= VIO
>  IGD17040I ERROR IN DADSM PROCESSING ON VOLUMEFOR DATA SET
>  SYS06211.T001632.RA000.PEMLA0UL.R0138931
>  HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 
> 0C060090  IGD306I UNEXPECTED ERROR DURING IGGDAC02 PROCESSING 
>  RETURN CODE 12 REASON CODE 144  THE MODULE THAT DETECTED THE 
> ERROR IS IGDVTSDA  SMS MODULE TRACE BACK - VTSDA VTSCR SSIRT  
> SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00269  IGD101I SMS 
> ALLOCATED TO DDNAME (ISPPROF )
>  DSN (SYS06211.T001632.RA000.PEMLA0UL.R0138931)
>  STORCLAS (SCSTAND) MGMTCLAS () DATACLAS ()
>  VOL SER NOS= WORK03
>  IGD101I SMS ALLOCATED
> 
> Ed. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: sequence numbers (or whatever)

[David Cole]

At 7/30/2006 09:12 AM, John Gilmore wrote:
My favorite---storm warning of a big word to come---is their 
notional usefulness in avoiding homoeoteleutera; but others may well 
have their own, different favorites.


Google User: "define: homoeoteleutera"
Google (paraphrasing here): "Huh?"

www.onelook.com user: "homoeoteleutera"
www.onelook.com: "Huh?"

Looks to me, John, like you've hit a home run here...






At 7/30/2006 09:12 AM, John Gilmore wrote:
The triviality of this issue is, however, convenient in one way.  It 
provides an occasion for noting that clinging to a piece of obsolete 
technology that we know and love, a high resolve to go on using it 
until it is pried from our lifeless fingers, is dysfunctional.


Such passion, John! It leaves me all aflutter...






My opinion, FWIW: Whether or not sequence numbers are useful depends 
upon whether or not you are willing to find a use for them.


In my own work, I use an update process that depends upon sequence 
numbers. It's all real ryo; but nevertheless, it is pretty good at 
allowing multiple developers to work in the same csects, and even in 
the same subroutines, without locking each other out, and with only a 
minimal chance of interfering with each other.


Are there other ways to do this? Of course. Are they better? Maybe. 
Probably depends up what you value.



Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SEQUENCE NUMBERS

[Edward Jaffe]

john gilmore wrote:
I am as aware as EJ is of the historical use that has been made of SNs 
to maintain source programs, and I mentioned this role for them 
explicitly in the post he comments upon.  We differ about the 
desirability of continuing to use them.  So be it.


Don't misunderstand me! We do *not* differ about the desirability of 
continuing to use sequence numbers. Personally, I don't like them. I 
prefer "unnumbered" source for programs not distributed to customers.


My objection was to your assertion that the use of sequence numbers is 
now 'obsolete'. That would be a valid statement only if a viable 
alternative to their use for source-maintained programs existed. 
Unfortunately, one does not.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SEQUENCE NUMBERS

[john gilmore]

Of my contention that Sequence Numbers (SNs) are obsolete, Edward Jeffe 
writes:


| This is just not true! There is nothing obsolete about the use of sequence 
numbers when creating | an SMP/E usermod. With this technology, it's 
possible to write a modification to the behavior of a
| program without distributing the entire program. This does two important 
things: a) it decouples
| the modification from past and future updates (enhancements, bug fixes, 
etc.) that might be
| made to the module by its owner (e.g., IBM) and b) allows distribution of 
such modifications via
| public fora or other similar public channel without violation of the 
owner's copyright.


I am not quite sure how to respond.

Usermods cannot in my experience be decoupled from future modifications at 
all automatically.  It is of course possible to preserve one or many of them 
by taking explicit, often ugly steps to do so; but that is a very different 
matter.


I am as aware as EJ is of the historical use that has been made of SNs to 
maintain source programs, and I mentioned this role for them explicitly in 
the post he comments upon.  We differ about the desirability of continuing 
to use them.  So be it.


John Gilmore
Ashland, MA 01721-1817
USA

_
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Message IGD17040I Error

[Ed Finnell]

 
In a message dated 7/30/2006 1:01:03 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

What  book will I find message IGD17040I Error.  I have looked in every book 
I  
can think of in bookmanager.




>>
System Messages Vol. 8 IEF-IGD?
 
 
12.315 IGD17040I



 





   IGD17040I ERROR IN DADSM PROCESSING FOR DATA SET dsname HISTORIC RETURN

  CODE IS rc DIAGNOSTIC INFORMATION IS cde




Explanation: SMS VTOC data set services  received an unexpected return code 
from DADSM.  
In the message text:  
dsname  
The data set name.  
rc  
The return code.  
cde  
Diagnostic information.  

System Action: The request involving the data set  fails. Also, the system 
writes a record describing the error to the logrec data  set.  
Application Programmer Response: Use the record in the  logrec data set, the 
return code and the diagnostic information to determine the  error. Use _z/OS  
DFSMSdfp Diagnosis Reference_ 
(http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/DOCNUM/GY27-7618/CCONTENTS?)
  to  determine the meaning of the DADSM 
historic return code and the DADSM diagnostic  information.  
Source: DFSMSdfp  
Routing Code: 2  
Descriptor Code: 4   



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Message IGD17040I Error

[Ed. Benoit]

Hello All,
What book will I find message IGD17040I Error.  I have looked in every book I 
can think of in bookmanager.

IGD101I SMS ALLOCATED TO DDNAME (ISPLST3 )
 DSN (SYS06211.T001632.RA000.PEMLA0UL.R0138929)
 STORCLAS (SCSTAND) MGMTCLAS () DATACLAS ()
 VOL SER NOS= VIO
 IGD101I SMS ALLOCATED TO DDNAME (ISPLSTA )
 DSN (SYS06211.T001632.RA000.PEMLA0UL.R0138930)
 STORCLAS (SCSTAND) MGMTCLAS () DATACLAS ()
 VOL SER NOS= VIO
 IGD17040I ERROR IN DADSM PROCESSING ON VOLUMEFOR DATA SET
 SYS06211.T001632.RA000.PEMLA0UL.R0138931
 HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
 IGD306I UNEXPECTED ERROR DURING IGGDAC02 PROCESSING
 RETURN CODE 12 REASON CODE 144
 THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA
 SMS MODULE TRACE BACK - VTSDA VTSCR SSIRT
 SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00269
 IGD101I SMS ALLOCATED TO DDNAME (ISPPROF )
 DSN (SYS06211.T001632.RA000.PEMLA0UL.R0138931)
 STORCLAS (SCSTAND) MGMTCLAS () DATACLAS ()
 VOL SER NOS= WORK03
 IGD101I SMS ALLOCATED

Ed. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Homoeoteleutera / Google Architecture / sequence numbers (or whatever)

[Ed Finnell]

 
In a message dated 7/30/2006 10:04:58 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Did you  mean: homoioteleuton



>>
More likely homoimaginus. Has anybody written a SHARE requirement for  
SEQ/NOSEQ in IEASYS? It would probably be on the order of Y2K  compliance.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: APF Authorized Code/Libraries.

[Binyamin Dissen]

On Sun, 30 Jul 2006 09:08:00 -0300 "Shmuel Metz (Seymour J.)"
<[EMAIL PROTECTED]> wrote:

:>In <[EMAIL PROTECTED]>, on
:>07/28/2006
:>   at 05:16 PM, Wayne Driscoll <[EMAIL PROTECTED]> said:

:>>While that is true, since non-reentrent code loaded out of an APF
:>>authorized library is loaded into KEY 8 storage, there is an
:>>integrity exposure if said code is loaded into a multi-user address
:>>space, since it is open to being modified (by accident or by intent)
:>>by a non-authorized program.

:>Authorization is at the address space level. Normally it's impossible
:>for authorized and unauthorized programs to run concurrently in the
:>same address space. If your authorized code circumvents the normal
:>safeguards then you have more serious issues than what key the code is
:>loaded under.
 
Actually authorization is at the jobstep task level.

--
Binyamin Dissen <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Data set ENQueues and DEQueues in Jobs

[Paul Gilmartin]

In a recent note, Robert A. Rosenberg said:

> Date: Sun, 30 Jul 2006 09:59:30 -0400
> 
> I have the impression that the initiator is also smart enough to
> issue a ENQ TYPE=CHNG (to switch from ENQ=EXC to ENQ=SHR) if
> 
I was unaware of such a facility.  In fact:

Title: z/OS V1R7.0 MVS Assembler Services Reference ABE-HSP 
 
Document Number: SA22-7606-07

91.1.8 "z/OS V1R7.0 MVS Assembler Services Reference ABE-HSP"

  91.1.8 Parameters

   ,RET=CHNG

The status of the resource specified is changed from shared
to exclusive control. When RET=CHNG is specified, the
exclusive|shared (E|S) parameter is overidden. This
parameter ensures that the request will be exclusive
regardless of the other parameter.

Perhaps initiator can do something ordinary programmers can't.
I haven't checked the Authorized volme.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: APF Authorized Code/Libraries.

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
07/28/2006
   at 05:16 PM, Wayne Driscoll <[EMAIL PROTECTED]> said:

>While that is true, since non-reentrent code loaded out of an APF
>authorized library is loaded into KEY 8 storage, there is an
>integrity exposure if said code is loaded into a multi-user address
>space, since it is open to being modified (by accident or by intent)
>by a non-authorized program.

Authorization is at the address space level. Normally it's impossible
for authorized and unauthorized programs to run concurrently in the
same address space. If your authorized code circumvents the normal
safeguards then you have more serious issues than what key the code is
loaded under.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SEQUENCE NUMBERS

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/28/2006
   at 03:50 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>It appeared to me that the OP, perhaps using ISPF as the editor-
>of-choice, was composing data to be exported as input to a desktop
>program.

Indeed. And it might be appropriate in his specific case to drop the
sequence numbers. But if the data are ultimately going to someone
else, it's his responsibility to be sure that they don't require the
sequence numbers.

>Perhaps you feel that all utilities, on all platforms, should
>process only columns 1-72 of their input data.

And perhaps not.

>Ain't gonna happen.

That's fortunate, since I routinely write source lines longer than 72.

Bruce: yes, I am assuming that 73-80 are in ISPF format, with 73-78
the real sequence number and 79-80 the change level.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SEQUENCE NUMBERS

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/29/2006
   at 12:42 PM, "R.S." <[EMAIL PROTECTED]> said:

>AFAIK the sequence numbers are completely useless nowadays.

Then your knowledge doesn't go very far.

>It was used for punched card sorter.

That hasn't been the important use for decades.

>Is there any other application ?

Yes - editing.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SEQUENCE NUMBERS

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/30/2006
   at 01:21 AM, john gilmore <[EMAIL PROTECTED]> said:

>It never needs to use them,

How else would you package ++ APAR sysmods to only change the relevant
code? There are packaging issues if you want to be able to use SUP as
intended, without requiring a RESTORE[1] of obsoleted service.

[1] Although sometimes that's unavoidable.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA SF and IOACMD

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 07/28/2006
   at 12:00 AM, Ted MacNEIL <[EMAIL PROTECTED]> said:

>Even IBM calls it USS.

Sigh! Humor is such a subtle thing. Maybe I was too subtle for you.
Even IBM calls the user id UID. RS was being a hypocrite. Worse,
because IBM was using UID as an abbreviation for user id before they
even thought of doing Open Edition. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA SF and IOACMD

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 07/29/2006
   at 11:45 AM, Ted MacNEIL <[EMAIL PROTECTED]> said:

>It just seems that some people can't take a hint,

PKB.

>Schmeul,

I see that not only can't you read, you can't copy text accurately
either.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA SF and IOACMD

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/29/2006
   at 12:08 PM, "R.S." <[EMAIL PROTECTED]> said:

>Since I noticed

ITYM perceived, inaccurately.

>malice and badgering 

PKB.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Homoeoteleutera / Google Architecture / sequence numbers (or whatever)

[Paul Gilmartin]

In a recent note, john gilmore said:

> Date: Sun, 30 Jul 2006 13:12:44 +
> 
> My favorite---storm warning of a big word to come---is their notional
> usefulness in avoiding homoeoteleutera; but others may well have their own,
> different favorites.
> 
Congratulations!

homoeoteleutera - Google Search

   homoeoteleutera__ Search   Advanced Search

   Did you mean: homoioteleuton

   No standard web pages containing all your search terms were found.
   Your search - homoeoteleutera - did not match any documents.

   ©2006 Google

I'm trying to parse it as same/early/distant/good/??? with
little success.  "Homoioteleuton" could be somewhat relevant
in that sequence numbers distinguish the endings of lines.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: wd4z JES job Monitor

[Mary Kay Tubello]

No, port 6715 is free.  The error I get is a return code of 38. Also, 
Bind failed - retry with REUSEADDR option   
Bind2 failed: rc=-1 errno=1115  
JM202I TCP/IP may have failed or been recycled. 
I can't find where these are documented.  (Another problem - the 
documentation is poor.)
thanks

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Google Architecture

[Anne & Lynn Wheeler]

Anne & Lynn Wheeler wrote:

Google runs on hundreds of thousands of servers—by one estimate, in
excess of 450,000—racked up in thousands of clusters in dozens of data
centers around the world.


re:
http://www.garlic.com/~lynn/2006n.html#12 Google Architecture

... in somewhat similar vein

Grid Is 'It' at eBay
http://www.eweek.com/article2/0,1895,1995124,00.asp

The dramatic growth and high exposure of eBay's Web presence make it a 
rare example of a grid computing platform and application portfolio that 
are well past the pilot-project stage.


... snip ...

and for a little drift
http://www.garlic.com/~lynn/95.html#13

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SEQUENCE NUMBERS

[Edward Jaffe]

john gilmore wrote:

Ted MacNeil WRITES:


 REPEAT AFTER ME!
 SMP is your friend!
 SMP NEEDS statement numbers.


SMP certainly uses SNs and IEBUPDTE in some contexts.  Equally, it 
omits to use them in others where it could do so.


It never needs to use them, and it would be well if it had stopped 
doing so long ago.  Affection for obsolete technology is 
understandable, even beguiling; but it is counter-productive.


This is just not true! There is nothing obsolete about the use of 
sequence numbers when creating an SMP/E usermod. With this technology, 
it's possible to write a modification to the behavior of a program 
without distributing the entire program. This does two important things: 
a) it decouples the modification from past and future updates 
(enhancements, bug fixes, etc.) that might be made to the module by its 
owner (e.g., IBM) and b) allows distribution of such modifications via 
public fora or other similar public channel without violation of the 
owner's copyright.


For example, here is the popular public usermod that provides multiple 
TSO/E logon for JES3 installations.


|++USERMOD(UMJES06) /*
|  
|  *  *
|  * Multiple TSO Logon   *
|  *  *
|  
| */ .
|++VER(Z038) FMID(HJS7708)
|.
|++SRCUPD(IATGRJS) .
|./ CHANGE NAME=IATGRJS
| B MSSCH030ACCEPT MULTIPLE LOGON   UMJES06  
38244010


Though IBM has implemented many unrelated updates to IATGRJS over the 
years, this usermod has continued to work unchanged and is expected to 
do so until no longer needed. And this is just one of hundreds, if not 
thousands, of similar usermods being maintained all over the world by 
various people for various reasons.


If serial numbers were no longer present in source-maintained program 
products, the z/OS community would require a replacement technology.


For example, if z/OS provided a pervasive and universally accepted 
method of describing the differences between two nearly-identical source 
members (e.g. as some sort of "delta deck"  -- pick your own term), and 
a procedure for *reliably* applying the changes represented by that 
"delta deck" to a source program (that BTW might have changed 
substantially since the "delta deck" was first generated), then we could 
do away with sequence numbers and I would agree they are obsolete.


Until then, sequence numbers can be called ugly, inconvenient, a PITA, 
(insert your favorite pejorative). But they are most-certainly *not* 
obsolete!


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Data set ENQueues and DEQueues in Jobs

[Robert A. Rosenberg]

At 09:06 -0700 on 07/28/2006, Edward Jaffe wrote about Re: Data set 
ENQueues and DEQueues in Jobs:



Staller, Allan wrote:

 I am not familiar enough w/JES3 to make a useful comment.
  


The initiator (IEFIIC) is not a JES program! It does what it does
without regard to the type of job entry subsystem in use.

As stated previously by others, the data set ENQs are acquired at job
initiation time. They're released at the end of the last step that
references them.


I have the impression that the initiator is also smart enough to 
issue a ENQ TYPE=CHNG (to switch from ENQ=EXC to ENQ=SHR) if 
subsequent steps have the DSN as DISP=SHR after the last step that 
has it as DISP=OLD (ie: Exclusive).


IOW: The holding of DISP=SHR Jobs due a DISP=OLD job will get removed 
with the Blocking Job only needs a DISP=SHR ENQ not when it no longer 
needs the dataset (ie: When the ENQ is released as is referenced 
above).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Data set ENQueues and DEQueues in Jobs

[Robert A. Rosenberg]

At 13:14 -0600 on 07/28/2006, Paul Gilmartin wrote about Re: Data set 
ENQueues and DEQueues in Jobs:



A JES3 partisan once told me, as I whined about a job spewing
ENQ messages into SYSLOG while another job held an ENQUE for
the same DSN on a different volume, "That wouldn't happen with
JES3."  Perhaps he merely meant that JES3 would hold the second
job from initiation until all resources it needed were immediately
available.


Part of the problem with this type of incorrect "conflict" is that 
the SYSDSN Queue (the QNAME used for the ENQ/DEQ) regards the DSN 
(the RNAME) as the identifier of the Dataset not the CORRECT DSN with 
VOLSER. This goes back to the OS360 (PCP/MFT/MVT) days when the 
concept of having two CPUs sharing their ENQ/DEQ Queue was not 
imagined. Since you do not know what VOLSER the DSN you are ENQing on 
will be on until you actually allocate it at Step Initiation time, 
there is no way to fix this problem (such as having another QNAME 
that uses a RNAME that contains the VOLSER along with the DSN). In 
fact, ISPF which should know better (since it allocates at 
dynamically and thus KNOWS at allocate time which VOLSER to use 
[either due to looking at the catalog or accepting this info from the 
User]) still does its private ENQ on a DSN only RNAME and thus can 
refuse to access a DSN on VOL2 when another ISPF User has a VOL1 
resident Dataset with the same name in use.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: sequence numbers (or whatever)

[john gilmore]

Ed Jaffe wrote:

| Ed Gould wrote:
|
|  | While your statement is true it would seem to me JES2 (JES3?) still 
sends out source and as
|  | long as it does then statement sequence numbers are needed. I vaguely 
remember that IBM
|  | at one time said they were going to stop sending out source for the 
JES's. They have done
|  | this with new function modules (at least JES2) I don't know if there is 
a specific date for the

|  | rest of the source.
|
|
|   believe this is planned for the year after the 64-bit TOD clock wraps.

There is no necessary linkage between supplying SNs in card-image columns 
73-80 and OCO foir JES2.


Several other almost but perhaps not quite equally bizarre arguments for the 
continuing usefulness of SNs have been advanced during the evolution of this 
thread.


My favorite---storm warning of a big word to come---is their notional 
usefulness in avoiding homoeoteleutera; but others may well have their own, 
different favorites.


The triviality of this issue is, however, convenient in one way.  It 
provides an occasion for noting that clinging to a piece of obsolete 
technology that we know and love, a high resolve to go on using it until it 
is pried from our lifeless fingers, is dysfunctional.


John Gilmore
Ashland, MA 01721-1817
USA

_
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html