Basic question about CPU instructions

[Supra Uche]

Hello List,
I want to learn how a cpu type change effects my application performance. 
When a new generation mainframe is  produced, it comes with hundreds of 
new instructions. I think that new instructions run applications more 
efficiently 
than the previous ones. Also for example if i had a 1000 MIPS capacity 1 CPU 
old machine, the new generation mainframe comes with 1200 MIPS capacity 
per CPU. If I think like, "the number of mips increased also the instructions 
will 
be more efficient than the previous ones. So my total gain is bigger than the 
mips capacity increase", is that idea correct or not ? Or is that directly 
related 
with the operating system version? If i dont upgrade my z/OS, will i able to 
get the benefit of new instructions?
I hope i could explain myself. 
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: auditor request question

[Bob Woodside]

On Wednesday 11 August 2010 19:58, Rick Fochtman wrote:
> ---
>---
>
> >> <>This has been an interesting thread. It seems we all really
> >> ENJOY auditors... Can someone say prostate exam?
> >>
> >> Isn't that essentially a different kind of audit ???
>
> -
>--- Yes it is, but I'm not sure which one is more of an insult
> to a man's basic dignity. :-)

Having been through the full course of the medical variety - PSA, 
digital, biopsy (I flunked), radiation, and semi-annual exams 
thereafter...I vote for the auditors that triggered this thread as the 
greater affront.  :-)


Cheers,
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: What are types of "Work" in SMF 30 record?

[Ted MacNEIL]

>The SMF30WID can be JES2, JES3, OMVS, STC, or TSO.  MXG uses JOB for JES2 & 
>JES2, and TSU for TSO.

Isn't there also a 6th sub-type for SYSTEM tasks, as a subset of STC?

We looked at it years ago, and we decided we didn't want to re-calculate all 
our ratios.

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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: IBM 3883 Manuals

[Anne & Lynn Wheeler]

rfocht...@ync.net (Rick Fochtman) writes:
> At Clearing, we ran MVS very nicely on three 4341 Model Group 2 boxen
> for three years and it ran very nicely. Nowdays, my pocket calculator
> probably has more raw compute power but the fact remains that we were
> very happy with the equipment, until our workload grew beyond their
> capacity to process it. IIRC, the DASD farm was a mix of 3330-11's and
> 3350's. Talk about ancient.

re:
http://www.garlic.com/~lynn/2010m.html#41 IBM 3883 Manuals

... group 2 was faster machine introduced later ... however, if you were
running with (existing?) DASD farm with mix of 3330-11s and 3350s ... it
was possibly upgrade of existing 370 machine (possibly single 158 to
three 4341 ... or maybe from a single 168?). it might have even been an
pre-existing MVS (that didn't require the new 3033 mvs microcode assist)
... and likely within a traditional looking datacenter.

... but this wasn't a couple machines ... part of the explosion in
mid-range were customers buying hundreds of 4341s at a time (which
required new processors as well as new mid-range dasd) ... and placing
them all over the business ... converting deparmental conference rooms
and supply rooms for 4341s with "mid-range" dasd  not exactly
someplace to load up a lot of 3380 disks cabinets (designed for the
datacenter).

another trivial example was the internal service processor for 3090
... it was a pair of (vm) 4361s with FBA (3090 service panels were
actually cms ios3270 screens)

internally installations, that vm/4341 mid-range explosion contributed
to scarcity of conference rooms ... with places like the santa teresa
labs putting vm/4341s on every floor in every tower.

the 3880 controller group in san jose, ran a huge microcode design
application on collection of 168s in bldg. 26 datacenter. The datacenter
was crammed to the walls and there wasn't any place to add more
machines. They started looking at also putting lots of these vm/4341s
out into all the departmental nooks & crannies ... as a means of
deliverying a lot more processing power to their development
organization (again all new installations requiring new mid-range dasd).

one of the things started in the 90s was very aggressive physical
packaging effort to configure ever increasing numbers of processors in
the smallest amount of floor space ... this was somewhat done to get
large numbers of the explosion in departmental and distributed
processors back into the datacenter. 

Much of the early work had gone to national labs (like LLNL) and high
energy physics labs (as GRID computing). It has also recently morphed
into "cloud computing" ... somewhat marrying massive cluster scaleup
with the 60&70s mainframe online commercial timesharing ... much of it
"virtual machine" based (starting with cp67 and then morphing into
vm370) ... one of the largest such (mainframe virtual machine)
operations was the internal (virtual machine based) online HONE system
providing world-wide sales & marketing support ... misc. old HONE
references 
http://www.garlic.com/~lynn/subtopic.html#hone

reference to jan92 meeting regarding early work on increasing processor
density (number of processor per sq. ft).
http://www.garlic.com/~lynn/95.html#13

and some old email from that period on the subject
http://www.garlic.com/~lynn/lhwemail.html#medusa

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
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

SHARE - REXX requirements

[William M Klein]

I recently posted this information in the comp.lang.rexx Usenet group, but
thought there might be some in IBM-MAIN would also be interested.  Please
feel free to pass this along if there are any other places you think this
should be distributed.

 

 * * * * *

 

After a "many-year hiatus", IBM has expressed a wiliness to accept and
process SHARE requirements against REXX.

Currently, there are less than 10 SHARE members "registered" to participate
in the REXX SHARE requirement process. Therefore, if you are a SHARE member
(work for a SHARE member organization) and wish to submit and/or vote on
REXX-related requirements, please go the SHARE requirements online page at:

http://www.share.org/Members/RequirementsIndustryInfluence/tabid/80/Default.
aspx

and either register for the system AND the REXX project (if you are not
currently participating in the requirement system for another project)
or
simply ADD the REXX project if you already participate in another project's
requirement process.

Remember, all requirement processing is now done "online" so you do not need
to attend (frequent) SHARE meetings to participate (but, of course, we do 
encourage you to do so).

If you have any questions on this process, please contact the SHARE
headquarters (or me off-list).

If you are an IBM customer but NOT a member of SHARE and you are interested
in REXX or any other SHARE activity, please consider joining.




--
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: auditor request question

[Rick Fochtman]

--


<>This has been an interesting thread. It seems we all really ENJOY
auditors... Can someone say prostate exam?

Isn't that essentially a different kind of audit ???




Yes it is, but I'm not sure which one is more of an insult to a man's 
basic dignity. :-)


Rick

--
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

AUTO: David Betten/Gaithersburg/IBM is out of the office (returning 08/17/2010)

[David Betten]

I am out of the office until 08/17/2010.

I am on vacation August 11-16, returning on Tuesday, August 17.  If you
need immediate assistance contact my backup Vicky Vezinaw
(vezi...@us.ibm.com) or my manager, Marc Casad  (mdca...@us.ibm.com)


Note: This is an automated response to your message  "Re: auditor request
question" sent on 8/11/10 11:59:18.

This is the only notification you will receive while this person is away.
--
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: What are types of "Work" in SMF 30 record?

[Cheryl Walker]

The SMF30WID can be JES2, JES3, OMVS, STC, or TSO.  MXG uses JOB for JES2 & 
JES2, and TSU for TSO.

Cheryl

==
Cheryl Watson
Watson & Walker, Inc.
www.watsonwalker.com
==


On Aug 11, 2010, at 11:06 AM, Mackenzie, Bruce wrote:

I can only speak for our shop in which I only see these four.  

 JES2 
 OMVS 
 STC  
 TSO  

I would assume that if we were a JES3 shop, the batch would show up as JES3.  


Bruce

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Charles Mills
Sent: Wednesday, August 11, 2010 9:50 AM
To: IBM-MAIN@bama.ua.edu
Subject: What are types of "Work" in SMF 30 record?

The documentation in Chapter 13 of z/OS V1R10.0 MVS System Management
Facilities (SMF) says "SMF30WID 4 EBCDIC Work type indicator for the address
space. The value identifies the type of address space that is being reported
on (for example: "STC" for started tasks and system address spaces, "TSO"
for TSO/E users, etc)."

The earlier paragraphs mention various types of "work": "a TSO/E session,
APPC/MVS transaction program, OMVS forked or spawned address space, started
task, or batch job."

What are all of the possible values for SMF30WID? I assume 'JOB' for a batch
job. What else?

Charles Mills

--
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


NOTICE OF CONFIDENTIALITY
This communication including any information transmitted with it is 
intended only for the use of the addressees and is confidential. 
If you are not an intended recipient or responsible for delivering 
the message to an intended recipient, any review, disclosure, 
conversion to hard copy, dissemination, reproduction or other use 
of any part of this communication is strictly prohibited, as is the 
taking or omitting of any action in reliance upon this communication. 
If you receive this communication in error or without authorization 
please notify us immediately by return e-mail or otherwise and 
permanently delete the entire communication from any computer, 
disk drive, or other storage medium.

If the above disclaimer is not properly readable, it can be found at 
www.td.com/legal

AVERTISSEMENT DE CONFIDENTIALITE   
Ce courriel, ainsi que tout renseignement ci-inclus, destiné uniquement 
aux destinataires susmentionnés,  est confidentiel.  Si vous 
n'êtes pas le destinataire prévu ou un agent responsable de la 
livraison de ce courriel, tout examen, divulgation, copie, impression, 
reproduction, distribution, ou autre utilisation d'une partie de ce 
courriel est strictement interdit de même que toute intervention ou 
abstraction à cet égard.  Si vous avez reçu ce message par erreur ou 
sans autorisation, veuillez en aviser immédiatement l'expéditeur par 
retour de courriel ou par un autre moyen et supprimer immédiatement 
cette communication entière de tout système électronique.

Si l'avis de non-responsabilité ci-dessus n'est pas lisible, vous 
pouvez le consulter à www.td.com/francais/legale

--
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: IBM 3883 Manuals

[Rick Fochtman]

there was big explosion in the mid-range market with 43xx machines ...
which MVS didn't fit well into.
--
I resemble that remark.  :-) 

At Clearing, we ran MVS very nicely on three 4341 Model Group 2 boxen 
for three years and it ran very nicely. Nowdays, my pocket calculator 
probably has more raw compute power but the fact remains that we were 
very happy with the equipment, until our workload grew beyond their 
capacity to process it. IIRC, the DASD farm was a mix of 3330-11's and 
3350's. Talk about ancient.


Rick

--
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: auditor request question

[Rick Fochtman]

-
I think the valid question here is #3 - Why would you do that? I don't 
know about everyone else on this forum, but I have too much to do to try 
and get an operator fired in this way. And if you ever got caught doing 
this, would you really want to lose your own job?


This has been an interesting thread. It seems we all really ENJOY 
auditors... Can someone say prostate exam?

--
If I wanted to get an operator fired, I'd have to come up with far 
better cause than questionable use of system commands.


In the city of Chicago, there are a number of shops where the operators 
are unionized, either Teamsters or Internation Brotherhood of Postal 
Workers. Supposedly, this is for the protection of the operators, so 
they can't be arbitrarily fired. HORSEFEATHERS! It's just because the 
union wants to collect dues money! In one shop, the unionized operators 
took some serious hits: they lost a week of vacation time and instead of 
100% Major Medical/Hospitalization coverage, their coverage dropped to 
80%. And the staff was small enough that dues were paid by payroll 
deduction.


Dumb move, folks. You didn't do your homework!

Any operator (or any other employee) that acts in a malicious fashion 
deserves to be fired.


An incompetent operator (or any other employee)  should be trained; if 
training oppurtunities are refused, let him/her go and "explore other 
challenges".


Rick

(Bob, do you remember one very oversized operator?)

--
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: auditor request question

[Ted MacNEIL]

>This has been an interesting thread.  It seems we all really ENJOY auditors... 
> Can someone say prostate exam?

Bummer! (Sorry, couldn't resist).

But, there is a blood test (PSA) that will do the same thing).

In the last company I worked for, I convinced the powers that be to elongate 
the time-out for users, enforce them all to go through supersession (or 
whatever it's called, now), and have a 10-minute time out on supersession --- 
without logging them off.
Some were still on real 3270's, so a screensaver password wasn't an option.

This was more to save resource costs due to multiple logins, which appealed to 
the capacity analyst in me.
But, it was more convenient (aka faster) for the users.

The lock function under supersession had been disabled at the request of one 
department.
And, this same department slowed down the implementation.

Quess which department.

Give me an 'A'!
Give me a  'U'!

(You get the picture)

It was a case of they'd never heard, or thought of it, so it couldn't be a 
standard practice.

(8-{]}

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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: auditor request question

[Dave Kopischke]

On Wed, 11 Aug 2010 17:51:45 -0400, Burrell, C. Todd (CDC/OCOO/ITSO) 
(CTR) wrote:

>
>This has been an interesting thread.  It seems we all really ENJOY
>auditors...  Can someone say prostate exam?
>

Isn't that essentially a different kind of audit ???

--
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: CPU time variance

[Ted MacNEIL]

>For those doing chargeback, it has been recommended for quite a while that you 
>move to "pricing bands" to account
for this variance.

When I took my first Capacity Planning course (1981), transaction-based 
accounting was recommended, because (even then) CPU Time was variable.

I worked for a wholesaler once, and we discovered that invoices opened (under 
CICS) had a very strong co-relation to overall processor utilisation.
RMA's, accounts receivable, accounts payable, and a few others ran under the 
same application, but they had little impact on the overall usage.
I know of a lot of business managers who would like to be charged on a business 
metric rather than CPU Time, but most charge backers (chargers back) get stuck 
on the techie stuff.


-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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: IBM 3883 Manuals

[Anne & Lynn Wheeler]

wmhbl...@comcast.net (William H. Blair) writes:
> I've never seen this documented. But I never looked that deeply,
> either, so it might have been in my face since 1981. Regardless,
> I was told it was only for purposes of allocating space on the
> actual track -- AS IF the device actually wrote 32-byte (the
> cell size) physical blocks (or multiples thereof). At the time,
> prior to PCs, this meant nothing special to me. Of course fixed
> sector sizes for PC drives made more sense, and I assumed the
> underlying 3380 and 3375 hardware, like the 3370, used a fixed
> block [or sector] size, which obviously had to a multiple of 32.
> Later, I was told (by IBM) that this was, in fact, the case.

i remember that the 32byte data error correcting block was also the
physical block on disk ... but I haven't found a documented reference to
that effect.

as I mentioned before ... 3380 was high-end ... while 3370 was
considered mid-range.

there was big explosion in the mid-range market with 43xx machines ...
which MVS didn't fit well into. possibly somewhat as part of helping MVS
possibly sell into that 43xx/midrange exploding market ... there was
3375 ... which emulated CKD on 3370 (there was also a major effort to
get the MVS microcode assist from the 3033, required by all the new
releases of MVS, implemented on 4341). recent post mentioning 3375
gave MVS CKD disk for mid-range:
http://www.garlic.com/~lynn/2010l.html#13 Old EMAIL Index

at the time, 3310/3370 were sometimes referred to as FBA-512 (rather than
simply FBA) ... implying plans for moving to even larger block
sizes. recent post referencing current FBA is looking at moving from 512
(with 512 byte data block error correcting) to 4096 (with 4096 byte data
block error correcting)
http://www.garlic.com/~lynn/2010m.html#1 History of Hard-coded Offsets

the above has some articles about various FBA-512
compatibility/simulation efforts (for FBA-4096) ... very slightly
analogous to CKD simulation on FBA.

other recent posts mentioning fba, ckd, etc
http://www.garlic.com/~lynn/2010k.html#10 Documenting the underlying FBA design 
of 3375, 3380 and 3390?
http://www.garlic.com/~lynn/2010k.html#17 Documenting the underlying FBA design 
of 3375, 3380 and 3390?
http://www.garlic.com/~lynn/2010l.html#76 History of Hard-coded Offsets

Of course, VM had native FBA support and didn't have problems with
low-end and mid-range markets. Part of this was that both VM kernel
paging ... and the CMS filesystem organization (dating back to the
mid-60s) have been logical FBA ... even when having to deploy on
physical CKD devices.

I've made past references that with the demise of FS that there was mad
rush to get stuff back into the 370 hardware & software pipeline ... and
it was going to take possibly 7-8 yrs to get XA (starting from time FS
was killed). The MVS/XA group managed to make the case that VM370
product had to be killed, the development group shutdown and all the
people moved to POK in order for MVS/XA to make its shipment schedule
(endicott managed to save the vm370 product mission, but had to
reconstitute a development group from scratch). misc. past posts
mentioning future system effort
http://www.garlic.com/~lynn/submain.html#futuresys

Later in the 80s, POK decided to come out with vm/xa high-end product.
However, there was some interesting back&forth about whether VM/XA would
include FBA support ... they were under pressure to state that CKD was
much better than FBA and that was why FBA support wasn't needed (as part
of supporting MVS lack of FBA support).

misc. past posts mentioning the disk division would let me come over
and play disk engineer in bldgs. 14 (engineering lab) & 15 (product
test lab)
http://www.garlic.com/~lynn/subtopic.html#disk

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
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: IBM 3883 Manuals

[William H. Blair]

Seymour J. Metz asks:

> I need a reference for Wikipedia as to whether the cells on a 3380 
> only relate to error checking or whether they actually reflect the 
> physical layout of the track.

The "cells" are mentioned in United States Patent US4680653. That
appears to be one of the patents that would apply to the emulation
of a 3380 on a 3390, so there is presumably yet another patent (or
two or three, if it's like most IBM technology patents) that would
actually apply to the cellular allocation technique.

--
WB

--
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: Return code x'00000010' from Latch Create

[Jim Mulder]

IBM Mainframe Discussion List  wrote on 08/11/2010 
03:37:01 PM:

> This return code says not enough storage available to create the 
> latch set.  I cannot find anywhere in either the auth services guide
> or the auth reference where it states the location of the storage 
> used for the latch set.  I did find in the auth assembler services 
> guide where it stated a latch set takes 128 bytes for the latchset 
> plus 32 bytes for each latch defined in the latchset.  My code was 
> asking for a latchset that contained 6 latches.  Hardly a 
> significant amount of storage, but I guess it depends upon from 
> which sub-pool the storage was to be allocated.  Any way to 
> determine this...what sub-pool is used for the latchset?  Thanks.

  Change your code to Abend when you get this return code
from latch create, and look in system trace in a dump to
see if there are any trace entries from a storage management
service preceeding the Abend entry. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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

Re: auditor request question

[Burrell, C. Todd (CDC/OCOO/ITSO) (CTR)]

I think the valid question here is #3 - Why would you do that?   I don't
know about everyone else on this forum, but I have too much to do to try
and get an operator fired in this way.  And if you ever got caught doing
this, would you really want to lose your own job?  

This has been an interesting thread.  It seems we all really ENJOY
auditors...  Can someone say prostate exam?

C. Todd Burrell 
PMP, MCSE 2003:Security
Security+, Network+
Lead z/OS Systems Programmer 
ITSO 
(404) 723-2017 (Cell) 



-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ted MacNEIL
Sent: Wednesday, August 11, 2010 4:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: auditor request question

>So if I want to get an operator fired, I'll just have my privileged
task issue a $PJ1-, using that operator's console id?

1. What are you doing with a privileged task?
2. Don't sources of commands show up in SYSLOG?
3. Why would you do that?
4. Are you attempting to hijack this thread, or to belittle a valid
concern?

Most shops don't allow other types of ids to be shared, so why should
console ids be so?

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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: IBM 3883 Manuals

[William H. Blair]

Seymour J. Metz asks:

> I need a reference for Wikipedia as to whether the cells on a 3380 
> only relate to error checking or whether they actually reflect the 
> physical layout of the track.

I have found it. And, now that I have found it, I remember it. This
getting old  is for the birds!

According to a paper in the IBM Systems Journal, Volume 25 Issue 3.4
(1986) on pages 274-305, titled "Impact of memory systems on computer 
architecture and system organization" --.

> A sector on a modern 3380 disk is about 512 bytes long 

After reading that, I remembered more in the 1981 discussion with
Ed Daray and Jack Gelb. There was something mentioned about what
they called "overhead bytes" (that was not the usual inter-block
gap requirement, they said -- that was there, too, but completely
invisible, which was the point of a cellular device) and "packing"
and other fine-sounding mumbo-jumbo and hand-waving to the effect
that the blocks actually written on the track were not _exactly_ a
multiple of the cell size. The cell size was the unit of allocation
of track space, but they were not written as 32-byte blocks (nor
exactly some multiple thereof), but (as far as the data one could
actually plan on being able to occupy space) it was made to LOOK
LIKE the physical blocks were 32 bytes but there was no IRG. That
is exactly how 3380s and 3390s behave.

Enough said. I think that settles it. The 3380 _WAS_ an FBA device
under the sheets. But I still don't have an authoritative reference
for you (other than that Systems Journal article).

--
WB

--
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: IBM 3883 Manuals

[William H. Blair]

Seymour J. Metz asks:

> I need a reference for Wikipedia as to whether the cells on a 
> 3380 only relate to error checking or whether they actually 
> reflect the physical layout of the track.

I've never seen this documented. But I never looked that deeply,
either, so it might have been in my face since 1981. Regardless,
I was told it was only for purposes of allocating space on the
actual track -- AS IF the device actually wrote 32-byte (the
cell size) physical blocks (or multiples thereof). At the time,
prior to PCs, this meant nothing special to me. Of course fixed
sector sizes for PC drives made more sense, and I assumed the
underlying 3380 and 3375 hardware, like the 3370, used a fixed
block [or sector] size, which obviously had to a multiple of 32.
Later, I was told (by IBM) that this was, in fact, the case.

The 3310 and 3370 were FBA above the covers. The 3375 was, as
has been acknowledged, FBA under the covers. The 3380 has been
claimed to be genuine CKD under the covers, but I was informed
authoritatively (supposedly, or I felt so at the time) that it
was also FBA under the covers. FBA was an acronym developed for
public consumption/marketing purposes. Internally, they were
called "cellular" [DASD] devices, and such terminology used to 
appear in MVS/SP and DF/DS and DF/EF source code and macros.
It also appeared in APAR and PTF text. Sadly, since all such
material remains licensed and proprietary, so none of it ever
made it into the public domain, and since the WWW effectively
started (for IBM) no earlier than 1995, none of this sort of
stuff appears to be anywhere online where Google can discover
it.

Nonetheless, despite (easily Google-able) claims that the 3380
was CKD under the covers, I was told (at the time, circa 1981)
by presumably authoritative sources that it was, in fact, an
FBA (or cellular) device. One had to use the same track balance
calculation algorithm for 3380s as one did for the 3375, and
the cell size was recorded as 32 bytes. If the 3380 was a CKD
device under the sheets, then San Jose went to an awful lot of
trouble to make it look like an FBA device below the spread so
that it would be compatible with a genuine below the covers FBA
[cellular] device.

Other than hearsay, I don't have any authoritative reference, 
so I don't have any (currently-online) material to offer you.

Immediately after I was told (by the late Ed Daray and Jack Gelb)
how 3380s worked (after they felt they could actually "tell" me),
I never gave it any further thought, unfortunately. Today I feel
that I _should_ have thought to be more curious and dug deeper.
But that did not happen.  So I'm as interested as you are.

Perhaps Lynn Wheeler has some old (actually physically archived) 
reference material that can shed light on this subject.

--
WB

--
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: CPU time variance

[Norman Hollander on DesertWiz]

So there are a couple of things to remember about the hardware architecture.
First, starting at the z9, the superscalar bus was introduced which created
the dual
highway for fetching instructions and data.  The attempt was to reduce the
number
of cycles necessary to fill the cache with the hope that the instruction or
data needed
next was brought at the same time with the current.  Goodness if you weren't
branching
elsewhere or if your data had good locality of reference.  Badness if it
didn't.  The badness
shows up as an increase in CPU time.  This got worse in z10 based on the new
cache structure
and their sizes.  Even more complex with the z196 that has an additional
cache plus the ability
to fetch instructions and data out of order.  All of this impacts where
cache data is, and where you
come back to execute on a processor.  Again, goodness, if the cache is
loaded and your return to
the same processor; badness if you don't HiperDispatch helps improve the
cache hits.  Depending
on the number of processors and the number of books, you can see anywhere in
the range of 2-11%
overhead to move instructions/data around.  Also, the variance is dependent
on how saturated your
processor is.  The busier the entire footprint, the more likely you will not
come back to the same
processor.  On z9s, the variance could be up to 20%, on the z10s, it was up
to 30%, don't know what
the z196 brings; but it could go higher.  So for those that are counting on
CPU time being the same for
each run of some unit of work, you'll have to get over that.  For those
doing chargeback, it has been
recommended for quite a while that you move to "pricing bands" to account
for this variance.  Hope
this helps...
zNorman

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of zMan
Sent: Wednesday, August 11, 2010 Wednesday 12:30 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CPU time variance

Thanks for the various replies. I guess I'm just surprised at a 20% variance
-- a few percent, yes; 20% does indeed make one wonder.

We have APA, but finding where the hot spots are is different from comparing
two different algorithms. The latter is what we were doing.

Thanks again.
--
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
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: auditor request question

[Ted MacNEIL]

>So if I want to get an operator fired, I'll just have my privileged task issue 
>a $PJ1-, using that operator's console id?

1. What are you doing with a privileged task?
2. Don't sources of commands show up in SYSLOG?
3. Why would you do that?
4. Are you attempting to hijack this thread, or to belittle a valid concern?

Most shops don't allow other types of ids to be shared, so why should console 
ids be so?

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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: Oracle: The future is diskless!

[Howard Brazee]

On 11 Aug 2010 08:57:53 -0700, r.skoru...@bremultibank.com.pl (R.S.)
wrote:

>The world is full of forecast, predictions and prophecies. People 
>remember only few of them: the most accurate and the most funny because 
>of its inaccuracy (Watson Sr: 5 computers, Gates: 640kB is enough).

Sometimes the inaccuracy is in how we interpret the sound-byte out of
context.

--
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: Oracle: The future is diskless!

[Howard Brazee]

On 11 Aug 2010 11:42:13 -0700, shmuel+ibm-m...@patriot.net (Shmuel
Metz  , Seymour J.) wrote:

>>IBM's use of the term DASD gets around saying "disk", 
>
>drum, data cell, MSS, ...
>
>>but by the time
>>disk goes away, the term DASD may not quite apply either.
>
>How not?

Indirect Access Storage Cloud???

--
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

Return code x'00000010' from Latch Create

[Dave Day]

This return code says not enough storage available to create the latch set.  I 
cannot find anywhere in either the auth services guide or the auth reference 
where it states the location of the storage used for the latch set.  I did find 
in the auth assembler services guide where it stated a latch set takes 128 
bytes for the latchset plus 32 bytes for each latch defined in the latchset.  
My code was asking for a latchset that contained 6 latches.  Hardly a 
significant amount of storage, but I guess it depends upon from which sub-pool 
the storage was to be allocated.  Any way to determine this...what sub-pool is 
used for the latchset?  Thanks.

--Dave 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: CPU time variance

[zMan]

Thanks for the various replies. I guess I'm just surprised at a 20% variance
-- a few percent, yes; 20% does indeed make one wonder.

We have APA, but finding where the hot spots are is different from comparing
two different algorithms. The latter is what we were doing.

Thanks again.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
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: Oracle: The future is diskless!

[Anne & Lynn Wheeler]

shmuel+ibm-m...@patriot.net (Shmuel Metz  , Seymour J.) writes:
> Is that anything like thin film replacing core? Or bubbles?
>
> Predicting that that a technology will be supplanted is easy.
> Accurately predicting what will replace it and when is hard.

lot of DBMS are disk-centric and based on the home position for data is
located on disk ... and real memory/storage is used to cache records.

with increase in real memory sizes, lots of databases can completely fit
in real storage. there has been work on "in memory" databases ... big
motivation was the telco industry ... being able to handle call record
volumes. there were some benchmarks of these "in memory" databases that
might use disks for sequential writing involving logging/recovery ...
against standard DBMS that had enough memory/storage to completely cache
the full DBMS ... and the "in memory" database still got ten times the
thruput ... than disk-centric DBMS (even with all data cached).

In the middle/late 90s, there was prediction that the telcos would take
over the payment industries ... because the telcos were the only
operations (based on scaleup to handle call-record volumes) that were
capable of handling the predicted volumes in micro-payments. Once firmly
entrenched handling micro-payment volumes ... they would then move
upstream to take over the rest of the payment industry. Well, the
micro-payment volumes never materialized ... and the telco industry has
yet to take over the payment industry.

However since then, Oracle has acquired at least one of the "in-memory"
DBMS implementations ... and some of the payment processors have
deployed backend platforms originally developed to handle the telco call
record volumes.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
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: CPU time variance

[Anne & Lynn Wheeler]

eamacn...@yahoo.ca (Ted MacNEIL) writes:
> The simple explanation is, during one of the MVS/SP1.x releases, some
> things that were done in disabled mode, and under SRB reported CPU,
> were done in disabled mode and TCB which was allocated to the last
> active task.

MVS didn't actually directly account for lots of activity ... so percent
processor activity captured could possibly be as low as 40% (of total
processor activity). Some of the subsystem intensive operations ... that
attempted to do everything possible to avoid MVS ... could get captured
processor activity up to 80% or so (only 20% of the MVS processor cycles
unaccounted for). Operations that billed for useage would potentially
take overall capture ratio (as percent of overall total processor
useage) ... and prorate all useage by that amount.

VM accurately accounted for all useage (didn't have the concept of
things like "uncaptured" processor useage). The variability that VM
operation might have would be things like concurrent activity resulting
in task switching rates ... which affect things like cache hit ratio.

Processor thruput (number of instructions executed per second) is
sensitve to processor cache hit ratios ... actually frequency that
instructions stall waiting for data to be fetched from main
storage/memory (because the data isn't in the cache). With increasing
processor speeds w/o corresponding increase in storage/memory speeds
... there is increased mismatch between processor execution speeds and
the slow-down that happens when waiting for data not in the cache.

When there is lots of task switching going on ... much of the data in
the processor cache may have to be changed in the switch from one task
to another ... resulting in very high cache miss rate during the
transition period (significantly slowing down the effective processor
execution rate and increasing the corresponding measured CPU utilization
to perform some operation).

Over the past couple decades ... the instruction stall penalty has
become more and more significant ... resulting in lots of new
technologies attempting to mask the latency in waiting for data to be
fetched from memory/storage (on cache miss) & keep processor doing
something ... aka things like deep pipelining and out-of-order execution
... which may then also result in branch prediction and speculative
execution.

in any case, variability in task switching and other concurrent activity
(that might occur in vm environment) ... can result in variability in
cache miss rate ... and therefor some variability in effective
instructions executed per second (i.e. variabiilty in elapsed cpu used
to perform some operation).

LPAR activity (effectively a subset of VM function in the hardware)
could also have similar effects on cache miss rates.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
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: Oracle: The future is diskless!

[Mark Pace]

Bubbles!!  HAHAHAHAHAHA!   I still remember that prediction.

On Wed, Aug 11, 2010 at 2:21 PM, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net > wrote:

> In ,
> on 08/11/2010
>   at 07:50 AM, "McKown, John"  said:
>
> >This is about some comments from Oracle EVP John Fowler. He indicates
> >that disk is dying. He envisions it being replace by flash RAM.
>
> Is that anything like thin film replacing core? Or bubbles?
>
> Predicting that that a technology will be supplanted is easy.
> Accurately predicting what will replace it and when is hard.
>
> --
> 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
>



-- 
Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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: Oracle: The future is diskless!

[Shmuel Metz (Seymour J.)]

In , on 08/11/2010
   at 07:55 AM, Howard Brazee  said:

>IBM's use of the term DASD gets around saying "disk", 

drum, data cell, MSS, ...

>but by the time
>disk goes away, the term DASD may not quite apply either.

How not?
 
-- 
 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: Oracle: The future is diskless!

[Shmuel Metz (Seymour J.)]

In <4c62a610.4000...@acm.org>, on 08/11/2010
   at 08:30 AM, "Joel C. Ewing"  said:

>As long as DASD technology is able to continue to provide storage
>capacity, access speeds, and reliability that are adequate for
>real-world business applications at lower cost than this directly
>connected RAM envisioned by Oracle, DASD will continue to play a
>significant role.

Sure, but for how long will those DASD be disk?

>Experience teaches that non-volatile storage
>sometimes becomes volatile,

Even on disks :-(

>Another issue is that closer integration of massive storage with a
>specific server introduces new problems in sharing data with other
>servers or migrating to new servers. 

That relates to the claim that the new DASD will be integrated, not to
the claim that it will be flash.
 
-- 
 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: Oracle: The future is diskless!

[Shmuel Metz (Seymour J.)]

In ,
on 08/11/2010
   at 07:50 AM, "McKown, John"  said:

>This is about some comments from Oracle EVP John Fowler. He indicates
>that disk is dying. He envisions it being replace by flash RAM. 

Is that anything like thin film replacing core? Or bubbles?

Predicting that that a technology will be supplanted is easy.
Accurately predicting what will replace it and when is hard.
 
-- 
 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: auditor request question

[Dave Kopischke]

On Tue, 10 Aug 2010 14:28:20 -0500, Pommier, Rex R. wrote:

>Quick question.  Do you require your operations staff to log onto the
>z/OS consoles?  Our auditors are claiming this is "industry standard"
>and so we need to be doing it, even though our consoles are all behind
>locked doors.
>

   We have two consoles physically located in the data center that do not 
require logon.

   We have several others defined that can be accessed remotely that do 
require logon.

   So it depends

--
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: auditor request question

[Pommier, Rex R.]

We still do share userids between the operators.  The auditors squawk
about that one every time we are audited.  They usually quiet down when
we explain that we have a total of 4 operators covering 2.5 shifts as
well as weekend support.  These operators need to move quickly from the
machine room to the console area to the 2 different print areas and back
again.  We would either have to assign each operator 4 different IDs or
have them spend an inordinate amount of time signing off one session so
they can sign onto another one.  The auditors complain about
accountability.  As others have pointed out, we simply explain that it
is easy to figure out who did what simply by time of day.

Rex



Our main issue years ago was that operators would share userids.  The
auditors LOVED that one.

C. Todd Burrell 
PMP, MCSE 2003:Security
Security+, Network+
Lead z/OS Systems Programmer 
ITSO 
(404) 723-2017 (Cell) 

--
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: auditor request question

[Burrell, C. Todd (CDC/OCOO/ITSO) (CTR)]

In most small shops the need for extensive operator auditing and
security is not needed for accountability (IMHO).  We normally have a
few operators on shift at one time, so if something happens on the
console we would be able to narrow it down fairly quickly.  And we push
the use of SDSF for most everything except commands that absolutely have
to come from the console.  

Our main issue years ago was that operators would share userids.  The
auditors LOVED that one.

C. Todd Burrell 
PMP, MCSE 2003:Security
Security+, Network+
Lead z/OS Systems Programmer 
ITSO 
(404) 723-2017 (Cell) 



-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Gerhard Postpischil
Sent: Wednesday, August 11, 2010 1:37 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: auditor request question

On 8/11/2010 1:00 PM, Ted MacNEIL wrote:
>> If the consoles are in a secure room that should suffice all but the
most
> stringent security standards.
>
> Unless you want to make your operators responsible for all commands
issued from their consoles.

So if I want to get an operator fired, I'll just have my 
privileged task issue a $PJ1-, using that operator's console id?




Gerhard Postpischil
Bradford, VT

--
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: auditor request question

[Gerhard Postpischil]

On 8/11/2010 1:00 PM, Ted MacNEIL wrote:

If the consoles are in a secure room that should suffice all but the most

stringent security standards.

Unless you want to make your operators responsible for all commands issued from 
their consoles.


So if I want to get an operator fired, I'll just have my 
privileged task issue a $PJ1-, using that operator's console id?





Gerhard Postpischil
Bradford, VT

--
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: Oracle: The future is diskless!

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Charles Mills
> Sent: Wednesday, August 11, 2010 11:50 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Oracle: The future is diskless!
> 
> > Why SW changes?  Won't the control units continue to provide a
> > 56kB/track 15 track/cylinder image?
> 
> I think perhaps a gradual shift in software architectural 
> thinking relative
> to "what goes on disk" versus "what goes in RAM" as the two become
> increasingly synonymous.
> 
> Charles

AS/400, aka iSeries, aka "i" uses the concept of a "single level store". 
Everything seems to be in memory. Everything has a virtual address. This is 
mapped onto the actual physical DASD. And it is "object oriented" in that 
everything, including what we think of as getmain'ed storage, is described by 
an object. And you have the virtual address of that "object". You can only do 
to that object what is allowed by the object. And, in most cases, a virtual 
address is never reused, so you cannot get some "old" object. A very 
interesting system.


--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

--
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: What are types of "Work" in SMF 30 record?

[Kelman, Tom]

That is correct.  What we see in out MXG JOBS dataset is the following

JOB
OMVS
STC
TSU

Tom Kelman
Capacity Planning
Commerce Bank, Kansas City

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Charles Mills
Sent: Wednesday, August 11, 2010 10:11 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What are types of "Work" in SMF 30 record?

Thanks. The plot thickens. I got a private reply that quoted MXG
documentation that had T or TSU (but no TSO) and J or JOB for batch (but
no
JESn).

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf
Of Mackenzie, Bruce
Sent: Wednesday, August 11, 2010 11:06 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What are types of "Work" in SMF 30 record?

I can only speak for our shop in which I only see these four.  

  JES2 
  OMVS 
  STC  
  TSO  

--
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


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer 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: auditor request question

[Ted MacNEIL]

>If the consoles are in a secure room that should suffice all but the most
stringent security standards.   

Unless you want to make your operators responsible for all commands issued from 
their consoles.

I don't know if that would be considered stringent, but it is consistent with 
the reasoning behind one user/one userid for TSO, CICS, IMS, etc.

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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: ISPF: How best to change user variable ZRETMINL in ISPSPROF

[Mark Zelden]

On Wed, 11 Aug 2010 09:30:49 -0500, Jochen Roehrig
 wrote:

>Hi Robert
>
>that's it!
>Shame on me: I knew the RETP, but I never recognized the 'OPTIONS'...
>
>Kind regards
>Jochen
>

You may have received a quicker answer if the question was more clear.  But
maybe it was clear to everyone but me.  :-)

I thought you wanted a way to either

a) Change the default via customization table for everyone (which you 
can't because there is no reset value)

b) mass update everyone's ISPF profile because the set a bad default
in the customization table and already knew you couldn't do the above.


Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/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: Oracle: The future is diskless!

[R.S.]

W dniu 2010-08-11 18:17, Paul Gilmartin pisze:

On Wed, 11 Aug 2010 17:58:02 +0200, R.S. wrote:


W dniu 2010-08-11 14:50, McKown, John pisze:

http://www.theregister.co.uk/2010/08/11/oracle_on_storage/


Regarding to the disks: indeed we observe first time when silicon "RAM"
succesfully replaces disks in some areas. Is it beginning of revolution


Most rapidly in personal/portable devices.


Most rapidly, but not only. The prices of SSDs are going down, like the 
numerous drawbacks are being fixed.



like CRT->LCD switch? Maybe, we will see. What's sure (?) the changes in
computer architecture will come much later, after "HDD philosophy" will
become totally obsolete. It would require many changes in both HW and SW.


Why SW changes?  Won't the control units continue to provide a
56kB/track 15 track/cylinder image?


Because it's quite senseless to emulate it. Frankly, I didn't mind 
mainframe which is vry conservative and pay much attention to 
backward compatibility, rather distributed systems world where the 
changes seems to be faster. BTW: All real HDDs does not use 
CYL-HEAD-RECORD addressing scheme for many years. For SCSI/FC drives it 
was since very beginning, as well as for most IDE drives (actually for 
all of them, but pre-LBA drives presented logical geometry which had 
nothing to do with physical one).


Why to drop emulation of HDD? I.e. for optimization. legendary features 
of Novell Netware assumed some physical parameters of HDDs like track to 
track seek, avg seek time, etc. The same for VSAM IMBED or REPLICATE. 
Nowadays such improvements has no sense, since all the geometry and 
timing related to geometry are fictitious. However other physical 
characteristics do have a meaning. That's why my PC has 2 DIMMs working 
in dual channel mode (maybe I misnamed it).

Not to mention gaps and lot of unused (wasted) space on virtual tracks...



--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.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.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
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: CPU time variance

[Ted MacNEIL]

>IIRC there is a statement in the SMF manual about CPU time not being 
>repeatable.

This has been the case since pre-MVS/XA.
IBM documented this in many places over the last 25+ years, and gave 
explanations at seminars such as CMG.

The simple explanation is, during one of the MVS/SP1.x releases, some things 
that were done in disabled mode, and under SRB reported CPU, were done in 
disabled mode and TCB which was allocated to the last active task.

This was, in a way, to reduce overhead, and make the system more responsive.
But, since some things were 'sensitive', whatever system related function was 
being done had to start over again when it was resumed.

We discovered this, at an insurance company I was working at, when we were 
bench marking an upgrade/replacement of a 470 with a 3081.
When we pointed out the discrepency to IBM, they tried to tell us our 
methodology was flawed, and our tools weren't up to the level of MVS we were 
running.
We pointed out we were using SMF & RMF only, and showed that we were current on 
PTF's.
When we threatened to go for a 5840, they opened up and explained the issue.

The whole event soured me on bench marking.

The overall day to day work of a busy corporate environment can be consistent.
But, individual jobs are not.

My understanding of VM, is that it introduces another level of variability, but 
I have never measured individual jobs under a guest operating system.
I've just measured the entire guest, or collection of guests.

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
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: Oracle: The future is diskless!

[Charles Mills]

> Why SW changes?  Won't the control units continue to provide a
> 56kB/track 15 track/cylinder image?

I think perhaps a gradual shift in software architectural thinking relative
to "what goes on disk" versus "what goes in RAM" as the two become
increasingly synonymous.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Wednesday, August 11, 2010 12:18 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Oracle: The future is diskless!

On Wed, 11 Aug 2010 17:58:02 +0200, R.S. wrote:

>W dniu 2010-08-11 14:50, McKown, John pisze:
>> http://www.theregister.co.uk/2010/08/11/oracle_on_storage/
>
>Regarding to the disks: indeed we observe first time when silicon "RAM"
>succesfully replaces disks in some areas. Is it beginning of revolution

Most rapidly in personal/portable devices.

>like CRT->LCD switch? Maybe, we will see. What's sure (?) the changes in
>computer architecture will come much later, after "HDD philosophy" will
>become totally obsolete. It would require many changes in both HW and SW.
>
Why SW changes?  Won't the control units continue to provide a
56kB/track 15 track/cylinder image?

--
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: auditor request question

[Greg Shirey]

>-Original Message-
>From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
>Sent: Wednesday, August 11, 2010 10:52 AM

>Should you allow a user simply to alternate between two?

Why not?  He or she is less likely to write them down.  

>Why should he need to remember so many?  Only the one most recent
>is useful.
>o To test that the rule is being enforced?
>o To avoid inadvertent collisions when he changes a password?

Yes.

Greg Shirey
Ben E. Keith Company 

--
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: Oracle: The future is diskless!

[Paul Gilmartin]

On Wed, 11 Aug 2010 17:58:02 +0200, R.S. wrote:

>W dniu 2010-08-11 14:50, McKown, John pisze:
>> http://www.theregister.co.uk/2010/08/11/oracle_on_storage/
>
>Regarding to the disks: indeed we observe first time when silicon "RAM"
>succesfully replaces disks in some areas. Is it beginning of revolution

Most rapidly in personal/portable devices.

>like CRT->LCD switch? Maybe, we will see. What's sure (?) the changes in
>computer architecture will come much later, after "HDD philosophy" will
>become totally obsolete. It would require many changes in both HW and SW.
>
Why SW changes?  Won't the control units continue to provide a
56kB/track 15 track/cylinder image?

-- 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: auditor request question

[Rick Fochtman]

---
I would definitely not call this an "industry standard"... If the 
consoles are in a secure room that should suffice all but the most 
stringent security standards.



None of you understand the basic "auditor mindset".

"If the auditor likes it, it becomes 'industry standard'"   :-)

Rick

--
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: Oracle: The future is diskless!

[R.S.]

W dniu 2010-08-11 14:50, McKown, John pisze:

http://www.theregister.co.uk/2010/08/11/oracle_on_storage/

This is about some comments from Oracle EVP John Fowler. He indicates that disk 
is dying. He envisions it being replace by flash RAM. And not in our current 
mode of being an external I/O device, but actually being on the data bus of the 
CPU. So all active data will be in non-volatile, directly addressable, server 
memory. Backup will be on high speed (1,380 Tb/hour ==~ 383 Mb/second) tape. 
Not related to this directly was talk about a Sparc processor with 128 cores 
and 16,384 threads.


Yes, he said. So what?
Case
a) it will happen. Journalists will cite him (mostly in the airplane 
magazines).

b) it won't happen. Dot. Nothing more. Nobody will remember his words.

The world is full of forecast, predictions and prophecies. People 
remember only few of them: the most accurate and the most funny because 
of its inaccuracy (Watson Sr: 5 computers, Gates: 640kB is enough).


Regarding to the disks: indeed we observe first time when silicon "RAM" 
succesfully replaces disks in some areas. Is it beginning of revolution 
like CRT->LCD switch? Maybe, we will see. What's sure (?) the changes in 
computer architecture will come much later, after "HDD philosophy" will 
become totally obsolete. It would require many changes in both HW and SW.


My €0.02

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
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: auditor request question

[Paul Gilmartin]

On Wed, 11 Aug 2010 09:41:50 -0500, Greg Shirey wrote:
>
>I worked at a place where the auditors suggested we should require 12
>unique passwords before we allow a user to  repeat one.  Fortunately, my
>management laughed at the idea.  And then, surprisingly, one of the

Should you allow a user simply to alternate between two?

>auditors admitted that he couldn't remember that many passwords, so he
>just used the same password each time with a two digit "counter" at the
>end which he upped each time he was forced to change.  Sheesh, talk
>about do as I say, not as I do...
>
Why should he need to remember so many?  Only the one most recent
is useful.

o To test that the rule is being enforced?

o To avoid inadvertent collisions when he changes a password?

I've dealt (perhaps too contemptuously) with a rule that required
that the new password differ from the (several) former in at least
N character positions.  It succumbed to an end-around shift of the
previous password.  How can such a rule be enforced?  If passwords
are stored encrypted by a one-way hash, the new password can be
tested for identity to any number of stored hash values, but for
similarity only to the current password entered for authentication.

-- 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: Abend U4088(3EC)

[HUTCHISON Gregory]

 U4088 is short on storage SOS and there is a VM related APAR PQ90148 if
that is of any help


 Please always remember that

I'm here for your Amusement!

Greg Hutchison


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paulo Roberto Leonardo Pereira
Sent: Wednesday, August 11, 2010 7:54 AM
To: IBM-MAIN@bama.ua.edu
Subject: Abend U4088(3EC)

Does anybody heard any solution for this abend before ?

I know that is related with memory (region). I run with REGION=0M, I'm
trying to run a PL/I/DB2 with the new SQL command called MERGE (with
MATCH(update) and NOT MATCHED(insert)) embedded in the program.
Interesting is: I changed several times the program and looks it does
not executed ! I changed the plan name also and still abend. I changed
to a non-existent plan and abend !

Thanks
Paulo

--
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: What are types of "Work" in SMF 30 record?

[Elliot, David]

That refers to the SMF30JNM field.

David Elliot
 
zSeries Software Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Charles Mills
Sent: Wednesday, August 11, 2010 10:11 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What are types of "Work" in SMF 30 record?

Thanks. The plot thickens. I got a private reply that quoted MXG
documentation that had T or TSU (but no TSO) and J or JOB for batch (but no
JESn).

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Mackenzie, Bruce
Sent: Wednesday, August 11, 2010 11:06 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What are types of "Work" in SMF 30 record?

I can only speak for our shop in which I only see these four.  

  JES2 
  OMVS 
  STC  
  TSO  

--
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: DFHSM QUESTION - RESTARTING SECONDARY SPACE MANAGEMENT

[willie bunter]

Mike,
 
I tried your suggestion about using "future time" and it worked.  Thanks a 
million.
 
Willie

--- On Wed, 8/11/10, Mike Schwab  wrote:


From: Mike Schwab 
Subject: Re: DFHSM QUESTION - RESTARTING SECONDARY SPACE MANAGEMENT
To: IBM-MAIN@bama.ua.edu
Received: Wednesday, August 11, 2010, 8:01 AM


You need to set it to a FUTURE TIME ( 2-5 minutes into the future) and
it should activate at that time.
Later, issue the commands with your permanent window.

Or maybe issue some of the volume migrate commands.

On Wed, Aug 11, 2010 at 9:48 AM, willie bunter  wrote:
> Good Morn To All,
>
> Because of an emergency (system response time) I had to curtail the Secondary 
> Space Management.  It started at 09:00 a.m. and I stopped it 10:30.  Since 
> the systeme response time problem has been resolved I issued the HSEND SETSYS 
> SECONDARYSPMGMTSTART(0900 2359) to restart the SSM however it hasn't kicked 
> off.
> Can SSM be restarted if it has been interrupted or do I have to wait for the 
> next day?
>
> Thanks in advance

-- 
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




--
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: auditor request question

[Ken Porowski]

But then you don't see the messages unless the screen saver is unlocked, 
message traffic does not count as activity for the screen saver. 

I had to get a security deviation to disable the screen saver on my console 
PC's.

-Original Message-
Mike Schwab

How about activating the System Console's PC's screen saver and putting a 
password on the PC?

On Wed, Aug 11, 2010 at 8:54 AM, Lizette Koehler  
wrote:
> Well, I might differ on the secure room part.
>
> Sometimes I have seen shops let cleaning people in to the secure room 
> that has the mainframe consoles (and other stuff) and then leave the 
> room because the cleaning materials odors are a bit strong.  In which 
> case, your secure room is no different as a lobby with mainframe consoles in 
> it.
>
> At least that is my opinion.
>
> Lizette

--
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: What are types of "Work" in SMF 30 record?

[Charles Mills]

Thanks. The plot thickens. I got a private reply that quoted MXG
documentation that had T or TSU (but no TSO) and J or JOB for batch (but no
JESn).

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Mackenzie, Bruce
Sent: Wednesday, August 11, 2010 11:06 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What are types of "Work" in SMF 30 record?

I can only speak for our shop in which I only see these four.  

  JES2 
  OMVS 
  STC  
  TSO  

--
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: What are types of "Work" in SMF 30 record?

[Mackenzie, Bruce]

I can only speak for our shop in which I only see these four.  

  JES2 
  OMVS 
  STC  
  TSO  

I would assume that if we were a JES3 shop, the batch would show up as JES3.  


 Bruce

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Charles Mills
Sent: Wednesday, August 11, 2010 9:50 AM
To: IBM-MAIN@bama.ua.edu
Subject: What are types of "Work" in SMF 30 record?

The documentation in Chapter 13 of z/OS V1R10.0 MVS System Management
Facilities (SMF) says "SMF30WID 4 EBCDIC Work type indicator for the address
space. The value identifies the type of address space that is being reported
on (for example: "STC" for started tasks and system address spaces, "TSO"
for TSO/E users, etc)."

The earlier paragraphs mention various types of "work": "a TSO/E session,
APPC/MVS transaction program, OMVS forked or spawned address space, started
task, or batch job."

What are all of the possible values for SMF30WID? I assume 'JOB' for a batch
job. What else?

Charles Mills

--
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


NOTICE OF CONFIDENTIALITY
This communication including any information transmitted with it is 
intended only for the use of the addressees and is confidential. 
If you are not an intended recipient or responsible for delivering 
the message to an intended recipient, any review, disclosure, 
conversion to hard copy, dissemination, reproduction or other use 
of any part of this communication is strictly prohibited, as is the 
taking or omitting of any action in reliance upon this communication. 
If you receive this communication in error or without authorization 
please notify us immediately by return e-mail or otherwise and 
permanently delete the entire communication from any computer, 
disk drive, or other storage medium.

If the above disclaimer is not properly readable, it can be found at 
www.td.com/legal
   
AVERTISSEMENT DE CONFIDENTIALITE   
Ce courriel, ainsi que tout renseignement ci-inclus, destiné uniquement 
aux destinataires susmentionnés,  est confidentiel.  Si vous 
n'êtes pas le destinataire prévu ou un agent responsable de la 
livraison de ce courriel, tout examen, divulgation, copie, impression, 
reproduction, distribution, ou autre utilisation d'une partie de ce 
courriel est strictement interdit de même que toute intervention ou 
abstraction à cet égard.  Si vous avez reçu ce message par erreur ou 
sans autorisation, veuillez en aviser immédiatement l'expéditeur par 
retour de courriel ou par un autre moyen et supprimer immédiatement 
cette communication entière de tout système électronique.

Si l'avis de non-responsabilité ci-dessus n'est pas lisible, vous 
pouvez le consulter à www.td.com/francais/legale

--
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: DFHSM QUESTION - RESTARTING SECONDARY SPACE MANAGEMENT

[Mike Schwab]

You need to set it to a FUTURE TIME ( 2-5 minutes into the future) and
it should activate at that time.
Later, issue the commands with your permanent window.

Or maybe issue some of the volume migrate commands.

On Wed, Aug 11, 2010 at 9:48 AM, willie bunter  wrote:
> Good Morn To All,
>
> Because of an emergency (system response time) I had to curtail the Secondary 
> Space Management.  It started at 09:00 a.m. and I stopped it 10:30.  Since 
> the systeme response time problem has been resolved I issued the HSEND SETSYS 
> SECONDARYSPMGMTSTART(0900 2359) to restart the SSM however it hasn't kicked 
> off.
> Can SSM be restarted if it has been interrupted or do I have to wait for the 
> next day?
>
> Thanks in advance

-- 
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: auditor request question

[Mike Schwab]

How about activating the System Console's PC's screen saver and
putting a password on the PC?

On Wed, Aug 11, 2010 at 8:54 AM, Lizette Koehler
 wrote:
> Well, I might differ on the secure room part.
>
> Sometimes I have seen shops let cleaning people in to the secure room that
> has the mainframe consoles (and other stuff) and then leave the room because
> the cleaning materials odors are a bit strong.  In which case, your secure
> room is no different as a lobby with mainframe consoles in it.
>
> At least that is my opinion.
>
> Lizette

-- 
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

Abend U4088(3EC)

[Paulo Roberto Leonardo Pereira]

Does anybody heard any solution for this abend before ?

I know that is related with memory (region). I run with REGION=0M, I'm
trying to run a PL/I/DB2 with the new SQL command called MERGE (with
MATCH(update) and NOT MATCHED(insert)) embedded in the program.
Interesting is: I changed several times the program and looks it does
not executed ! I changed the plan name also and still abend. I changed
to a non-existent plan and abend !

Thanks
Paulo

--
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

DFHSM QUESTION - RESTARTING SECONDARY SPACE MANAGEMENT

[willie bunter]

Good Morn To All,
 
Because of an emergency (system response time) I had to curtail the Secondary 
Space Management.  It started at 09:00 a.m. and I stopped it 10:30.  Since the 
systeme response time problem has been resolved I issued the HSEND SETSYS 
SECONDARYSPMGMTSTART(0900 2359) to restart the SSM however it hasn't kicked off.
Can SSM be restarted if it has been interrupted or do I have to wait for the 
next day?
 
Thanks in advance




--
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: auditor request question

[Greg Shirey]

Right, auditors always want to make suggestions.  The problem can come
if management decides to accept their suggestions at face value and
demand their implementation.

I worked at a place where the auditors suggested we should require 12
unique passwords before we allow a user to  repeat one.  Fortunately, my
management laughed at the idea.  And then, surprisingly, one of the
auditors admitted that he couldn't remember that many passwords, so he
just used the same password each time with a two digit "counter" at the
end which he upped each time he was forced to change.  Sheesh, talk
about do as I say, not as I do... 

Greg Shirey
Ben E. Keith Co. 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Hal Merritt
Sent: Wednesday, August 11, 2010 9:29 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: auditor request question

Let's not give the auditors too much credit. 

I think it fair to say that we all have ways to identify what operator
did what and hold that person accountable for his/her actions. More,
most all of us protect the consoles in some way. Perhaps 'industry
standard' is a fair description. 

What many auditors are guilty of doing is identifying a potential issue,
then framing their concerns in a proposed/required solution. That is,
the auditors in question may want to see that there is some due
diligence in protecting the console resource. Something simple that they
can understand and easily test.   

What may work for some is to brush the logon requirement aside and push
the auditors for a better statement of their concerns. Then some sort of
alternate solution can be proposed. This need to happen mid way through
the process and it may be too late for the OP.   

My $0.02 
 
 

--
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: ISPF: How best to change user variable ZRETMINL in ISPSPROF

[Jochen Roehrig]

Hi Robert

that's it! 
Shame on me: I knew the RETP, but I never recognized the 'OPTIONS'...

Kind regards
Jochen

--
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: auditor request question

[Hal Merritt]

Let's not give the auditors too much credit. 

I think it fair to say that we all have ways to identify what operator did what 
and hold that person accountable for his/her actions. More, most all of us 
protect the consoles in some way. Perhaps 'industry standard' is a fair 
description. 

What many auditors are guilty of doing is identifying a potential issue, then 
framing their concerns in a proposed/required solution. That is, the auditors 
in question may want to see that there is some due diligence in protecting the 
console resource. Something simple that they can understand and easily test.   

What may work for some is to brush the logon requirement aside and push the 
auditors for a better statement of their concerns. Then some sort of alternate 
solution can be proposed. This need to happen mid way through the process and 
it may be too late for the OP.   

My $0.02 
 
 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Joel C. Ewing
Sent: Tuesday, August 10, 2010 7:17 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: auditor request question

..snip

As others have pointed out, your auditors are all wet if they think that
practice is "standard".  Logging on to consoles that are in a restricted
access location that is always supervised is a nonsense requirement, and
if carried to its logical conclusion would require some mechanism for
enforced logoff every time an Operator's posterior left their chair --
totally impractical if you expect them to get anything useful done.

This would be a reasonable requirement only for consoles in a less
protected area that might be left unattended for an extended time.
-- 
Joel C. Ewing, Fort Smith, ARjcew...@acm.org

 
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

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

Re: auditor request question

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ken Porowski
> Sent: Wednesday, August 11, 2010 9:13 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: auditor request question
> 
> IIRC the SYSCONS (HMC Console) does not have logon capability so you
> should be able to do the reply from there in a worst case scenario 

You're right. You need to logon to the HMC itself, but you literally CANNOT do 
a LOGON from that "console". If you try, you get the message:
IEE847I LOGON NOT VALID FOR EXTENDED MCS CONSOLE

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

--
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: Oracle: The future is diskless!

[Ken Porowski]

Didn't they say the same thing about disk replacing tape?  Although that
does appear to be happening tape is still around and has it's uses. 

-Original Message-
Howard Brazee

On 11 Aug 2010 05:51:20 -0700, john.mck...@healthmarkets.com (McKown,
John) wrote:

>This is about some comments from Oracle EVP John Fowler. He indicates
that disk is dying. 
>He envisions it being replace by flash RAM. And not in our current mode

>of being an external I/O device, but actually being on the data bus of 
>the CPU. So all active data will be in non-volatile, directly 
>addressable, server memory. Backup will be on high speed (1,380 Tb/hour

>==~ 383 Mb/second) tape. Not related to this directly was talk about a
Sparc processor with 128 cores and 16,384 threads.

I remember Jerry Pournelle in Byte talking about how every year people
were talking about disk dying, but disk keeping getting cheaper and
better.   He opinioned that eventually it would happen, but way after
the pundits would predict.

IBM's use of the term DASD gets around saying "disk", but by the time
disk goes away, the term DASD may not quite apply either.

--
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: auditor request question

[Ken Porowski]

IIRC the SYSCONS (HMC Console) does not have logon capability so you
should be able to do the reply from there in a worst case scenario 

-Original Message-
Walt Farrell

On Tue, 10 Aug 2010 17:13:27 -0500, Pommier, Rex R.
 wrote:

>Ken,  (and any others who would like to weigh in on this),
>
>We were playing with this on our sandbox just now, and came across an 
>interesting scenario.  There are 2 of us here who are RACF SPECIAL.  As

>you know, if a SPECIAL user types in the wrong password too many times,

>instead of simply revoking their account, RACF will toss message 
>ICH301I to allow another attempt.  Unfortunately, the console and the 
>system apparently get caught in a twilight-zone type loop.  We couldn't

>log onto the console as a different ID to respond to the message 
>because all RACF logons were stacked up behind the message!  I tried to

>reply to the ICH301I message from an SDSF session and that, too, 
>locked.  Fortunately I was logged onto a different console already 
>(thanks, IBM, for not implementing console timeouts :-) ) and was able 
>to respond to the RACF message.  The affected console then rapid-fire 
>logged off and on each of the IDs that we had tried to log on to.
>
>I think that alone will probably be enough to convince management that 
>activating console logon requirements is a bad idea.
>
You might consider setting up automatic logon, and allowing the
automatic IDs the authority to issue the REPLY command.

--
Walt Farrell
IBM STSM, z/OS Security 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: auditor request question

[Walt Farrell]

On Tue, 10 Aug 2010 17:13:27 -0500, Pommier, Rex R.
 wrote:

>Ken,  (and any others who would like to weigh in on this),
>
>We were playing with this on our sandbox just now, and came across an
>interesting scenario.  There are 2 of us here who are RACF SPECIAL.  As
>you know, if a SPECIAL user types in the wrong password too many times,
>instead of simply revoking their account, RACF will toss message ICH301I
>to allow another attempt.  Unfortunately, the console and the system
>apparently get caught in a twilight-zone type loop.  We couldn't log
>onto the console as a different ID to respond to the message because all
>RACF logons were stacked up behind the message!  I tried to reply to the
>ICH301I message from an SDSF session and that, too, locked.  Fortunately
>I was logged onto a different console already (thanks, IBM, for not
>implementing console timeouts :-) ) and was able to respond to the RACF
>message.  The affected console then rapid-fire logged off and on each of
>the IDs that we had tried to log on to.
>
>I think that alone will probably be enough to convince management that
>activating console logon requirements is a bad idea.
>
You might consider setting up automatic logon, and allowing the automatic
IDs the authority to issue the REPLY command.

-- 
Walt Farrell
IBM STSM, z/OS Security 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: Oracle: The future is diskless!

[Howard Brazee]

On 11 Aug 2010 05:51:20 -0700, john.mck...@healthmarkets.com (McKown,
John) wrote:

>This is about some comments from Oracle EVP John Fowler. He indicates that 
>disk is dying. 
>He envisions it being replace by flash RAM. And not in our current mode of 
>being an 
>external I/O device, but actually being on the data bus of the CPU. So all 
>active data 
>will be in non-volatile, directly addressable, server memory. Backup will be 
>on high 
>speed (1,380 Tb/hour ==~ 383 Mb/second) tape. Not related to this directly was 
>talk 
>about a Sparc processor with 128 cores and 16,384 threads.

I remember Jerry Pournelle in Byte talking about how every year people
were talking about disk dying, but disk keeping getting cheaper and
better.   He opinioned that eventually it would happen, but way after
the pundits would predict.

IBM's use of the term DASD gets around saying "disk", but by the time
disk goes away, the term DASD may not quite apply either.

--
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: auditor request question

[Lizette Koehler]

Well, I might differ on the secure room part.

Sometimes I have seen shops let cleaning people in to the secure room that
has the mainframe consoles (and other stuff) and then leave the room because
the cleaning materials odors are a bit strong.  In which case, your secure
room is no different as a lobby with mainframe consoles in it.

At least that is my opinion.

Lizette


> C. Todd Burrell (CDC/OCOO/ITSO) (CTR) Wrote: 
> Subject: Re: auditor request question
> 
> Your auditors are wrong (as usual).  We do not require logons (except
> on
> the HMC) as all of the consoles are in a secure room requiring card key
> access.  So there has never been a need for console logons.
> 
> I would definitely not call this an "industry standard"...  If the
> consoles are in a secure room that should suffice all but the most
> stringent security standards.
> 
> C. Todd Burrell

--
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: Driver 76 End of Support

[Scott Rowe]

Ed, I typically have a very good dialog with our CE, and there is no one else 
in the company he would discuss this sort of thing with.  I am the one who 
schedules this sort of thing, not operations.  IBM did not go to the "top guy", 
they didn't tell anyone.  It looks like this notice came out in April, and we 
did a microcode upgrade in May, if IBM had even been aware of it they would 
have been able to do the Driver level upgrade in May, but they didn't.  It was 
I that coordinated bringing microcode up to date on all our equipment (DASD, 
Tape, CEC) in May, but I relied on the CE to select what levels to load.  I 
don't have time to do his job for him, and there is no one else to hand that 
off to, seeing that I AM the systems department (as far as z is concerned). 

>>> Ed Gould  8/10/2010 6:02 PM >>>
(sorry if this is a dup as the first email disappeared before I wanted to send 
it).
I always kept a dialog with IBM (and other vendors except one who will remain 
nameless) about items like drivers and other such "upgrades". They knew I could 
be counted on to see that it got done. IBM has changed (for the bad) over the 
years and they tend not to communicate with the customer as well as they use to.
After hearing about items that needed operations involvement, I always made 
sure they knew what was coming down and the length of outage that would be 
needed to allow them to schedule "upgrades". I was good friend of the head of 
operations and we always met for t least a half an hour a day to discuss 
everything. I would ask him if he knew anything coming up that I (or the 
department ) needed to be aware of so we didn't try and schedule things at the 
same time. It was painless and it worked.
IBM people I think handle it differently (and not for the good either) now 
days. I have got the impression that they go to the top guy and then let him 
decided scheduling. That does not work (at least from what I have seen) as you 
really need a person who communicates well and co-ordinates things (and people 
and departments). Upper management tends not to be detailed oriented so a lot 
of things seem to fall through the cracks and then all of a sudden you find you 
are 6 months behind in maintenance. 
I think I would (in your situation) go to IBM and let them know you are on 
their side and you can help get things done easier. I think they will be 
willing to try it out. But make sure you have the time needed to do this and if 
you do not then find someone that is in your systems department. It is way 
better to be proactive than reactive.
Ed

--- On Mon, 8/9/10, Scott Rowe  wrote:

From: Scott Rowe 
Subject: Driver 76 End of Support
To: IBM-MAIN@bama.ua.edu 
Date: Monday, August 9, 2010, 3:38 PM

I just got an email from my CE informing me that Driver 76 is going out of 
support, and that we should upgrade to Driver 79.  He can't come up with any 
exact date.  This seems like a rather vague notice to me, I thought we usually 
got better notice in the past.

Does anyone have any further info on this?


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 





--
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 

What are types of "Work" in SMF 30 record?

[Charles Mills]

The documentation in Chapter 13 of z/OS V1R10.0 MVS System Management
Facilities (SMF) says "SMF30WID 4 EBCDIC Work type indicator for the address
space. The value identifies the type of address space that is being reported
on (for example: "STC" for started tasks and system address spaces, "TSO"
for TSO/E users, etc)."

The earlier paragraphs mention various types of "work": "a TSO/E session,
APPC/MVS transaction program, OMVS forked or spawned address space, started
task, or batch job."

What are all of the possible values for SMF30WID? I assume 'JOB' for a batch
job. What else?

Charles Mills

--
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: Oracle: The future is diskless!

[Joel C. Ewing]

On 08/11/2010 07:50 AM, McKown, John wrote:
> http://www.theregister.co.uk/2010/08/11/oracle_on_storage/
> 
> This is about some comments from Oracle EVP John Fowler. He indicates that 
> disk is dying. 
>He envisions it being replace by flash RAM. And not in our current mode of 
>being an external 
>I/O device, but actually being on the data bus of the CPU. So all active data 
>will be in 
>non-volatile, directly addressable, server memory. Backup will be on high 
>speed 
>(1,380 Tb/hour ==~ 383 Mb/second) tape. Not related to this directly was talk 
>about 
>a Sparc processor with 128 cores and 16,384 threads.
> 
> John McKown
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets(r)
> 
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone * (817)-691-6183 cell
> john.mck...@healthmarkets.com * www.HealthMarkets.com

As always, such grandiose predictions will be subject to the realities
of cost effectiveness and reliability.

As long as DASD technology is able to continue to provide storage
capacity, access speeds, and reliability that are adequate for
real-world business applications at lower cost than this directly
connected RAM envisioned by Oracle, DASD will continue to play a
significant role.  Experience teaches that non-volatile storage
sometimes becomes volatile, and we might even find on the next unusually
large solar flare-up that non-magnetic storage may be more sensitive to
damage from solar EMP interference.

Another issue is that closer integration of massive storage with a
specific server introduces new problems in sharing data with other
servers or migrating to new servers.  Consider how trivially DASD
subsystems may be migrated by plugging in a few new fiber channels,
shutting down the old, and starting the new; versus having to physically
copy the data to internal storage on a new server while both new and old
are running, and keeping all data in sync until applications are
switched over and the old server is turned off.

High speed 1,380 Tb/hour backups are only useful if you can also
reliably restore from the backups.
-- 
Joel C. Ewing, Fort Smith, ARjcew...@acm.org

--
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: auditor request question

[Burrell, C. Todd (CDC/OCOO/ITSO) (CTR)]

Your auditors are wrong (as usual).  We do not require logons (except on
the HMC) as all of the consoles are in a secure room requiring card key
access.  So there has never been a need for console logons. 

I would definitely not call this an "industry standard"...  If the
consoles are in a secure room that should suffice all but the most
stringent security standards.   

C. Todd Burrell 
PMP, MCSE 2003:Security
Security+, Network+
Lead z/OS Systems Programmer 
ITSO 
(404) 723-2017 (Cell) 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Pommier, Rex R.
Sent: Tuesday, August 10, 2010 3:28 PM
To: IBM-MAIN@bama.ua.edu
Subject: auditor request question

Hi List,

Quick question.  Do you require your operations staff to log onto the
z/OS consoles?  Our auditors are claiming this is "industry standard"
and so we need to be doing it, even though our consoles are all behind
locked doors.

Thanks.

Rex

--
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: HSM list of backups of a dataset command

[MONTERO ROMERO, ENRIQUE ELOI]

Thanks Barry

It is just the command i was looking for, it also shows me the backup volume.

hlist dsname(MY.FILE.BACKUP) backup


See you
Enrique.

--
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: SMP/E packaging - using CALLLIBS

[Binyamin Dissen]

On Wed, 11 Aug 2010 08:49:39 -0400 Kurt Quackenbush  wrote:

:>Binyamin Dissen wrote:
:>> According to my understanding of the doc, by placing a 
 
:>> //*CALLLIBS=YES
 
:>> in the JCLIN input after a job card and before the LINKS step will cause 
SMP/E
:>> to allocate the SYSLIB DDDEF's and do a link of the specified module with 
the
:>> CALL option.

:>When SMP/E sees the //*CALLLIBS=YES comment (or the CALLLIBS operand on 
:>the ++JCLIN) it also looks for the //SYSLIB DD concatenation in the link 
:>edit steps.  It is the combination of the comment (or operand) and the 
:>SYSLIB concat that tells SMP/E the defined load modules should be linked 
:>with the CALL option.

:>Does your link edit step contain the //SYSLIB DD statement?

Yes.

At the end of a long stream of JCLIN:

//CMP20SRU  JOB 0,CLASS=A,MSGCLASS=H,NOTIFY=&SYSUID,REGION=0M   
//*CALLLIBS=YES 
//S3 EXEC LINKS,PARM='RENT,REUS,CALL'   
//SYSLMOD   DD DSN=SYS1.LOADAUTH,DISP=SHR   
//SYSLIB  DD DISP=SHR,DSN=CEE.SCEELKED  
//ALOAD   DD DSN=SYS1.ALOAD,DISP=SHR
//SYSLINDD *
  INCLUDE ALOAD()   
  ENTRY 
 NAME (R)
/*  

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: CPU time variance

[Staller, Allan]

IIRC there is a statement in the SMF manual about CPU time not being
repeatable.

HTH,

--
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

Oracle: The future is diskless!

[McKown, John]

http://www.theregister.co.uk/2010/08/11/oracle_on_storage/

This is about some comments from Oracle EVP John Fowler. He indicates that disk 
is dying. He envisions it being replace by flash RAM. And not in our current 
mode of being an external I/O device, but actually being on the data bus of the 
CPU. So all active data will be in non-volatile, directly addressable, server 
memory. Backup will be on high speed (1,380 Tb/hour ==~ 383 Mb/second) tape. 
Not related to this directly was talk about a Sparc processor with 128 cores 
and 16,384 threads.

John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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


--
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: SMP/E packaging - using CALLLIBS

[Kurt Quackenbush]

Binyamin Dissen wrote:
According to my understanding of the doc, by placing a 


//*CALLLIBS=YES

in the JCLIN input after a job card and before the LINKS step will cause SMP/E
to allocate the SYSLIB DDDEF's and do a link of the specified module with the
CALL option.


When SMP/E sees the //*CALLLIBS=YES comment (or the CALLLIBS operand on 
the ++JCLIN) it also looks for the //SYSLIB DD concatenation in the link 
edit steps.  It is the combination of the comment (or operand) and the 
SYSLIB concat that tells SMP/E the defined load modules should be linked 
with the CALL option.


Does your link edit step contain the //SYSLIB DD statement?

Kurt Quackenbush -- IBM, SMP/E Development

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

Re: auditor request question

[Don Imbriale]

The only shop I ever worked in that required logon for consoles did so not
for security reasons but for accountability.  Some operators had
'questionable' skills and at times dangerous commands were entered without
consulting the shift supervisor or someone on the systems staff.  This
sometimes led to serious problems.  Operators had to logon to the consoles
and they were responsible for any commands that were entered while they were
logged on, whether they entered them or not.  They got into the habit of
logging off whenever they stepped away from the console.  A real PITA, but
it satisfied management.

- Don Imbriale

On Tue, Aug 10, 2010 at 3:28 PM, Pommier, Rex R.
wrote:

> Hi List,
>
> Quick question.  Do you require your operations staff to log onto the
> z/OS consoles?  Our auditors are claiming this is "industry standard"
> and so we need to be doing it, even though our consoles are all behind
> locked doors.
>

--
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: auditor request question

[Robert Birdsall]

All of our consoles are SMCS consoles accessed via telnet (SSL).
They all require logon.  When we had physical consoles cabled to a controller 
we did not require logon.

Our management decided that the operators should work in the new 
datacenter (before we had any production equipment there).  This did have 
the desirable side effect that we learned that there was no longer any reason 
for the operators to be physically near the machine room (printing has been 
moved to the financial center, tapes are all virtual, ...).

--
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

FORCE thread on IBM-Main

[Peter Relson]

Greg,

There's a thread with subject: Re: STC is canceled and forced, but still 
won't go away

And this append:
Before you force any address space that has threads in DB2 you should kill 
the threads otherwise you get this situation. With a DB2 monitor you 
should be able to identify and kill the thread. 


Jon L. Veilleux 
veilleu...@aetna.com 
(860) 636-9179 

Any mention of "force" catches my attention. Any idea what this is 
referring to? Some DB2 memterm resmgr that is "waiting"?

Peter
rel...@us.ibm.com 
 1-845-435-83908+295-8390

--
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: ISPF: How best to change user variable ZRETMINL in ISPSPROF

[Robert Birdsall]

>From the ISPF command line, type RETP 
This brings up a panel that allows selecting previous commands (like retrieve n 
times).  It also has an Options menu at the top.  That menu looks like this:
1. Set minimum number of characters saved in retrieve stack
2. Select cursor position for retrieve
3. Exit
You can set the minimum number of characters for retrieve using the 1st 
option.

Note:  I tie RETP to PF24 - it is very useful for issuing the same sequence of 
commands (possible slightly altered) multiple times.

On Tue, 10 Aug 2010 09:51:28 -0500, Jochen Roehrig 
 wrote:

>Hi
>
>I wonder how TSO/ISPF users could change variables that are stored in
>ISPSPROF, esp. ZRETMINL. This variable has been set systemwide with
>RETRIEVE_MINIMUM_LENGTH using the ISPF Configuration Table.
>
>Thanks in advance
>Jochen
>
>--
>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: CPU time variance

[Scott Chapman]

I'm  not familiar with any variability issues that may arise out of 
running under z/VM but I would guess that guest systems might find 
more CPU variability than when running just under PR/SM.  But that's 
just a guess.

My experience has been that when we moved from z900 to z9s we 
saw an increase in CPU time variation.  When we moved from z9s to 
z10s we saw a larger increase in that variation.  I believe the reason 
for this is the increased sensitivity to processor cache misses.  (E.G. 
memory speed is not keeping up with CPU speed.)

I've seen 10% variations on my z10s, but primarily when they're more 
heavily loaded.  At some point I'd like to do a bit of studying on that 
and attempt to correlate the variation back to the numbers from HIS, 
but I haven't done that yet.

--
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