Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In
,
on 11/29/2012
   at 09:32 PM, John Gilmore  said:

>Shmuel's comments, which suggested that I did not understand some
>things that I have understood for many years, were ad hominem

Nonszense: what you *wrote* was wrong, whether you knew better or not,
and if you really did know better than your subsequent post is
inexplicable, since you defended your previous, incorrect, post.

>gratuitously ad hominem

PKB.

>motivated by

More ad hominem; either you are delusional or lying.

>quotes others' posts selectively

I cite the relevant parts; I won't do cascades no matter how often you
whine that you want them.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In
,
on 11/29/2012
   at 03:46 PM, John Gilmore  said:

>(taken from z/OS MVS Assermbler Services Reference, ABEND-HSPSERV)

Taken quite selectively.

>This is exactly what I described,

No; in fact, other text in the same manual conflicts with what you
wrote. You wrote "If instead it is already present in storage, having
been loaded by someone else, its usage count is increased by one.",

>From that manual: "Also, the DELETE macro must be issued by the same
task that issued the LOAD macro."

>From z/OS MVS Programming: Assembler Services Guide, SA22-7605-11:

"With the exception of those load modules contained in this area,
copies of all of the reenterable load modules you request are brought
into your area of virtual storage and are available to any task in
your job step. The portion of your area containing the copies of the
load modules is called the job pack area. Any program loaded by a
particular task is also represented within that task's load list."

Note carefully that this is per address space, contrary to your claim.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

My last post has elicited several off-list clarifications and caveats,
which were certainly valuable.

They were also, in a sense, irrelevant.  I had used the behavior of
LOAD and DELETE to make the point that z/OS and its predecessors must
and do virtualize some operations.

Shmuel's comments, which suggested that I did not understand some
things that I have understood for many years, were ad hominem and,
finally irrelevant.  My problem with his posts is not that he
disagrees with me; it is that they are gratuitously ad hominem and
motivated by a desire to make debaters' points without really
contributing to the clarification of the issues under discussion.  He
quotes others' posts selectively and he is quick, too quick, to impute
stupidity to people who dfisagree with him.

He has appointed himself as a sort of intellectual policeman of
IBM-MAIN; but his finally very pedestrian, detail-ridden intellect is
inadeq

On 11/29/12, Bill Fairchild  wrote:
> Slight correction.  A non-GLOBAL load will not let other address spaces find
> your load module implicitly, but it will let other tasks in your address
> space find it through the LOAD service.
>
> Bill Fairchild
> Programmer
> Rocket Software
> 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
> t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w:
> www.rocketsoftware.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Fairchild
> Sent: Thursday, November 29, 2012 3:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
>
> LOADing a module somehow other than GLOBALly does cause the loaded module to
> be implicitly known to other address spaces, because the operating system
> adds such implicit knowledge into its control block structure for all loaded
> modules that will be findable through the published rules by which the LOAD
> service works.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Gilmore, Ashland, MA 01721 - USA

t.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Bill Fairchild]

Slight correction.  A non-GLOBAL load will not let other address spaces find 
your load module implicitly, but it will let other tasks in your address space 
find it through the LOAD service.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Fairchild
Sent: Thursday, November 29, 2012 3:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

LOADing a module somehow other than GLOBALly does cause the loaded module to be 
implicitly known to other address spaces, because the operating system adds 
such implicit knowledge into its control block structure for all loaded modules 
that will be findable through the published rules by which the LOAD service 
works.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Bill Fairchild]

John,

You didn't read widely enough.  What you read is correct, necessary, but not 
sufficient.  In the Authorized Assembler Services Reference book, in the 
section on the LOAD services, for the keyword GLOBAL=YES, is this text:
"Note: A load request with the GLOBAL=YES, (YES,P), or (YES,F) option does
not cause the loaded module to be implicitly known to other address
spaces. The loaded module can be accessed by other address spaces,
however, only the task that loaded the module may delete it."

LOADing a module somehow other than GLOBALly does cause the loaded module to be 
implicitly known to other address spaces, because the operating system adds 
such implicit knowledge into its control block structure for all loaded modules 
that will be findable through the published rules by which the LOAD service 
works.

But other tasks in other address spaces cannot even find a GLOBALly loaded 
module implicitly (i.e., through system services), nor may they delete it 
(meaning they cannot use the DELETE service and thus reduce the 
load/responsibility count).  All they can do is find it somehow (through some 
structure known to all the developers who are either LOADing the module or else 
explicitly finding and using it) and branch into it.

The note says nothing about any requirements upon the module that does the 
deletion, such as knowing that it is still being used by 50 other address 
spaces and thus not deleting it for a while.  The task that LOADed it may 
DELETE it at any time it wants to with no sharing of such knowledge with its 
users, which may then suffer S0C4s or other unpredictable ABENDs.  Some might 
say this is a design flaw, even though it is what Paul Gilmartin would like to 
be able to do with externalized data sets so that z/OS will behave like some 
other operating system.  It's not a design flaw if all the developers involved 
understand all the rules and then some developer invents a scheme for managing 
the continued existence and usability of the load module in question.  E.g., 
users of the load module might all ENQ on some esoteric resource name before 
attempting to find the module and branch to it.  Or maybe the load module 
itself can increment a use count when it is first entered reentrantly by any 
address space and then decrement the use count when it exits.  The use count 
must obviously be stored somewhere in commonly addressable storage with known 
rules for accessing and managing the use count field.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Thursday, November 29, 2012 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Shmuel has urged me, rudely, to RYFM.  Doing so, I find


The LOAD macro is used to bring the load module containing the specified entry 
name into virtual storage, if a usable copy is not available in virtual 
storage. Control is not passed to the load module; instead, the load module's 
entry point address is returned in GPR 0. LOAD services places the load module 
in storage above or below 16 megabytes depending on the module's RMODE. The 
responsibility count for the load module is increased by one.

The load module remains in virtual storage until the responsibility count is 
reduced to 0 through task terminations or until the effects of all outstanding 
LOAD requests for the module have been canceled (using the DELETE macro), and 
there is no other requirement for the module.


(taken from z/OS MVS Assermbler Services Reference, ABEND-HSPSERV)

This is exactly what I described, with a single, I think unimportant,
exception:  I spoke of invocation or usage counts,. and this text speaks of 
responsibility counts.  For that lapse: mea minima culpa.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

Shmuel has urged me, rudely, to RYFM.  Doing so, I find


The LOAD macro is used to bring the load module containing the
specified entry name into virtual storage, if a usable copy is not
available in virtual storage. Control is not passed to the load
module; instead, the load module’s entry point address is
returned in GPR 0. LOAD services places the load module in storage
above or below 16 megabytes depending on the module’s RMODE. The
responsibility count for the load module is increased by one.

The load module remains in virtual storage until the responsibility
count is reduced to 0 through task terminations or until the effects
of all outstanding LOAD requests for the module have been canceled
(using the DELETE macro), and there is no other requirement for the
module.


(taken from z/OS MVS Assermbler Services Reference, ABEND-HSPSERV)

This is exactly what I described, with a single, I think unimportant,
exception:  I spoke of invocation or usage counts,. and this text
speaks of responsibility counts.  For that lapse: mea minima culpa.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In
,
on 11/29/2012
   at 08:26 AM, John Gilmore  said:

>This is the second time in recent days trhat Shmuel has commented
>adversely on one of my posts.

Don't make stupid errors and I won't comment on your stupid errors.

>In both cases he is the one who is talking nonsense,

The fact that you don't understand doesn't make it nonsense. RTFM.

>in this case

While I don't believe in quoting extraneous text, it is certainly
inappropriate to describe "this case" as "flagrant nonsense" without
quoting it.

"Nonsense; that's not even true for an authorized application that
specifies GLOBAL=YES; ownership is at the task and address space
levels. What is true is that the owning task can delete a module
loaded with GLOBAL=YES while code in another address space is
executing it and that tasks in the same address space can step on each
other."

Again, RYFM.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

This is the second time in recent days trhat Shmuel has commented
adversely on one of my posts.

In both cases he is the one who is talking nonsense, in this case
flagrant nonsense; but he of course has every right to do so.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In
,
on 11/28/2012
   at 10:44 AM, John Gilmore  said:

>The functioning of LOAD and DELETE provide a convenient example 
>of what this implies  If I LOAD a reentrant program that is not
>already present in storage, it is loaded and its usage/invocation
>count is increased from zero to one.  If instead it is already
>present in storage, having been loaded by someone else, its usage
>count is increased by one.  If I then DELETE that program, its usage count is 
>reduced
>by one; and only if that count is thus reduced to zero, i..e., if no one else 
>is 
>currently using it, is the storage occupied by this program recovered for 
>reuse.

Nonsense; that's not even true for an authorized application that
specifies GLOBAL=YES; ownership is at the task and address space
levels. What is true is that the owning task can delete a module
loaded with GLOBAL=YES while code in another address space is
executing it and that tasks in the same address space can step on each
other..

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Steve Thompson]

From:   Paul Gilmartin 
To: IBM-MAIN@listserv.ua.edu, 
Date:   11/28/2012 11:52 AM
Subject:Re: "New" way to do UCB lookups
Sent by:IBM Mainframe Discussion List 





And consider the job:

//WHATEVER JOB ...
//*
//STEP1  EXEC  PGM=BPXBATCH,PARM='SH sleep '
//*
//STEP2  EXEC  PGM=IEFBR14,COND=(0,LE)
//SYSUT1  DD   DISP=MOD,DSN=M42TOM.LINKLIB
//
... I can monopolize your data set while not using it for several
hours, preventing any of your use of it.  The design shouldn't
allow that.


Then a 44 magnum should not be allowed to discharge when pointed at  _ 
(fill in with your|their|my  foot|head|knee  etc.).

YOU created a BATCH job that needs certain resources that YOU determined 
prior to submitting the JOB. The system scheduled and then ran the JOB 
based on how you have the system defined and set up.

You effectively loaded a side-arm in a crowded room, cocked it, and 
pointed it and pulled the trigger.

Now you want to blame the manufacturer for it taking your knee off. Or 
killing all the power in the room.

Would you like some cheese with your whine?


Opinions expressed by this poster do not necessarily reflect those of 
poster's employer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Paul Gilmartin]

On Wed, 28 Nov 2012 10:19:04 -0600, Tom Marchant wrote:

>On Wed, 28 Nov 2012 00:30:24 -0600, Paul Gilmartin wrote:
>
>>If I _own_ a thing, you shouldn't be able to
>>do anything that prevents my doing what I want with it.
>
>So if you own a data set and you have permitted me to read it, 
>you should be able to delete that data set while I am reading it?
> 
If needed, yes.  I can certainly do likewise with a UNIX file, although
the space isn't reclaimed until you close it, and I don't know whose
quota it counts again in the meantime.

Last week I needed to delete and rebuild a linklib that a colleague
had allocated.  Possibly since July.  When he came back this week,
he readily cancelled the job -- it was a test he had largely forgotten.

If JCL allowed UNIX directories in STEPLIB concatenations, the
problem wouldn't have occurred.

And consider the job:

//WHATEVER JOB ...
//*
//STEP1  EXEC  PGM=BPXBATCH,PARM='SH sleep '
//*
//STEP2  EXEC  PGM=IEFBR14,COND=(0,LE)
//SYSUT1  DD   DISP=MOD,DSN=M42TOM.LINKLIB
//
... I can monopolize your data set while not using it for several
hours, preventing any of your use of it.  The design shouldn't
allow that.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Space allocation was Re: "New" way to do UCB lookups

[John Gilmore]

Clark Morris wrote:


So far as I can tell, other than making requests for a big quota, the
application developers
don't need to deal with space allocation in the other environments and
definitely not on a file by file basis.


and I think this should be conceded.

What is not so clear is that this is not a defect rather than a merit.

Long ago, I remember being regaled over and over again with statements
that adversely compared the great simplicity of a FORTRAN compilation
under UNIVAC's EXEC 8 with the 'gratuitous' complexity of this same
operation under OS/360.

I investigated and found that it was indeed much easier to compile a
FORTRAN program under EXEC 8; but a price had to be and was paid for
this simplicity.  It was hard to do much of anything else.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Space allocation was Re: "New" way to do UCB lookups

[Clark Morris]

On 27 Nov 2012 22:07:05 -0800, in bit.listserv.ibm-main you wrote:

 On 11/27/2012 at 08:35 PM, John McKown  
 wrote: 
>> IIRC, quotas can be implemented on some of the file systems in Linux.
>
>Most of them, in fact.
>
But there is no equivalent of the SPACE parameter in scripts for any
of those environments that I have seen.  It appears to be more like
something done under the covers by DF/SMS in z/OS and solely under the
control of the systems administration groups.  So far as I can tell,
other than making requests for a big quota, the application developers
don't need to deal with space allocation in the other environments and
definitely not on a file by file basis.

Clark Morris

>
>Mark Post
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Tom Marchant]

On Wed, 28 Nov 2012 00:30:24 -0600, Paul Gilmartin wrote:

>If I _own_ a thing, you shouldn't be able to
>do anything that prevents my doing what I want with it.

So if you own a data set and you have permitted me to read it, 
you should be able to delete that data set while I am reading it?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

I have grown weary of responding to Paul Gilmartin's moral outrage of
the day, but today's does require some comment.  He writes:


If I _own_ a thing, you shouldn't be able to do anything that prevents
my doing what I want with it.  RACF is badly oblivious to this.


This is a bad design notion.  (It is also bad law; the state can
invoke eminent domain to take my property away from me for purposes
that I may disapprove.)  MVS and its immediate antecedents have,
properly in my view, always judged that many operations must be
virtualizable.

The functioning of LOAD and DELETE provide a convenient example of
what this impliesIf I LOAD a reentrant program that is not already
present in storage, it is loaded and its usage/invocation count is
increased from zero to one.  If instead it is already present in
storage, having been loaded by someone else, its usage count is
increased by one.  If I then DELETE that program, its usage count is
reduced by one; and only if that count is thus reduced to zero, i..e.,
if no one else is currently using it, is the storage occupied by this
program recovered for reuse.

Paul's notion that the absolutist property-rights doctrines of
19th-century robber-baron capitalism provide an appropriate
system-design paradigm has a fatal flaw.  It prevents sharing those
resources.

Like many of his other comments, this one makes sense for a literally
'personal' computer, one used by a single person.  It is radically
inappropriate to a mainframe, the resources of which are shared by
many people.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Paul Gilmartin]

On Wed, 28 Nov 2012 00:03:06 -0600, Ed Gould wrote:
>
>If I read your entry correctly you are incorrect. OS/360 *DID* have
>enq/deq facilities (on the same system ) So on the same system you
>could simply not delete a data set that was in use.
>The cross system is more or less true albeit a small exception for
>GDG's but that was at the cvol level not dataset,
> 
Almost the opposite.  If I _own_ a thing, you shouldn't be able to
do anything that prevents my doing what I want with it.  RACF is
badly oblivious to this.  Even if I have all accesses to a DSN and
you have none, you can still ENQ on it and prevent my using it.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Mark Post]

>>> On 11/27/2012 at 08:35 PM, John McKown  
>>> wrote: 
> IIRC, quotas can be implemented on some of the file systems in Linux.

Most of them, in fact.


Mark Post

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Ed Gould]

Gil,

If I read your entry correctly you are incorrect. OS/360 *DID* have  
enq/deq facilities (on the same system ) So on the same system you  
could simply not delete a data set that was in use.
The cross system is more or less true albeit a small exception for  
GDG's but that was at the cvol level not dataset,


Ed

On Nov 27, 2012, at 11:25 PM, Paul Gilmartin wrote:


On Tue, 27 Nov 2012 17:12:01 -0800, Edward Jaffe wrote:


I have heard of filesystems that implement space quotas.


That's per user, of course.  But MVS grew out of OS/360, which had
little concept of resource ownership, and has not well matured beyond
that.  For example, if I own a data set, I ought to be able to  
delete or

rename it, even if the consequence is preempting other users who may
happen to have it allocated.

But user quotas is a much less cumbersome scheme than requiring a
user to specify SPACE= on each individual data set.  Given the  
essential

corollary of effective reporting ("How close am I to exceeding quota,
and what data sets are the major offenders?")  z/OS Unix System
services (USS) does pretty well here, by giving each user a zFS  
partition

and letting that user subdivide it as desired.  du(1) is a reasonably
effective reporting tool.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Paul Gilmartin]

On Tue, 27 Nov 2012 17:12:01 -0800, Edward Jaffe wrote:
>
>I have heard of filesystems that implement space quotas.
> 
That's per user, of course.  But MVS grew out of OS/360, which had
little concept of resource ownership, and has not well matured beyond
that.  For example, if I own a data set, I ought to be able to delete or
rename it, even if the consequence is preempting other users who may
happen to have it allocated.

But user quotas is a much less cumbersome scheme than requiring a
user to specify SPACE= on each individual data set.  Given the essential
corollary of effective reporting ("How close am I to exceeding quota,
and what data sets are the major offenders?")  z/OS Unix System
services (USS) does pretty well here, by giving each user a zFS partition
and letting that user subdivide it as desired.  du(1) is a reasonably
effective reporting tool.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John McKown]

IIRC, quotas can be implemented on some of the file systems in Linux.
On Nov 27, 2012 7:12 PM, "Edward Jaffe"  wrote:

> On 11/27/2012 4:22 PM, Clark Morris wrote:
>
>> Remember than most of the other environments don't have the equivalent
>> of SPACE=.  UNIX doesn't.  Windows doesn't.  I doubt MAC does.  Do the
>> UNISYS operating systems have the equivalent?
>>
>
> I have heard of filesystems that implement space quotas.
>
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.**com/ 
>
> --**--**--
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Edward Jaffe]

On 11/27/2012 4:22 PM, Clark Morris wrote:

Remember than most of the other environments don't have the equivalent
of SPACE=.  UNIX doesn't.  Windows doesn't.  I doubt MAC does.  Do the
UNISYS operating systems have the equivalent?


I have heard of filesystems that implement space quotas.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Clark Morris]

On 19 Nov 2012 07:29:15 -0800, in bit.listserv.ibm-main you wrote:

>McKown, John wrote:
>
>>... They are simply incapable of properly sizing (SPACE=) their data sets. ...
>
>Aw, ! Still struggling with them? I still remember that messy threads 
>about the space, volsers, SMS, etc...
>
>>... I don't know why.  ... etc... It's just way too much trouble. 
>
>Are these brain-cell challenged guys/gals still *USE* a "computer"?


Remember than most of the other environments don't have the equivalent
of SPACE=.  UNIX doesn't.  Windows doesn't.  I doubt MAC does.  Do the
UNISYS operating systems have the equivalent?

Clark Morris
>
>Groete / Greetings
>Elardus Engelbrecht
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

I know that one:

Älä vasta ja anna sen kuolla omin.

(For those who took Spanish instead of Finnish in high school:  Don't answer 
and it will die on its own.)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ibmmain
Sent: Wednesday, November 21, 2012 7:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

> How does one say "enough already of this thread" in French, German, 
> Russian, Finnish and COBOL ?

STOP!

Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Mike Schwab]

On Tue, Nov 20, 2012 at 11:20 PM, ibmmain  wrote:
>> How does one say "enough already of this thread" in French, German,
>> Russian, Finnish and COBOL ?
>
> STOP!
>
> Barbara
STOP RUN is much more effective than GOBACK.

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[ibmmain]

> How does one say "enough already of this thread" in French, German, 
> Russian, Finnish and COBOL ?

STOP!

Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In <45fcfbbb8bc8eb4a9dfedc6fa2cc7fdf2dbef...@sdkmbx02.emea.sas.com>,
on 11/20/2012
   at 01:53 PM, Lindy Mayfield  said:

>Now what does that mean?  Like your three points?  I have no idea. 
>But I am sure that it meets all criteria.  

Well, if you meant that they aren't taking off-site backups, that's
reckless.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Ted MacNEIL]

BNF.
Backus Naur/Normal Form.

I hated it more than Pseudo-Code in University.
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: Lindy Mayfield 
Sender:   IBM Mainframe Discussion List 
Date: Tue, 20 Nov 2012 17:08:07 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: "New" way to do UCB lookups

Dammit, Janet.  I did something I didn't think I needed to do. I went through 
one Rexx exec over 3000 lines long, which isn't really so big when you count 
that I added hundreds of lines of comments.  (That was a joke.)

There wasn't anything there that couldn't be as easily as Rexx be defined by 
(Oh, I forgot the acronym and google didn't help me because I forgot it, BNC or 
something similar), but you mentioned it many times.  The extended version.  
And IMO, any language if a special design (that I cannot describe) could 
satisfy those requirements if that language is of a certain design like Rexx.  
Perl?  Maybe, but I don't write Perl. I don't like it. 

 I think that some computer languages are very easy, and some almost impossible 
to do in any other language than English, or similar enough to English than to 
make it a nit.  

My Finnish isn't yet good enough to read a  novel, but my Finnish is good 
enough to read a novel written in Finnish and translated to English.  Your 
points are very spot on.

If you simply look for an MVS operator command that may be next to impossible 
in any other language than English, then I'll try to find one in Finnish.

Kind regards
Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Tuesday, November 20, 2012 6:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

One of the translators of Tolkien into Italian is an old friend, and I have 
discussed with him some of the problems he encountered in doing so.  Between 
two Indo-European languages translation that conveys substance is always 
possible, but words must often be replaced by phrases, and this can be highly 
problematic.

Consider the character Strider.  Italian has no equivalent of the verb 'to 
stride'.  Fine, camminare a gran passi, walk in large steps, conveys the sense 
accurately.  Unfortunately, however, a character named Camminatore-a-gran-passi 
has the same connotation for an Italian as Walker-in-large-steps has for an 
American: It strongly suggests an American-Indian character.  (Italians know 
all about 'cowboys e
indiani'.)  In the end 'Strider' was left untranslated in the Italian text.

Similar problems abound in translations of Pushkin from Russian into other 
European languages.  Pushkin's texts are full of puns, deliberately contrived 
ambiguities, connotation-laden names, and the like too; and finding equivalents 
for them in another language is very difficult.  In the upshot, people who, 
since they cannot read Russian, must depend upon inadequate translations, may 
wonder why Russians regard Pushkin as the equal of Shakespeare and Dante.

Chomsky has maintained that there is little reason to suppose that translation 
is possible in general, and this is not because he does not know that it has 
been done brilliantly.  (Unfortunately, the canonical examples are Catullus's 
Latin translations of some short Greek lyrics of Sappho, which somehow manage 
to be at once literal and perfect.  It would be agreeable if they were still 
accessible to non-specialists, but they are not.)

Text translation and the translation of, say, FORTRAN into sequences of machine 
instructions have some things in common, but they are also very different.  
Semantic ambiguity has been largely banished from procedural languages, and 
their translation is thus very much simpler than the translation of, for 
example, arbitrary Russian text into English.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Elardus Engelbrecht]

Tony B. wrote:

>How does one say "enough already of this thread" in French, German, Russian, 
>Finnish and COBOL ?

COBOL version: DISPLAY 'Enough already of this thread' UPON CONSOLE.

Afrikaans version: "Dis nou genoeg hiervan!"

I'm outta here before Big D jumps into... ;-D

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Tony B. AOL Mozilla]

How does one say "enough already of this thread" in French, German, 
Russian, Finnish and COBOL ?


Furthermore, I've never needed (nor wanted) to look up a UCB.  Lucky, I 
guess.




On 11/20/2012 10:36 AM, John Gilmore wrote:

One of the translators of Tolkien into Italian is an old friend, and I
have discussed with him some of the problems he encountered in doing
so.  Between two Indo-European languages translation that conveys
substance is always possible, but words must often be replaced by
phrases, and this can be highly problematic.

Consider the character Strider.  Italian has no equivalent of the verb
'to stride'.  Fine, camminare a gran passi, walk in large steps,
conveys the sense accurately.  Unfortunately, however, a character
named Camminatore-a-gran-passi has the same connotation for an Italian
as Walker-in-large-steps has for an American: It strongly suggests an
American-Indian character.  (Italians know all about 'cowboys e
indiani'.)  In the end 'Strider' was left untranslated in the Italian
text.

Similar problems abound in translations of Pushkin from Russian into
other European languages.  Pushkin's texts are full of puns,
deliberately contrived ambiguities, connotation-laden names, and the
like too; and finding equivalents for them in another language is very
difficult.  In the upshot, people who, since they cannot read Russian,
must depend upon inadequate translations, may wonder why Russians
regard Pushkin as the equal of Shakespeare and Dante.

Chomsky has maintained that there is little reason to suppose that
translation is possible in general, and this is not because he does
not know that it has been done brilliantly.  (Unfortunately, the
canonical examples are Catullus's Latin translations of some short
Greek lyrics of Sappho, which somehow manage to be at once literal and
perfect.  It would be agreeable if they were still accessible to
non-specialists, but they are not.)

Text translation and the translation of, say, FORTRAN into sequences
of machine instructions have some things in common, but they are also
very different.  Semantic ambiguity has been largely banished from
procedural languages, and their translation is thus very much simpler
than the translation of, for example, arbitrary Russian text into
English.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

Dammit, Janet.  I did something I didn't think I needed to do. I went through 
one Rexx exec over 3000 lines long, which isn't really so big when you count 
that I added hundreds of lines of comments.  (That was a joke.)

There wasn't anything there that couldn't be as easily as Rexx be defined by 
(Oh, I forgot the acronym and google didn't help me because I forgot it, BNC or 
something similar), but you mentioned it many times.  The extended version.  
And IMO, any language if a special design (that I cannot describe) could 
satisfy those requirements if that language is of a certain design like Rexx.  
Perl?  Maybe, but I don't write Perl. I don't like it. 

 I think that some computer languages are very easy, and some almost impossible 
to do in any other language than English, or similar enough to English than to 
make it a nit.  

My Finnish isn't yet good enough to read a  novel, but my Finnish is good 
enough to read a novel written in Finnish and translated to English.  Your 
points are very spot on.

If you simply look for an MVS operator command that may be next to impossible 
in any other language than English, then I'll try to find one in Finnish.

Kind regards
Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Tuesday, November 20, 2012 6:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

One of the translators of Tolkien into Italian is an old friend, and I have 
discussed with him some of the problems he encountered in doing so.  Between 
two Indo-European languages translation that conveys substance is always 
possible, but words must often be replaced by phrases, and this can be highly 
problematic.

Consider the character Strider.  Italian has no equivalent of the verb 'to 
stride'.  Fine, camminare a gran passi, walk in large steps, conveys the sense 
accurately.  Unfortunately, however, a character named Camminatore-a-gran-passi 
has the same connotation for an Italian as Walker-in-large-steps has for an 
American: It strongly suggests an American-Indian character.  (Italians know 
all about 'cowboys e
indiani'.)  In the end 'Strider' was left untranslated in the Italian text.

Similar problems abound in translations of Pushkin from Russian into other 
European languages.  Pushkin's texts are full of puns, deliberately contrived 
ambiguities, connotation-laden names, and the like too; and finding equivalents 
for them in another language is very difficult.  In the upshot, people who, 
since they cannot read Russian, must depend upon inadequate translations, may 
wonder why Russians regard Pushkin as the equal of Shakespeare and Dante.

Chomsky has maintained that there is little reason to suppose that translation 
is possible in general, and this is not because he does not know that it has 
been done brilliantly.  (Unfortunately, the canonical examples are Catullus's 
Latin translations of some short Greek lyrics of Sappho, which somehow manage 
to be at once literal and perfect.  It would be agreeable if they were still 
accessible to non-specialists, but they are not.)

Text translation and the translation of, say, FORTRAN into sequences of machine 
instructions have some things in common, but they are also very different.  
Semantic ambiguity has been largely banished from procedural languages, and 
their translation is thus very much simpler than the translation of, for 
example, arbitrary Russian text into English.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

One of the translators of Tolkien into Italian is an old friend, and I
have discussed with him some of the problems he encountered in doing
so.  Between two Indo-European languages translation that conveys
substance is always possible, but words must often be replaced by
phrases, and this can be highly problematic.

Consider the character Strider.  Italian has no equivalent of the verb
'to stride'.  Fine, camminare a gran passi, walk in large steps,
conveys the sense accurately.  Unfortunately, however, a character
named Camminatore-a-gran-passi has the same connotation for an Italian
as Walker-in-large-steps has for an American: It strongly suggests an
American-Indian character.  (Italians know all about 'cowboys e
indiani'.)  In the end 'Strider' was left untranslated in the Italian
text.

Similar problems abound in translations of Pushkin from Russian into
other European languages.  Pushkin's texts are full of puns,
deliberately contrived ambiguities, connotation-laden names, and the
like too; and finding equivalents for them in another language is very
difficult.  In the upshot, people who, since they cannot read Russian,
must depend upon inadequate translations, may wonder why Russians
regard Pushkin as the equal of Shakespeare and Dante.

Chomsky has maintained that there is little reason to suppose that
translation is possible in general, and this is not because he does
not know that it has been done brilliantly.  (Unfortunately, the
canonical examples are Catullus's Latin translations of some short
Greek lyrics of Sappho, which somehow manage to be at once literal and
perfect.  It would be agreeable if they were still accessible to
non-specialists, but they are not.)

Text translation and the translation of, say, FORTRAN into sequences
of machine instructions have some things in common, but they are also
very different.  Semantic ambiguity has been largely banished from
procedural languages, and their translation is thus very much simpler
than the translation of, for example, arbitrary Russian text into
English.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In , on 11/19/2012
   at 04:20 PM, Ed Gould  said:

>Paper tape is an oxymoron when used with WORM,

Not if the M stands for Maybe.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In <3944a5e9-71b2-48a9-902c-06a52d845...@comcast.net>, on 11/19/2012
   at 04:18 PM, Ed Gould  said:

>And remember a spade can sever a fiber optic cable just as easily 
>as a back hoe.

Yes, but the backhoe is the traditional instrument for the purpose (-;

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

No, not misinformed, I'm daft but that daft.  :-)

It means that I've been in shops that say they have gotten rid of all tape 
drives.  Don't even bring them a tape.

Now what does that mean?  Like your three points?  I have no idea.  But I am 
sure that it meets all criteria.

Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shmuel Metz (Seymour J.)
Sent: Tuesday, November 20, 2012 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

In <45fcfbbb8bc8eb4a9dfedc6fa2cc7fdf2dbee...@sdkmbx02.emea.sas.com>,
on 11/19/2012
   at 09:09 PM, Lindy Mayfield  said:

>Paper tape is even cheaper, but I'm just being a smart a$$.  :-)

No, just misinformed. Paper tape is far more expensive per bit, and the cost 
per foot isn't relevant.

>But seriously, I think that must be wrong if so many people are getting 
>rid of tape drives.


What does that mean?

 1. Using a hot backup site, which costs more but get you back
up more rapidly.

 2. Using tape drives at a remote location.

 3. Getting rid of off-site backups, which is risky.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2<http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In ,
on 11/19/2012
   at 03:22 PM, "McKown, John"  said:

>I have only recently gotten into writing rent code as "normal".
>Unfortunately(?) that has been coupled with the fact that all I 
>write any more is LE enabled HLASM. I still have some problems 
>with DCBs. I really wish IBM had a way to dynamically create one 
>in dynamic storage _easily

What is hard about an MVC or MVCL?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In <45fcfbbb8bc8eb4a9dfedc6fa2cc7fdf2dbee...@sdkmbx02.emea.sas.com>,
on 11/19/2012
   at 09:09 PM, Lindy Mayfield  said:

>Paper tape is even cheaper, but I'm just being a smart a$$.  :-)

No, just misinformed. Paper tape is far more expensive per bit, and
the cost per foot isn't relevant.

>But seriously, I think that must be wrong if so many people are
>getting rid of tape drives.


What does that mean?

 1. Using a hot backup site, which costs more but get you back
up more rapidly.

 2. Using tape drives at a remote location.

 3. Getting rid of off-site backups, which is risky.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Ted MacNEIL]

My favourite episode!
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: Mike Schwab 
Sender:   IBM Mainframe Discussion List 
Date: Mon, 19 Nov 2012 15:47:03 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: "New" way to do UCB lookups

Juliet on her Balcony - Star Trek TNG Episode Darmark

On Mon, Nov 19, 2012 at 3:39 PM, Lindy Mayfield  wrote:
> This has been so off topic for so long I don't mind this:  I was thinking, at 
> some point during some sort of stupid thing I had to do when I was bored to 
> tears:  What would SQL be like if it were developed in Finnish?
>
> Or any other human language to any other computer language.
>
> Select age, boyfriend_status, phone_number
>   From Cool_People_Table
>   where Sex = 'F';
>
> It gets me all Lewis Carroll just thinking about it.  I cannot even imagine 
> how to create something like that SQL in Finnish.  Something so simple as 
> that, I cannot even think how a computer could parse it written in an 
> agglutinative language.  Though I am a bear of very little brain, so I'm sure 
> it could be done.  :-)
>
> So to bring it a bit back on to topic, English can be weird, but sometimes 
> quite useful in its own way.
>
> Lindy
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of McKown, John
> Sent: Monday, November 19, 2012 11:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
>
> Yea, but paper tape is hell to reuse!  I guess it was the original WORM 
> tape media. But that WORM tape is not the same as tape worm. What a weird 
> language English is.
>
> --
> John McKown
> Systems Engineer IV
> IT
>
> Administrative Services Group
>
> HealthMarkets(r)
>
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone *
> john.mck...@healthmarkets.com * www.HealthMarkets.com
>
> Confidentiality Notice: This e-mail message may contain confidential or 
> proprietary information. If you are not the intended recipient, please 
> contact the sender by reply e-mail and destroy all copies of the original 
> message. HealthMarkets(r) is the brand name for products underwritten and 
> issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake 
> Life Insurance Company(r), Mid-West National Life Insurance Company of 
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
>
>
>> -Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Lindy Mayfield
>> Sent: Monday, November 19, 2012 3:10 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: "New" way to do UCB lookups
>>
>> Paper tape is even cheaper, but I'm just being a smart a$$.  :-)
>>
>> But seriously, I think that must be wrong if so many people are
>> getting rid of tape drives.  But honestly, I haven't a clue about this
>> stuff at all other than just thinking about it and reading posts.
>>
>> Lindy
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Tony Harminc]

On 19 November 2012 16:39, Lindy Mayfield  wrote:
> This has been so off topic for so long I don't mind this:  I was thinking, at 
> some point during some sort of stupid thing I had to do when I was bored to 
> tears:  What would SQL be like if it were developed in Finnish?
>
> Or any other human language to any other computer language.
>
> Select age, boyfriend_status, phone_number
>   From Cool_People_Table
>   where Sex = 'F';
>
> It gets me all Lewis Carroll just thinking about it.  I cannot even imagine 
> how to create something like that SQL in Finnish.  Something so simple as 
> that, I cannot even think how a computer could parse it written in an 
> agglutinative language.

Jabberwocky has, on its own and as part of the whole book, been
translated with varying success into many languages, and there are at
least two Finnish translations. The minor constraints facing a
translator of SQL would be a relative piece of cake...

> Though I am a bear of very little brain, so I'm sure it could be done.  :-)

The translation of Winnie the Pooh into such a relatively English-like
language as Esperanto has a minor problem because the English word
"pole" is used for both the Earth's north pole, and for the long
wooden object supposedly found there. These are two different words in
Esperanto, and it makes the pun (or collapse, if you like Paulos's
catastrophe model of humor) not so successful.

IBM's PL/I compilers from the earliest days provided an infrastructure
for translation of PL/I into other languages. But the authors realized
that there would be problems, and documented a couple of them, e.g.
that the keyword "TO" in "GO TO label" had to be the same "TO" as that
in "DO i = 1 TO n". This works in some languages; doubtless it doesn't
in others.

But all these are trivial tasks in comparison when you think of not
just the coined nonsense words in Jabberwocky, and their requirements
to rhyme at times, but that there are both commentary and
illustrations of the poem within the book that must remain consistent
with any translation.

> So to bring it a bit back on to topic, English can be weird, but sometimes 
> quite useful in its own way.

PL/I and SQL are surely on-topic for IBM-MAIN, if perhaps not for UCB
lookups and serialization.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Ed Gould]

Paper tape is an oxymoron when used with WORM,


On Nov 19, 2012, at 3:16 PM, McKown, John wrote:

Yea, but paper tape is hell to reuse!  I guess it was the  
original WORM tape media. But that WORM tape is not the same as  
tape worm. What a weird language English is.


--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain  
confidential or proprietary information. If you are not the  
intended recipient, please contact the sender by reply e-mail and  
destroy all copies of the original message. HealthMarkets(r) is the  
brand name for products underwritten and issued by the insurance  
subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance  
Company(r), Mid-West National Life Insurance Company of TennesseeSM  
and The MEGA Life and Health Insurance Company.SM




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Lindy Mayfield
Sent: Monday, November 19, 2012 3:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Paper tape is even cheaper, but I'm just being a smart a$$.  :-)

But seriously, I think that must be wrong if so many people are  
getting
rid of tape drives.  But honestly, I haven't a clue about this  
stuff at

all other than just thinking about it and reading posts.

Lindy


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Ed Gould]

On Nov 19, 2012, at 2:47 PM, Shmuel Metz (Seymour J.) wrote:




Their blind use is a recipe for disaster. Little gets done in an
industrial society without the use of high explosives, but that
doesn't mean that it is prudent to use them as a substitute for a
spade when digging up your garden. Google for "principle of least
privilege", then use the right tool for the job at hand.

-

Shmuel:
And remember a spade can sever a fiber optic cable just as easily as  
a back hoe.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Paul Gilmartin]

On Mon, 19 Nov 2012 21:09:52 +, Lindy Mayfield wrote:

>Paper tape is even cheaper, but I'm just being a smart a$$.  :-)
>
Per bit of storage?  I doubt that it's cheaper than even DVD-R or
consumer hard drives.  But you'll have to do the computation for me.
(Include floor space costs.)

>But seriously, I think that must be wrong if so many people are getting rid of 
>tape drives.  But honestly, I haven't a clue about this stuff at all other 
>than just thinking about it and reading posts.
>
Hush!  My job is at risk!
-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Mike Schwab]

Juliet on her Balcony - Star Trek TNG Episode Darmark

On Mon, Nov 19, 2012 at 3:39 PM, Lindy Mayfield  wrote:
> This has been so off topic for so long I don't mind this:  I was thinking, at 
> some point during some sort of stupid thing I had to do when I was bored to 
> tears:  What would SQL be like if it were developed in Finnish?
>
> Or any other human language to any other computer language.
>
> Select age, boyfriend_status, phone_number
>   From Cool_People_Table
>   where Sex = 'F';
>
> It gets me all Lewis Carroll just thinking about it.  I cannot even imagine 
> how to create something like that SQL in Finnish.  Something so simple as 
> that, I cannot even think how a computer could parse it written in an 
> agglutinative language.  Though I am a bear of very little brain, so I'm sure 
> it could be done.  :-)
>
> So to bring it a bit back on to topic, English can be weird, but sometimes 
> quite useful in its own way.
>
> Lindy
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of McKown, John
> Sent: Monday, November 19, 2012 11:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
>
> Yea, but paper tape is hell to reuse!  I guess it was the original WORM 
> tape media. But that WORM tape is not the same as tape worm. What a weird 
> language English is.
>
> --
> John McKown
> Systems Engineer IV
> IT
>
> Administrative Services Group
>
> HealthMarkets(r)
>
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone *
> john.mck...@healthmarkets.com * www.HealthMarkets.com
>
> Confidentiality Notice: This e-mail message may contain confidential or 
> proprietary information. If you are not the intended recipient, please 
> contact the sender by reply e-mail and destroy all copies of the original 
> message. HealthMarkets(r) is the brand name for products underwritten and 
> issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake 
> Life Insurance Company(r), Mid-West National Life Insurance Company of 
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
>
>
>> -Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Lindy Mayfield
>> Sent: Monday, November 19, 2012 3:10 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: "New" way to do UCB lookups
>>
>> Paper tape is even cheaper, but I'm just being a smart a$$.  :-)
>>
>> But seriously, I think that must be wrong if so many people are
>> getting rid of tape drives.  But honestly, I haven't a clue about this
>> stuff at all other than just thinking about it and reading posts.
>>
>> Lindy
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

My Pooh can kick your Propertius' butt:

"When you are a Bear of Very Little Brain, and you Think of Things, you find 
sometimes that a Thing which seemed very Thingish inside you is quite different 
when it gets out into the open and has other people looking at it."


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Monday, November 19, 2012 11:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Lindy,

The point Propertius---and I, derivatively---was making was that how people 
think about their problems, the kinds of questions they ask, etc., etc, are 
shaped by what they do.

We are all creatures of our experience; and that experience is different for 
each of us.

What this thread established once again was that we often talk at cross 
purposes here because we are so different, see the world refracted through so 
many different epistemes.  There is, I am sure, a place for non-reentrant, 
unserialized code in some universe of
discourse, but not in mine.   My objections to it are intellectual
certainly, but they are also visceral.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Thomas H Puddicombe]

Paper tape - the scars on my back translate WORM as "Write Once, Read? 
Maybe ..."

Vacation Notice:  None
 
Tom Puddicombe
Mainframe Performance & Capacity Planning
CSC

31 Brookdale Rd, Meriden, CT 06450
ITIS | (860) 428-3252 | tpudd...@csc.com | www.csc.com

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.



From:   "McKown, John" 
To: IBM-MAIN@listserv.ua.edu
Date:   11/19/2012 04:16 PM
Subject:        Re: "New" way to do UCB lookups
Sent by:IBM Mainframe Discussion List 



Yea, but paper tape is hell to reuse!  I guess it was the original 
WORM tape media. But that WORM tape is not the same as tape worm. What a 
weird language English is.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message. HealthMarkets(r) is the brand name for products underwritten and 
issued by the insurance subsidiaries of HealthMarkets, Inc. -The 
Chesapeake Life Insurance Company(r), Mid-West National Life Insurance 
Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lindy Mayfield
> Sent: Monday, November 19, 2012 3:10 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> Paper tape is even cheaper, but I'm just being a smart a$$.  :-)
> 
> But seriously, I think that must be wrong if so many people are getting
> rid of tape drives.  But honestly, I haven't a clue about this stuff at
> all other than just thinking about it and reading posts.
> 
> Lindy

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

This has been so off topic for so long I don't mind this:  I was thinking, at 
some point during some sort of stupid thing I had to do when I was bored to 
tears:  What would SQL be like if it were developed in Finnish?

Or any other human language to any other computer language.

Select age, boyfriend_status, phone_number
  From Cool_People_Table
  where Sex = 'F';

It gets me all Lewis Carroll just thinking about it.  I cannot even imagine how 
to create something like that SQL in Finnish.  Something so simple as that, I 
cannot even think how a computer could parse it written in an agglutinative 
language.  Though I am a bear of very little brain, so I'm sure it could be 
done.  :-)

So to bring it a bit back on to topic, English can be weird, but sometimes 
quite useful in its own way.

Lindy



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of McKown, John
Sent: Monday, November 19, 2012 11:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Yea, but paper tape is hell to reuse!  I guess it was the original WORM 
tape media. But that WORM tape is not the same as tape worm. What a weird 
language English is.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lindy Mayfield
> Sent: Monday, November 19, 2012 3:10 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> Paper tape is even cheaper, but I'm just being a smart a$$.  :-)
> 
> But seriously, I think that must be wrong if so many people are 
> getting rid of tape drives.  But honestly, I haven't a clue about this 
> stuff at all other than just thinking about it and reading posts.
> 
> Lindy

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

Mr. Gilmore, yes, thanks for taking the time to respond to my musings.

You give me the impression (albeit possibly falsely in my mind) that  you are 
correct, when you are simply being exact.  I was a DBA in D.C. government for 
the Y2K, and we, and I knew all the DB2 rules.  But I also knew what batch jobs 
were running, and when, and doing what, reading, updating, etc.  I also knew 
when I took down the CICS systems.  We were stressed for time, and I let a lot 
of things slide because that was how the batch jobs were designed.  Like I 
said, because I knew what was going on.

Now.  Was that optimal, even good?  At the time, yes.  But god help them if 
after I left they deviated from it all. If they left an online system up and 
running when it shouldn't be.  I certainly took my consultant pay, did whatever 
I had to do, and left when they told me to leave.  

You seem to be saying what everyone else is saying:  This is how it should be 
done, but in some cases (like an Rexx exec), it is ok.  This thread is fun, but 
seems to me in their own way everyone pretty much agrees with everyone else.  
:-)

Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Monday, November 19, 2012 11:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Lindy,

The point Propertius---and I, derivatively---was making was that how people 
think about their problems, the kinds of questions they ask, etc., etc, are 
shaped by what they do.

We are all creatures of our experience; and that experience is different for 
each of us.

What this thread established once again was that we often talk at cross 
purposes here because we are so different, see the world refracted through so 
many different epistemes.  There is, I am sure, a place for non-reentrant, 
unserialized code in some universe of
discourse, but not in mine.   My objections to it are intellectual
certainly, but they are also visceral.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[McKown, John]

I have only recently gotten into writing rent code as "normal". 
Unfortunately(?) that has been coupled with the fact that all I write any more 
is LE enabled HLASM. I still have some problems with DCBs. I really wish IBM 
had a way to dynamically create one in dynamic storage _easily_. Like a DCB 
macro which had a MF=(E,(1)) type parameter.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John Gilmore
> Sent: Monday, November 19, 2012 3:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> Lindy,
> 
> The point Propertius---and I, derivatively---was making was that how
> people think about their problems, the kinds of questions they ask,
> etc., etc, are shaped by what they do.
> 
> We are all creatures of our experience; and that experience is
> different for each of us.
> 
> What this thread established once again was that we often talk at cross
> purposes here because we are so different, see the world refracted
> through so many different epistemes.  There is, I am sure, a place for
> non-reentrant, unserialized code in some universe of
> discourse, but not in mine.   My objections to it are intellectual
> certainly, but they are also visceral.
> 
> John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[McKown, John]

Yea, but paper tape is hell to reuse!  I guess it was the original WORM 
tape media. But that WORM tape is not the same as tape worm. What a weird 
language English is.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lindy Mayfield
> Sent: Monday, November 19, 2012 3:10 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> Paper tape is even cheaper, but I'm just being a smart a$$.  :-)
> 
> But seriously, I think that must be wrong if so many people are getting
> rid of tape drives.  But honestly, I haven't a clue about this stuff at
> all other than just thinking about it and reading posts.
> 
> Lindy

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

Lindy,

The point Propertius---and I, derivatively---was making was that how
people think about their problems, the kinds of questions they ask,
etc., etc, are shaped by what they do.

We are all creatures of our experience; and that experience is
different for each of us.

What this thread established once again was that we often talk at
cross purposes here because we are so different, see the world
refracted through so many different epistemes.  There is, I am sure, a
place for non-reentrant, unserialized code in some universe of
discourse, but not in mine.   My objections to it are intellectual
certainly, but they are also visceral.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

Paper tape is even cheaper, but I'm just being a smart a$$.  :-)

But seriously, I think that must be wrong if so many people are getting rid of 
tape drives.  But honestly, I haven't a clue about this stuff at all other than 
just thinking about it and reading posts.

Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shmuel Metz (Seymour J.)
Sent: Monday, November 19, 2012 10:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

In <45fcfbbb8bc8eb4a9dfedc6fa2cc7fdf2dbee...@sdkmbx02.emea.sas.com>,
on 11/19/2012
   at 02:44 PM, Lindy Mayfield  said:

>People still use tapes?

It's an inexpensive way to create media for backup.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In <45fcfbbb8bc8eb4a9dfedc6fa2cc7fdf2dbee...@sdkmbx02.emea.sas.com>,
on 11/19/2012
   at 02:44 PM, Lindy Mayfield  said:

>People still use tapes?

It's an inexpensive way to create media for backup.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In
,
on 11/19/2012
   at 11:10 AM, John Gilmore  said:

>An authorized program can do great, even lethal damage; and the
>standards for them are or should be much higher than they are or 
>need be for a program that generates mailing labels.  That 
>conceded, little that is useful gets done without the use, either 
>explicitly or under the covers, of authorized programs; there is 
>nothing fearsome about them; and their avoidance is a recipe for 
>inadequacy.

Their blind use is a recipe for disaster. Little gets done in an
industrial society without the use of high explosives, but that
doesn't mean that it is prudent to use them as a substitute for a
spade when digging up your garden. Google for "principle of least
privilege", then use the right tool for the job at hand.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

What is so bad about that?  When all you have is a hammer, AND you are a 
carpenter, etc...

You chastised us, then told us in Latin it was ok.  :-) 

(Well, not me you didn't.  If I needed to know it, I'd learn it. Here I am just 
curious.)

Anyway, if I am a seaman, why would I care how many sheep you have unless I am 
eating them on the way to far-away lands.  :-)

Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Monday, November 19, 2012 10:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Navita (sic) . . .

The seaman recalls his winds; the plowman remembers his bulls; the soldier 
enumerates his wounds; the shepherd lists his sheep.

Propertius, Elegies II.i.43

--jg

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

Navita (sic) . . .

The seaman recalls his winds; the plowman remembers his bulls; the
soldier enumerates his wounds; the shepherd lists his sheep.

Propertius, Elegies II.i.43

--jg

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[McKown, John]

Gee, every bit of the code that I have sent to the CBT has clearly (I hope) 
stated: "Your take full responsibility for this use of this software. It if 
breaks, you own both pieces." The CBT is not just a place for "production 
quality" code, though I think the majority of the code there is. But, 
personally, I never put CBT code into a production job. I use it strictly for 
my own use. That's for my own self protection. OK, mainly so that I can blame 
the vendor when something goes horribly wrong.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Gould
> Sent: Monday, November 19, 2012 2:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> Sam,
> 
> if its for your use only I guess I agree. But if it becomes public
> domain then a higher (stricter?) standard should be made *UNLESS*
> (IMO) a statement is made that the output is should not be depended on
> and the statement should be either at the the top or of the report or
> somewhere plain that you can see (even thats a maybe IMO)).
> 
> Ed
> 
> On Nov 19, 2012, at 1:20 PM, Sam Golob wrote:
> 
> > Hi Folks,
> >
> > Just for the record, I have to say one thing.  If you are writing
> > some program that you're selling for money, it has to be (at least
> > with your best effort) 100 percent airtight.  When you have the
> > responsibility for keeping a data center up, you have to take that
> > responsibility seriously.  Usually a "for pay" product comes with
> some
> > sort of written warranty, and therefore you can't risk any loss of
> > money for the data center, or for yourself. (This really goes without
> > saying, but obviously I have to say it, because of the above
> > discussion thread.)  Notwithstanding, people still find it useful to
> > write "quick and dirty" programs for themselves, or even "quick, but
> > clean and careful" programs. (And this is obvious to all of us).
> >
> > So with that said, I wish you all the best of everything.
> > Thanks for your feedback.
> >
> > Sam
> >
> > -
> -
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Ed Gould]

Sam,

if its for your use only I guess I agree. But if it becomes public  
domain then a higher (stricter?) standard should be made *UNLESS*  
(IMO) a statement is made that the output is should not be depended  
on and the statement should be either at the the top or of the report  
or somewhere plain that you can see (even thats a maybe IMO)).


Ed

On Nov 19, 2012, at 1:20 PM, Sam Golob wrote:


Hi Folks,

Just for the record, I have to say one thing.  If you are  
writing some program that you're selling for money, it has to be  
(at least with your best effort) 100 percent airtight.  When you  
have the responsibility for keeping a data center up, you have to  
take that responsibility seriously.  Usually a "for pay" product  
comes with some sort of written warranty, and therefore you can't  
risk any loss of money for the data center, or for yourself. (This  
really goes without saying, but obviously I have to say it, because  
of the above discussion thread.)  Notwithstanding, people still  
find it useful to write "quick and dirty" programs for themselves,  
or even "quick, but clean and careful" programs. (And this is  
obvious to all of us).


So with that said, I wish you all the best of everything.  
Thanks for your feedback.


Sam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Bill Fairchild]

IBM software must continue to support features X, Y, and Z and hardware devices 
X1, Y2, and Z99 long after the vast majority of their customers no longer use 
those things.  Just because your installation might have NO real tape drives 
does not mean that you do not have software running right now that thinks it is 
writing data to a real tape but it is really writing data to a virtual tape 
drive (all puns really intended).  By inserting more levels of virtualization 
between the application and the real hardware you avoid ever having to change 
the application and you can still support that application's use of all the 
latest and greatest hardware virtually forever.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lindy Mayfield
Sent: Monday, November 19, 2012 1:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

No mainframe shop that I know of in Finland has had tape drives for some years. 
 I thought they went the way of card readers and paper tape already.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Conway
Sent: Monday, November 19, 2012 4:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Why is that curious?

Steven F. Conway, CISSP
LA Systems
z/OS Systems Support
Phone: 703.295.1926
steve_con...@ao.uscourts.gov



From:   Lindy Mayfield 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/19/2012 09:44 AM
Subject:        Re: "New" way to do UCB lookups
Sent by:IBM Mainframe Discussion List 



People still use tapes?  Oh.  That's curious.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Bill Fairchild]

Try Googling for it again with "navita" instead of "navitra".

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lindy Mayfield
Sent: Monday, November 19, 2012 2:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

That Latin phrase Google didn't find for me.

How do you say, "If all you got is a hammer, everything looks like a nail."  
The Romans must have had something similar.

:-)

Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Monday, November 19, 2012 6:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

I have had a curious reaction to recent developments in this thread.

Many posters apparently see virtues in not being authorized that are distinct 
from not needing to be authorized.
...

Many posters do not really know what serialization is and are quite happy in 
their ignorance.  I find this at once more surprising and more disturbing, not 
least because even minimally competent COBOL programmers need to know about it.

Still, we all have our own preoccupations:

 Navitra de ventis, de tauris narrat arator,  Enumerat miles vulnera, pastor 
oves.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

I never asked how they do those things, just when a few years ago I learned 
that all tapes were gone I thought, oh, cool.  

But, thinking about it, I have never seen, for example, a z/OS level more than 
two below the latest one.  My latest customer went to 1.13 a month ago.  It is 
just, I guess, a Finnish thing.  :-)

Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of McKown, John
Sent: Monday, November 19, 2012 10:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

I assume the companies without tapes do off-site replication of their disk 
arrays for disaster recovery and on-line (error) recovery? We would like to do 
that. But 3952 tape and storage fees cost less than the duplicated disk array 
plus telecommunications fees would. 


--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lindy Mayfield
> Sent: Monday, November 19, 2012 1:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> No mainframe shop that I know of in Finland has had tape drives for 
> some years.  I thought they went the way of card readers and paper 
> tape already.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Steve Conway
> Sent: Monday, November 19, 2012 4:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> Why is that curious?
> 
> Steven F. Conway, CISSP
> LA Systems
> z/OS Systems Support
> Phone: 703.295.1926
> steve_con...@ao.uscourts.gov
> 
> 
> 
> From:   Lindy Mayfield 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   11/19/2012 09:44 AM
> Subject:Re: "New" way to do UCB lookups
> Sent by:IBM Mainframe Discussion List  m...@listserv.ua.edu>
> 
> 
> 
> People still use tapes?  Oh.  That's curious.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

That Latin phrase Google didn't find for me.

How do you say, "If all you got is a hammer, everything looks like a nail."  
The Romans must have had something similar.

:-)

Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Monday, November 19, 2012 6:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

I have had a curious reaction to recent developments in this thread.

Many posters apparently see virtues in not being authorized that are distinct 
from not needing to be authorized.
...

Many posters do not really know what serialization is and are quite happy in 
their ignorance.  I find this at once more surprising and more disturbing, not 
least because even minimally competent COBOL programmers need to know about it.

Still, we all have our own preoccupations:

 Navitra de ventis, de tauris narrat arator,  Enumerat miles vulnera, pastor 
oves.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[McKown, John]

I assume the companies without tapes do off-site replication of their disk 
arrays for disaster recovery and on-line (error) recovery? We would like to do 
that. But 3952 tape and storage fees cost less than the duplicated disk array 
plus telecommunications fees would. 


-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lindy Mayfield
> Sent: Monday, November 19, 2012 1:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> No mainframe shop that I know of in Finland has had tape drives for
> some years.  I thought they went the way of card readers and paper tape
> already.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Steve Conway
> Sent: Monday, November 19, 2012 4:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> Why is that curious?
> 
> Steven F. Conway, CISSP
> LA Systems
> z/OS Systems Support
> Phone: 703.295.1926
> steve_con...@ao.uscourts.gov
> 
> 
> 
> From:   Lindy Mayfield 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   11/19/2012 09:44 AM
> Subject:Re: "New" way to do UCB lookups
> Sent by:IBM Mainframe Discussion List  m...@listserv.ua.edu>
> 
> 
> 
> People still use tapes?  Oh.  That's curious.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

No mainframe shop that I know of in Finland has had tape drives for some years. 
 I thought they went the way of card readers and paper tape already.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Conway
Sent: Monday, November 19, 2012 4:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Why is that curious?

Steven F. Conway, CISSP
LA Systems
z/OS Systems Support
Phone: 703.295.1926
steve_con...@ao.uscourts.gov



From:   Lindy Mayfield 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/19/2012 09:44 AM
Subject:        Re: "New" way to do UCB lookups
Sent by:IBM Mainframe Discussion List 



People still use tapes?  Oh.  That's curious.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Bill Fairchild]

ocks must 
follow all the externally documented conventions or system integrity can be 
compromised.

If you write authorized code, you follow all the rules, and you get weird 
results, then there may be some other authorized code changing the control 
block structure incorrectly.  But it most likely will be your own code that is 
not strictly following all the documented rules.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lindy Mayfield
Sent: Friday, November 16, 2012 10:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Are you saying, that you can put some sort of "lock" on a control block, so 
that when you update it, you know that nobody else has updated it?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

I have had a curious reaction to recent developments in this thread.

Many posters apparently see virtues in not being authorized that are
distinct from not needing to be authorized.

An authorized program can do great, even lethal damage; and the
standards for them are or should be much higher than they are or need
be for a program that generates mailing labels.  That conceded, little
that is useful gets done without the use, either explicitly or under
the covers, of authorized programs; there is nothing fearsome about
them; and their avoidance is a recipe for inadequacy.

Many posters do not really know what serialization is and are quite
happy in their ignorance.  I find this at once more surprising and
more disturbing, not least because even minimally competent COBOL
programmers need to know about it.

Still, we all have our own preoccupations:

 Navitra de ventis, de tauris narrat arator,
 Enumerat miles vulnera, pastor oves.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Elardus Engelbrecht]

McKown, John wrote:

>... They are simply incapable of properly sizing (SPACE=) their data sets. ...

Aw, ! Still struggling with them? I still remember that messy threads about 
the space, volsers, SMS, etc...

>... I don't know why.  ... etc... It's just way too much trouble. 

Are these brain-cell challenged guys/gals still *USE* a "computer"?

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[McKown, John]

We use tapes quite a bit. We use 3592 carts for off-site storage. We use 
virtual 3490 for use in batch jobs for in-house backups. We have OpenTech's 
(now Rocket Software's) TapeCopy for data on virtual 3490 which needs to be off 
site for recovery. We considered using "TMM" to convert from virtual 3490 to 
real disk. But "it was too much bother" for the programmers. They are simply 
incapable of properly sizing (SPACE=) their data sets. We had to set up SMS so 
that the DATACLAS has a DVC of 59, effectively allowing them to have 
"unlimited" space for disk resident data sets. We still get complaints about 
PDSes because they cannot span multiple volumes and are limited to 16 extents. 
Like many here, the programmers don't like PDSEs very much. I don't know why. 
And don't mention UNIX to them. "Deer in headlights" looks from them. They 
can't grasp why the path separator in UNIX is / rather that the universal 
standard of \ like Windows. Or why they must put the UNIX file names in 
'quotes' and not "quotes". And why 'file.ext' is not the same as 'FILE.EXT' 
like in Windows. It's just way too much trouble. And lower case is a tool of 
the Devil anyway.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lindy Mayfield
> Sent: Monday, November 19, 2012 8:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> People still use tapes?  Oh.  That's curious.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Sam Golob
> Sent: Monday, November 19, 2012 7:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: "New" way to do UCB lookups
> 
> 
>  Now for a new one.  I just wrote another program, called UCBTAPE,
> that I also put on File 731 on the Updates page of www.cbttape.org.  It
> was written using the same method of reading the UCB's.  This one is a
> TSO command to display all your online tape drives, and to tell you all
> the outstanding tape mounts.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Steve Conway]

Why is that curious?

Steven F. Conway, CISSP
LA Systems
z/OS Systems Support
Phone: 703.295.1926
steve_con...@ao.uscourts.gov



From:   Lindy Mayfield 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/19/2012 09:44 AM
Subject:Re: "New" way to do UCB lookups
Sent by:IBM Mainframe Discussion List 



People still use tapes?  Oh.  That's curious.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Sam Golob
Sent: Monday, November 19, 2012 7:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: "New" way to do UCB lookups


 Now for a new one.  I just wrote another program, called UCBTAPE, 
that I also put on File 731 on the Updates page of www.cbttape.org.  It 
was written using the same method of reading the UCB's.  This one is a TSO 
command to display all your online tape drives, and to tell you all the 
outstanding tape mounts. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

People still use tapes?  Oh.  That's curious.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sam Golob
Sent: Monday, November 19, 2012 7:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: "New" way to do UCB lookups


 Now for a new one.  I just wrote another program, called UCBTAPE, that I 
also put on File 731 on the Updates page of www.cbttape.org.  It was written 
using the same method of reading the UCB's.  This one is a TSO command to 
display all your online tape drives, and to tell you all the outstanding tape 
mounts.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In <45fcfbbb8bc8eb4a9dfedc6fa2cc7fdf2dbed...@sdkmbx02.emea.sas.com>,
on 11/18/2012
   at 01:55 AM, Lindy Mayfield  said:

>May I infer, then, that you are talking about "serious" issues 
>where the program better get it right the first time, especially 
>when updating these control blocks (1) that are being discussed 
>at the moment.

The issues are serious in general, especially when updating control
blocks. However, the Devil is in the details.

>And simple interfaces to storage, such as Rexx  need have 
>different requirements, thus because of simple functions to read 
>storage be exempt from this discussion?

The requirements don't change; what changes is your ability to satisfy
the requirements.

The case under discussion is one where an unauthorized program needs
to read a control block but not update it, and where garbage output is
acceptable. Change those constraints and the requirements change; it's
at that point that the term "Russian Roulette" becomes relevant.

>(1)  Who can update these control blocks?  I think from reading this
>only z/OS can.  (or should, you guys do what you want, seems like,
>then justify it like I just did.)

Again, the Devil is in the details, but, in general:

 1. Don't do it if you don't understand the rules.
 2. Follow the rules if you can,
 3. Don't break the rules unless you understand the possible[1]
consequences and can live with them.

[1] All of the consequences, not just best case or most likely.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In
,
on 11/17/2012
   at 01:41 PM, John Gilmore  said:

>Some of the computer science literature talks instead about
>serialization and semaphores

Serialization is not ENQ/DEQ; it is more general. Nor is ENQ/DEQ the
only serialization mechanism in z/OS. Semaphores are a specific
type[1] of serialization

>(Dijkstra's term, a metaphoric hijacking of the European word for 
>what Americans usually call  'traffic lights').

No.

Noun:

A system of sending messages by holding the arms or two flags or poles
in certain positions according to an alphabetic code.

The use of the term "semaphore" to designate traffic lights came
later.

[1] Well, two related types.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shmuel Metz (Seymour J.)]

In
,
on 11/16/2012
   at 10:18 AM, John Gilmore  said:

>A minimal requirement for their integrity is that two 
>dispatchables not access one of them concurrently.

No. That is an unnecessary and insufficient condition. The rules for
accessing control blocks safely vary depending on the control block
and the type of access.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Sam Siegel]

On Sat, Nov 17, 2012 at 5:55 PM, Lindy Mayfield wrote:

> May I infer, then, that you are talking about "serious" issues where the
> program better get it right the first time, especially when updating these
> control blocks (1) that are being discussed at the moment.  And simple
> interfaces to storage, such as Rexx  need have different requirements, thus
> because of simple functions to read storage be exempt from this discussion?
>  I mean, that's all there is that programs like Rexx have, and they need
> live with it, yet at the same time understand discussions such as these.
>

Lindy - Please consider the topic in a more general fashion.  Any
applications (problem or supervisor state) that has 2 or more threads of
executions (TCBs) operating at the same time and share data structures
(memory) need to agree when how to synchronise updates and read access to
the share memory area.  Otherwise, both threads may attempt to update the
same memory location at the same time with different values.  One of the
values will be lost.  This will negatively impact the way the application
runs.

Sam


>
> Kind regards
> Lindy
>
> (1)  Who can update these control blocks?  I think from reading this only
> z/OS can.  (or should, you guys do what you want, seems like, then justify
> it like I just did.)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John Gilmore
> Sent: Saturday, November 17, 2012 8:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
>
> Lindy,
>
> I have received several private, offlist requests for elucidations of the
> same sort you make.
>
> I suggest that you read the descriptions of the ENQ and DEQ macros in
>
> z/OS MVS: Assembler Services Reference, Volume 1 (ABEND-HSPSERV),
> SA22-7606.
>
> Some of the computer science literature talks instead about serialization
> and semaphores (Dijkstra's term, a metaphoric hijacking of the European
> word for what Americans usually call 'traffic lights').
>
> Also worth looking at are the discussions of the Test and Set (TS)
> instruction and its more powerful brethren, the most recent of which is
> Perform Locked Operation (PLO),  in z/Architecture Principles of Operation,
> SA22-7832.
>
> These notions are important ones.  What needs to be emphasized about them
> is that they all make use of a mixture of conventions and hardware help.
>  If you and I and others agree to adhere to a set of such conventions, then
> we can safely share access to serially reusable resources.  If not, not.
>
> John Gilmore, Ashland, MA 01721 - USA
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

May I infer, then, that you are talking about "serious" issues where the 
program better get it right the first time, especially when updating these 
control blocks (1) that are being discussed at the moment.  And simple 
interfaces to storage, such as Rexx  need have different requirements, thus 
because of simple functions to read storage be exempt from this discussion?  I 
mean, that's all there is that programs like Rexx have, and they need live with 
it, yet at the same time understand discussions such as these.

Kind regards
Lindy

(1)  Who can update these control blocks?  I think from reading this only z/OS 
can.  (or should, you guys do what you want, seems like, then justify it like I 
just did.)


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Saturday, November 17, 2012 8:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Lindy,

I have received several private, offlist requests for elucidations of the same 
sort you make.

I suggest that you read the descriptions of the ENQ and DEQ macros in

z/OS MVS: Assembler Services Reference, Volume 1 (ABEND-HSPSERV), SA22-7606.

Some of the computer science literature talks instead about serialization and 
semaphores (Dijkstra's term, a metaphoric hijacking of the European word for 
what Americans usually call 'traffic lights').

Also worth looking at are the discussions of the Test and Set (TS) instruction 
and its more powerful brethren, the most recent of which is Perform Locked 
Operation (PLO),  in z/Architecture Principles of Operation, SA22-7832.

These notions are important ones.  What needs to be emphasized about them is 
that they all make use of a mixture of conventions and hardware help.  If you 
and I and others agree to adhere to a set of such conventions, then we can 
safely share access to serially reusable resources.  If not, not.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Paul Gilmartin]

On Fri, 16 Nov 2012 10:18:43 -0500, John Gilmore wrote:
>
>I have not elected to screen my own house in this way; equally, I have
>not reinforced its roof against purple cows falling from the sky; I
>have judged that these two risks are exiguous here in Massachusetts.
> 
Probability?  I can't resist:

http://xkcd.com/1132/

>Serialization was invented to address this class of problems.  We can
>make programs reentrant.  Control blocks, on the other hand, are and
>will remain serially reusable.  A minimal requirement for their
>integrity is that two dispatchables not access one of them
>concurrently.
> 
But the serialization can be inconspicuous.  IEANTRT makes do with
nothing more than the block-concurrent character of Load and STore,
given major cooperation by IEANTCR.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Mark Zelden]

On Sat, 17 Nov 2012 04:24:44 +, Lindy Mayfield  
wrote:


>
>Can I read these control blocks with Rexx?  If so, maybe I'll give it a go 
>when I have some free moments.
>

I think a good example is the SHOWDASD exec (& panel) in CBT File 183.   It is 
Gilbert's
code that Sam used that started this thread.  I've used it for many years and 
never
had a problem.

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

Lindy,

I have received several private, offlist requests for elucidations of
the same sort you make.

I suggest that you read the descriptions of the ENQ and DEQ macros in

z/OS MVS: Assembler Services Reference, Volume 1 (ABEND-HSPSERV), SA22-7606.

Some of the computer science literature talks instead about
serialization and semaphores (Dijkstra's term, a metaphoric hijacking
of the European word for what Americans usually call 'traffic
lights').

Also worth looking at are the discussions of the Test and Set (TS)
instruction and its more powerful brethren, the most recent of which
is Perform Locked Operation (PLO),  in z/Architecture Principles of
Operation, SA22-7832.

These notions are important ones.  What needs to be emphasized about
them is that they all make use of a mixture of conventions and
hardware help.  If you and I and others agree to adhere to a set of
such conventions, then we can safely share access to serially reusable
resources.  If not, not.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Lindy Mayfield]

I don't quite  understand this thread, but I find it interesting in that I'd 
like to understand it.

Are you saying, that you can put some sort of "lock" on a control block, so 
that when you update it, you know that nobody else has updated it?

I am not sure if this is apples and giraffes, but I wrote a Rexx exec and ISPF 
panel to show ASCB and related control blocks for a given job that shows all 
about timeouts.

I hit the enter, and my Rexx and ISPF fields change accordingly.

Sometimes I hit enter and see weird garbage in there.  No matter.  I just hit 
enter again and all is well.  I assume the garbage in some of the fields is due 
to the control blocks being in some unknown state.

But if I hit enter and see, for example, 5 things, and somebody updates and 
adds one or takes one away, then when I hit enter again, I'll see the updated 
list.  I see how long I have to wait for a 522, or I see that the job is exempt 
from timeout.  That won't change.  If someone adds something new just a 
millisecond from when I look for it, how is that different from updating a 
database table?  You might say to lock it for update.  I may say that I want to 
read the row, then lock it and update it just if it is has changed.  In that 
case I know if it has changed.  

I'm not trying to be smart, I only want to understand what is the real issue.  
The only thing I can think of is that if multiple control blocks are chained 
together, or somehow are related, that I don't want to read one while the other 
is updated.  

Can I read these control blocks with Rexx?  If so, maybe I'll give it a go when 
I have some free moments.

Kind regards,
Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Tuesday, November 13, 2012 11:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Jim Mulder's point is very well taken indeed.

Traversing a dynamic list without serialization on the assumption that since 
you do not plan to change  it no one else will is a mug's game.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Clark Morris]

On 16 Nov 2012 11:40:12 -0800, in bit.listserv.ibm-main you wrote:

>Saying that I running Sam's UCBLOOK or SHOWZOS in an unauthorized state, can 
>be traversing one of these chains, encounter an element disappearing, and 
>initiate an I/O or any other action which results in more than an abend of my 
>SHOWMVS/UCBLOOK? Anything that actually could lead to something as drastic as 
>an IPL? Surely such a failure of system integrity would be APARable. Even if 
>the interface is not GUPI. Integrity is not enforced by documentation :)
>
>Although a screwdriver is generally preferred to drive a screw, there are 
>times when expedience or need indicates a hammer will do the job adequately 
>for the specific situation.

I would prefer a dime or a coin as a screwdriver replacement.  I have
used pliers in the place of a hammer.  In this case, if I understand
the original intent of the code for UCB scanning, it is for read and
display purposes.  Doing any I/O to any UCB address found probably
would not be overly brilliant.  Thus the question is the magnitude and
seriousness of the risk.  Thr traversing is being done unauthorized so
no system storage should adversely affected.  If the process doing the
scan abends, it should not take the system with it and if it does
there are problems because an unauthorized programs shouldn't have the
ability.  If any abend in UCBLOOK can be trapped and the scan rerun,
then the worst scenario is an abend or a loop in the case of
repetitive failures.  If UCBLOOK or similar code is used in site
maintained system monitoring and display problem programming state
tools which have no impact upon failure, then I don't see a problem.
If this technique is used in commercial tools then at least graceful
recovery is needed, again with the caveat that I am thinking of
problem program unauthorized state tools.  In short given that the
technique has a non-zero probability of failure, is the consequence of
that failure acceptable.

Clark Morris
>
>Dave Gibney
>Information Technology Services
>Washington State University
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Bob Shannon
>> Sent: Friday, November 16, 2012 7:31 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: "New" way to do UCB lookups
>> 
>> >A minimal requirement for their integrity is that two dispatchables not
>> access >one of them concurrently.
>> 
>> Absolutely.
>> 
>> > we are dealing here with well understood risks that are entirely avoidable
>> and that there is thus no excuse for incurring them
>> 
>> At a higher level no one has mentioned the risk of using an undocumented
>> interface to do something for which documented services are available.
>> 
>> Bob Shannon
>> Rocket Software
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Bill Fairchild]

Sam's code uses the official z/OS's UCB lookup table, so I don't think this 
code traverses any chain of control blocks.  I would guess that it traverses 
the lookup table, whose location remains constant (unless an IODF change 
happens, perhaps) but possibly the contents of any given cell in the table 
might change.   The contents of the cell would somehow be used to find the 
address of the UCB.  To know exactly how the lookup table is used to look up 
the UCB address, see Sam's code (which I have not done).

The reIPL I referred to happened in the mid-1980s, and may well have been due 
to an operator's panicking rather than any APAR-able design defect in MVS/XA.  
My code used the system service LSPACE to query a device without first having 
done anything to ensure that the device did not lose its last available channel 
path.  LSPACE back then did 3 or 4 EXCPs sequentially to the device 
(interrogating the VTOC, mostly, as I remember).  Somewhere in between two of 
these EXCPs the last path went away, then the next EXCP happened and device 
allocation got "hung up" (I don't remember the details).  I was told that the 
only way the data center could regain the use of the device involved was to 
reIPL, which they did since they felt they needed the device.  That was the 
beginning of my education in doing I/O to an offline device.  I don't remember 
now if my code was running authorized or not.

Like John Gilmore, I believe that one should always follow all the guidelines 
in IBM's documentation about serialization, environmental requirements 
(cross-address space, protect key, addressing mode, etc.), etc., unless the 
code is being used for one's own learning experience.  And most especially if 
the code is being distributed in a commercial product or even as an unsupported 
sample program in the public domain.

However, PINning a UCB is an authorized function, Sam's code runs unauthorized, 
so Sam's code cannot serialize on each UCB.  I personally would rather use 
UCBLOOK to run through all the UCBs in any code that I expected to be taken 
seriously.  But finding the ULUT and how to use it would certainly be a fun 
project (see "learning experience" above).  IBM's UCBLOOK service obviously has 
some way of serializing properly.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Friday, November 16, 2012 1:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Saying that I running Sam's UCBLOOK or SHOWZOS in an unauthorized state, can be 
traversing one of these chains, encounter an element disappearing, and initiate 
an I/O or any other action which results in more than an abend of my 
SHOWMVS/UCBLOOK? Anything that actually could lead to something as drastic as 
an IPL? Surely such a failure of system integrity would be APARable. Even if 
the interface is not GUPI. Integrity is not enforced by documentation :)

Although a screwdriver is generally preferred to drive a screw, there are times 
when expedience or need indicates a hammer will do the job adequately for the 
specific situation.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Bob Shannon
> Sent: Friday, November 16, 2012 7:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> >A minimal requirement for their integrity is that two dispatchables 
> >not
> access >one of them concurrently.
> 
> Absolutely.
> 
> > we are dealing here with well understood risks that are entirely 
> > avoidable
> and that there is thus no excuse for incurring them
> 
> At a higher level no one has mentioned the risk of using an 
> undocumented interface to do something for which documented services are 
> available.
> 
> Bob Shannon
> Rocket Software
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Gibney, Dave]

Saying that I running Sam's UCBLOOK or SHOWZOS in an unauthorized state, can be 
traversing one of these chains, encounter an element disappearing, and initiate 
an I/O or any other action which results in more than an abend of my 
SHOWMVS/UCBLOOK? Anything that actually could lead to something as drastic as 
an IPL? Surely such a failure of system integrity would be APARable. Even if 
the interface is not GUPI. Integrity is not enforced by documentation :)

Although a screwdriver is generally preferred to drive a screw, there are times 
when expedience or need indicates a hammer will do the job adequately for the 
specific situation.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bob Shannon
> Sent: Friday, November 16, 2012 7:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> >A minimal requirement for their integrity is that two dispatchables not
> access >one of them concurrently.
> 
> Absolutely.
> 
> > we are dealing here with well understood risks that are entirely avoidable
> and that there is thus no excuse for incurring them
> 
> At a higher level no one has mentioned the risk of using an undocumented
> interface to do something for which documented services are available.
> 
> Bob Shannon
> Rocket Software
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Bob Shannon]

>A minimal requirement for their integrity is that two dispatchables not access 
>>one of them concurrently.

Absolutely.

> we are dealing here with well understood risks that are entirely avoidable 
> and that there is thus no excuse for incurring them

At a higher level no one has mentioned the risk of using an undocumented 
interface to do something for which documented services are available.

Bob Shannon
Rocket Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

Sam Golob and I assess some risks differently.

The American military in Iraq and Afghanistan have built elaborate
protective screens well above their major buildings.  These screens
are designed to detonate mortar shells fired at the roofs of these
buildings before they land on them.

I have not elected to screen my own house in this way; equally, I have
not reinforced its roof against purple cows falling from the sky; I
have judged that these two risks are exiguous here in Massachusetts.

If the house were in Kabul I should perhaps make a different judgment,
at least about the mortar shells.  All risk assessments are and must
be situational.

Consider now two dispatchables, T and U.  If T attempts to traverse a
list while U is updating it---adding an element to or deleting one
from that list---two unfortunate events may well occur, are certain to
occur in that long run in which we shall all be dead.  The first is
that T will traverse only a portion of the list uneventfully, and the
second is that T will end up in storage that is not a part of the
list, with ABEND the likely result.

Serialization was invented to address this class of problems.  We can
make programs reentrant.  Control blocks, on the other hand, are and
will remain serially reusable.  A minimal requirement for their
integrity is that two dispatchables not access one of them
concurrently.

None of this is very controversial in general, but different people
are all but certain to assess risks differently in different
particular cases.  My view is that we are dealing here with well
understood risks that are entirely avoidable and that there is thus no
excuse for incurring them.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Bill Fairchild]

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Skip Robinson
Sent: Thursday, November 15, 2012 5:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups
>... I'm curious about the purported risk of a 'moving device'. In order to 
>make a significant change to a device--especially UCB address--the volume has 
>to be offline or else the dynamic ACTIVATE fails.

There is a way, and it's not very difficult, of doing I/O to an offline device. 
 The device has to have been varied offline but not yet have all of its channel 
paths varied offline.  If there is at least one connected path remaining to a 
device, then authorized code can do I/O to it.  Code like this probably should 
serialize on the appropriate resource before doing its I/O to an offline 
device.  At least the UCB should be PINned before trying to do the I/O.

However, some programmers seem to think that the probability of having the last 
path varied out from under an I/O request is so remote that the need to 
serialize is ignored in order to get the code working faster.  I am not one who 
thinks so, as I have seen it happen to my code.

Yes, there is some "overhead" in PINning the UCB.  There is also a huge 
headache waiting to happen if the UCB is not serialized by PINning and then the 
UCB is somehow changed, the device has its last online path varied offline, or 
the UCB is deleted, meaning its storage is FREEMAINed and possibly reused 
instantly by some other process needing a small piece of virtual storage.  
Sometimes this headache has caused a reIPL of a system.  How much overhead does 
a reIPL cost the entire data center in order to save a fraction of a 
millisecond in order to serialize properly because the reIPL will probably not 
have to happen?

Write the PIN and UNPIN code once, get it debugged, then encapsulate it in a 
simple macro so you don't have to look it up in the book each time you want to 
use it again.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
www.rocketsoftware.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[nitz-...@gmx.net]

> OTOH I'm curious about the purported risk of a 'moving device'. In order 
> to make a significant change to a device--especially UCB address--the 
> volume has to be offline or else the dynamic ACTIVATE fails. 

How about a dynamic activate that succeeded but a component (catalog) that 
doesn't listen to the ENF signal that a UCB was removed, that had stored the 
old address in a common control block and *after* the activate abends CAS with 
very frequent 0C4s trying to touch the (now freemained) storage. While IBM took 
an apar on that 4 or 5 years ago, when we were hit with this problem and had an 
unscheduled installation wide outage because of it, the apar was closed SUG or 
some such and as far as I know it is still NOT fixed. During the escalation I 
was assured that IBM would fix it (in 1.13 at the latest), but the apar still 
doesn't say that the requirement was fulfilled. And that's IBM code.

And don't tell me how to move a catalog. The documentation how to do it if you 
delete and then re-add the UCB to your config under a different name was 
written due to our outage. I think the HCD book now has a footnote that says 
'don't do it'.

Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

I had judged that there was little more to be saidor at any rate
little more for me to say---about this issue, but Mark Zelden has
changed my mind.

He wrote:


I think the point was about how often they are done.  Quarterly?
Monthly? Weekly?  Daily?   I have never been at a production shop that
had a need to do them more often than monthly.  Maybe some hardware
vendors do them daily on a given system, I don't know.


because this does not seem to me to be the point at all.

To use a lawyer's word, we have stipulated/agreed that disaster
can/will ensue without serialization.  Mark's view is that, this
conceded, the important question is not whether it will occur but how
often.

He and I disagree about this.  My view is that if the unfortunate can
occur it will occur and at a disagreeably inappropriate time.

Moreover, the substantive question at issue is a curiously trivial
one.  There are z/OS macros available for implementing the
serializations required here.  Any sysprog competent to chase
control-block pointers at all is presumably also competent to use
these macros.   Why then court the unfortunate by refusing to do so?

Russian roulette is a diseased pastime, all but independently of
whether the probability that a trial will have an unfortunate outcome
is 1/8 or 1/4096.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Skip Robinson]

It's a little like the question of performance hits on a volume shared by 
'low use' data sets. A data set may get used infrequently, but when it 
gets used, it gets used heavily if only for a brief period. 

We undergo periodic hardware refreshes in which we move all data on every 
subsystem from one box to another. During that exercise, we perform many 
dynamic IODF changes because we don't have the real estate to completely 
install all of the new gear along all of the old gear. We have to do it in 
stages. Every few years. 

OTOH I'm curious about the purported risk of a 'moving device'. In order 
to make a significant change to a device--especially UCB address--the 
volume has to be offline or else the dynamic ACTIVATE fails. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   Mark Zelden 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   11/15/2012 07:00 AM
Subject:Re: "New" way to do UCB lookups
Sent by:IBM Mainframe Discussion List 



On Thu, 15 Nov 2012 07:26:24 -0600, Tom Marchant 
 wrote:

>On Wed, 14 Nov 2012 14:39:35 -0500, Bonaduce, Frank wrote:
>
>>Are dynamic IODF changes actually so prevalent in most environments 
>>(especially in Production) that the condition warrants that much 
>
>Why wouldn't IODF changes be implemented dynamically in production 
>environments?  Anyway, how many shops have CECs dedicated to 
>non-production LPARs?
>



I think the point was about how often they are done.  Quarterly?  Monthly?
Weekly?  Daily?   I have never been at a production shop that had
a need to do them more often than monthly.  Maybe some hardware
vendors do them daily on a given system, I don't know.  So even if you
did it once a day, you wouldstill  have to be using one of these 
programs at the same time as the IODF change to have a problem. 
The person using the program (a sysprog) is likely the one activating
the IODF change, which makes it even less likely to be a problem.

--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS 
mailto:m...@mzelden.com 
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Stone, Sandy]

yeah

s



http://www.medmutual.com/
Visit http://www.medmutual.com/
CONFIDENTIALITY NOTICE:
This message is intended only for the use of the individual or entity to which 
it is addressed and may contain information that is privileged, confidential or 
exempt from disclosure by law. If the reader of this message is not the 
intended recipient, or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that you are 
strictly prohibited from printing, storing, disseminating, distributing or 
copying this message. If you have received this message in error, please notify 
us immediately by replying to the message and deleting it from your computer. 
Neither this information block, the typed name of the sender, nor anything else 
in this message is intended to constitute an electronic signature, unless a 
specific statement to the contrary is included in this message.
Thank you, Medical Mutual.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Gould
Sent: Wednesday, November 14, 2012 5:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Frank,

In one environment it was at least a weekly occurrence. In others once a month 
and others every 6 months, In the "weekly" environment it was a lively change 
management adventure as we did have several outages (sometime entire sysplex) 
It was fraught with issues and maybe if we had been more aggressive with 
maintenance the outage might not have happened. But the boss bought off on the 
chances, so... We did not have the man power to stay current like we should 
have been in that type of environment, but the boss yelled a few times and 
chasing down the cause was not a witch hunt per se but we just tried to tell 
them about issues and that is all we could do.
At times we would get DASD that had data on it from a previous installation. 
The DASD people just wiped it out without looking or caring.
As for CPU's it was at times scary (at least for me) as we had so many issue 
with OEM vendors that We had so many serial numbers floating around it was a 
PITA.
That was scarier (to me) that the upgrades. I won't even go into tape drives 
types.

Ed


Ed

On Nov 14, 2012, at 1:39 PM, Bonaduce, Frank wrote:

> This ongoing discussion prompts a question: Are dynamic IODF changes
> actually so prevalent in most environments (especially in
> Production) that the condition warrants that much consideration ?
> I, for one, would tend to doubt it. If it is the case in a 'sandbox'
> or development type environment, it's likely a tolerable condition.
> The advantage of using established facilities like UCBSCAN is that you
> can exploit parameters, like IOCTOKEN, to indicate if there is
> something of this nature happening and allows you the option of
> whether or not to react to it. In the case of DASD, the recommendation
> for some time has been to PIN the UCB if exclusivity is required and
> subsequently UNPIN it when it is no longer needed. These operations,
> of course, require authorization.
>
> Frank.
> GSG Systems.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu]
> On Behalf Of Sam Golob
> Sent: Wednesday, November 14, 2012 2:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: "New" way to do UCB lookups
>
> Hi Folks,
>
>  Somebody please enlighten me.  If you're trying to scratch a
> dataset on a pack, and somebody else is in the middle of doing an IODF
> change at the time, what is the difference if you are obtaining a copy
> of the UCB (to determine what's on the disk pack), or the real UCB
> itself?  I'm not expecting a complete answer from somebody, but I'd at
> least like a reference to a manual or manuals where the perspective
> and advantages/disadvantages of copied, (and
> captured) UCB's is explained, as opposed to the real UCB's.  I want to
> read about it.  Please show me where.
>
>  Thanks.
>
>  All the best
>
> Sam
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Mark Zelden]

On Thu, 15 Nov 2012 07:26:24 -0600, Tom Marchant  
wrote:

>On Wed, 14 Nov 2012 14:39:35 -0500, Bonaduce, Frank wrote:
>
>>Are dynamic IODF changes actually so prevalent in most environments 
>>(especially in Production) that the condition warrants that much 
>
>Why wouldn't IODF changes be implemented dynamically in production 
>environments?  Anyway, how many shops have CECs dedicated to 
>non-production LPARs?
>



I think the point was about how often they are done.  Quarterly?  Monthly?
Weekly?  Daily?   I have never been at a production shop that had
a need to do them more often than monthly.  Maybe some hardware
vendors do them daily on a given system, I don't know.  So even if you
did it once a day, you wouldstill  have to be using one of these 
programs at the same time as the IODF change to have a problem. 
The person using the program (a sysprog) is likely the one activating
the IODF change, which makes it even less likely to be a problem.

--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Tom Marchant]

On Wed, 14 Nov 2012 14:39:35 -0500, Bonaduce, Frank wrote:

>Are dynamic IODF changes actually so prevalent in most environments 
>(especially in Production) that the condition warrants that much 

Why wouldn't IODF changes be implemented dynamically in production 
environments?  Anyway, how many shops have CECs dedicated to 
non-production LPARs?

Many years ago, I had a channel switch that had a few lightly used 
unit-record devices attached.  IIRC, there were four devices and four 
LPARs connected to the switch.  One of the LPARs was production. 
We still wanted to be able to connect any of the devices to any LPAR, 
but wanted to eliminate the channel switch.

The solution was to connect each device to a dedicated channel path 
and when there was a need to switch a device the channel path off of 
one LPAR and on to another.  We made multiple dynamic IODF changes, 
removing one CHPID at a time and butting the cables together to connect 
one device to that CHPID, then another IODF change to bring the device 
back online to the production LPAR.  The entire reconfiguration was done 
during the day while with no disruption, just the unavailability of one 
device at a time for a relatively short time.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Ed Gould]

Frank,

In one environment it was at least a weekly occurrence. In others  
once a month and others every 6 months,
In the "weekly" environment it was a lively change management  
adventure as we did have several outages (sometime entire sysplex) It  
was fraught with issues and maybe if we had been more aggressive with  
maintenance the outage might not have happened. But the boss bought  
off on the chances, so... We did not have the man power to stay  
current like we should have been in that type of environment, but the  
boss yelled a few times and chasing down the cause was not a witch  
hunt per se but we just tried to tell them about issues and that is  
all we could do.
At times we would get DASD that had data on it from a previous  
installation. The DASD people just wiped it out without looking or  
caring.
As for CPU's it was at times scary (at least for me) as we had so  
many issue with OEM vendors that We had so many serial numbers  
floating around it was a PITA.
That was scarier (to me) that the upgrades. I won't even go into tape  
drives types.


Ed


Ed

On Nov 14, 2012, at 1:39 PM, Bonaduce, Frank wrote:

This ongoing discussion prompts a question: Are dynamic IODF  
changes actually so prevalent in most environments (especially in  
Production) that the condition warrants that much consideration ?   
I, for one, would tend to doubt it. If it is the case in a  
'sandbox' or development type environment, it's likely a tolerable  
condition. The advantage of using established facilities like  
UCBSCAN is that you can exploit parameters, like IOCTOKEN, to  
indicate if there is something of this nature happening and allows  
you the option of whether or not to react to it. In the case of  
DASD, the recommendation for some time has been to PIN the UCB if  
exclusivity is required and subsequently UNPIN it when it is no  
longer needed. These operations, of course, require authorization.


Frank.
GSG Systems.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM- 
m...@listserv.ua.edu] On Behalf Of Sam Golob

Sent: Wednesday, November 14, 2012 2:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: "New" way to do UCB lookups

Hi Folks,

 Somebody please enlighten me.  If you're trying to scratch a  
dataset on a pack, and somebody else is in the middle of doing an  
IODF change at the time, what is the difference if you are  
obtaining a copy of the UCB (to determine what's on the disk pack),  
or the real UCB itself?  I'm not expecting a complete answer from  
somebody, but I'd at least like a reference to a manual or manuals  
where the perspective and advantages/disadvantages of copied, (and  
captured) UCB's is explained, as opposed to the real UCB's.  I want  
to read about it.  Please show me where.


 Thanks.

 All the best

Sam

--
For IBM-MAIN subscribe / signoff / archive access instructions,  
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Bonaduce, Frank]

This ongoing discussion prompts a question: Are dynamic IODF changes actually 
so prevalent in most environments (especially in Production) that the condition 
warrants that much consideration ?  I, for one, would tend to doubt it. If it 
is the case in a 'sandbox' or development type environment, it's likely a 
tolerable condition. The advantage of using established facilities like UCBSCAN 
is that you can exploit parameters, like IOCTOKEN, to indicate if there is 
something of this nature happening and allows you the option of whether or not 
to react to it. In the case of DASD, the recommendation for some time has been 
to PIN the UCB if exclusivity is required and subsequently UNPIN it when it is 
no longer needed. These operations, of course, require authorization. 

Frank.
GSG Systems. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sam Golob
Sent: Wednesday, November 14, 2012 2:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: "New" way to do UCB lookups

Hi Folks,

 Somebody please enlighten me.  If you're trying to scratch a dataset on a 
pack, and somebody else is in the middle of doing an IODF change at the time, 
what is the difference if you are obtaining a copy of the UCB (to determine 
what's on the disk pack), or the real UCB itself?  I'm not expecting a complete 
answer from somebody, but I'd at least like a reference to a manual or manuals 
where the perspective and advantages/disadvantages of copied, (and captured) 
UCB's is explained, as opposed to the real UCB's.  I want to read about it.  
Please show me where.

 Thanks.

 All the best

Sam

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Shane Ginnane]

On Tue, 13 Nov 2012 19:17:54 -0500, John Gilmore wrote:

>The question whether these disagreeable consequences are tolerable is
>a judgment call.  Sam and others think they are.  I think not.  So be
>it.

John at his imperious best - consider me one of the others (in this case).

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Gerhard Postpischil]

On 11/14/2012 2:33 AM, Sam Golob wrote:

 Somebody please enlighten me.  If you're trying to scratch a
dataset on a pack, and somebody else is in the middle of doing an IODF
change at the time, what is the difference if you are obtaining a copy
of the UCB (to determine what's on the disk pack), or the real UCB
itself?  I'm not expecting a complete answer from somebody, but I'd at
least like a reference to a manual or manuals where the perspective and
advantages/disadvantages of copied, (and captured) UCB's is explained,
as opposed to the real UCB's.  I want to read about it.  Please show me
where.


The general problem for traditional chains, each member linking to the 
next, is that the link address may become invalid if your task is 
preempted by one deleting the element matching your link. For scratch 
and all system services, proper serialization is provided (or APARable), 
so a problem is not likely.


I have no idea what the current system does (last tried UCB chains on 
OS/390), but in the case of an IODF change, any address you have may 
become invalid, or give erroneous results. A copied UCB gives you the 
information for that device, but isn't persistent over an IODF change 
unless locked (or otherwise protected); and if you can lock the UCB, you 
don't need a copy?


I disagree with Mr. Gilmore's general assertion that serialization is 
required. For a mission critical application, I would expect code that 
rigorously follows all of IBM's recommended practices. But for quick and 
dirty applications it's more efficient to test for and recover from 
errors either by programming, or by letting the user scratch his/her 
head and try the request again. I have an application that has been in 
use since the late sixties; one of its attractions is code that 
minimizes the use of system services, thus allowing recovery from system 
hangs and other funnies.


Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Gibney, Dave]

And I for at least for one, am very likely to know when a dynamic IODF (or 
other major such change) is happening and therefore expect that I will get 
different results before, during and afterward if I am using one of the 
valuable tools :) at the same time. 
   

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark Zelden
> Sent: Tuesday, November 13, 2012 2:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
> 
> I think Sam has been around long enough to understand the caveats to
> traversing  the control blocks without serializing.  I'm sure there are some
> monitoring the list that don't understand, so the discussion is good.  For
> the general use case, it's "good enough" as long as you understand the
> caveat and are willing to live with it.
> 
> One of the most popular and widely used freeware tools on this platform -
> ShowMVS (ShowzOS), has the same caveat with many of the displays
> the program provides.  But most of us use it or have used it anyway
> and it still is a valuable tool.
> 
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://expertanswercenter.techtarget.com/
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

This issue has anyway, I think, been exhausted.

We have two different, opposed views; neither camp is likely to change
its position;  moreover, there does not appear to be a substantive
issue dividing us.  Both camps are aware that the absence of
serialization can have disagreeable consequences.

The question whether these disagreeable consequences are tolerable is
a judgment call.  Sam and others think they are.  I think not.  So be
it.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Ed Gould]

Couldn't the owner of the program just put a statement in the title  
and thus eliminating the whole issue?


Ed

On Nov 13, 2012, at 4:04 PM, John Gilmore wrote:


Bill Fairchild writes:


Only those who have studied the code that accesses the ULUT can know
exactly how safe it is to use the ULUT without first serializing.


and thus makes my point better than I did.  In this OCO period we
cannot know.  We must therefore assume that accessing a dynamic list,
q


On 11/13/12, Bill Fairchild  wrote:
If your code is only reading from a control block structure and  
you do not
serialize, there is the danger that other code might serialize and  
update
the control block structure in a way that could cause your code to  
behave
incorrectly.  I do not know the structure or use of the UCB lookup  
table
(ULUT) as used now in z/OS.  But I remember the lookup table  
scheme in MVT
and the queue of UCBs that we used to have in between MVT and z/ 
OS.  The
other code might change the UCB that you have found and are  
reading-only, in
which case your code needs to withstand the possibility that any  
or all of
the fields may change while you are looking at it.  Possibly a UCB  
might be
deleted, in which case even a lookup table can not prevent your  
code's
attempting to accessing freshly FREEMAINed storage.  Perhaps even  
the entire

ULUT could be freed and replaced with a whole new ULUT at a different
virtual address.  Only those who have studied the code that  
accesses the

ULUT can know exactly how safe it is to use the ULUT without first
serializing.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w:
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM- 
m...@listserv.ua.edu] On

Behalf Of John Gilmore
Sent: Tuesday, November 13, 2012 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Jim Mulder's point is very well taken indeed.

Traversing a dynamic list without serialization on the assumption  
that since

you do not plan to change  it no one else will is a mug's game.

John Gilmore, Ashland, MA 01721 - USA

- 
-
For IBM-MAIN subscribe / signoff / archive access instructions,  
send email

to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

- 
-

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM- 
MAIN





--
John Gilmore, Ashland, MA 01721 - USA

t.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

Bill Fairchild writes:


Only those who have studied the code that accesses the ULUT can know
exactly how safe it is to use the ULUT without first serializing.


making my point better than I did.  In this OCO period, we cannot
study this code; ergo, we must serialize.

--jg

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Mark Zelden]

I think Sam has been around long enough to understand the caveats to 
traversing  the control blocks without serializing.  I'm sure there are some
monitoring the list that don't understand, so the discussion is good.  For
the general use case, it's "good enough" as long as you understand the
caveat and are willing to live with it. 

One of the most popular and widely used freeware tools on this platform -
ShowMVS (ShowzOS), has the same caveat with many of the displays 
the program provides.  But most of us use it or have used it anyway 
and it still is a valuable tool. 

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[John Gilmore]

Bill Fairchild writes:


Only those who have studied the code that accesses the ULUT can know
exactly how safe it is to use the ULUT without first serializing.


and thus makes my point better than I did.  In this OCO period we
cannot know.  We must therefore assume that accessing a dynamic list,
q


On 11/13/12, Bill Fairchild  wrote:
> If your code is only reading from a control block structure and you do not
> serialize, there is the danger that other code might serialize and update
> the control block structure in a way that could cause your code to behave
> incorrectly.  I do not know the structure or use of the UCB lookup table
> (ULUT) as used now in z/OS.  But I remember the lookup table scheme in MVT
> and the queue of UCBs that we used to have in between MVT and z/OS.  The
> other code might change the UCB that you have found and are reading-only, in
> which case your code needs to withstand the possibility that any or all of
> the fields may change while you are looking at it.  Possibly a UCB might be
> deleted, in which case even a lookup table can not prevent your code's
> attempting to accessing freshly FREEMAINed storage.  Perhaps even the entire
> ULUT could be freed and replaced with a whole new ULUT at a different
> virtual address.  Only those who have studied the code that accesses the
> ULUT can know exactly how safe it is to use the ULUT without first
> serializing.
>
> Bill Fairchild
> Programmer
> Rocket Software
> 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
> t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w:
> www.rocketsoftware.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John Gilmore
> Sent: Tuesday, November 13, 2012 3:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "New" way to do UCB lookups
>
> Jim Mulder's point is very well taken indeed.
>
> Traversing a dynamic list without serialization on the assumption that since
> you do not plan to change  it no one else will is a mug's game.
>
> John Gilmore, Ashland, MA 01721 - USA
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Gilmore, Ashland, MA 01721 - USA

t.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "New" way to do UCB lookups

[Bill Fairchild]

If your code is only reading from a control block structure and you do not 
serialize, there is the danger that other code might serialize and update the 
control block structure in a way that could cause your code to behave 
incorrectly.  I do not know the structure or use of the UCB lookup table (ULUT) 
as used now in z/OS.  But I remember the lookup table scheme in MVT and the 
queue of UCBs that we used to have in between MVT and z/OS.  The other code 
might change the UCB that you have found and are reading-only, in which case 
your code needs to withstand the possibility that any or all of the fields may 
change while you are looking at it.  Possibly a UCB might be deleted, in which 
case even a lookup table can not prevent your code's attempting to accessing 
freshly FREEMAINed storage.  Perhaps even the entire ULUT could be freed and 
replaced with a whole new ULUT at a different virtual address.  Only those who 
have studied the code that accesses the ULUT can know exactly how safe it is to 
use the ULUT without first serializing.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Tuesday, November 13, 2012 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: "New" way to do UCB lookups

Jim Mulder's point is very well taken indeed.

Traversing a dynamic list without serialization on the assumption that since 
you do not plan to change  it no one else will is a mug's game.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN