Re: Do we need to implement HSM

[Ron Hawkins]

Ed,

> (with DFHSM) all the old datasets. The data was there for recall. Although
I
> did
> find a VSAM data set that was empty and it spanned 5 volumes and haddn't
been
> referenced in many many months. I archived it and clipped the volumes and
out
[Ron Hawkins] I'm a little surprised to hear that an empty VSAM dataset was
allocated across five volumes.

As most of your references are pre-SMS or non-SMS I'd be interested to know
how it got that way without guaranteed space. 

Ron

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

Re: Do we need to implement HSM

[Ed Gould]

---SNIP
  Our Situation :Our shop don't have DASD enough(no tapelib) and the 
application 
programer always allocate very bigger datasets.
PS and VSAM are almost extended format data sets. 
We want to 
1.Release unused and  overallocated space for PS,VSAM and PO by HSM 
or BATCH JCL 

2.Reduce fewer extents for  PS,VSAM and PO by HSM or BATCH JCL
What can we do?
Thanks a lot!

--END---

Suggestion:

1. It depends on PS datasets, IMO. If you do MOD then do not release space. If 
mod is not used then sure why not release space (for ps). I was at a shop that 
was infamous for being tight with the $$ and we ran a release job everynight 
after production bacups were done. We did not allow MOD period.

2. During the mass release everynight we also released extents. 

We did this using DMS. It did a credible job for releasing space. We were in 
the 
middle of replacing DMS with DFHSM and we had decided to run DFDSS to release 
the space instead of keeping DMS around. We did have issues with how DFDSS 
worked. DMS just spit out an error message and continued on but DFDSS stopped 
and wait until it could get exclusive control of the dataset.

I honestly do not remember the space we got back but it wasn't all that much 
IIRC. Maybe a half 3380-3 pack out of say 20 mod 3's .

DMS did have a report mode that was fairly acurate as to numbers. We also had 
standards that all space requests had to specify rlse.

We also had pretty tight control on our DASD (production wise), test was 
scrutinized by other criteria and was reasonably stable.

VSAM was a ball of wax. We did not have a way on reporting VSAM (if memory 
serves me).

At another shop I was at the DASD was a mess. I was called in and found 40 
volumes that were there but not being used and I cleaned it up and I got yelled 
at by several managers. I welcomed the chance to go into the meeting to have 
the 
manager talk to my manager and she backed up everything I did. I just archived 
(with DFHSM) all the old datasets. The data was there for recall. Although I 
did 
find a VSAM data set that was empty and it spanned 5 volumes and haddn't been 
referenced in many many months. I archived it and clipped the volumes and out 
them in another pool. That was a scream fest as well.

My boss loved these arguments as she liked to play the hard nose. 
Ed

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

Re: Do we need to implement HSM

[Chris Taylor]

Releasing space at close can be handled in the management class by 
specifying Partial release with Yes Immediate (YI) or Conditional Immediate 
(CI) if you want to ensure that data sets have secondary allocation before 
the space is released. This does not require the space management function 
of HSM to be active whereas Y or C would typically release space during 
primary space management. 

If you are licensed for DFSMSdss, you can also release space and perform 
extent reduction. Since you are using extended format datasets, DSS will 
release space against VSAM as well as sequential. Extent reduction can be 
performed using the CONSOLIDATE function. CONSOLIDATE used to be 
specified as a keyword of DEFRAG but is now its own command as of z/OS 
1.10. 

Hope this helps.

Chris Taylor

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

Re: Do we need to implement HSM

[ibmnew]

Dear all

 
>proper use of mgmtclas/storclas can save a whole lot of dasd and prevents the 
>need to clean up garbage on a regular basis.  


  Our Situation :Our shop don't have DASD enough(no tapelib) and the 
application programer always allocate very bigger datasets.
 PS and VSAM are almost extended format data sets. 
 We want to 
1.Release unused and  overallocated space for PS,VSAM and PO by HSM 
or BATCH JCL 
2.Reduce fewer extents for  PS,VSAM and PO by HSM or BATCH JCL
 What can we do?
 Thanks a lot!

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

A matter snuck into "Under z/OS UNIX" which shouldn't have been!

[Chris Mason]

The Swiss gentleman will not be reading this so this is for any interested in 
the topic

-

The supposed "great one" is the description of a message, EZD1353I, in which 
the second "S" of a use of the dread 3 characters is missing. Swiss humour 
rises to heights not found in other places!

-

It was brought to my attention that a set of redbooks regarding the IP 
component of Communications Server had errors relating to this misuse 
problem. Mainly it was overcorrection in that something inextricably related to 
Unformatted System Services as used by TN3270 got labelled with UNIX 
System Services when there was a bulk change of the dread 3 characters to 
UNIX System Services. I assisted the redbook author to remove the 
overcorrections. This is just one more example of the destruction caused by 
this misuses which some arrogant people - who can all very easily be named 
as a result of these exposures - happily and sneeringly impose upon us all.

I have just seen the ridiculous suggestion/implication that this whole matter 
is "historical" and not "technical". That's an idea that sits very oddly with a 
set of redbooks that is in the process of being published wouldn't you say?

It was also suggested that is was "pedantic" but "pedantic" is just a way of 
sneering at being precise and we are dealing with computers and software and 
software that can take a bit of effort to comprehend.

-

Incidentally we here see arrogance complemented by ignorance over quoting 
URLs in reference to the IBM bookshelves. It should be appreciated that the 
following reduced URL would suffice:

http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/f1a1c8a0/11.342

-

> Go to the z/OS V1.12 doc site and do a search on "USS" over all books 
(some 370+), ...

I think this is a reference to

http://www-03.ibm.com/systems/z/os/zos/bkserv/v1r12books.html

and "all books" would be the "Search text" box for "All z/OS V1R12.0 Base 
Elements Optional Features - 389 books"

It's clear he actually doesn't really want you to follow these instructions 
because he would be exposed for the dissembler he is. The number of "hits" is 
not 370+ but 88. I guess we can smell a rat in the use of the plus sign.

It's going to take a bit of time checking all of this but I'm pretty sure 
already 
what could be said.

Each one of the "hits" - excepting for "hits" in both the IP and SNA 
components of Communications Server which, I expect, nearly all align with 
[1] - is a mistake[2] brought about by IBM people having been adversely 
affected by the pervasive misuse about which we have talked ad nauseam but 
I fear more nausea will be needed while these arrogant - often anti-SNA 
bigots as in this case - persist with their nonsense.

This is nevertheless a very interesting analysis technique. When I split out 
the 
manual with "UNIX System Services" in the title, guess what, there were 5 of 
them. I thought that compared with another number in a quite revealing way 
so I checked what it was. Well, indeed, the total number of manuals in the 
z/OS UNIX bookshelf is 11!

Now those who have skulls of normal thickness will be able to conclude that, if 
there were any imprimatur attaching to the dread 3 characters, the most 
extensive use would be found in the z/OS UNIX bookshelf but - well - it just 
isn't. QED!

Alternatively, there's none so blind as those who will not see!

-

[1] http://www-
01.ibm.com/software/globalization/terminology/u.html#x2042481



unformatted system service (USS)

A communications function that translates a character-coded command, such 
as a LOGON or LOGOFF command, into a field-formatted command for 
processing by formatted system services. See also formatted system service.

...

USS
See unformatted system service.



[2] Or preliminary checking has shown that some manuals such as the MVS 
Messages manuals have a cross-reference to the message prefixes used by 
the components of the Communications Server and the dread 3 characters is 
one of those.

-

That's right. When anti-SNA bigots are prowling, I don't take prisoners!

Also I really just don't like the tone implied by rolling on any floor doing 
anything when directed to sensible arguments.

Chris Mason

On Wed, 4 May 2011 17:14:26 +0200, Hunkeler Peter (KIUP 4) 
 wrote:

>>FWIW, IBM publications now use the current terminology:  "z/OS UNIX
>>System Services (z/OS UNIX)".  This is not a discussion of the
>>commonly used yet disputed TLA.  Please.
>
>Go to the z/OS V1.12 doc site and do a search on "USS" over all books
>(some 370+), be surprised and be amused.
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/EZ2ZBK0K
>
>A great one from the Communication Server's bookshelf (watch the wrap):
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1c8a0/11.3
>42?
ACTION=MATCHES&REQUEST=USS&TYPE=FUZZY&SHELF=EZ2ZBK0K.bks&DT=20
1006010
>44843&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&ra
nk=RAN
>K&ScrollTOP=FIRSTHIT#FIRSTHIT

--

Re: POHD: vs UTE (was: USS vs USS)

[Chris Mason]

Kirk

Before I address this ridiculous post directly, let me remind you how we got 
here.

Ted MacNeil decided to make the claim that something that was wrong was 
right. Unchallenged your to be nurtured "newbies" might get the impression 
that he was indeed right and so they might continue in all innocence with the 
error.

As I have indicated many times before, it does matter since it can cause 
ambiguity.

The discussion has actually established what is right and what is wrong and 
Ted MacNeil has been obliged to depart - we hope - admitting that he is 
wrong but sticking to his wrongness out of spite.

In trying to get that cleared up I deliberately created a new thread containing 
the words "unnecessary controversy" so that any who needed to stay away 
could and only the recalcitrants and recusants need participate - along with a 
few who have seen the light and helped out, as it were.

Unfortunately, yet another thread was started with rather poor "list-craft" 
since it was not linked to the "unnecessary controversy" thread. Here the 
errors persisted in the shape of some saying what was wrong was right but 
maybe it shouldn't be. Again some cleaning up was required and, because the 
connection was not made, a certain amount of repetition was needed to be 
sure the correct message got through.

This was and continues to be a technical exchange about proper words. Unlike 
with a rose, we don't have smell to guide us.

Nevertheless, this second thread had a peculiar thread title, sufficiently 
peculiar for there to be no need for those not thinking they needed to be 
involved to participate.

So, given the thread titles, I don't see why you're making this fuss. It is not 
obligatory actually to read each post which crops up on IBM-MAIN. I don't. It 
was only the month change that - some, including myself, might say 
unfortunately - somehow prompted me to look into something involving "ported 
tools".

Chris Mason

On Wed, 4 May 2011 18:11:02 -0500, Kirk Wolf  wrote:

>Maybe its time to have two lists - one for "Pedantic or Historical
>Discussions" (POHD) , and one for "Useful Technical Exchange" (UTE)
>(sorry if these acronyms are taken, I fully expect this thread to
>blossom to discuss improper usage :-)
>
>A rough count of recent traffic on the "USS" TLA yields well over a
>hundred posts, whereas only a handful of UTE on z/OS UNIX.
>
>Discussing two lists will likely turn pedantic, and since it has
>probably been discussed before, historical.
>
>Unfortunately, many folks (and poor newbies) interested in UTE will
>just tune out, since a few on list seem to think that POHD == UTE.
>
>Kirk Wolf
>Dovetailed Technologies
>http://dovetail.com
>
>PS> Here's a mildly aggressive idea:  prefix your new UTE threads with
>"UTE:" and as the OP be diligent and respond to any posts on your
>thread that vector to pedantic or historical discussions with an
>altered subject line prefixed "RE: POHD:"Note that I have
>preemptively tagged this thread "POHD:"

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

Re: POHD: vs UTE (was: USS vs USS)

[Chris Mason]

Potentially a question also for the list moderator

> ... .. can't our moderator stop this crep?

In what respect is avoiding ambiguity in posts and products "crep" - whatever 
that is - and of no relevance to IBM-MAIN?

Chris Mason

On Wed, 4 May 2011 20:24:40 -0400, Graham Hobbs 
 wrote:

>Right .. can't our moderator stop this crep?
>
>- Original Message -
>From: "Shane Ginnane" 
>Newsgroups: bit.listserv.ibm-main
>To: 
>Sent: Wednesday, May 04, 2011 7:43 PM
>Subject: Re: POHD: vs UTE (was: USS vs USS)
>
>
>>A least the change in subject got me to read it Kirk   ;-)
>>
>> It's a pity the list doesn't support (per subscriber) blacklisting
>> threads/contributors *at the server*.
>> Would save an awful lot of bandwidth.
>>
>> ISTR an OT group was set up a while back. Doesn't seem to have helped.
>>
>> Shane ...

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

Incidental Matters relating to "Under z/OS UNIX"

[Chris Mason]

Kirk

The change of subject is to try to respect your perceived intentions with this 
thread.

Your - at first glance - rather ridiculous and inaccurate new thread I will 
deal 
with if I am saved. Meantime I'll get off what I have noted already.

-

I'm finally paying attention to this thread, apparently interesting for those 
more familiar with the territory. The reason is that I think I noticed some 
rather sneaky behaviour going on which will need to be exposed along with the 
imposter practising it! We'll see!

Otherwise:

-

> FWIW, IBM publications now use the current terminology: "z/OS UNIX 
System Services (z/OS UNIX)". This is not a discussion of the commonly used 
yet disputed TLA. Please.

What's that "now" supposed to mean? If the IBM products follow correct 
guidelines and the publications follow correct guidelines, the dread three 
letter 
initialism will always apply only to what you can do with certain VTAM macros.

It's not as if other IBM products - whichever they were - used the dread 
three letters but were required to change them! 

-

> ... who despise z/OS Unix, ...

I think you'd better find some way of defining who these people are. Just 
because I rail against misuse of the dread three letters says nothing 
whatsoever about my feelings for z/OS UNIX. Once I'd got over the cultural 
shock, I got quite fond of AIX - even ran classes on the AIX NetView and SNA 
products and, out of the latter having defined myself as a rare resource, got a 
trip which included a walk on the Great Wall[1]. Although I've not really 
needed to transfer my AIX skills to the z/OS flavour, I appreciate that I'm 
some way there already if I ever need to work with z/OS UNIX - or zUNIX.

-

Note that when providing URLs for the purposes of accessing on-line manuals, 
it is sufficient to quote everything up to the "?". More is pointless and 
causes 
possibly confusing "wraps". We don't need to know *how* you got to that URL 
which is what I think all the garbage after the "?" indicates.

In addition, if you are indicating only the Contents" page, you can drop 
the "CCONTENTS".

-

What the  is the so-called "Penalty box". An exasperated 
guess might be the "Commands" window. If so,  say so! If 
*I* don't know, supposedly part of the prevalent English-speaking culture 
inhabiting the list, I fear for all those other poor folk trying to keep up 
with 
this clique!

-

[1] From someone who can claim an affinity only with Hadrian's run-down 
equivalent!

-

Chris Mason

On Tue, 3 May 2011 08:29:53 -0500, Kirk Wolf  wrote:

>FWIW, IBM publications now use the current terminology:  "z/OS UNIX
>System Services (z/OS UNIX)".  This is not a discussion of the
>commonly used yet disputed TLA.  Please.
>
>I've been thinking about this for some time, and what I would like to
>discuss - and in some areas clear up my own technical assumptions - is
>this:
>
>What is z/OS Unix, and what do people mean when they say "under USS"
>(or the more proper: "under z/OS Unix") ?
>
>Of course, the phrase itself is not the problem.   It is the common
>misconceptions of "z/OS Unix" that I would like to discuss.   I
>realize that there are some here who despise z/OS Unix, and "Under
>z/OS Unix" / "Under USS" is good enough granularity to describe all
>the crap that they can't stand.  If this is you, please go back to
>discussing the TLA ;-)
>
>z/OS Unix is somewhat difficult to define, but here is an overview by IBM:
>(See: http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/bpxzb2b0/1.0?
SHELF=EZ2ZBK0K&DT=20100625104049
>)
>
>My own conception model (perhaps flawed) is that there are a bunch of
>related things:
>
>1) POSIX / XPG4 APIs
>XPLINK and non-XPLINK LE C libraries
>
>2) Lower level APIs  (assembler or other HLLs)
>http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/bpxzb1b0/CCONTENTS?
SHELF=EZ2ZBK0K&DN=SA22-7803-13&DT=20100701130653
>These are used to implement (1).
>Just about any program  / job can call these or (1), and the first
>time it does it gets "dubbed" (8) with a z/OS Unix PID and can use the
>kernel (below)
>
>3) The "Kernel" Address space (BPXOINIT?)
>Common services for (1), (2)
>
>4) The zFS filesystem (including its address space, APIs, storage
>container, etc).
>This is POSIX / UNIX compliant, and can be used by any "dubbed" job.
>"HFS" was the previous version, which is still available but "stabilized".
>APIs in (1) and (2) allow you to use these, but also
>QSAM/BSAM/BPAM front-ends.
>
>5) z/OS Unix "command" binaries
>Program binder objects that are stored in (or linked to by) a file
>in the zFS or HFS filesystem (4).
>Unix command binaries can be invoked by BPXBATCH/COZBATCH (see
>10), or via fork()/spawn() APIs in (1) or (2), or more commonly by a
>shell (see 6).
>
>6) The Unix  "shell" program (/bin/sh, and example of (5)
>Also part of the POSIX / XPG specs.   Closest legacy z/OS analog
>would be IKJEFT01 + CLISTS + REXX, but this is kind of a stretc

Re: POHD: vs UTE (was: USS vs USS)

[Graham Hobbs]

Right .. can't our moderator stop this crep?

- Original Message - 
From: "Shane Ginnane" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Wednesday, May 04, 2011 7:43 PM
Subject: Re: POHD: vs UTE (was: USS vs USS)



A least the change in subject got me to read it Kirk   ;-)

It's a pity the list doesn't support (per subscriber) blacklisting
threads/contributors *at the server*.
Would save an awful lot of bandwidth.

ISTR an OT group was set up a while back. Doesn't seem to have helped.

Shane ...

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


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

Re: POHD: vs UTE (was: USS vs USS)

[Shane Ginnane]

A least the change in subject got me to read it Kirk   ;-)

It's a pity the list doesn't support (per subscriber) blacklisting
threads/contributors *at the server*.
Would save an awful lot of bandwidth.

ISTR an OT group was set up a while back. Doesn't seem to have helped.

Shane ...

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

POHD: vs UTE (was: USS vs USS)

[Kirk Wolf]

Maybe its time to have two lists - one for "Pedantic or Historical
Discussions" (POHD) , and one for "Useful Technical Exchange" (UTE)
(sorry if these acronyms are taken, I fully expect this thread to
blossom to discuss improper usage :-)

A rough count of recent traffic on the "USS" TLA yields well over a
hundred posts, whereas only a handful of UTE on z/OS UNIX.

Discussing two lists will likely turn pedantic, and since it has
probably been discussed before, historical.

Unfortunately, many folks (and poor newbies) interested in UTE will
just tune out, since a few on list seem to think that POHD == UTE.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> Here's a mildly aggressive idea:  prefix your new UTE threads with
"UTE:" and as the OP be diligent and respond to any posts on your
thread that vector to pedantic or historical discussions with an
altered subject line prefixed "RE: POHD:"Note that I have
preemptively tagged this thread "POHD:"


On Wed, May 4, 2011 at 5:00 PM, Anne & Lynn Wheeler  wrote:
> mike.a.sch...@gmail.com (Mike Schwab) writes:
>> http://en.wikipedia.org/wiki/IBM_AIX
>> IBM wrote TSS/370 in 1980 then VM/IX then AIX/370 in 1988 then AIX/ESA
>> until 1999 when it merged into MVS/ESA Open Edition.
>
> tss/360 was done in the 60s (official system for 360/67) ... was
> decommited and lived on as small special project. some of the
> single-level-store (paged-mapped filesystem) ideas were picked up for
> (failed) future system effort ... misc. past posts mentioning future
> system
> http://www.garlic.com/~lynn/submain.html#futuresys
>
> folklore is that after demise of future system, some of the participants
> retreated to rochester and did s/38 ... which then morphs into as/400
>
> in the 80s, tss/370 got something of a new life ... as base for special
> bid mainframe unix for AT&T ... stripped down tss/370 kernel (SSUP) with
> AT&T doing unix interfaces to the SSUP kernel interface (in some sense
> this is somewhat analogous to USS for MVS). this was competing with
> Amdahl's GOLD/UTS unix internally inside AT&T.
>
> AIX/370 (in conjunction with AIX/386) was done by palo alto group using
> the unix-like LOCUS done at UCLA. This was similar but different from
> the unix-like MACH done at CMU ... which was used by a number of vendors
> including NeXT and morphs into current Apple operating system after Jobs
> returns to Apple. AIX/370 morphs into AIX/ESA.
>
> The "argument" for (Amdahl) UTS under vm370, aix/370 under vm370,
> tss/370 ssup, and vm/ix (on vm370) was that the cost to add mainframe
> RAS&erep to unix was several times larger than the base, direct,
> straight-forward unix port (running under vm370 &/or tss/370 leveraged
> the already existing ras&erep support w/o having to re-implement
> directly in unix).  This was aggrevated by field service stand that it
> wouldn't service/support machines that lacked mainframe RAS&erep.
>
> I ran internal advanced technology conference in '82 ... and some of the
> presentation were about VM/IX implementation ... old post reference:
> http://www.garlic.com/~lynn/96.html#4a
>
> Palo Alto group had also been working with Berkeley to port their
> unix-like BSD to mainframe ... but they got redirected instead doing a
> PC/RT port ... released from ACIS as "AOS" ... as an alternative UNIX to
> the "official" AIXV2.
>
> The wiki page says much of the AIX v2 kernel was written in PL/I. The
> issue was that the original "displaywriter" was based on ROMP, cp.r, and
> PL.8 (sort of pli subset). Redirected to the unix workstation market
> required unix&C (all being done by the company that had done pc/ix and
> had been involved in vm/ix). For the internal people, a project called
> VRM was devised ... a sort of abstract virtual machine layer ... to be
> done by the internal employees trained in pl.8. The claim was that the
> combination VRM plus unix port to VRM ... could be done in shorter time
> and less resources than unix port directly to ROMP hardware. The exact
> opposite was shown when the palo alto group did the BSD port direct to
> ROMP hardware (for "AOS"). VRM+unix drastically increased original/total
> development costs, life-cycle support costs and complicated things like
> new device drivers (since both non-standard unix/c device driver to VRM
> interface as well as VRM/pl.8 device driver had to be developed &
> supported).  misc. past posts mentioning 801, romp, rios, pc/rt, aixv2,
> aixv3, power, rs/6000, etc
> http://www.garlic.com/~lynn/subtopic.html#801
> misc. old email mentioning 801
> http://www.garlic.com/~lynn/lhwemail.html#801
>
> Besides various other issues, the AIX wiki page skips over the whole
> generation of OSF
> http://en.wikipedia.org/wiki/Open_Software_Foundation
> and the "unix wars"
> http://en.wikipedia.org/wiki/UNIX_wars
>
> Project Monterey
> http://en.wikipedia.org/wiki/Project_Monterey
>
> skips over the whole cluster scaleup after IBM bought Sequent and
> support for Sequent's 256-way SCI-based 

Re: Do we need to implement HSM

[Cris Hernandez #9]

proper use of mgmtclas/storclas can save a whole lot of dasd and prevents the 
need to clean up garbage on a regular basis.  

--- On Wed, 5/4/11, ibmnew  wrote:

> From: ibmnew 
> Subject: Do we need to implement HSM
> To: IBM-MAIN@bama.ua.edu
> Date: Wednesday, May 4, 2011, 5:45 AM
> Dear all 
> 
>    In our shop we don't have any tapelib.
> 
>  Do you need to implement HSM ?
> 
> Any suggestions is greatly appreciated!
> 
> Thanks a lot!
> 
> Jason Cai 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access
> instructions,
> send email to lists...@bama.ua.edu
> with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 

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

Re: How Does DFhsm and Flashcopy Work?

[George Rodriguez]

I've already started the investigation on how to get the job done and you're
right, it's not a small task.

I appreciate the information.

Thanks,
George Rodriguez
Specialist II - IT Solutions
Application Support / Quality Assurance
PX - 47652
(561) 357-7652 (office)
(561) 707-3496 (mobile)
School District of Palm Beach County
3348 Forest Hill Blvd.
Room B-332
West Palm Beach, FL. 33406-5869
Florida's Only A-Rated Urban District For Six Consecutive Years

- Original Message -
From: IBM Mainframe Discussion List 
To: IBM-MAIN@bama.ua.edu 
Sent: Wed May 04 17:26:03 2011
Subject: Re: How Does DFhsm and Flashcopy Work?

Yes, though I don't know about using command backup, I usually use HSM
autodump.  However, use of FRBACKUP will require a certain amount of setup,
so it is not appropriate for ad-hoc uses.

On Wed, May 4, 2011 at 1:33 PM, George Rodriguez <
george.rodrig...@palmbeachschools.org> wrote:

> Scott,
>
> So to paraphrase what you're saying, if I use FRBACKUP to perform the
> Flashcopy then I use the DFhsm commands to backup the FRBACKUP volumes,
> DFhsm will know that the backup is on flash copied backup. It that
> correct?
> *
> *
> *George Rodriguez*
> *Specialist II - IT Solutions*
> *Application Support / Quality Assurance*
> *PX - 47652*
> *(561) 357-7652 (office)*
> *(561) 707-3496 (mobile)*
> *School District of Palm Beach County*
> *3348 Forest Hill Blvd.*
> *Room B-332*
> *West Palm Beach, FL. 33406-5869*
> *Florida's Only A-Rated Urban District For Six Consecutive Years*
>
>
>
> On Wed, May 4, 2011 at 11:55 AM, Scott Rowe  wrote:
>
> > When you do the FlashCopy yourself like this, then HSM doesn't know that
> it
> > is a backup of PTST00, so he doesn't look to this backup to restore a
> > dataset on PTST00.  It looks to me like you should be using FRBACKUP for
> > this, so that it is HSM that is doing the FlashCopy, and he knows what
> the
> > backup really is.
> >
> > On Wed, May 4, 2011 at 9:47 AM, George Rodriguez <
> > george.rodrig...@palmbeachschools.org> wrote:
> >
> > > When a Flashcopy of volumes are done and commands are sent to DFhsm to
> > DUMP
> > > the all the flashed volumes, how do I recover a lost dataset. I
> honestly
> > > thought that DFhsm would know that this procedure was done and it
> > > would
> > use
> > > the flashed copy to recover the dataset, but when I use ISMF to either
> > > HRECOVER or RESTORE the dataset it's not using the flashed copy. I'm
> > going
> > > to provide the JCL that I use to Flashcopy the volume(s) and the job
> > > to
> > > back
> > > up the volume, just in case:
> > >
> > > //STEP010 EXEC PGM=ADRDSSU
> > > //SYSPRINT  DD SYSOUT=*
> > > //SYSIN DD *
> > >  COPY FULL INDY(PTST00) OUTDY(XTST00) FCNOCOPY PURGE DUMPCONDITIONING
> > >  .
> > >  .
> > >
> > > Here's the backup job:
> > >
> > > //STEP010 EXEC PGM=IKJEFT01
> > > //SYSPRINT  DD SYSOUT=X
> > > //SYSTSPRT  DD SYSOUT=X
> > > //SYSTSIN   DD *
> > >  HSENDCMD BACKVOL VOL(XTST00) DUMP(DUMPCLASS(DAILYDR))
> > >  .
> > >  .
> > >
> > > Thanks for the help.
> > > *
> > > *
> > > *George Rodriguez*
> > > *Specialist II - IT Solutions*
> > > *Application Support / Quality Assurance*
> > > *PX - 47652*
> > > *(561) 357-7652 (office)*
> > > *(561) 707-3496 (mobile)*
> > > *School District of Palm Beach County*
> > > *3348 Forest Hill Blvd.*
> > > *Room B-332*
> > > *West Palm Beach, FL. 33406-5869*
> > > *Florida's Only A-Rated Urban District For Six Consecutive Years*
> > >
> > > Home of Florida's first LEED Gold Certified School
> > >
> > > Under Florida law, e-mail addresses are public records. If you do not
> > want
> > > your e-mail address
> > > released in response to a public records request, do not send
> electronic
> > > mail to this entity.
> > > Instead, contact this office by phone or in writing.
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> > >
> >
> > CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
> > confidential and privileged information intended only for the addressee.
> > If you are not the intended recipient, please be advised that you have
> > received this material in error and that any forwarding, copying,
> printing,
> > distribution, use or disclosure of the material is strictly prohibited.
> > If you have received this material in error, please (i) do not read it,
> > (ii) reply to the sender that you received the message in error, and
> > (iii) erase or destroy the material. Emails are not secure and can be
> > intercepted, amended, lost or destroyed, or contain viruses. You are
> deemed
> > to have accepted these risks if you communicate with us by email. Thank
> > you.
> >
> > --
> > For IBM-MAIN subscribe / s

Re: SV: USS vs USS

[Anne & Lynn Wheeler]

mike.a.sch...@gmail.com (Mike Schwab) writes:
> http://en.wikipedia.org/wiki/IBM_AIX
> IBM wrote TSS/370 in 1980 then VM/IX then AIX/370 in 1988 then AIX/ESA
> until 1999 when it merged into MVS/ESA Open Edition.

tss/360 was done in the 60s (official system for 360/67) ... was
decommited and lived on as small special project. some of the
single-level-store (paged-mapped filesystem) ideas were picked up for
(failed) future system effort ... misc. past posts mentioning future
system
http://www.garlic.com/~lynn/submain.html#futuresys

folklore is that after demise of future system, some of the participants
retreated to rochester and did s/38 ... which then morphs into as/400

in the 80s, tss/370 got something of a new life ... as base for special
bid mainframe unix for AT&T ... stripped down tss/370 kernel (SSUP) with
AT&T doing unix interfaces to the SSUP kernel interface (in some sense
this is somewhat analogous to USS for MVS). this was competing with
Amdahl's GOLD/UTS unix internally inside AT&T.

AIX/370 (in conjunction with AIX/386) was done by palo alto group using
the unix-like LOCUS done at UCLA. This was similar but different from
the unix-like MACH done at CMU ... which was used by a number of vendors
including NeXT and morphs into current Apple operating system after Jobs
returns to Apple. AIX/370 morphs into AIX/ESA.

The "argument" for (Amdahl) UTS under vm370, aix/370 under vm370,
tss/370 ssup, and vm/ix (on vm370) was that the cost to add mainframe
RAS&erep to unix was several times larger than the base, direct,
straight-forward unix port (running under vm370 &/or tss/370 leveraged
the already existing ras&erep support w/o having to re-implement
directly in unix).  This was aggrevated by field service stand that it
wouldn't service/support machines that lacked mainframe RAS&erep.

I ran internal advanced technology conference in '82 ... and some of the
presentation were about VM/IX implementation ... old post reference:
http://www.garlic.com/~lynn/96.html#4a

Palo Alto group had also been working with Berkeley to port their
unix-like BSD to mainframe ... but they got redirected instead doing a
PC/RT port ... released from ACIS as "AOS" ... as an alternative UNIX to
the "official" AIXV2. 

The wiki page says much of the AIX v2 kernel was written in PL/I. The
issue was that the original "displaywriter" was based on ROMP, cp.r, and
PL.8 (sort of pli subset). Redirected to the unix workstation market
required unix&C (all being done by the company that had done pc/ix and
had been involved in vm/ix). For the internal people, a project called
VRM was devised ... a sort of abstract virtual machine layer ... to be
done by the internal employees trained in pl.8. The claim was that the
combination VRM plus unix port to VRM ... could be done in shorter time
and less resources than unix port directly to ROMP hardware. The exact
opposite was shown when the palo alto group did the BSD port direct to
ROMP hardware (for "AOS"). VRM+unix drastically increased original/total
development costs, life-cycle support costs and complicated things like
new device drivers (since both non-standard unix/c device driver to VRM
interface as well as VRM/pl.8 device driver had to be developed &
supported).  misc. past posts mentioning 801, romp, rios, pc/rt, aixv2,
aixv3, power, rs/6000, etc 
http://www.garlic.com/~lynn/subtopic.html#801
misc. old email mentioning 801
http://www.garlic.com/~lynn/lhwemail.html#801

Besides various other issues, the AIX wiki page skips over the whole
generation of OSF
http://en.wikipedia.org/wiki/Open_Software_Foundation
and the "unix wars"
http://en.wikipedia.org/wiki/UNIX_wars

Project Monterey 
http://en.wikipedia.org/wiki/Project_Monterey

skips over the whole cluster scaleup after IBM bought Sequent and
support for Sequent's 256-way SCI-based Numa-Q. Recent posts in
(linkedin) "Greater IBM" (current & former IBMer) discussion
http://www.garlic.com/~lynn/2011d.html#7 IBM Watson's Ancestors: A Look at 
Supercomputers of the Past

the sequent wiki ... mentioned in the above post ... used to be somewhat
more caustic about sequent being dropped shortly after the sponsoring
executive retired:
http://en.wikipedia.org/wiki/Sequent_Computer_Systems

as noted in the "Greater IBM" post ... at one time, IBM had been
providing quite a bit of funding for Chen's Supercomputer ... Sequent
later acquires Chen Supercomputer and Chen becomes CTO at Sequent ... we
do some consulting for Chen (before Sequent purchase by IBM).

Part of the speculation for IBM's purchase of Sequent was that Sequent
was major platform for some of the IBM mainframe simulator products.

much of the "posix" (aka unix) support in MVS during the first half of
the 90s was sponsored by the head of the disk division software
group. in the late 80s, a senior disk engineer got a talk scheduled at
the internal, annual, world-wide communication group conference ... and
opened the talk with the statement that the communication group was
goin

Re: USS vs USS

[Bob Rutledge]

Shmuel Metz (Seymour J.) wrote:

John Eels said otherwise, and he's in a position to know.


Eells.

Bob

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

Re: How Does DFhsm and Flashcopy Work?

[Scott Rowe]

Yes, though I don't know about using command backup, I usually use HSM
autodump.  However, use of FRBACKUP will require a certain amount of setup,
so it is not appropriate for ad-hoc uses.

On Wed, May 4, 2011 at 1:33 PM, George Rodriguez <
george.rodrig...@palmbeachschools.org> wrote:

> Scott,
>
> So to paraphrase what you're saying, if I use FRBACKUP to perform the
> Flashcopy then I use the DFhsm commands to backup the FRBACKUP volumes,
> DFhsm will know that the backup is on flash copied backup. It that correct?
> *
> *
> *George Rodriguez*
> *Specialist II - IT Solutions*
> *Application Support / Quality Assurance*
> *PX - 47652*
> *(561) 357-7652 (office)*
> *(561) 707-3496 (mobile)*
> *School District of Palm Beach County*
> *3348 Forest Hill Blvd.*
> *Room B-332*
> *West Palm Beach, FL. 33406-5869*
> *Florida's Only A-Rated Urban District For Six Consecutive Years*
>
>
>
> On Wed, May 4, 2011 at 11:55 AM, Scott Rowe  wrote:
>
> > When you do the FlashCopy yourself like this, then HSM doesn't know that
> it
> > is a backup of PTST00, so he doesn't look to this backup to restore a
> > dataset on PTST00.  It looks to me like you should be using FRBACKUP for
> > this, so that it is HSM that is doing the FlashCopy, and he knows what
> the
> > backup really is.
> >
> > On Wed, May 4, 2011 at 9:47 AM, George Rodriguez <
> > george.rodrig...@palmbeachschools.org> wrote:
> >
> > > When a Flashcopy of volumes are done and commands are sent to DFhsm to
> > DUMP
> > > the all the flashed volumes, how do I recover a lost dataset. I
> honestly
> > > thought that DFhsm would know that this procedure was done and it would
> > use
> > > the flashed copy to recover the dataset, but when I use ISMF to either
> > > HRECOVER or RESTORE the dataset it's not using the flashed copy. I'm
> > going
> > > to provide the JCL that I use to Flashcopy the volume(s) and the job to
> > > back
> > > up the volume, just in case:
> > >
> > > //STEP010 EXEC PGM=ADRDSSU
> > > //SYSPRINT  DD SYSOUT=*
> > > //SYSIN DD *
> > >  COPY FULL INDY(PTST00) OUTDY(XTST00) FCNOCOPY PURGE DUMPCONDITIONING
> > >  .
> > >  .
> > >
> > > Here's the backup job:
> > >
> > > //STEP010 EXEC PGM=IKJEFT01
> > > //SYSPRINT  DD SYSOUT=X
> > > //SYSTSPRT  DD SYSOUT=X
> > > //SYSTSIN   DD *
> > >  HSENDCMD BACKVOL VOL(XTST00) DUMP(DUMPCLASS(DAILYDR))
> > >  .
> > >  .
> > >
> > > Thanks for the help.
> > > *
> > > *
> > > *George Rodriguez*
> > > *Specialist II - IT Solutions*
> > > *Application Support / Quality Assurance*
> > > *PX - 47652*
> > > *(561) 357-7652 (office)*
> > > *(561) 707-3496 (mobile)*
> > > *School District of Palm Beach County*
> > > *3348 Forest Hill Blvd.*
> > > *Room B-332*
> > > *West Palm Beach, FL. 33406-5869*
> > > *Florida's Only A-Rated Urban District For Six Consecutive Years*
> > >
> > > Home of Florida's first LEED Gold Certified School
> > >
> > > Under Florida law, e-mail addresses are public records. If you do not
> > want
> > > your e-mail address
> > > released in response to a public records request, do not send
> electronic
> > > mail to this entity.
> > > Instead, contact this office by phone or in writing.
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> > >
> >
> > CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
> > confidential and privileged information intended only for the addressee.
> > If you are not the intended recipient, please be advised that you have
> > received this material in error and that any forwarding, copying,
> printing,
> > distribution, use or disclosure of the material is strictly prohibited.
> > If you have received this material in error, please (i) do not read it,
> > (ii) reply to the sender that you received the message in error, and
> > (iii) erase or destroy the material. Emails are not secure and can be
> > intercepted, amended, lost or destroyed, or contain viruses. You are
> deemed
> > to have accepted these risks if you communicate with us by email. Thank
> > you.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
>
> Home of Florida's first LEED Gold Certified School
>
> Under Florida law, e-mail addresses are public records. If you do not want
> your e-mail address
> released in response to a public records request, do not send electronic
> mail to this entity.
> Instead, contact this office by phone or in writing.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send ema

Re: USS vs USS

[Shmuel Metz (Seymour J.)]

In , on 05/03/2011
   at 02:28 PM, Mark Zelden  said:

>IBM didn't misuse it.  The description of the parm used "official"
>(ahem) IBM terminology.

John Eels said otherwise, and he's in a position to know.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: TSO Profile NUM and PACK

[Tom Marchant]

On Wed, 4 May 2011 13:23:24 -0400, Shmuel Metz (Seymour J.) wrote:

>In , on 05/04/2011
>   at 08:57 AM, Tom Marchant  said:
>
>>I use a wide display too.  With NUMBER ON, the sequence numbers are
>>not displayed.
>
>Are you perhaps thinking of BROWSE? EDIT and VIEW displayed sequence
>numbers when the screen width was 132 or 160.

No.  Edit and View display sequence numbers on a wide enough screen with NUM
ON DISPLAY or RENUM DISPLAY.  With NUM ON (without specifying DISPLAY), they
are not shown.

-- 
Tom Marchant

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

Re: "Under z/OS Unix"

[Kirk Wolf]

Good discussion.   As OP, I was hoping for some consensus that "Under
z/OS Unix" or "Under USS" are not very useful terms since most people
don't recognize them as meaning "any dubbed z/OS Unix process".
"Under a z/OS Unix shell" or "program in a zFS filesystem" are closer
to what most people see to think of.But I don't care to discuss
"proper" terminology - there is enough of that around here.   More
interesting to me is to better understand how z/OS Unix works and what
needs improvement.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, May 4, 2011 at 1:44 PM, Mike Schwab  wrote:
> On Wed, May 4, 2011 at 1:33 PM, Mark Zelden  wrote:
>> On Wed, 4 May 2011 12:48:14 -0400, Shmuel Metz (Seymour J.)
>>  wrote:
>>
>>>In , on 05/03/2011
>>>   at 10:10 AM, Mark Zelden  said:
>>>
But I think your last part I quoted is probably closer.   People
don't say "under USS" when they use FTP or Telnet for example,
>>>
>>>Which people? I certainly consider FTP and telnet in z/OS to be Unix
>>>services.
>>>
>>
>> The part I was addressing wasn't "what is z/OS Unix", rather it was
>> what people meant when they write or say "I was doing blah blah
>> under USS".   I've never heard anyone say "I was FTPing under USS" for
>> example unless they were executing FTP interactively from a shell of
>> some sort.
>>
>> Mark
>> --
>> Mark Zelden
> When I FTP a tersed dump or log to IBM, I use a batchjob with no step
> lib and control cards that reference z/OS PS files.  Yes, I did have
> to get a OMVS RACF segment in order to run, but the appearance of the
> control cards just look like a login FTP logoff sequence.
>

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

Re: USS vs USS

[Mark Zelden]

On Wed, 4 May 2011 13:28:30 -0500, Chris Mason  wrote:

>Mark - who clearly hasn't cleaned the egg off yet[1]

Please try and keep this professional.  I have no idea what
you are referring to, but it doesn't add to the discussion. 

>
>> IBM didn't misuse it.
>
>Wrong!
>
>> The description of the parm used "official" (ahem) IBM terminology.
>
>More wrong - if possible!
>

Not the parm... which is just an 8 char name, the DESCRIPTION:

"USSHOME
The USSHOME system initialization parameter specifies the name and path
of the root directory for CICS® TS 4.1 files on z/OS® UNIX. "
~~



>> USS is still a convenient abbreviation for Unix System Services ...
>
>
>> ... and all the current pubs are still called Unix System Services something
>or other (not z/OS Unix something or other).
>
>And your point is ... ?
>

I had just made the point.  USS is an abbreviation for Unix System Services. 

>I thought I might have an idea what your point was until I checked the
>current V1R12 z/OS UNIX bookshelf - yes, I trust you noticed, "z/OS UNIX" -
>although it does differ from your "z/OS Unix" by using upper case - and,
>looking in the most general manual, the "Planning" manual, I noted that
>Chapter 1 was "Introduction to z/OS UNIX".
>
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB2B0/1.0
>

Perhaps you don't understand how the OS is packaged and documented.

The "z/OS VnRn" prefaces all the element shelves / book names for the most
part. So you can ignore that.  Prior to z/OS substitute "OS/390".   The
element / component names come after the "z/OS VnRn".  MVS is a component,
DFSMS is a component, Security Server, Communication Server and
Unix System Services are all components of z/OS.

If you had read more than the chapter heading, you would have seen
the first sentences which read:

"The UNIX System Services element of z/OS is a UNIX operating
environment, implemented within the z/OS operating system. It is
also known as z/OS UNIX. "

z/OS UNIX itself is just another form of abbreviation because Unix System
Services is too long a name I guess or isn't catchy enough.   

>
>> Just because IBM started using z/OS unix doesn't mean every software MF
>component known to man kind is going to change their parms / keywords (for
>example, ZUXHOME for CICS SIT).
>
>Ditto!
>
>What's to "change"?[2] It was wrongly composed in the first place by pure
>carelessness - egged (sorry) on by misuse by the ignorant.  It was careless
>because John Eells - I believe - implied that there is a formal process whereby
>developers can discover whether implied initialisms and other abbreviations
>have been taken already and careless developers may very well imagine they
>are allowed to bypass that process when they find others extensively misusing
>a particular initialism.
>

You casting a very wide net in your disparaging remarks about IBM 
developers.  One example used in this discussion often is the USS 
abbreviation in Health Checker.  This is a relatively new component
of z/OS and I'm sure it went through all the formal processes, yet 
USS is used as the abbreviation for the check names and the check
owner.

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

Re: SV: USS vs USS

[Mike Schwab]

On Wed, May 4, 2011 at 1:29 PM, Mark Zelden  wrote:
> On Wed, 4 May 2011 18:33:27 +0200, Thomas Berg  
> wrote:
>
>>FWIW, I have always considered a use of USS as a name for a UNIX system as
> ugly.
>>Especially for z/OS.  Would in such a case prefer something like "ZUNIX",
> "UNIZ"
>>or "ZUX" ;).
>>
>
> How soon we forget.  Openedition existed for MVS/ESA  4.3 and MVS/ESA 5.1
> and 5.2.  It was later rename to Unix System Services under OS/390 long
> before "z" hardware and z/OS were ever dreamed of as a name for
> the 64-bit hardware and OS.   What would you have called it under OS/390
> to have short meaningful abbreviation?
>
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS

http://en.wikipedia.org/wiki/IBM_AIX
IBM wrote TSS/370 in 1980 then VM/IX then AIX/370 in 1988 then AIX/ESA
until 1999 when it merged into MVS/ESA Open Edition.

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

Re: SV: USS vs USS

[Mark Zelden]

On Wed, 4 May 2011 13:29:03 -0500, Mark Zelden  wrote:

>On Wed, 4 May 2011 18:33:27 +0200, Thomas Berg  wrote:
>
>>FWIW, I have always considered a use of USS as a name for a UNIX system as
>ugly.
>>Especially for z/OS.  Would in such a case prefer something like "ZUNIX",
>"UNIZ"
>>or "ZUX" ;).
>>
>
>How soon we forget.  Openedition existed for MVS/ESA  4.3 and MVS/ESA 5.1
>and 5.2.  It was later rename to Unix System Services under OS/390 long
>before "z" hardware and z/OS were ever dreamed of as a name for
>the 64-bit hardware and OS.   What would you have called it under OS/390
>to have short meaningful abbreviation?
>

I guess I forgot too. :-) 

After looking at an old bookshelf I see it was still Openedition until 
OS/390 2.6.

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

Re: USS vs USS

[Mike Schwab]

I know we were using these
http://www.cs.kuleuven.be/museum/varian/teletype-E.html
teletypes well into the 1990s.  By 1984 they were being used as
printers only attached to a modem, 16*64 green screen, and keyboard
unit.

On Wed, May 4, 2011 at 1:20 PM, Chris Mason  wrote:
> Scott
>
>> ... the SNA 3270 days to be exact.
>
> Well, not quite as exact as it might be. SNA devices supporting human end
> users - as opposed to SNA devices supporting programs - needed some
> technique for composing the three data elements needed for the SSCP
> (VTAM) to initiate a session. This applies to all such devices not just 3270
> display devices. Some of us still recall a typewriter device, the 3767. 
> Racking
> my brains for other such devices, I managed to conjure up the fascinating
> 3770 range and, of course, the 3270 emulation on the 3790 - and was there
> something similar on some of the (other) "industry" systems of the late 
> 1970's?
> But that's all 3270 again, so doesn't count!
>


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

Re: USS vs USS

[Mike Schwab]

On Wed, May 4, 2011 at 1:17 PM, Chris Mason  wrote:
> Ed

>
> http://www-01.ibm.com/software/globalization/terminology/u.html#x2042481
>
http://bama.ua.edu/archives/ibm-main.html

Re: USS vs USS

[Chris Mason]

Dave

I've repeated an example of why it matters to Don Grinsell.

I thought it might be interesting to dig out another case. In fact, I see now 
it's the same person still bemused by hearing the misuse so often and getting 
confused in a way other than that other example:



I have the following entry in my USSTAB:
 
P39TMMVS USSCMD CMD=P39TMMVS,REP=LOGON,FORMAT=BAL
 USSPARM PARM=APPLID,DEFAULT=TMONMVS 
 
When I key in P39TMMVS we are really getting TMONMVS as the executable.
 
What I don't understand is what path is followed to execute TMONMVS?



http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0902&L=ibm-
main&T=0&F=&S=&P=53610

Chris Mason

On Mon, 2 May 2011 16:51:44 -0700, Gibney, Dave  
wrote:

>Amen, can you say AAAMeennn
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
>> Behalf Of Scott Rowe
>> Sent: Monday, May 02, 2011 2:42 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: USS vs USS
>>
>> Ed,
>>
>> That has to be the most sensible post of this entire idiotic
>kerfuffle.
>>
>> I owe you a beer if I ever make it to SCIDS again.
>>
>> Scott
>>
>> On Mon, May 2, 2011 at 11:55 AM, Edward Jaffe
>> wrote:
>>
>> > On 5/2/2011 8:44 AM, Ed Gould wrote:
>> >
>> >> I suggest a SHARE requirement to get IBM to decide once and for all
>> of a
>> >> definition for USS.
>> >>
>> >
>> > I would like to know which use is the most offensive to the largest
>> number
>> > of people. That's the one I will start using most.
>> >
>> > --
>> > Edward E Jaffe

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

Some good news to send to upper management

[Ed Gould]

I have been reading a new(?) book called Real World IBM z Stories.

It talks specifically about companies (with names) of system z success stories. 
It also talks about 3 univesities that teach OS's that run on System z.
I got my copy on AMAZON, it is approx 168 pages of really good stories about 
companies that have used System z for various reasons like power savings and 
being green and other facets that system z brings with it.

It would be a great airline read (chuckle) but in this case its true ;)

The stories are a few pages each so it short and to the point. I think its 
great 
reading but I am biased. IBM should be handing this out at various meetings for 
upper management.

Ed

ps: Its put out by Maxpress (in florida I believe) ISBN 9781936187027

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

Re: USS vs USS

[Chris Mason]

Don

> It seems to me that the big argument here is that once an acronym is used 
for one thing it may never, ever be used for any other purpose else mass 
confusion will result, ...

Not "will result" but rather "has resulted". If there was a time where one use 
was appropriate which has disappeared to be followed - at a decent interval 
for all to reset their memories - by a new use, what you said would be 
relevant. But there wasn't, so it isn't!

> ... can anybody please provide a practical example of how the old USS and 
the new USS could possibly be used alone or together where the meaning 
could not be correctly derived from context?

I posted one yesterday. It would be s helpful if people just read up on 
the topic before jumping in!

Admittedly the water was muddied by this being a fresh thread without any 
obvious connection to "An unnecessary controversy (Was: Ported tools for 
z/OS on ADCD)". We'll just have to put that down to poor "list-craft" on the 
part of the person starting the fresh thread if you were not following the 
earlier thread.

I'll repeat it again to save you the trouble of searching the archives:



This pair of posts dates from July 2009.

The subject was "Mainframe hacking". A lady was telling a story of a "hack" 
which included the following two sentences:



I had one once, circa 1992-1993.

...

Someone got the uss screen, was able to get into the production CICS, and 
the CECI command was not protected, so they were able to shut the CICS 
down.



A gentleman responded:



Interesting, I didn't think that back in '93 MVS 4.3 had a USS piece.



See

http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0907&L=ibm-
main&D=0&T=0&P=131204

and

http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0907&L=ibm-
main&D=0&T=0&P=132279



This isn't actually the main area where ambiguity is possible, it's just a 
consequence of the general misuse.

The main problem is in the area of z/OS Communications Server TELNET which 
can be used to access UNIX System Services - OTELNETD - or can be used to 
access 3270 data stream applications - TN3270. In the former case - once 
logged on - we have UNIX System Services commands and messages. In the 
latter case - for the purposes of logging on - we have Unformatted System 
Services commands and messages.

Of particular irritation even if the full post reveals the context well enough 
- 
although it need not - is the matter of the Subject line. As you can very 
easilty imagine from what I explained above, it would be very easy for a 
subscriber, typically one relatively new to z/OS, having only these awful 
examples to guide him or her, to come up with a Subject line such as the 
following:

"Why doesn't my  command work?" - Ambiguous enough 
for you?

"Can anyone explain this  message I'm getting" - Ditto?

The other example I gave to Dave Gibney could easily have been an individual 
post with the title:

"Where does the  executable come from?" - Ditto?

Either those expecting a question about UNIX System Services or those 
expecting a question about Unformatted System Services are going to get 
riled - and riling in the revered IBM-MAIN list is surely not to be encouraged!

It is the latter, the Communications Server components, which rightly claims 
the dread initials since this particular usage has been around since the mid-
70s and is enshrined in the relevant IBM web site - again a repeat from the 
other thread but this time rather than just give the reference I'll quote the 
entries:



unformatted system service (USS)

A communications function that translates a character-coded command, such 
as a LOGON or LOGOFF command, into a field-formatted command for 
processing by formatted system services. See also formatted system service.

...

USS
See unformatted system service.



http://www-01.ibm.com/software/globalization/terminology/u.html#x2042481

UNIX System Services is just this week's name when last week it was 
OpenEdition or OpenMVS or some such. Either way, it is very much a johnny-
come-lately which is probably the attraction for these dedicated followers of 
fashion.

> If not ...

But actually so.

> ... then might I suggest to all that this topic has about run it's course?

Not until the recalcitrants and recusants - and they know who they are - are 
purged.

This topic will continue to have healthy legs!

> ... I believe the United States Navy was using USS long before IBM ever got 
into the game.

We have a regular contributor who takes an interest in at least one - the 
original one - of these uses. He takes care to inform us he is retired from the 
navy. I don't believe he has any difficulty understanding that, when posting in 
IBM-MAIN or IBMTCP-L, he will not ever be dealing with an United States Ship!

Chris Mason

On Tue, 3 May 2011 04:29:45 +, Grinsell, Don  wrote:

>Language is evolutionary.  Acronyms are an extension of language.  It seems 
to me that the big argument here is that once an acronym is used for one 
thing it 

Re: Ported tools for z/OS on ADCD

[Chris Mason]

Rob

> Are we ready to let this thread die?

Since the OP has already said "thank you" and moved on, there is no real need 
still to continue with this thread.

If you mean "Are we ready to let the topic which emerged from this thread 
and which has spawned other threads die?", very probably not while the 
recalcitrants and recusants persist.

> We go round and round with this without any meaningful movement from our 
relatively entrenched positions.

I don't recognise what you say here as being related to "Ported Tools" any 
more.

Again, if you mean the topic, there are now two threads from which to 
choose, one properly attached to the stimulating thread and one regrettably 
not - thereby occasioning the need to repeat some references.

> VTAM USS or zOS USS context is clear ...

Won't work! The trouble with this superficially attractive idea has been 
exposed elsewhere but explain again:

Those who are unfamiliar with proper use - or who have been so bombarded 
with the misuse that they have forgotten the correct use - see my cases - 
need to have a proper example set for long enough that they will not misuse 
even when they don't know (much about) the correct use.

Only then will the ambiguity that Don Grinsell didn't appreciate existed be 
definitely avoided.

> ... and google searches return the correct information.

When the subject concerns IBM products, an IBM search is so obviously to be 
preferred it really goes without saying - but - *! - I've said it already!

> Where is Amy Farrah Fowler when we need her? 

I have absolutely no idea who this excellent lady might be!

Well, although I don't have much time for this sort of insular nonsense, I did 
a 
quick Wikipedia check and I see

1. She is fictional!

2. She is associated with a title "Pumpkinhead" which does not engender 
confidence that anything useful has been offered here!

> ... Sheldon ...

Whoever he or she might happen to be.

> I am sure Sheldon would agree that USS would only have one use 
determined by him.

Which is just one probably fictional character's position worth nothing 
whatsoever at all!

Perhaps a little more long-windedness is needed when you have a global 
audience!

> I expect that this argument will go on for the next 20 or 30 years.

It is possible that IBM will steer all users away from hacker-proof SNA to 
hacker-ridden - you can't open a news web page without learing that Sony 
has screwed up again - IP because that's what the glossy coffee table rubbish 
pontificates is the "smart" thing to do. When SNA is no more, the VTAM API 
will be no more and actually the 3270 data stream will be no more. Then, after 
a decent interval, those who inhabit the IBM-MAIN universe of the day can 
petition to use the dread three letters - except that all will by then have got 
into the habit of using some variation of z/OS UNIX System Services, or z/OS 
UNIX or z/UNIX or zUNIX - assuming those brilliant marketing "suits" in IBM 
haven't decided that they're tired of z/OS UNIX System Services and come up 
with something else like zOpenUNIX as a swipe at traditional non-open UNIXes 
which is what my IBM MVS colleagues crowed about when this POSIX-
compliant function was stuck onto MVS.

Chris Mason

On Tue, 3 May 2011 09:33:51 -0400, Rob Schramm 
 wrote:

>Are we ready to let this thread die?  We go round and round with this
>without any meaningful movement from our relatively entrenched positions.
> Apart from some fairly humorous quips and some long winded prose
>there is little progress made.
>
>I did have an idea for helping the context (and google searches) that forces
>all to suffer (all suffering is the core of compromise? )  VTAM USS or
>zOS USS  context is clear and google searches return the correct
>information.  viva la evolution! 
>
>Where is Amy Farrah Fowler when we need her?  I am sure Sheldon would 
agree
>that USS would only have one use determined by him.
>
>I expect that this argument will go on for the next 20 or 30 years.  After
>which USS will be ceded to Unix System Services as a "no-prize" (marvel
>reference) due to lack of opposition and the fact that no one will care
>anymore.
>
>Rob Schramm
>
>On Tue, May 3, 2011 at 8:52 AM, Shmuel Metz (Seymour J.) <
>shmuel+ibm-m...@patriot.net> wrote:
>
>> In , on 
05/02/2011
>>at 07:49 PM, Itschak Mugzach  said:
>>
>> >Everybodu uses USS for Unix System Services,
>>
>> No.
>>
>> >including IBM.
>>
>> John Eels is from IBM.
>>
>> --
>>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>--
>Rob Schramm

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

Re: "Under z/OS Unix"

[Mike Schwab]

On Wed, May 4, 2011 at 1:33 PM, Mark Zelden  wrote:
> On Wed, 4 May 2011 12:48:14 -0400, Shmuel Metz (Seymour J.)
>  wrote:
>
>>In , on 05/03/2011
>>   at 10:10 AM, Mark Zelden  said:
>>
>>>But I think your last part I quoted is probably closer.   People
>>>don't say "under USS" when they use FTP or Telnet for example,
>>
>>Which people? I certainly consider FTP and telnet in z/OS to be Unix
>>services.
>>
>
> The part I was addressing wasn't "what is z/OS Unix", rather it was
> what people meant when they write or say "I was doing blah blah
> under USS".   I've never heard anyone say "I was FTPing under USS" for
> example unless they were executing FTP interactively from a shell of
> some sort.
>
> Mark
> --
> Mark Zelden
When I FTP a tersed dump or log to IBM, I use a batchjob with no step
lib and control cards that reference z/OS PS files.  Yes, I did have
to get a OMVS RACF segment in order to run, but the appearance of the
control cards just look like a login FTP logoff sequence.

Used to do this (or very similar sequences) with compuserve forums in
the early about 1992-1994 on MS-DOS 5.

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

Re: Using EMC Clariion SCSI disk with Linux

[Crabtree, Anne D]

I can say, definitely yes, that a device was attached to the linux guest, but 
since I don't do the Linux stuff, can't answer the HBA question.  
Unfortunately, linux person out till May 15!


From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] On Behalf Of Mark 
Post [mp...@novell.com]
Sent: Wednesday, May 04, 2011 12:13 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Using EMC Clariion SCSI disk with Linux

>>> On 5/2/2011 at 08:46 AM, "Crabtree, Anne D"  wrote:
> In z/VM, the chips appear fine, defined as FCP with devices attached and
> FREE.  I'm not sure what else I can do from the mainframe side to help the
> situation?  HELP!

Have you tried attaching a device number to one of the Linux guests and having 
it bring the HBA online?


Mark Post

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

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

Re: "Under z/OS Unix"

[Mark Zelden]

On Wed, 4 May 2011 12:48:14 -0400, Shmuel Metz (Seymour J.)
 wrote:

>In , on 05/03/2011
>   at 10:10 AM, Mark Zelden  said:
>
>>But I think your last part I quoted is probably closer.   People
>>don't say "under USS" when they use FTP or Telnet for example,
>
>Which people? I certainly consider FTP and telnet in z/OS to be Unix
>services.
>

The part I was addressing wasn't "what is z/OS Unix", rather it was 
what people meant when they write or say "I was doing blah blah
under USS".   I've never heard anyone say "I was FTPing under USS" for 
example unless they were executing FTP interactively from a shell of
some sort.  

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

Re: USS vs USS

[Chris Mason]

See post to John Chase - or perhaps not if you want to continue to have a 
good day.

Chris Mason

On Wed, 4 May 2011 10:29:48 +0200, Hunkeler Peter (KIUP 4) 
 wrote:

>>SIT
>>parameter:
>>
>>USSHOME
>>The USSHOME system initialization parameter specifies the name and path
>>of the root directory for CICS(r) TS 4.1 files on z/OS(r) UNIX.
>
>Ha, ha, ha.ROTFL. you made my day!

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

Re: SV: USS vs USS

[Mark Zelden]

On Wed, 4 May 2011 18:33:27 +0200, Thomas Berg  wrote:

>FWIW, I have always considered a use of USS as a name for a UNIX system as
ugly.
>Especially for z/OS.  Would in such a case prefer something like "ZUNIX",
"UNIZ"
>or "ZUX" ;).
>

How soon we forget.  Openedition existed for MVS/ESA  4.3 and MVS/ESA 5.1
and 5.2.  It was later rename to Unix System Services under OS/390 long
before "z" hardware and z/OS were ever dreamed of as a name for 
the 64-bit hardware and OS.   What would you have called it under OS/390
to have short meaningful abbreviation?  

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

Re: USS vs USS

[Chris Mason]

Mark - who clearly hasn't cleaned the egg off yet[1]

> IBM didn't misuse it.

Wrong!

> The description of the parm used "official" (ahem) IBM terminology.

More wrong - if possible!

Yet again for those who wilfully try to present untruths:

http://www-01.ibm.com/software/globalization/terminology/u.html#x2042481

Is there some subtlety here that I - and perhaps I alone, no sorry, also John 
Eells - has missed which somehow makes this come from an unreliable set of 
web pages and we are too stupid to find the correct ones?

But thanks for the low blood pressure help anyhow!

> USS is still a convenient abbreviation for Unix System Services ...

It would be a shame to break a "hat trick" of ducks - Oh, back to the "egg" 
again!

> ... and all the current pubs are still called Unix System Services something 
or other (not z/OS Unix something or other).

And your point is ... ?

I thought I might have an idea what your point was until I checked the 
current V1R12 z/OS UNIX bookshelf - yes, I trust you noticed, "z/OS UNIX" - 
although it does differ from your "z/OS Unix" by using upper case - and, 
looking in the most general manual, the "Planning" manual, I noted that 
Chapter 1 was "Introduction to z/OS UNIX".

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB2B0/1.0

No, I really haven't the first  clue what you are talking 
about!

> Just because IBM started using z/OS unix doesn't mean every software MF 
component known to man kind is going to change their parms / keywords (for 
example, ZUXHOME for CICS SIT).

Ditto!

What's to "change"?[2] It was wrongly composed in the first place by pure 
carelessness - egged (sorry) on by misuse by the ignorant. It was careless 
because John Eells - I believe - implied that there is a formal process whereby 
developers can discover whether implied initialisms and other abbreviations 
have been taken already and careless developers may very well imagine they 
are allowed to bypass that process when they find others extensively misusing 
a particular initialism.

That's the explanation of how this particular CICS aberration happened - 
unless somebody, somebody who understands sensible software development 
procedures, has a better idea.

> BTW, ISTR a time B4 this thread when real mainframe discussions took place 
on this list.

I would have thought hammering out an understanding of software 
development procedures was a valid tangent to find room for discussion on 
IBM-MAIN - or maybe I'm just getting old, not trendy enough in this long-
haired UNIX world ...

> Let's please get back to it ASAP!

Sooner rather than later - see above.

Incidentally, it's one of the marks of an argument which finds its premises 
have become unsafe which prompts calls to evacuate the building!

> If it sounds like I'm making an argument for both sides, I'm not and yet I 
am. :-)

You also lost me here - but, unlike Peter Hunkeler, I'm obviously having a bad 
day!

-

[1] http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind1105&L=ibm-
main&T=0&F=&S=&P=9690

[2] Just - I think - to be clear, "UNIX System Services", the full title giving 
rise 
to this misused initialism, had previous incarnations which could never have 
given rise to the initialism so how could the initials have been in use before 
the title UNIX System Services" was devised - unless referring to the correct 
entity - thereby requiring a "change"?

-

Chris Mason

On Tue, 3 May 2011 14:28:54 -0500, Mark Zelden  
wrote:

>On Tue, 3 May 2011 14:54:27 -0400, Chicklon, Thomas 

>wrote:
>
>>Yeah, just when I conceded to never misuse USS, along comes IBM. IBM! In 
an
>OFFICIAL PUBLICATION! Now what are we to think? I'm just so confused now.
>>
>>Tom
>>
>
>
>(I can't even believe I'm going to add to this thread)
>
>IBM didn't misuse it.  The description of the parm used "official" (ahem)
>IBM terminology.   USS is still a convenient abbeviation for Unix System
>Services and all the current pubs are still called Unix System Services
>something or other (not z/OS Unix something or other).   Just because
>IBM started using z/OS unix doesn't mean every software MF component
>known to man kind is going to change their parms / keywords (for example,
>ZUXHOME for CICS SIT).
>
>If it sounds like I'm making an argument for both sides, I'm not and yet
>I am.  :-)
>
>There is software development, then there is marketing (like IFA vs. zAAP),
>and then there is reality.The reality is people like to use abbreviations,
>official or not.
>
>BTW, ISTR a time B4 this thread when real mainframe discussions
>took place on this list.  Let's please get back to it ASAP!
>
>Ty.   L8r.  Cya.  (Jk)
>
>Mark
>--
>Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS

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

Re: USS vs USS

[Chris Mason]

John

Actually Hursley - eventual home of CICS - has my prize for the case of a non-
native product having the most useful description of something which the 
product did not "own". There may be better instances - and if so they would 
be rare - but this one is mine.

Just to try to keep up my approach to posting in IBM-MAIN which is actually 
to back up what I say with suitable references, I found what I guess is the 
latest GDDM bookshelf and discovered that what I remembered of this 
excellence is the section "GDDM Devices" in the GDDM System Customization 
and Administration manual.

So in case anyone who might need to know happens to be reading this, if you 
want to know about 3270 mode table entries - and not just presentation 
space dimensions - this is probably even a better reference source that the 
3174 Functional Description manual!

-

Otherwise - and I fear I have to take the risk of utterly ruining Peter 
Hunkeler's day - the usual principle that, the further away you are from what 
you are describing, the less likely you are to get it right - veering towards 
actually getting it quite wrong[1]. Distance in this case being whether what 
you are describing is the product your "shop" "owns" - or - is a product to 
which you are obliged to make a reference.

And just to cover Thomas Chicklon's "Malvolio's letter", products with 
inappropriate references in their customization "names" through to mistaken 
information in their manuals are obviously created by the folk responsible for 
the products themselves and thus can be and are described as "official" 
manuals.

I've said it before and for those who seem to suffer from reading difficulties 
I'll 
say it again, the only useful documents to rely on are those which describe 
the key product itself. Although some contagion infects the manuals on the 
z/OS UNIX System Services bookshelf, mainly as a result of the "intern" or 
whoever who wrote the Health Checker up, this shelf clearly only uses the 
dread 3 initials in remarkably few fits of forgetfulness.

-

[1] This is only for deep specialists in "legacy" communication products and 
protocols.

The example that has me metaphorically at risk from nearby sharp objects is 
VTAM trying to handle an X.25 NPSI enhancement.

http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/F1A1B6A0/5.5.4.6

describes the DCODE operand of the MODEENT macro used to create mode 
table entries. The poor lambs authoring the VTAM manual have made very 
heavy weather of an X.3/X.29/X.28 topic which X.25 NPSI exploited in order 
to support an SNA character set (SCS) functions "inhibit presentation" (INP) 
and "enable presentation" (ENP) used by TSO - among programs supporting an 
LU type 1 without function management headers (3767) appearance - in order 
to prevent the exposure of secure fields such as passwords.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bald2001/3.3.6

is one description of what this is all about. It's almost by accident that 
there 
is any correspondence between this any what the poor lambs wrote!

http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/BOOKS/bald2001/APPENDIX2.2.1.6

is the reference which links the two descriptions.

Actually, even reading both these descriptions, you'd see just the thin thread 
of correspondence but you wouldn't have much of a clue what it was all about.

Since the introductory notes to this topic from my X.25 NPSI presentation 
cover sufficient of the topic to satisfy the curious - I hope - I may as well 
include them here:



Applications which support LU Type 1 without function management headers, 
may employ two SCS characters, ENP (enable presentation) and INP (inhibit 
presentation), in order to support the entry of password data.

- The INP character is designed to cause subsequent entered data *not* to 
be copied to the presentation surface of the device

- The ENP character is designed to cause subsequent entered data to be 
copied to the presentation surface of the device as usual, thus removing the 
effect of the INP character.

Prior to X.25 NPSI Versions 2 and 3, an application is expected to remove 
these characters when converting output data from SCS to the EBCDIC 
translation of the ASCII character set required by Asynchronous ASCII devices 
attached to a PAD. X.25 NPSI Versions 2 and 3 will accept these ENP and INP 
characters in the data stream from the application. "Integrated PAD" support 
removes these characters and takes action to try to ensure that any data 
entered between the receipt of an INP character and an ENP character is not 
displayed on the presentation surface of the Asynchronous ASCII device.

An application, such as TSO, can discover whether ENP and INP characters 
may be left in the data stream, and thus have the entry of passwords 
protected, if the session is started using a mode table entry which specifies 
DCODE=X'80'. The specification of the DCODE byte is passed to the 
application in control vector

Re: USS vs USS

[Rob Schramm]

Chris,

I would successfully argue that the "universally understood, accepted and
mandated expressions" is a bit wide and not at all in synch with reality.
 If it were universal, we would never be having these discussions.

Wednesday and still Cheery,
Rob Schramm

On Wed, May 4, 2011 at 2:16 PM, Chris Mason  wrote:

> Don
>
> We are not dealing with a language - that would be another campaign such as
> getting rid of the stupid misuse of "issue" or "issues" for "problem". We
> are
> dealing with explaining technical matters where there is an opportunity for
> ambiguity if we don't stick to universally understood, accepted and
> mandated
> expressions.
>
> Chris Mason
>
> On Mon, 2 May 2011 17:53:54 -0400, Don Leahy 
> wrote:
>
> >Usage gives meaning.  That's how languages evolve.  Acronyms too,
> >apparently.  ;-)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Rob Schramm
Senior Systems Engineer

w: 513.305.6224

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

Re: USS vs USS

[Chris Mason]

David

> Just sitting back, eating my popcorn on this one ...

I'd hate to disappoint you - and thanks for what I eventually discovered was 
concern for my health.

> ... Hopefully Chris doesn’t have a Chest grabber

"Chest grabber" is not an universal synonym for a heart attack but, when 
searching on "chest grabber" alone found this post before anything related 
to "heart attack" - that I noticed - appeared in the Google abstracts, I found 
the following by adding "heart attack":



Don't expect a heart attack to be a literal chest grabber. Nothing can be 
further from the truth.



Actually I rather need anger-stimulating information to enter my 
consciousness from time to time as a way to combat *low* blood pressure.

However the utterances from that stupid moron[1] (and his acolytes) who is 
the leader of the British "no shame" party as caught on BBC news broadcasts 
more than adequately fulfils that role.

As far as this topic is concerned, I simply need to bat the obstinacy back over 
the net as calmly to the ghosts. Why ghosts? Because they must be floating 
in air since they haven't a leg to stand on!

Now I'll get back to the Lotus position.

-

[1] And not what he looks like!

-

Chris Mason

On Tue, 3 May 2011 14:41:42 -0400, Jousma, David  
wrote:

>Just sittin back, eating my popcorn on this oneHopefully Chris doesn’t 
have a
>Chest grabber
>
>_
>Dave Jousma

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

Re: USS vs USS

[Chris Mason]

Frank

> Just to unnecessarily add fuel to the fire, ...

Unfortunately, this thread got established without a proper indication to the 
thread which inspired it and so your "unnecessary"[1] may or may not be 
paying homage to what I had already indicated in the title of that thread "An 
unnecessary controversy".

> ... the following is a CICS SIT parameter:

> USSHOME

> The USSHOME system initialization parameter specifies the name and path 
of the root directory for CICS® TS 4.1 files on z/OS® UNIX.

Don't you find it interesting that the dread three initials appear only in the 
parameter name - where, thanks to the famous IBM 8-character limit, space is 
at a premium but there is nary a trace in the explanatory text where z/OS - 
with a trademark symbol no less - UNIX appears?

Curious that!

Alternatively it is a good example to  anyone actually taking the trouble to 
pay 
attention rather than rattling the bars of the cage of obstinacy into which 
they have imprisoned themselves.

Incidentally, I'm not really sure which side of the cage you are on although 
you are definitely doing some rattling!

Further relevant comment is in my response to John Chase.

-

[1] Boldly to be found expressed as an adverb splitting the infinite in the 
full 
IBM tradition!

-

Chris Mason

On Tue, 3 May 2011 12:33:10 -0600, Frank Swarbrick 
 wrote:

>Just to unnecessarily add fuel to the fire, the following is a CICS SIT
>parameter:
>
>USSHOME
>The USSHOME system initialization parameter specifies the name and path
>of the root directory for CICS® TS 4.1 files on z/OS® UNIX.

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

Re: USS vs USS

[Chris Mason]

Ted

> I don't believe it's an OOPS.

In principle, you are correct. As John Eells told us in that post I quoted and 
I'm sure you will have seen, your misuse is *not* sanctioned by IBM.

If IBMers are guilty of your misuse, they are just that, guilty of misuse - but 
I 
don't expect they will be docked pay for it! One could say that each of these 
instances is an "IBM oops".

> It's a reuse.

It's an *attempted* reuse which will be sat upon whenever I discover a 
reason so to do.

> And, it's not worth all this BS.

The stone that got thrown into the pond:



Is anybody else sick of the USS argument?

IBM has used the term in many documents.

So, I tend to hold that over a few on IBM-MAIN.

Terminology evolves.



Chris Mason

On Tue, 3 May 2011 03:13:14 +, Ted MacNEIL  
wrote:

>>USS was WAY before Unix.the SNA 3270 days to be exact. So, IBM 
makes a oops, wouldnt be the first time...
>
>I don't believe it's an OOPS.
>It's a reuse.
>
>And, it's not worth all this BS.
>I shall continue to use USS to relate to z/UNIX.
>If that makes me a bad person: tough t*tty said the kitty!
>-
>Ted MacNEIL

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

Re: USS vs USS

[Chris Mason]

Scott

> ... the SNA 3270 days to be exact.

Well, not quite as exact as it might be. SNA devices supporting human end 
users - as opposed to SNA devices supporting programs - needed some 
technique for composing the three data elements needed for the SSCP 
(VTAM) to initiate a session. This applies to all such devices not just 3270 
display devices. Some of us still recall a typewriter device, the 3767. Racking 
my brains for other such devices, I managed to conjure up the fascinating 
3770 range and, of course, the 3270 emulation on the 3790 - and was there 
something similar on some of the (other) "industry" systems of the late 1970's? 
But that's all 3270 again, so doesn't count!

In addition to initiating the session, there is also the possibility to 
terminate 
the session, typically for the case where the application is misbehaving.

> So, IBM makes a oops, ...

There is *no* IBM "oops", there are only IBMers who make "oops" - in 
unofficial papers and presentations and possibly in pseudo-products such as 
the so-called "Health-Checker".

If you go to 

http://www-03.ibm.com/systems/z/os/zos/bkserv/zshelves12.html

and enter the dread three characters in the z/OS UNIX bookshelf "Search 
text" box, you will find very few "hits". Each of the ones present is an 
"oops". 
Exclusively in the Planning manual, they are down to the "graduate student" 
on some sort of "work experience" or whoever on whatever who, not knowing 
how to go about matters formally, got a lot of his or her labels wrong. The 
very few others are simple mindless "oops".

Have you marvelled at how few there are? If the use was correct, the 
manuals would be suffused with the initials!

I posted the official position twice yesterday, once in this thread but I 
guessed you missed it. If there are still some who imagine we are dealing with 
an official "oops" here, it's worth posting yet again:



> I still think that IBM should have chosen another acronym for Unix than USS. 
I believe VTAM USS table is still valid, and still used, so it is  confusing to 
me 
that IBM should use the same acronym for something that is still in use.

We did not chose "USS" as an acronym for z/OS UNIX System Services. It's 
not on the list of names people are supposed to use, and nobody in IBM 
should use this abbreviation to mean z/OS UNIX System Services. (Anyone 
from IBM who thinks differently should contact me so I can tell them why 
they're wrong.)

In reality, herding cats is easier than making absolutely sure that everyone 
uses the correct full and short names all the time in all contexts, formal and 
informal, but we keep trying.



http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0907&L=ibm-
main&T=0&F=&S=&P=198809

Chris Mason

On Mon, 2 May 2011 20:00:06 -0700, Scott Ford 
 wrote:

>USS was WAY before Unix.the SNA 3270 days to be exact. So, IBM
>Ed,

USS was WAY before Unix.the SNA 3270 days to be exact. So, IBM makes 
a oops, 
wouldnt be the first time...


Scott J Ford

From: Ed Gould 
To: IBM-MAIN@bama.ua.edu
Sent: Mon, May 2, 2011 6:36:23 PM
Subject: Re: USS vs USS

Ed:
Becareful you will start up another war. 
I think it is a problem that IBM can decide and clarify quite nicely. IBM 
should 
IMO do a 360 and say USS means unformatted system services. My rather 
poor 
memory says unformatted was in use before Unix came into general use. 
FWIW the 
UNIX people are usurping the acronym and are playing the elephant in the 
room 
here.

Ed

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

Re: USS vs USS

[Chris Mason]

Ed

I would have thought you would have understood the position from my earlier 
post.

> IBM should IMO do a 360 and say USS means unformatted system services.

IBM should stay exactly where it is, veer not one degree off course, and stick 
to the following - which I obviously have to post in full - again:



unformatted system service (USS)

A communications function that translates a character-coded command, such 
as a LOGON or LOGOFF command, into a field-formatted command for 
processing by formatted system services. See also formatted system service.

...

USS
See unformatted system service.



http://www-01.ibm.com/software/globalization/terminology/u.html#x2042481

> FWIW the UNIX people are usurping the acronym and are playing the 
elephant in the room here.

Indeed. This is where Dave Gibney's devotional exclamations should be 
appended!

Chris Mason

On Mon, 2 May 2011 15:36:23 -0700, Ed Gould  wrote:

> Ed:
> Becareful you will start up another war.
>I think it is a problem that IBM can decide and clarify quite nicely. IBM 
>should 
IMO do a 360 and say USS means unformatted system services. My rather 
poor memory says unformatted was in use before Unix came into general use. 
FWIW the UNIX people are usurping the acronym and are playing the elephant 
in the room here.
>
>Ed

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

Re: USS vs USS

[Chris Mason]

Don

We are not dealing with a language - that would be another campaign such as 
getting rid of the stupid misuse of "issue" or "issues" for "problem". We are 
dealing with explaining technical matters where there is an opportunity for 
ambiguity if we don't stick to universally understood, accepted and mandated 
expressions.

Chris Mason

On Mon, 2 May 2011 17:53:54 -0400, Don Leahy  
wrote:

>Usage gives meaning.  That's how languages evolve.  Acronyms too,
>apparently.  ;-)

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

Re: USS vs USS

[Chris Mason]

Scott

>> I would like to know which use is the most offensive to the largest number 
of people. That's the one I will start using most.

> That has to be the most sensible post 

Of course this is utter nonsense - and I hope Ed's contribution was a twisted 
joke!

Chris Mason

On Mon, 2 May 2011 17:42:16 -0400, Scott Rowe  
wrote:

>Ed,
>
>That has to be the most sensible post of this entire idiotic kerfuffle.
>
>I owe you a beer if I ever make it to SCIDS again.
>
>Scott
>
>On Mon, May 2, 2011 at 11:55 AM, Edward Jaffe
>wrote:
>
>> On 5/2/2011 8:44 AM, Ed Gould wrote:
>>
>>> I suggest a SHARE requirement to get IBM to decide once and for all of a
>>> definition for USS.
>>>
>>
>> I would like to know which use is the most offensive to the largest number
>> of people. That's the one I will start using most.
>>
>> --
>> Edward E Jaffe

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

Re: An unnecessary controversy (Was: Ported tools for z/OS on ADCD)

[Chris Mason]

Bob

> I call it USS when referring to VTAM, and Z/unix when referring to OE.

Just about quite right with two qualifications:

1. The "VTAM" reference needs to include the TN3270 server use where VTAM 
is involved only in supplying the macros from which the table used by the 
TN3270 server is built.

2. I would reverse the upper and lower case making "Z/unix" "z/UNIX".

Chris Mason

On Mon, 2 May 2011 21:40:18 +, Lester, Bob 
 wrote:

>Hi All,
>
> This seems like a Friday topic, but...
>
> I call it USS when referring to VTAM, and Z/unix when referring to OE.
>
>Thanks!
>BobL
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
Behalf Of Don Leahy
>Sent: Monday, May 02, 2011 3:36 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: An unnecessary controversy (Was: Ported tools for z/OS on 
ADCD)
>
>On Mon, May 2, 2011 at 12:22, Chris Mason  
wrote:
>
>> John
>>
>> However, as I have just mentioned to Ed Gould, it's only a "VTAM
>> message 10"
>> these days because VTAM developers were prepared to allow the IP side
>> of Communications Server to use their macros for the purposes of
>> providing a table for the TN3270 server to behave like VTAM does when
>> analysing a 3270 display user's attempts to enter the information
>> necessary to prepare an SNA session initiation request and to return
>> suitable messages when he or she made a mess of it, in general and the
>> initial message 10 apart, of course.
>>
>> > I use "z/OS UNIX" or "z/OS UNIX System Services" ...
>>
>> What about the even further compressed "zUNIX" you suggested a while 
ago?
>> Perhaps Ed Gould's initiative with SHARE could have that enshrined as
>> the approved and unambiguous abbreviation - although it did cause one
>> of the usual suspects to lose a vital part of his anatomy when last 
suggested!
>>
>> Chris Mason
>>
>> On Mon, 2 May 2011 10:56:56 -0500, McKown, John
>>  wrote:
>>
>> >Personally, I don't use USS at all. I use "z/OS UNIX" or "z/OS UNIX
>> >System
>> Services" for UNIX related posts. For CommServer, I will usually say
>> "the VTAM message 10 screen", which is what most of the VTAM related
>> USS message seem to be related to. It is much more difficult for
>> anybody, even n00bies, to be confused by that. Oh, I need to type more
>> characters. But I can afford the pain. And yes, with my arthritis, it
>> hurts to type. That's why some of my posts have misspellings and other
>> errors. Well, that and I'm lazy.
>> >
>> >--
>> >John McKown

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

Re: An unnecessary controversy (Was: Ported tools for z/OS on ADCD)

[Chris Mason]

Rex

> It would be best for everybody involved to simply make sure that their 
usage of the acronym isn't ambiguous.

In principle, I could agree. However, how do you make sure that there is no 
ambiguity when so often contributors seeking guidance have seen only the 
incorrect use and maybe never the correct use - and what they are 
discussing involves TELNET in some very often mangled form?

The devil's in the details!

Chris Mason

On Mon, 2 May 2011 15:30:39 +, Pommier, Rex R. 
 wrote:

>Steve,
>
>Not quite.  The second word, System versus SystemS.  It took me a while to 
catch that one.  :-)
>
>
>And, yes, I'm tired of the bickering back and forth.  Neither side will 
>convince 
the other that they're right/wrong.  It would be best for everybody involved 
to simply make sure that their usage of the acronym isn't ambiguous.
>
>Rex
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
Behalf Of Steve Comstock
>Sent: Monday, May 02, 2011 10:19 AM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: An unnecessary controversy (Was: Ported tools for z/OS on 
ADCD)
>
>On 5/2/2011 9:11 AM, Paul Gilmartin wrote:
>> On Mon, 2 May 2011 09:25:51 -0400, Chicklon, Thomas wrote:
>>
>>> OK, you win. USS is officially only to be used when speaking of VTAM's
>>> table thing.
>>>
>>> So, if you (and some others I'm sure) want to preserve the purity of the
>>> acronym USS, good for you. Don't misuse it. Just leave the rest of us
>>> out of it.
>>>
>> It's interesting that the link Kirk Wolf posted:
>>
>>  http://www.acronymfinder.com/USS.html
>>
>> rates the incorrect
>
>USS (Unix System Services) number six, and
>USS (Unix Systems Services) number fourteen respectively.
>
>Ummm. These are the same.
>
>
>The
>> usage correct according to the IBM Glossary doesn't even make the
>> list.  And when I filter by Information Technology, USS (Unix
>> System Services) becomes number one, and USS (Unix Systems Services)
>> becomes number two.
>
>the above are the same
>
>   Now, I suspect that AcronymFinder hasn't an
>> army of gnomes researching and consulting authorities to verify that
>> USS (Unix System Services) or USS (Unix Systems Services)
>
>the above are the same
>
>is
>> technically correct.  More likely, they have a nest of spiders that
>> crawl the Web, and whenever they find constructs such as USS (Unix
>> System Services) or USS (Unix Systems Services)
>
>the above are the same
>
>they add weight
>> to the ranking of that interpretation.
>>
>> When I want to understand an acronym, I rarely RTFM; more often
>> I simply type the acronym in a Google search box, and take
>> whatever appears in the first page of hits as conventional,
>> although possibly technically incorrect.  So Chris Mason's
>> polemics are likely counterproductive of his end: the more
>> stridently he denies that USS stands for Unix System Services, or
>> that USS stands for Unix Systems Services
>
>the above are the same
>
>, provoking followups
>> that sometimes quote him, the higher he boosts the construct he
>> detests in AcronymFinder's ratings.
>>
>> He'd more effectively further his cause of eliminating use of
>> USS (Unix System Services) and USS (Unix Systems Services)
>
>the above are the same
>
>
>if
>> he'd simply STFU.  (AcronymFinder gets that one almost right.)
>>
>> -- gil
>
>???
>
>--
>
>Kind regards,
>
>-Steve Comstock

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

Re: SV: USS vs USS

[Chris Mason]

Thomas

According to Steve Comstock, you are here on the side of the angels. But let 
us speak of it quietly! There's one contributor responding to another posts of 
Steve's where he saw something funny in the contraction from z/OS UNIX to 
zUNIX - oddly unexplained - who lost a part of his anatomy normally 
considered to be vital at this suggestion.

I think I can understand why the "ZUX" might be considered a contraction 
step too far reminding one, as it does, of the opening credits of "Getting 
Straight".

I suppose it's just an affectation to employ a lower case "z" for zUNIX".

-

Oh well, now I'd better (try to) clear up all the remaining mess!

Chris Mason

On Wed, 4 May 2011 18:33:27 +0200, Thomas Berg 
 wrote:

>FWIW, I have always considered a use of USS as a name for a UNIX system 
as ugly.
>Especially for z/OS.  Would in such a case prefer something 
like "ZUNIX", "UNIZ"
>or "ZUX" ;).
>
>
> 
>Regards,
>Thomas Berg

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

Re: TSO Profile NUM and PACK

[Farley, Peter x23353]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Shmuel Metz (Seymour J.)
> Sent: Wednesday, May 04, 2011 1:28 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: TSO Profile NUM and PACK
 
> By "intelligent use" do you mean plcing labels that have no semantic
> content? That would appear to be more awkward than sequence numbers.

On the contrary, I mean labels with significant semantic content, as 
descriptive and as long (or short) as your personal style prefers or corporate 
standards demand (and the language allows).  Perhaps my presumption of 
structured coding and appropriately parameterized 
subroutines/paragraphs/sections that don't duplicate the business function 
performed elsewhere in the code produces my point of view.

Peter
--

This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.


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

Re: How Does DFhsm and Flashcopy Work?

[George Rodriguez]

Scott,

So to paraphrase what you're saying, if I use FRBACKUP to perform the
Flashcopy then I use the DFhsm commands to backup the FRBACKUP volumes,
DFhsm will know that the backup is on flash copied backup. It that correct?
*
*
*George Rodriguez*
*Specialist II - IT Solutions*
*Application Support / Quality Assurance*
*PX - 47652*
*(561) 357-7652 (office)*
*(561) 707-3496 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-332*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Six Consecutive Years*



On Wed, May 4, 2011 at 11:55 AM, Scott Rowe  wrote:

> When you do the FlashCopy yourself like this, then HSM doesn't know that it
> is a backup of PTST00, so he doesn't look to this backup to restore a
> dataset on PTST00.  It looks to me like you should be using FRBACKUP for
> this, so that it is HSM that is doing the FlashCopy, and he knows what the
> backup really is.
>
> On Wed, May 4, 2011 at 9:47 AM, George Rodriguez <
> george.rodrig...@palmbeachschools.org> wrote:
>
> > When a Flashcopy of volumes are done and commands are sent to DFhsm to
> DUMP
> > the all the flashed volumes, how do I recover a lost dataset. I honestly
> > thought that DFhsm would know that this procedure was done and it would
> use
> > the flashed copy to recover the dataset, but when I use ISMF to either
> > HRECOVER or RESTORE the dataset it's not using the flashed copy. I'm
> going
> > to provide the JCL that I use to Flashcopy the volume(s) and the job to
> > back
> > up the volume, just in case:
> >
> > //STEP010 EXEC PGM=ADRDSSU
> > //SYSPRINT  DD SYSOUT=*
> > //SYSIN DD *
> >  COPY FULL INDY(PTST00) OUTDY(XTST00) FCNOCOPY PURGE DUMPCONDITIONING
> >  .
> >  .
> >
> > Here's the backup job:
> >
> > //STEP010 EXEC PGM=IKJEFT01
> > //SYSPRINT  DD SYSOUT=X
> > //SYSTSPRT  DD SYSOUT=X
> > //SYSTSIN   DD *
> >  HSENDCMD BACKVOL VOL(XTST00) DUMP(DUMPCLASS(DAILYDR))
> >  .
> >  .
> >
> > Thanks for the help.
> > *
> > *
> > *George Rodriguez*
> > *Specialist II - IT Solutions*
> > *Application Support / Quality Assurance*
> > *PX - 47652*
> > *(561) 357-7652 (office)*
> > *(561) 707-3496 (mobile)*
> > *School District of Palm Beach County*
> > *3348 Forest Hill Blvd.*
> > *Room B-332*
> > *West Palm Beach, FL. 33406-5869*
> > *Florida's Only A-Rated Urban District For Six Consecutive Years*
> >
> > Home of Florida's first LEED Gold Certified School
> >
> > Under Florida law, e-mail addresses are public records. If you do not
> want
> > your e-mail address
> > released in response to a public records request, do not send electronic
> > mail to this entity.
> > Instead, contact this office by phone or in writing.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
>
> CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
> confidential and privileged information intended only for the addressee.
> If you are not the intended recipient, please be advised that you have
> received this material in error and that any forwarding, copying, printing,
> distribution, use or disclosure of the material is strictly prohibited.
> If you have received this material in error, please (i) do not read it,
> (ii) reply to the sender that you received the message in error, and
> (iii) erase or destroy the material. Emails are not secure and can be
> intercepted, amended, lost or destroyed, or contain viruses. You are deemed
> to have accepted these risks if you communicate with us by email. Thank
> you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

Home of Florida's first LEED Gold Certified School

Under Florida law, e-mail addresses are public records. If you do not want your 
e-mail address
released in response to a public records request, do not send electronic mail 
to this entity. 
Instead, contact this office by phone or in writing.

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

Re: TSO Profile NUM and PACK

[Shmuel Metz (Seymour J.)]

In
<985915eee6984740ae93f8495c624c6c21d230c...@jscpcwexmaa1.bsg.ad.adp.com>,
on 05/04/2011
   at 09:07 AM, "Farley, Peter x23353" 
said:

>I disagree.  The existence and intelligent use of labeled blocks of
>code (paragraphs and sections in COBOL, Procedures in PL/1, labels
>and sometimes separate CSECT/RSECT's in assembler) are what provide
>the tag to which you may direct a person or a computer's attention.

By "intelligent use" do you mean plcing labels that have no semantic
content? That would appear to be more awkward than sequence numbers.

>I think everyone here does (or should) already know that,

I question "does", but agree with "should", although I could make a
case[1] that both cvs and svn are obsolete. However, I can resist
anything except a good pun.

[1] In some Linux forum, not here.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: TSO Profile NUM and PACK

[Farley, Peter x23353]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Tom Marchant
> Sent: Wednesday, May 04, 2011 9:57 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: TSO Profile NUM and PACK
> 
> On Wed, 4 May 2011 09:07:15 -0400, Farley, Peter wrote:
> 
> >The first thing I do these days when editing a program for maintenance
> >is "UNNUM".  I edit on TN3270E 50x132 almost all the time, and I find
> >that the visual clutter of sequence numbers is far too visually
> confusing.
> 
> I use a wide display too.  With NUMBER ON, the sequence numbers are
> not displayed.  If you are editing a data set with NUMBER OFF the
> sequence numbers are not maintained.

I had not noticed that, since I always edit with NUMBER OFF.  Well, I still 
prefer no line numbers, YMMV.  I certainly don't advocate people changing to 
suit my tastes.

Peter
--

This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.


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

Re: TSO Profile NUM and PACK

[Veilleux, Jon L]

AHHH, speak French to me Tish.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Wednesday, May 04, 2011 1:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: TSO Profile NUM and PACK

In , on 05/03/2011
   at 06:05 PM, Paul Gilmartin  said:

>CDC did this, sort of.

Il va sans dire ;-)

At least in the systems that I saw on th 6400; I'm not sure what they used on 
the 3600.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

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

Re: TSO Profile NUM and PACK

[Shmuel Metz (Seymour J.)]

In , on 05/04/2011
   at 08:57 AM, Tom Marchant  said:

>I use a wide display too.  With NUMBER ON, the sequence numbers are 
>not displayed. 

?

Are you perhaps thinking of BROWSE? EDIT and VIEW displayed sequence
numbers when the screen width was 132 or 160.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: TSO Profile NUM and PACK

[Shmuel Metz (Seymour J.)]

In , on 05/03/2011
   at 06:05 PM, Paul Gilmartin  said:

>CDC did this, sort of.

Il va sans dire ;-)

At least in the systems that I saw on th 6400; I'm not sure what they
used on the 3600.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: SMPPTS run out of Space (another approach)

[Shmuel Metz (Seymour J.)]

In <4dc13f61.4090...@bremultibank.com.pl>, on 05/04/2011
   at 01:58 PM, "R.S."  said:

>3. Last, but not least: sometimes ACCEPT is simply required.
>Sometimes a product reads from DLIB libraries.

Normally that's from a macro library and including MTS in SYSLIB takes
care of it.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: "Under z/OS Unix"

[Shmuel Metz (Seymour J.)]

In
,
on 05/04/2011
   at 10:08 AM, "Hunkeler Peter (KIUP 4)"
 said:

>The OMVS TSO command processor had its rights in the nineties; it is
>obsolete today. Its a PITA. People having a need to work with UNIx 
>shells interactively should use SSH/rlogin(/telnet) to login.

The OMVS TSO command is still a convenience for people primarily using
foreground TSO. A separate telnet session is not always convenient,
and in some cases[1] not even possible.

[1] I consider the restriction misguided, but it exists at some shops.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: "Under z/OS Unix"

[Shmuel Metz (Seymour J.)]

In , on 05/03/2011
   at 10:10 AM, Mark Zelden  said:

>But I think your last part I quoted is probably closer.   People
>don't say "under USS" when they use FTP or Telnet for example,

Which people? I certainly consider FTP and telnet in z/OS to be Unix
services.

Where it gets stickier is an application that is native MVS except for
using the TCP/IP protocol stack.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

SV: USS vs USS

[Thomas Berg]

FWIW, I have always considered a use of USS as a name for a UNIX system as 
ugly. 
Especially for z/OS.  Would in such a case prefer something like "ZUNIX", 
"UNIZ" 
or "ZUX" ;).


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

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

Re: Using EMC Clariion SCSI disk with Linux

[Mark Post]

>>> On 5/2/2011 at 08:46 AM, "Crabtree, Anne D"  wrote: 
> In z/VM, the chips appear fine, defined as FCP with devices attached and 
> FREE.  I'm not sure what else I can do from the mainframe side to help the 
> situation?  HELP!

Have you tried attaching a device number to one of the Linux guests and having 
it bring the HBA online?


Mark Post

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

Re: How Does DFhsm and Flashcopy Work?

[Scott Rowe]

When you do the FlashCopy yourself like this, then HSM doesn't know that it
is a backup of PTST00, so he doesn't look to this backup to restore a
dataset on PTST00.  It looks to me like you should be using FRBACKUP for
this, so that it is HSM that is doing the FlashCopy, and he knows what the
backup really is.

On Wed, May 4, 2011 at 9:47 AM, George Rodriguez <
george.rodrig...@palmbeachschools.org> wrote:

> When a Flashcopy of volumes are done and commands are sent to DFhsm to DUMP
> the all the flashed volumes, how do I recover a lost dataset. I honestly
> thought that DFhsm would know that this procedure was done and it would use
> the flashed copy to recover the dataset, but when I use ISMF to either
> HRECOVER or RESTORE the dataset it's not using the flashed copy. I'm going
> to provide the JCL that I use to Flashcopy the volume(s) and the job to
> back
> up the volume, just in case:
>
> //STEP010 EXEC PGM=ADRDSSU
> //SYSPRINT  DD SYSOUT=*
> //SYSIN DD *
>  COPY FULL INDY(PTST00) OUTDY(XTST00) FCNOCOPY PURGE DUMPCONDITIONING
>  .
>  .
>
> Here's the backup job:
>
> //STEP010 EXEC PGM=IKJEFT01
> //SYSPRINT  DD SYSOUT=X
> //SYSTSPRT  DD SYSOUT=X
> //SYSTSIN   DD *
>  HSENDCMD BACKVOL VOL(XTST00) DUMP(DUMPCLASS(DAILYDR))
>  .
>  .
>
> Thanks for the help.
> *
> *
> *George Rodriguez*
> *Specialist II - IT Solutions*
> *Application Support / Quality Assurance*
> *PX - 47652*
> *(561) 357-7652 (office)*
> *(561) 707-3496 (mobile)*
> *School District of Palm Beach County*
> *3348 Forest Hill Blvd.*
> *Room B-332*
> *West Palm Beach, FL. 33406-5869*
> *Florida's Only A-Rated Urban District For Six Consecutive Years*
>
> Home of Florida's first LEED Gold Certified School
>
> Under Florida law, e-mail addresses are public records. If you do not want
> your e-mail address
> released in response to a public records request, do not send electronic
> mail to this entity.
> Instead, contact this office by phone or in writing.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
confidential and privileged information intended only for the addressee.
If you are not the intended recipient, please be advised that you have
received this material in error and that any forwarding, copying, printing,
distribution, use or disclosure of the material is strictly prohibited.
If you have received this material in error, please (i) do not read it,
(ii) reply to the sender that you received the message in error, and
(iii) erase or destroy the material. Emails are not secure and can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by email. Thank you.

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

Re: Problem with LPA=xx on IEASYSxx

[Rob Schramm]

It can be a bit much to go thru.. but it also is a powerful record of what
has been setup and what JCL is run... which is helpful when dealing with
goofy problems that seem to be doing their best to hide.

Rob Schramm

On Wed, May 4, 2011 at 11:22 AM, Richard L Peurifoy  wrote:

> On 5/4/2011 8:52 AM, Rob Schramm wrote:
>
>> If you specify the ",L" at the end most of the parms have a list option.
>>  At
>> least it will give you a record in syslog of what you chose.
>>
>
> You might not want to do this on the MSTRJCL parm, IIRC it will cause
> the JCL and messages for all started tasks to be written to the log,
> not just the MSTR JCL. Otherwise, I specify this on most parms that
> support it.
>
> --
> Richard
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Rob Schramm
Senior Systems Engineer

w: 513.305.6224

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

Re: SYSEVENT QVS question

[Mike Schwab]

On Wed, May 4, 2011 at 9:17 AM, Steve Austin  wrote:
> Hello,
>
> Does anyone have an explanation of why this service returns different
> capacity figures for the partition if z/OS is running under VM from when
> running natively.
>
> Thanks
>
> Steve
The overhead of running z/VM under a z/OS system.

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

Re: TSO Profile NUM and PACK

[Mike Schwab]

On Wed, May 4, 2011 at 8:57 AM, Tom Marchant  wrote:
> On Wed, 4 May 2011 09:07:15 -0400, Farley, Peter wrote:
>
>>The first thing I do these days when editing a program for maintenance
>>is "UNNUM".  I edit on TN3270E 50x132 almost all the time, and I find
>>that the visual clutter of sequence numbers is far too visually confusing.
>
> I use a wide display too.  With NUMBER ON, the sequence numbers are
> not displayed.  If you are editing a data set with NUMBER OFF the
> sequence numbers are not maintained.
>
> --
> Tom Marchant
I set a tab mask to hide the sequence numbers if I scroll right or use
a Mod 5 screen.

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

Re: Problem with LPA=xx on IEASYSxx

[Richard L Peurifoy]

On 5/4/2011 8:52 AM, Rob Schramm wrote:

If you specify the ",L" at the end most of the parms have a list option.  At
least it will give you a record in syslog of what you chose.


You might not want to do this on the MSTRJCL parm, IIRC it will cause
the JCL and messages for all started tasks to be written to the log,
not just the MSTR JCL. Otherwise, I specify this on most parms that
support it.

--
Richard

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

Re: "Under z/OS Unix"

[Kirk Wolf]

Peter,

Thanks for your earlier info and corrections.

But everyone, PLEASE resist more discussions of the TLA on this thread.

Re: BPXOINIT - do you find it surprising that in z/OS Unix that all
processes don't inherit from pid=1 ?   This is a PITA, since the
environment variables established by BPXINIT will not be set in, say,
a batch job that gets dubbed.   How many places should, say, TZ
settings be maintained?   How should vendor applications that use z/OS
Unix services get the installation defined environment variables?

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, May 4, 2011 at 10:14 AM, Hunkeler Peter (KIUP 4)
 wrote:
>>FWIW, IBM publications now use the current terminology:  "z/OS UNIX
>>System Services (z/OS UNIX)".  This is not a discussion of the
>>commonly used yet disputed TLA.  Please.
>
> Go to the z/OS V1.12 doc site and do a search on "USS" over all books
> (some 370+), be surprised and be amused.
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/EZ2ZBK0K
>
> A great one from the Communication Server's bookshelf (watch the wrap):
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1c8a0/11.3
> 42?ACTION=MATCHES&REQUEST=USS&TYPE=FUZZY&SHELF=EZ2ZBK0K.bks&DT=201006010
> 44843&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RAN
> K&ScrollTOP=FIRSTHIT#FIRSTHIT
>
>
> --
> Peter Hunkeler
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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

Re: Do we need to implement HSM

[Mike Schwab]

You could implement the Small Dataset packing (small migrated datasets
stored in a vsam file) and compress to disk the larger migrated
datasets.  This would reduce your utilization but would require some
dedicated volumes.

On Wed, May 4, 2011 at 8:38 AM, Paul Gilmartin  wrote:
> On Wed, 4 May 2011 17:45:01 +0800, ibmnew wrote:
>>
>>   In our shop we don't have any tapelib.
>>
>> Do you need to implement HSM ?
>>
> In fact, IBM early proposed HSM as an alternative to tape
> libraries, asserting that careful configuration of HSM should
> reduce mount traffic to a point that manual mounts would be
> sufficient.
>
> Of course, this was at a time when IBM was not marketing tape
> libraries and IBM's competitors were.
>
> -- gil
-- 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Editing Unicode Files in z/OS

[Mike Schwab]

You could give http://gccmvs.sourceforge.net/ a shot.

On Wed, May 4, 2011 at 8:33 AM, Paul Gilmartin  wrote:
> On Wed, 4 May 2011 15:46:53 +0800, Timothy Sipples wrote:
>>
>>The former, for the most part. But the latter is also interesting. Speaking
>>of which, has anyone tried to compile the "mined" editor for z/OS UNIX
>>System Services? That particular editor claims to be a stand-out for
>>Unicode support on Linux/UNIX.
>>
> That sort of thing would be far easier if IBM extended the C/C++
> Enhanced ASCII support to include runtime libraries for X11
> (and perhaps Curses).
>
> Hmmm.  We've dropped the license for IBM's C/C++ compiler (the
> project motivating them was abandoned).  Should I look at gcc
> native or Dignus cross-platform.  Does either have an ASCII
> mode?
>
> -- gil
>
-- 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: "Under z/OS Unix"

[Hunkeler Peter (KIUP 4)]

>FWIW, IBM publications now use the current terminology:  "z/OS UNIX
>System Services (z/OS UNIX)".  This is not a discussion of the
>commonly used yet disputed TLA.  Please.

Go to the z/OS V1.12 doc site and do a search on "USS" over all books
(some 370+), be surprised and be amused.
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/EZ2ZBK0K

A great one from the Communication Server's bookshelf (watch the wrap):
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1c8a0/11.3
42?ACTION=MATCHES&REQUEST=USS&TYPE=FUZZY&SHELF=EZ2ZBK0K.bks&DT=201006010
44843&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RAN
K&ScrollTOP=FIRSTHIT#FIRSTHIT


--
Peter Hunkeler

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

Re: Editing Unicode Files in z/OS?

[Jim Heifetz]

I would like to edit such files with ISPF, if it had a the ability to do so.
 The only tools that I have to edit Unicode files are Windows tools -
NOTEPAD and WORDPAD.  I can access almost any z/OS Unix file from Windows
because DFS is sharing them.  

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

SYSEVENT QVS question

[Steve Austin]

Hello,

Does anyone have an explanation of why this service returns different
capacity figures for the partition if z/OS is running under VM from when
running natively.

Thanks

Steve

The following is taken from the z/OS V1R9.0 MVS Authorized Assembler
Services Reference 

QvsCecCapacity, QvsImgCapacity, and QvsVmCapacity contain the maximum
service rate that theoretically could be achieved at each level. The
value is in millions of service units per hour (MSU).

QvsCecCapacity is equal to the individual CPU speed multiplied by the
number of online and offline physical CPUs.

If QvsImgValid is on, the image is in ESAME mode, and QvsVmValid is off,
then QvsImgCapacity is equal to one of the following:

*   The partition's defined capacity set via the Hardware Management
Console, if any
*   The individual CPU speed multiplied by the number of online and
offline logical CPUs, if the partition is uncapped and has no defined
capacity
*   The capacity at the partition's weight, if the partition is
capped via the Hardware Management Console.

If QvsImgValid is on, and either the image is in ESA/390 mode or
QvsVmValid is on, then QvsImgCapacity is equal to the individual CPU
speed multiplied by the number of online and offline logical CPUs.

QvsVmCapacity is the individual CPU speed multiplied by the number of
online and offline virtual CPUs.

In all cases, the individual CPU speed in based on the MP factor for the
number of online and offline physical CPUs.


- 
This email has been scanned for all known viruses by the MessageLabs Email
Security Service and the Macro 4 internal virus protection system.
. 
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: TSO Profile NUM and PACK

[Tom Marchant]

On Wed, 4 May 2011 09:07:15 -0400, Farley, Peter wrote:

>The first thing I do these days when editing a program for maintenance 
>is "UNNUM".  I edit on TN3270E 50x132 almost all the time, and I find 
>that the visual clutter of sequence numbers is far too visually confusing.

I use a wide display too.  With NUMBER ON, the sequence numbers are 
not displayed.  If you are editing a data set with NUMBER OFF the 
sequence numbers are not maintained.

-- 
Tom Marchant

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

How Does DFhsm and Flashcopy Work?

[George Rodriguez]

When a Flashcopy of volumes are done and commands are sent to DFhsm to DUMP
the all the flashed volumes, how do I recover a lost dataset. I honestly
thought that DFhsm would know that this procedure was done and it would use
the flashed copy to recover the dataset, but when I use ISMF to either
HRECOVER or RESTORE the dataset it's not using the flashed copy. I'm going
to provide the JCL that I use to Flashcopy the volume(s) and the job to back
up the volume, just in case:

//STEP010 EXEC PGM=ADRDSSU
//SYSPRINT  DD SYSOUT=*
//SYSIN DD *
 COPY FULL INDY(PTST00) OUTDY(XTST00) FCNOCOPY PURGE DUMPCONDITIONING
 .
 .

Here's the backup job:

//STEP010 EXEC PGM=IKJEFT01
//SYSPRINT  DD SYSOUT=X
//SYSTSPRT  DD SYSOUT=X
//SYSTSIN   DD *
 HSENDCMD BACKVOL VOL(XTST00) DUMP(DUMPCLASS(DAILYDR))
 .
 .

Thanks for the help.
*
*
*George Rodriguez*
*Specialist II - IT Solutions*
*Application Support / Quality Assurance*
*PX - 47652*
*(561) 357-7652 (office)*
*(561) 707-3496 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-332*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Six Consecutive Years*

Home of Florida's first LEED Gold Certified School

Under Florida law, e-mail addresses are public records. If you do not want your 
e-mail address
released in response to a public records request, do not send electronic mail 
to this entity. 
Instead, contact this office by phone or in writing.

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

Re: Problem with LPA=xx on IEASYSxx

[Rob Schramm]

If you specify the ",L" at the end most of the parms have a list option.  At
least it will give you a record in syslog of what you chose.

Rob Schramm

On Wed, May 4, 2011 at 9:44 AM, Casey Rhodes  wrote:

> The D IPLINFO,LPA and others is great but it would be even better if
> that was something you could use to display all settings at once with
> an ALL option or *.
>
> This will keep me from chasing the chain from LOADXX to parmlib to
> IEASYSXX all the time. Thanks for the information.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Rob Schramm
Senior Systems Engineer

w: 513.305.6224

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

Re: Problem with LPA=xx on IEASYSxx

[Casey Rhodes]

The D IPLINFO,LPA and others is great but it would be even better if 
that was something you could use to display all settings at once with 
an ALL option or *. 

This will keep me from chasing the chain from LOADXX to parmlib to 
IEASYSXX all the time. Thanks for the information. 

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

Re: Do we need to implement HSM

[Paul Gilmartin]

On Wed, 4 May 2011 17:45:01 +0800, ibmnew wrote:
>
>   In our shop we don't have any tapelib.
>
> Do you need to implement HSM ?
>
In fact, IBM early proposed HSM as an alternative to tape
libraries, asserting that careful configuration of HSM should
reduce mount traffic to a point that manual mounts would be
sufficient.

Of course, this was at a time when IBM was not marketing tape
libraries and IBM's competitors were.

-- gil

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

Re: Editing Unicode Files in z/OS

[Paul Gilmartin]

On Wed, 4 May 2011 15:46:53 +0800, Timothy Sipples wrote:
>
>The former, for the most part. But the latter is also interesting. Speaking
>of which, has anyone tried to compile the "mined" editor for z/OS UNIX
>System Services? That particular editor claims to be a stand-out for
>Unicode support on Linux/UNIX.
>
That sort of thing would be far easier if IBM extended the C/C++
Enhanced ASCII support to include runtime libraries for X11
(and perhaps Curses).

Hmmm.  We've dropped the license for IBM's C/C++ compiler (the
project motivating them was abandoned).  Should I look at gcc
native or Dignus cross-platform.  Does either have an ASCII
mode?

-- gil

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

New website for jobs and Educational materials

[Hylton Tom P]

An IBM instructor recently passed on this link on another list, and it
seemed appropriate to pass on here for those with interest.   

http://systemzjobs.com

According to him,  it's sponsored by IBM but run by someone else.

It looks like it's primary purpose is a job board specifically for
mainframe types, so may be useful for those seeking and those hiring.
It also has links to IBM educational materials, colleges that teach
mainframe studies, and the IBM academic initiatives. 


tom  

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

Re: TSO Profile NUM and PACK

[Farley, Peter x23353]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Shmuel Metz (Seymour J.)
> Sent: Tuesday, May 03, 2011 11:34 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: TSO Profile NUM and PACK
 
> Sequence numbers provide convenient tags for referring to blocks of
> code. Withing a single edit session that isn't too important, but when
> you add in compilers, human readers, etc. it acquires more importance.
> The goo gets blinding when there are multiple occurrences[1] of the
> same block and you want to direct someone's attention to one of them.

I disagree.  The existence and intelligent use of labeled blocks of code 
(paragraphs and sections in COBOL, Procedures in PL/1, labels and sometimes 
separate CSECT/RSECT's in assembler) are what provide the tag to which you may 
direct a person or a computer's attention.

The first thing I do these days when editing a program for maintenance is 
"UNNUM".  I edit on TN3270E 50x132 almost all the time, and I find that the 
visual clutter of sequence numbers is far too visually confusing.
 
> [1] That sort of thing can cause problems reconciling independent
> changes when using something like cvs[2].

Again, I disagree.  Labels and intelligent, maintainable code structure are 
what prevent such problems.
 
> [2] Not a pharmacy.

I think everyone here does (or should) already know that, but it was worth a 
small chuckle.

Peter
--
This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.


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

Re: Problem with LPA=xx on IEASYSxx

[Peter Relson]

All of the responses have been right on target.

A few additional notes

As of z/OS 1.12, you can issue DISPLAY IPLINFO,sysparm and it will show 
you the value that was used for that system parameter. For example, 
DISPLAY IPLINFO,LPA
might show
IEE255I SYSTEM PARAMETER 'LPA': 00

The LPALST data set list is displayed only if you have requested it via 
",L" in the specification  -- 
LPA=(x1,...,xn,L)
But you can see which LPALSTxx members were processed.

Missing a continuation comma on an earlier line of IEASYSxx, as was 
mentioned, is a frequent error.
IPLing without CLPA when you change the LPALST, as was mentioned, is also 
a problem.

Peter Relson
z/OS Core Technology Design

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

Re: SMPPTS run out of Space (another approach)

[R.S.]

W dniu 2011-04-30 06:47, Linda Mooney pisze:

As can be seen from the replies, there are different approaches for handling 
the PTS.  In my shop, when a z/OS release is installed, the PTS is placed on a 
volume where it will have plenty of room.  For the life of the install, PTFs 
are not purged from the PTS - ever.  If necessary, spill PTS datasets are 
defined.  We are not a large shop, and this works for us.



For ACCEPT, we generally run the ACCEPT of previous service just before 
beginning the next maintenance cycle.


1. Size of the shop is loosely related to the size of PTS. I would say 
more: in a large shop there's more chance to get additional disk space 
for PTS.


2. People consider ACCEPT process as dangerous, they are reluctant to do 
ACCEPT. What about APPLY? There are PTFs which cannot be simply RESTOREd 
(HOLDSYS DELETE) and the RESTORE itself is cumbersome. IMHO the best way 
to move back is to have copy of system volumes (including RES, DLIB and 
SMPE). In such scenario there is no big thing to ACCEPT older PTFs.


3. Last, but not least: sometimes ACCEPT is simply required.
Sometimes a product reads from DLIB libraries. IMHO it's plain wrong, 
but it happens. Someone mentioned IMS as such product, I vaguely 
remember something else.
Another example: fmid H09F210, COBOL and CICS Command Level Conversion 
Aid (CCCA). It is distributed with error in SMP/E description (wrong 
RMID). Recommended solution includes ACCEPT.


--
Radoslaw Skorupka
Lodz, Poland


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2011 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.346.696 złotych.


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

Re: Do we need to implement HSM

[Lizette Koehler]

> 
>In our shop we don't have any tapelib.
> 
>  Do you need to implement HSM ?
> 
> Any suggestions is greatly appreciated!
>

Jason,  I think the answer will be "it depends'.

First DFSMShsm does not have to have tape.  I have seen shops run DFSMShsm
with only dasd.  

But, what is your shop's requirements for backup/recovery/space management.

You need to evaluate your shops needs against the product.  Then you need to
decide 
1)  How do I recover a file or a volume?
2)  How do I manage space on a pack/pool?
3)  What do I need to do for disaster recovery
4)  What is the effort involved?
5)  Is it going to provide an easily supported solution?
6)  Do I already have other products that can provide the functions of
DFSMShsm? (CA has CA-DISK CA-ALLOCATE, etc)


Each shop is unique.  I think you have to research DFSMShsm and its
capabilities and determine if it fits your shops environment.

I could not tell you if you need to implement DFSMShsm or not.  That would
be something your environmental requirements would decide.


HTH

Lizette

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

AD: Best of IMS Java Workshops in Germany Cologne May 17th and Munich May 19th

[D Gaebler]

Hi,

we still have a little bit of room for both workshops.
It will basically be a rerun of the Best of IMS Java workshop run as part 
of the AD Days in Ehningen.

That differs from the agenda posted on the IBM web page:
See the description for Track 6: 
http://www-05.ibm.com/de/events/ad/index3.html

Basically after 1,5 hours of presentation you can pick and choose your 
lab(s) of choice:
1. Open Database with IMS Java.
2. COBOL/Java Interoperability in IMS (COBOL calls Java with Persistent 
JVM feature and Java calls COBOL in IMS Java Dependend Regions).
3. Try IMS XML DB functionality.
4. Using the Hibernate Framework with the IMS Open Database Drivers and a 
sample IMS DB.

Enrollments here:
http://www-05.ibm.com/de/events/fromzerotozhero/imsjava/anmeldung.html

Thanks.

PS: Please note that these workshops can also scheduled on request at your 
companies site. Depending on the needs IBM can bring Laptops and 3G 
Routers if Security does not permit the use of local PCs or Networks.
The Labs use IBMs Democenter z/OS systems, that are globally available.

regards
D. Gäbler.

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

Re: SMPPTS run out of Space (another approach)

[R.S.]

W dniu 2011-04-29 16:45, Mark Zelden pisze:
[...]

I should tell you to RTFM, but I like you.  :-)

It means to "consider all the specified zones when doing the REJECT" - so it
is an "AND" condition.   If only one zone was specified, it would only look
at that one zone and could delete a PTF from the global zone that was not
yet accepted into the other DLIB zone(s) being maintained.


Mark,
I like you too ;-)
Thank you for the explanation.
In fact I read the manual but I wasn't sure about the above. I don't 
want say the manual is "fine" - RTfM ;-), my point is the manual does 
not accept any question. Or at least no answer can be expected. ;-)


Regards
--
Radoslaw Skorupka
Lodz, Poland


--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych.


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

PHP modules..

[Rafal Hanzel]

Hi all ...

Are there any extensions modules for PHP for z/OS ?
We would like to use socket_create()function, so we need php_sockets.so
Is it possible to get this module ?
 ... or maybe some other possibilities ?

TIA

--
Pozdrawiam/Best regards,

Rafał Hanzel
Programista systemowy, Dział Badań i Rozwoju Systemów Komputerowych
Tel. +48 32 3589246, Fax +48 32 3589277, email: hanz...@zetokatowice.pl
Tel. kom. +48 501677656
Zakład Elektronicznej Techniki Obliczeniowej w Katowicach Spółka z o.o.
40-158 Katowice, ul. Owocowa 1
Sąd Rejonowy Katowice - Wschód w Katowicach Wydział VIII Gospodarczy Krajowego 
Rejestru Sądowego, KRS 051477
Kapitał zakładowy: 264500 zł
NIP 634-013-11-06
http://www.zetokatowice.pl

Jesteśmy uczestnikiem Programu
RZETELNA Firma
Sprawdź naszą rzetelność na
http://www.rzetelnafirma.pl/8FGKEVFH

Treść tej informacji może być poufna, w związku z czym powinna trafić 
bezpośrednio do rąk adresata. Jakiekolwiek jej ujawnianie, rozpowszechnianie, 
bądź kopiowanie jest zabronione. W przypadku omyłkowego otrzymania niniejszej 
informacji prosimy o poinformowanie nadawcy i usunięcie jej z komputera.



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

Do we need to implement HSM

[ibmnew]

Dear all 

   In our shop we don't have any tapelib.

 Do you need to implement HSM ?

Any suggestions is greatly appreciated!

Thanks a lot!

Jason Cai 

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

Re: Hercules, friend or foe?

[R.S.]

W dniu 2011-04-29 17:14, Mike Schwab pisze:
[...]

As long as you work at a shop with a licensed z/OS, you do have the
right to test on a box of your choice, or for DR testing.


Playing with z/OS or learning it is not DR testing.
I wish there would be free z/OS for hobbyist use, but currently the 
above is license violation.



--
Radoslaw Skorupka
Lodz, Poland


--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych.


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

Re: USS vs USS

[Hunkeler Peter (KIUP 4)]

>parameter:
>
>USSHOME
>The USSHOME system initialization parameter specifies the name and path
>of the root directory for CICS(r) TS 4.1 files on z/OS(r) UNIX. 

Ha, ha, ha.ROTFL. you made my day!

--
Peter Hunkeler

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

Re: "Under z/OS Unix"

[Hunkeler Peter (KIUP 4)]

Some thoughts and comments from my side. More may follow. 

>2) Lower level APIs  (assembler or other HLLs)
>These are used to implement (1).
>Just about any program  / job can call these or (1), and the first
>time it does it gets "dubbed" (8) with a z/OS Unix PID and can use 
>the kernel (below)

By calling (2), programs are in fact calling the kernel. The kernel may
then recognize that the unit of work (TCB or SRB, "task" for short
hereafter)
has not yet been "authorized" to use its services. If so, the kernel
will
see if the task can become an authorized user, i.e. does the userid the
task is running under have UNIX credentials (uid/gid). If it has, then
the task is said as being "dubbed" (which involves creation of some
control blocks, an possibly more).


>3) The "Kernel" Address space (BPXOINIT?)
>Common services for (1), (2)

System address space "OMVS" is the kernel. "BPXOINIT" is the so 
called init process. The former provides the services the latter 
is the process with PID=1, becoming parent of all orphaned 
processes.

>5) z/OS Unix "command" binaries
>Program binder objects that are stored in (or linked to by) a file
>in the zFS or HFS filesystem (4).
>Unix command binaries can be invoked by BPXBATCH/COZBATCH (see
>10), or via fork()/spawn() APIs in (1) or (2), or more commonly by 
>a shell (see 6).

You can sometimes read a distinction between "commands" and "utilities".
The former is then referring to the shell built in commands and the 
latter is referring to the standalone binaries. Mostly this distinction
is not of importance but sometimes it may well be.

UNIX binaries (the binder objects) may also be stored in a PDSE and then
called via EXEC PGM= directly. If there is a corresponding entry in the
file system (external link or null file with sticky bit set), then these
binaries may also be called from a shell command line (or any of the
other
means you listed). 


>6) The Unix  "shell" program (/bin/sh, and example of (5)
>[snip]
>The shell can be run interactively, under TSO OMVS (see 10), 
>[snip]

I'd prefer "The shell can be run interactively, via TSO OMVS..."
It sufficient that tasks run "under z/OS UNIX" :-)


>7) BPXAS initiator and its "forked" / (non locally) "spawned" address 
>   spaces.
>Typically associated with the z/OS Unix shell (6) and Unix
>"commands" (5), but not necessarily so.

Better: "BPXAS initiator and its "forked" / (non locally) "spawned" 
 *processes*.
BPXAS *is* the address space where forked()/spawned() processes run.


>8) A z/OS job that is "dubbed" (has issued a service (1) or (2) and
>   has a Unix PID.
>This doesn't preclude it from accessing other resources, like
>traditional z/OS Datasets, etc.

You may add obtaining and freeing storage. There is no separate
storage management for z/OS UNIX, its all done by the single
VSM/RSM/ASM.
You may add workload management. There are no separate work unit queues,
"undubbed" TCBs/SRBs are on the same queues as "dubbed" ones. Etc, etc.

>- The "OMVS" TSO command is also contributory to the "Under z/OS
>UNIX" problem - it allows you to run a shell under TSO, but it is not
>integrated well with ISPF (IMO).

The OMVS TSO command processor had its rights in the nineties; it is
obsolete today. Its a PITA. People having a need to work with UNIx 
shells interactively should use SSH/rlogin(/telnet) to login.

>So, when people say "Under z/OS UNIX" ( or "Under USS"), which of
>these do they mean?

No offence intended: They probably don't know :-)


--
Peter Hunkeler

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

Re: Editing Unicode Files in z/OS

[Timothy Sipples]

Tony asks:
>Are you asking what people are currently using, or what they
>might like to see?

The former, for the most part. But the latter is also interesting. Speaking
of which, has anyone tried to compile the "mined" editor for z/OS UNIX
System Services? That particular editor claims to be a stand-out for
Unicode support on Linux/UNIX.

Rob Schramm writes:
>I had been using Putty connecting via openssh, tagging the file,
>setting the _BPXK_AUTOCVT=ON and editing with vi for quick edits.

Yes, that's one method that seems to work well. There's some more
information here:

http://dovetail.com/docs/misc/editascii.html

- - - - -
Timothy Sipples
Resident Enterprise Architect
Value Creation & Complex Deals Team
IBM Growth Markets (Based in Singapore)
E-Mail: timothy.sipp...@us.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Add'l Volume Amount

[Gonzalo Cengotita]

You are right, I didn't notice before, it only applies for VSAM.
Then the limit is 255 extents per component, and you can remove this limit
using the  "Extent constraint removal" (put a value of  "YES" in it)




On Wed, May 4, 2011 at 4:15 AM, ibmnew  wrote:

>
> Dear
>
>
>
> Add'l Volume Amount, This  attribute is used during VSAM EOV processing,
> and is only applicable to any VSAM multivolume data sets
> allocated in the extended format.
>
>  Is it only  used for any VSAM multivolume data sets?
>
> Thanks a lot!
>
> Best Regards,
>
> Jason Cai
>
>
>
>
> 发件人： Gonzalo Cengotita
> 发送时间： 2011-05-03  19:25:48
> 收件人： IBM-MAIN
> 抄送：
> 主题： Re: Add'l Volume Amount
>
> On Tue, May 3, 2011 at 12:57 PM, ibmnew  wrote:
> > Dear
> >
> >
> > >It means that if the dataset is multivolume, when it expands to another
> > >volume you can decide wether you want to use the amount of the primary
> > >allocation or the amount of the secondary allocation to expand.
> > >Suppose you have a dataset created with SPACE=10,5 cylinders
> >
> >  What situation do dataset expands to another volume ?
> >
>  If the dataset is full, it will extent 5 cylinders.
> >
> >  When it extent 5 cylinders,the volume is full. In this situation,does
> > dataset expand to another volume?
> >
> Yes, if the dataset is multivolume
> > Then it will :
> >
> > >If you filled with "primary" value the dataset wil try allocations in
> new
> > >volumes with 10 cylinders
> > >If you filled with "Secondary" value the dataset will try allocations in
> > new
> > >volumes with 5 cylinders
> >
> >
> > does it mean that if volume isn't full,dataset always extent 5 cylinders
> > and if volume is full,dataset always extent 10 cylinders?
> >
> > Yes, if you fill this field with "Primary"
> >
> > What is benefit of  Add'l Volume Amount ?
> >
> You could have a large pool of many disks with a lot of fragmentation and
> in
> this situation, you will prefer "secondary" amount wich is usually less
> than
> primary.
> Keep in mind that the quantity of the allocation must be found all in one
> piece, no fragmentation is allowed, so you will get less errors if the
> allocation in a new volume try with the lesser value.
> (The example would be better if the dataset would have SPACE=2000,50
> cylinders)
> Of course all of it depends on the size of the dataset, and the number of
> disks, etc
> I hope it is clear enough, English is not my mother tongue, too!
> Regards
> Gonzalo Cengotita
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> --
>  Gonzalo Cengotita Quirce
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 

  Gonzalo Cengotita Quirce

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