Re: Simple iinventory control products?

[Raja Mohan]

out of all the software mentioned, I did not see anyone noting ISC software. 
They do have excellent inventory software, If you were to evaluate I highly 
recommend looking in to e-Gen suite. I have no affiliation with them, except as 
a user of the software.

http://www.iscsoftware.com/Welcome.aspx

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

Re: zSeries Manpower Sizing

[Timothy Sipples]

Bart Grijn writes:
>There are large shops that run large mainframes, but they likely run
>other platforms as well and a large part of the manpower will be
>shared across platforms.

That's an excellent point. There's a common accounting measurement (FTEs =
Full-Time Equivalents) used to tally up labor effort when you have
particular individuals working on multiple projects and to provide a level
of abstraction in measurements. That said, a lot of organizations, if they
calculate FTEs, do it badly.

For example, I've seen many cases where the "mainframe team" ends up with
problem determination responsibility for non-specific IT issues. They might
be counted as mainframe FTEs, but they spend much or most of their time
providing network support, desktop support, etc. If FTE calculations were
based on problem outcomes and root causes rather than who happened to take
the call, that'd probably be useful.


Timothy Sipples
Resident Enterprise Architect (Based in Singapore)
E-Mail: timothy.sipp...@us.ibm.com

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Ed Gould]

The analyst has to have the numbers for it is he(she) that is  
designing the system.

He is supposed to be the giver of the grail.
The real issue is which analyst. There are several different types  
business, system and a few others.

The delineation is supposed to be the job description.
The real problem is who's pervue does it come under if it is no one.

Ed

On Feb 17, 2012, at 7:03 PM, Frank Swarbrick wrote:

But who has the responsibility?  This seems something that a system  
programmer, with some good analysis tools, should do.  Or the  
system itself should be such that it can do it's own analysis.   
After all, is that not what computers are for?


Frank






From: John Gilmore 
To: IBM-MAIN@bama.ua.edu
Sent: Friday, February 17, 2012 5:21 PM
Subject: Re: Archaic allocation in JCL (Was: Physical record size  
query)


Frank Swabrick wrote:


| No, I'm not expecting a real answer to that question.
| Just trying to point out why it's hard, to say the least,
| to know how to size files of this type.


The question itself has not been very well formulated.

No one, I hope and suppose, sizes files directly in cylinders, tracks
or megabytes.  These are derived quantities.  One begins with record
types, their individual sizes, and their expected volumes/counts.

Initially one has only estimates, often poor ones, of
transaction/processing volumes, but these estimates can be improved
incrementally by collecting statistics of the volumes actually
experienced during processing and then analyzing these data..

That this is not much done does not been that it cannot or should not
be done.

Adequate capacity planning and even many design decisions are
impossible without the systematic collection and analysis of such
information.

John Gilmore, Ashland, MA 01721 - USA

- 
-

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





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


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

'SYS1.PARMLIB(ALLOCxx)'

[Paul Schuster]

Hi:

Is it possible to dynamically (from a program) determine some of the settings 
(or defaults) in SYS1.PARMLIB(ALLOCxx)'? I am interested in determining the SVC 
99 defaults.

Thank you.

Paul

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

Re: Authorized functions

[Scott Ford]

Really ? The command line vs a GUILinux terminal session and cms virtually 
look alike except for the commands..

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Feb 17, 2012, at 2:16 PM, "Shmuel Metz (Seymour J.)" 
 wrote:

> In <1329430553.61141.yahoomail...@web164510.mail.gq1.yahoo.com>, on
> 02/16/2012
>   at 02:15 PM, Scott Ford  said:
> 
>> I loved VM/CMS and like Linux really well, close my eyes they are
>> kissing cousins
> 
> ?
> 
> I don't see any point of similarity. Not the API, not the file system,
> not the shells.
> 
> -- 
> 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: INFO IBM-MAIN

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

Re: Authorized functions

[Lindy Mayfield]

Based on my notes about this from previous posts, an entry in Ikjtsoxx would 
allow a Rexx program to "call" an authorized TSO program, then if necessary it 
can use ikjct44 to access any variables.

For example "CALL *(MYAUTH)" "myparms"

Lindy   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Thursday, February 16, 2012 8:33 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Authorized functions

>Do i create an entry in ikjtso00 for the STC program

No.

>Do I create an entry in ikjtso00 for the clist name

No. 
 
-- 
 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: INFO IBM-MAIN

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

Re: IEBCOPY with I/O error on SYSIN

[J R]

I would have thought that the effect of a dummy, empty or omitted SYSIN 
is perfectly well known.  Moreover, its "shortcut" functionality is not limited 
to compress operations.  

More to the point, a malfunctioning SYSIN dataset is "none of the above" 
and it makes no sense to interpret it as such.  

 > Date: Thu, 16 Feb 2012 16:27:17 +
> From: mike.wawio...@barclays.com
> Subject: Re: IEBCOPY with I/O error on SYSIN
> To: IBM-MAIN@bama.ua.edu
> 
> This behaviour gives a simple, and little known/used, method of running a 
> compress without control cards.
> 
> 1. Allocate SYSUT1 to your PDS
> 2. SYSUT2 DSN=*.SYSUT1
> 3. Omit SYSIN
> 
> Runs a compress of SYSUT1
> 
> Regards, 
> Mike 
> Mike Wawiorko
> Global z Connectivity and Automation Engineering
> Global Technology Infrastructure and Services
> Barclays Bank
> Ground Floor (B4), Turing House, Radbroke Hall, WA16 9EU (Mail Van 49)
> Tel: +44(0)1565 615415 or internal 7-2000-5415
> Mobile:  07824527120
> Email: mailto:mike.wawio...@barclays.com
> P Please consider the environment before printing this e-mail
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Mary Anne Matyaz
> Sent: 16 February 2012 12:12
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEBCOPY with I/O error on SYSIN
> 
> Paul,
> IEBCOPY is documented (and functions) as generating a SYSIN if none exists, 
> if it's dummied, or if it's an empty file. Not sure what category a 'bad' 
> file fits into, but I would guess it's essentially 'omitted'. 
> 
> If you feel strongly about it you could open a Share requirement. 
> 
> 
> From DFP Utilities: 
> 
> "When the SYSIN DD statement is a DD DUMMY, points to an empty file, or is 
> omitted, IEBCOPY will generate a COPY statement that allows you to run 
> IEBCOPY without supplying a control statement data set for SYSIN."
> 
> MA
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@bama.ua.edu with the message: INFO IBM-MAIN
> This e-mail and any attachments are confidential and intended
> solely for the addressee and may also be privileged or exempt from
> disclosure under applicable law. If you are not the addressee, or
> have received this e-mail in error, please notify the sender
> immediately, delete it from your system and do not copy, disclose
> or otherwise act upon any part of this e-mail or its attachments.
> 
> Internet communications are not guaranteed to be secure or
> virus-free.
> The Barclays Group does not accept responsibility for any loss
> arising from unauthorised access to, or interference with, any
> Internet communications by any third party, or from the
> transmission of any viruses. Replies to this e-mail may be
> monitored by the Barclays Group for operational or business
> reasons.
> 
> Any opinion or other information in this e-mail or its attachments
> that does not relate to the business of the Barclays Group is
> personal to the sender and is not given or endorsed by the Barclays
> Group.
> 
> Barclays Bank PLC. Registered in England and Wales (registered no.
> 1026167).
> Registered Office: 1 Churchill Place, London, E14 5HP, United
> Kingdom.
> 
> Barclays Bank PLC is authorised and regulated by the Financial
> Services Authority.
> 
> --
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: zSeries Manpower Sizing

[Gibney, Dave]

Isn't CICS via VTAM behind many ATMs :)

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Tony's Comcast account
> Sent: Friday, February 17, 2012 11:31 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: zSeries Manpower Sizing
> 
> Wow, imagine running a PCI application on USS.  ;-)
> 

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

Re: REXX IEBCOPY Continuation?

[Shmuel Metz (Seymour J.)]

In
,
on 02/15/2012
   at 03:58 PM, Skip Robinson  said:

>I believe that IEBCOPY (and some/all? of the old DFP utilities)
>consider anything in column 1 to be a label.

Some, including IEBCOPY, but not all. But when you're comparing a
working batch file to a failing Rexx program, it's always a good idea
to see whether the respective inputs are *exactly* the same.
 
-- 
 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: INFO IBM-MAIN

Re: Authorized functions

[Shmuel Metz (Seymour J.)]

In <1329430553.61141.yahoomail...@web164510.mail.gq1.yahoo.com>, on
02/16/2012
   at 02:15 PM, Scott Ford  said:

>I loved VM/CMS and like Linux really well, close my eyes they are
>kissing cousins

?

I don't see any point of similarity. Not the API, not the file system,
not the shells.
 
-- 
 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: INFO IBM-MAIN

Re: Archaic allocation in JCL (Was: Physical record size query)

[Shmuel Metz (Seymour J.)]

In
,
on 02/17/2012
   at 12:50 PM, John Gilmore  said:

>is not really wrongheaded.  It is an unfortunate oversimplification
>for real DASD.

Not if you were only discussing conversion of the SPACE parameter. I
agree that carrying over BLKSIZE from generation to generation is
ghastly, albeit far too common.
 
-- 
 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: INFO IBM-MAIN

Re: Authorized functions

[Shmuel Metz (Seymour J.)]

In <1329428012.66311.yahoomail...@web164507.mail.gq1.yahoo.com>, on
02/16/2012
   at 01:33 PM, Scott Ford  said:

>but no normal program, even if APF authorized can invoke the TMP. 
>It wants to run as the job step task, and that's difficult.

In what way is it difficult? What do you need beyond a MODESET and an
ATTACH?

>In particular, while you can have more than one job step task in 
>an address space, the TMP and REXX won't stand for it.

They have no choice. As I recall, by the time login completes there
are three jobstep TCB's.
 
-- 
 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: INFO IBM-MAIN

Re: Authorized functions

[Shmuel Metz (Seymour J.)]

In
,
on 02/16/2012
   at 03:40 PM, Chris Craddock  said:

>Yes, exactly right  on both counts. Don't forget that TSO is older
>than dirt

It's not as old as CMS, which some of you like. For that matter, EUnix
is rather long in the tooth.
 
-- 
 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: INFO IBM-MAIN

Re: Authorized functions

[Shmuel Metz (Seymour J.)]

In <3403779024688147.wa.paulgboulderaim@bama.ua.edu>, on
02/16/2012
   at 06:54 PM, Paul Gilmartin  said:

>Ah, for something like the DIAL command in VM!

Be carefull what you ask for; you might get it, along with operators
who don't grasp the distinctions among RESET, DISCONNECT and LOGOFF
:-(
 
-- 
 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: INFO IBM-MAIN

Re: Debug TSO through ISPF panels installation

[Shmuel Metz (Seymour J.)]

In
,
on 02/16/2012
   at 09:00 AM, Alvaro Guirao Lopez  said:

>Subject: Debug TSO through ISPF panels installation

Don't confuse TSO with ISPF. There are debugging tools for TSO
applications that do not deal well with ISPF and there are debugging
tools specific to ISPF applications that don't deal well with non-ISPF
applications called via the TSO command or ISPF option 6.

>I'm installing a product in a client and when I invoked the primary
>panel of the installation, one of the selections don't do anything
>when I select it with an 's'.

Have you tried the ISPF diagnostic facilities, normally under option
7?

>I want to debug the TSO navigation,

There is no such thing. Do you mean ISPF panel navigation? If so, I'd
suggest an ISPF trace.

>I see once how to activate a trace online with a TSO command,

Perhaps you're thinking of TSO TEST, but it's not appropriate for most
ISPF issues.

>If you have any other suggestions will be much appreciated.

There are mailing lists for ISPF and for TSO, but this list is also a
suitable forum.
 
-- 
 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: INFO IBM-MAIN

Re: IEBCOPY with I/O error on SYSIN

[Shmuel Metz (Seymour J.)]

In <9289112425599854.wa.maryanne4psugmail@bama.ua.edu>, on
02/16/2012
   at 06:12 AM, Mary Anne Matyaz  said:

>Not sure what category a 'bad' file fits into, but I would guess 
>it's essentially 'omitted'. 

That would be broken behavior.
 
-- 
 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: INFO IBM-MAIN

Re: IEBCOPY with I/O error on SYSIN

[Shmuel Metz (Seymour J.)]

In
,
on 02/16/2012
   at 04:27 PM, Mike Wawiorko  said:

>This behaviour

What behavior? The bevior Paul described, or the behavior in your
example? They're not the same.

>"When the SYSIN DD statement is a DD DUMMY, points to an empty file,
>or is omitted, IEBCOPY will generate a COPY statement that allows
>you to run IEBCOPY without supplying a control statement data set
>for SYSIN."

Paul had a SYSIN and it was neither empty nor a DUMMY.
 
-- 
 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: INFO IBM-MAIN

Re: REXX IEBCOPY Continuation?

[Shmuel Metz (Seymour J.)]

In
<84ea18831601b6429e578236ae239b01a4c7eaa...@eagnmnsxmb07.usa.dce.usps.gov>,
on 02/15/2012
   at 03:03 PM, "Hansen, Dave L - Eagan, MN" 
said:

>   Batch works fine because of the sysin DD:

No, it works fine because you have a leading blank, unlike what your
Rexx code wrote.
 
-- 
 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: INFO IBM-MAIN

Re: Authorized functions

[Shmuel Metz (Seymour J.)]

In ,
on 02/16/2012
   at 04:14 PM, "McKown, John"  said:

>CMS and XEDIT can easily bury TSO/ISPF.

While I would love to see an XEDIT port to TSO, ISPF/PDF EDIT does
have a few nice features that XEDIT is missing, e.g., the ditintion
between ("<", ">") and ("(", ")") shifts.

>The only thing better is Linux/gvim .

The road to which is paved with good intensions. Somebody should
market a current ISPF clone for Linux.
 
-- 
 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: INFO IBM-MAIN

Re: Archaic allocation in JCL (Was: Physical record size query)

[Shmuel Metz (Seymour J.)]

In <0987218410888335.wa.paulgboulderaim@bama.ua.edu>, on
02/17/2012
   at 11:02 AM, Paul Gilmartin  said:

>It would seem to me that when the time came to convert from 3330 to
>3350 (e.g.), the simple path would have been to replace "TRK" with
>"13030" 

That would have left a lot of slack. Possibly that would have been a
good thing.
 
-- 
 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: INFO IBM-MAIN

Re: 5 Byte Device Addresses?

[Shmuel Metz (Seymour J.)]

In , on 02/16/2012
   at 08:23 PM, "Robert A. Rosenberg"  said:

>No Bill is right.

No.

>OS/VS2 Release 2 WAS MVS 

But MVS wasn't OS/VS2 Release 2.

>like OS/VS2 Release 1 was SVS.

The difference is that SVS was *only* release 1; MVS was *not* only
release 2.

>SVS was OS/360 MVT with Virtual Addresses

That depends on what "was" was. SVS was missing OS/360 component and
had some significant differences from OS/360 MVT over and above
paging.

BTDT,GTS
 
-- 
 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: INFO IBM-MAIN

Re: 5 Byte Device Addresses?

[Shmuel Metz (Seymour J.)]

In
<77142d37c0c3c34da0d7b1da7d7ca346c...@nwt-s-mbx1.rocketsoftware.com>,
on 02/16/2012
   at 08:55 PM, Bill Fairchild  said:

>Seymour is right that we have had subchannel numbers since 1983
>instead of device addresses, but we have also had device numbers
>since 1983.

At the same time, and not necessarily with the same values.

>As John Gilmore explained in an earlier post, we used to have 12-bit
>device addresses composed of three parts, the channel number,
>control unit number within the channel, and device number within the
>control unit within the channel. 

It wasn't quite that clean; the uu part of the cuu split differently
depending on the control unit. The 8 bits of uu were presented on the
channel and it was up to the control units to recognize which belonged
to it and which didn't. Some control units had fewer than 16 devices,
some had more.
 
-- 
 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: INFO IBM-MAIN

Re: Archaic allocation in JCL (Was: Physical record size query)

[John Gilmore]

Frank,

Your point is well taken.  Often no one has the responsibility.

Still, while the system cannot analyze itself, it can include
data-collection machinery that greatly facilitates such analyses; and
this machinery is/should be the responsibility of those who design and
 maintain a system

--jg

On 2/17/12, Frank Swarbrick  wrote:
> But who has the responsibility?  This seems something that a system
> programmer, with some good analysis tools, should do.  Or the system itself
> should be such that it can do it's own analysis.  After all, is that not
> what computers are for?
>
> Frank
>
>
>
>
>>
>> From: John Gilmore 
>>To: IBM-MAIN@bama.ua.edu
>>Sent: Friday, February 17, 2012 5:21 PM
>>Subject: Re: Archaic allocation in JCL (Was: Physical record size query)
>>
>>Frank Swabrick wrote:
>>
>>
>>| No, I'm not expecting a real answer to that question.
>>| Just trying to point out why it's hard, to say the least,
>>| to know how to size files of this type.
>>
>>
>>The question itself has not been very well formulated.
>>
>>No one, I hope and suppose, sizes files directly in cylinders, tracks
>>or megabytes.  These are derived quantities.  One begins with record
>>types, their individual sizes, and their expected volumes/counts.
>>
>>Initially one has only estimates, often poor ones, of
>>transaction/processing volumes, but these estimates can be improved
>>incrementally by collecting statistics of the volumes actually
>>experienced during processing and then analyzing these data..
>>
>>That this is not much done does not been that it cannot or should not
>>be done.
>>
>>Adequate capacity planning and even many design decisions are
>>impossible without the systematic collection and analysis of such
>>information.
>>
>>John Gilmore, Ashland, MA 01721 - USA
>>
>>--
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>>
>>
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Gilmore, Ashland, MA 01721 - USA

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Frank Swarbrick]

But who has the responsibility?  This seems something that a system programmer, 
with some good analysis tools, should do.  Or the system itself should be such 
that it can do it's own analysis.  After all, is that not what computers are 
for?

Frank




>
> From: John Gilmore 
>To: IBM-MAIN@bama.ua.edu 
>Sent: Friday, February 17, 2012 5:21 PM
>Subject: Re: Archaic allocation in JCL (Was: Physical record size query)
> 
>Frank Swabrick wrote:
>
>
>| No, I'm not expecting a real answer to that question.
>| Just trying to point out why it's hard, to say the least,
>| to know how to size files of this type.
>
>
>The question itself has not been very well formulated.
>
>No one, I hope and suppose, sizes files directly in cylinders, tracks
>or megabytes.  These are derived quantities.  One begins with record
>types, their individual sizes, and their expected volumes/counts.
>
>Initially one has only estimates, often poor ones, of
>transaction/processing volumes, but these estimates can be improved
>incrementally by collecting statistics of the volumes actually
>experienced during processing and then analyzing these data..
>
>That this is not much done does not been that it cannot or should not
>be done.
>
>Adequate capacity planning and even many design decisions are
>impossible without the systematic collection and analysis of such
>information.
>
>John Gilmore, Ashland, MA 01721 - USA
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>
>

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

Re: Entry point on attach

[John Gilmore]

Gerhard has outlined what is available very well, but you seem to be
confusing load addresses with entry points and to be assuming that
there is/will be only one entry.

One, but only one, of the important uses of aliases is to associate
different aliases with different entries in the same load module |
program object.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[John Gilmore]

Frank Swabrick wrote:


| No, I'm not expecting a real answer to that question.
| Just trying to point out why it's hard, to say the least,
| to know how to size files of this type.


The question itself has not been very well formulated.

No one, I hope and suppose, sizes files directly in cylinders, tracks
or megabytes.  These are derived quantities.  One begins with record
types, their individual sizes, and their expected volumes/counts.

Initially one has only estimates, often poor ones, of
transaction/processing volumes, but these estimates can be improved
incrementally by collecting statistics of the volumes actually
experienced during processing and then analyzing these data..

That this is not much done does not been that it cannot or should not
be done.

Adequate capacity planning and even many design decisions are
impossible without the systematic collection and analysis of such
information.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Frank Swarbrick]

If that is not sarcasm than you've hopelessly lost me.
Frank




>
> From: Paul Gilmartin 
>To: IBM-MAIN@bama.ua.edu 
>Sent: Friday, February 17, 2012 3:57 PM
>Subject: Re: Archaic allocation in JCL (Was: Physical record size query)
> 
>On Fri, 17 Feb 2012 13:46:12 -0800, Frank Swarbrick wrote:
>
>>How many transactions am I going to post today?  How many on Monday.  What 
>>about Tuesday after a three day weekend?  What about Tuesday on a 3 day 
>>weekend 4 years from now?
>
>>Each "transactions" is 100 bytes.  We save the transactions for a year.  We 
>>are a brand new bank that has not yet processed any transactions.  How many 
>>megabytes should I define my transaction file?
>
>>No, I'm not expecting a real answer to that question.  Just trying to point 
>>out why it's hard, to say the least, to know how to size files of this type.
>
>Well, that's because you're posing the question in them PFCSK "megabytes".
>If you'd just think in cylinders like a good mainframer is supposed to, it 
>would
>be simple.
>
>--- gil
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>
>

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

Re: Entry point on attach

[Gerhard Postpischil]

On 2/17/2012 5:21 PM, Micheal Butz wrote:

Again if I do a attach with disp=no And r1 has the tcb
address I can look at the TCBRBP or relating CDE for the
loadpoint of the module


I'm not really sure what you're looking for. The CDE (or LPDE 
for an LPA module) points to another CDE (if it's an alias, 
a.k.a. minor entry), or an extent list. The CDE has the entry 
address, the XT list the load address and size.


If you are asking about an additional entry in the program, then 
ATTACH will find that only if it's an ALIAS entry in the load 
library. If it's not an ALIAS, and you have made some provision 
for finding the entry address programmatically, you can load the 
module before the ATTACH, and use IDENTIFY to create a name for 
the entry.


The IDENTIFY method may also be used to let you load the program 
prior to the ATTACH, so that you know the address, and attach 
with the fake name.


Gerhard Postpischil
Bradford, VT

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Paul Gilmartin]

On Fri, 17 Feb 2012 13:46:12 -0800, Frank Swarbrick wrote:

>How many transactions am I going to post today?  How many on Monday.  What 
>about Tuesday after a three day weekend?  What about Tuesday on a 3 day 
>weekend 4 years from now?

>Each "transactions" is 100 bytes.  We save the transactions for a year.  We 
>are a brand new bank that has not yet processed any transactions.  How many 
>megabytes should I define my transaction file?

>No, I'm not expecting a real answer to that question.  Just trying to point 
>out why it's hard, to say the least, to know how to size files of this type.

Well, that's because you're posing the question in them PFCSK "megabytes".
If you'd just think in cylinders like a good mainframer is supposed to, it would
be simple.

--- gil

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

Entry point on attach

[Micheal Butz]

Hi

Again if I do a attach with disp=no
And r1 has the tcb address I can look at the TCBRBP or relating CDE for the 
loadpoint of the module

Sent from my iPhone

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Frank Swarbrick]

Variable length records?




>
> From: Scott Ford 
>To: IBM-MAIN@bama.ua.edu 
>Sent: Friday, February 17, 2012 8:59 AM
>Subject: Re: Archaic allocation in JCL (Was: Physical record size query)
> 
>Gil,
>
>Worked with a math phd for a bunch of yrs and he preached records for 
>allocations, not cyls or tracks. I guess everyone has an opinion...
>
>Sent from my iPad
>Scott Ford
>Senior Systems Engineer
>www.identityforge.com
>
>
>
>On Feb 17, 2012, at 10:41 AM, Paul Gilmartin  wrote:
>
>> On Fri, 17 Feb 2012 09:59:13 -0500, Scott Ford wrote:
>>> 
>>> Me too, never even thought of megabytes until the pc slam dunk artists came 
>>> along, everyone I knew calculated their file size in tracks or cyls. As 
>>> someone tod me new world orderlol
>>> 
>> I would have expected that during technology transitions with a
>> mixture of DASD geometries in a shop, bytes or records would
>> have been the invariant metric of data set size, therefore the
>> most convenient.  Perhaps it was just bigotry, evident in the
>> characterization in the paragraph above: "We're dinos; we don't
>> do megabytes!"
>> 
>> But then there's volume capacity which, in megabytes, is not
>> invariant, even for a single volume of a single given model.
>> 
>> -- gil
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>
>

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Frank Swarbrick]

How many transactions am I going to post today?  How many on Monday.  What 
about Tuesday after a three day weekend?  What about Tuesday on a 3 day weekend 
4 years from now?

Each "transactions" is 100 bytes.  We save the transactions for a year.  We are 
a brand new bank that has not yet processed any transactions.  How many 
megabytes should I define my transaction file?

No, I'm not expecting a real answer to that question.  Just trying to point out 
why it's hard, to say the least, to know how to size files of this type.

Frank




>
> From: Edward Jaffe 
>To: IBM-MAIN@bama.ua.edu 
>Sent: Friday, February 17, 2012 7:57 AM
>Subject: Re: Archaic allocation in JCL (Was: Physical record size query)
> 
>On 2/17/2012 6:32 AM, Steve Comstock wrote:
>> On 2/17/2012 12:57 AM, Edward Jaffe wrote:
>>>
>>> TRKs and CYLs? Most of our allocations are in MEGs. Doesn't everyone do that
>>> these days?
>>>
>>> SPACE=(1,(5,1),RLSE),AVGREC=M Allocate in MEGs
>>>
>>
>> I would have thought allocations in records or thousands of records,
>> or millions of records, e.g.:
>>
>>   SPACE=(440,(100,5),RLSE),AVGREG=M
>>
>> allocate space for 100 million records of 440 bytes long.
>
>Like the folks in John McKown's shop, I have trouble dealing with space in 
>terms 
>of average record size and number of records. It seems overburdensome to have 
>to 
>worry about space at that level or detail. OTOH, I have no trouble at all 
>knowing how many megabytes I'll need! :-)
>
>-- 
>Edward E Jaffe
>Phoenix Software International, Inc
>831 Parkview Drive North
>El Segundo, CA 90245
>310-338-0400 x318
>edja...@phoenixsoftware.com
>http://www.phoenixsoftware.com/
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
>
>

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

Program entry point on Attached program

[Micheal Butz]

Hi,

 

I know that if a program is re-entrant a subsequent ATTACH will use that
address as the entry point.

 

How about a non-reentrant program

 

 

If I do a ATTACH DISP=NO is the attached program LOADED and if so is there a
way to find the entry point

 

 


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

FW: Assembler Control of SYSLOG Messages

[Fred Hoffman]

 

 

From: Robert Payne 
Sent: Friday, February 17, 2012 2:46 PM
To: Fred Hoffman
Subject: RE: Assembler Control of SYSLOG Messages

 

Looks like DESC code 11 on the WTO macro would work;

 

 
DESC=(descriptor code...) Specifies one or more descriptor codes as
decimal numbers in the range 1-16. Codes 1 to 6, 11 and 12 are mutually
exclusive. If more 
 than one of these codes are specified, the most significant one is
used (see below), the others are ignored. Code 7 can be assigned in
combination with any 
 other code.  When DESC is omitted, a descriptor code of 7 is
assumed. DESC is ignored if specified together with CONNECT (see below).
 
 Descriptor codes determine, along with other factors, the
presentation and retention attributes of a message. The meaning
associated with each descriptor code 
 is as follows:
 
 1System Failure: The message indicates an error that disrupts
system operations. To continue, the operator may have to re-IPL the
system or restart a major 
  subsystem.
 
 2Immediate Action Required: The message indicates that the
operator must perform an action immediately. Some tasks may be in a wait
state until the action is 
  performed, and system performance is affected.
 
 3Eventual Action Required: The message indicates that the
operator must perform an action eventually. No tasks are waiting for
action completion.
 
 4System Status: The message indicates the status of a system
task or of a hardware unit.
 
 5Immediate Command Response: The message is issued as a
response to a system command.
 
 6Job Status: The message indicates the status of a job or job
step.
 
 7Task-Related: The message is related to the processing of an
application or system program and is automatically DOMed by the system
when the related job 
  step ends after logging, if applicable.
 
  This descriptor code is assigned automatically when the
message is issued by a user task on its own behalf.
 
 8-10 Not used by z/VSE, ignored when specified.
 
 11   Critical Eventual Action Required: The message indicates that
the operator must perform an action eventually, and no tasks are waiting
for action completion. 
  However, the action is important enough for retaining the
message on the console screen until the action is completed.
 
 12   Important Information: The message contains important
information that must be displayed at a console, but does not require
any action in response.
 
 13-16 Reserved.

-Original Message-
From: Fred Hoffman 
Sent: Friday, February 17, 2012 2:42 PM
To: Robert Payne
Subject: FW: Assembler Control of SYSLOG Messages

 

 

From: vse-l-bounces+fhoffman=tad@lists.lehigh.edu
[mailto:vse-l-bounces+fhoffman=tad@lists.lehigh.edu] On Behalf Of
industryn...@winwholesale.com
Sent: Friday, February 17, 2012 2:10 PM
To: vs...@lists.lehigh.edu
Subject: Assembler Control of SYSLOG Messages

 

Here's hoping someone can help me out so I don't have to
research how this works.  We have an RPG-II batch program which invokes
an assembler routine both for file SPECIAL I/O and via the EXIT opcode.
When this program has a particular file open in update mode, the
assembler routine puts a message on the console which is both
highlighted and held to prevent it scrolling off the screen.  At the end
of the program the message is unhighlighted and unheld.  The following
is the calling code: 

ISOPEN   MVI   FSTSW,C'O'  FILE STATUS
SWITCH 
 MVI   WRTKEY,X'00' 
 MVC   WRTKEY+1(63),WRTKEY 
 MVI   CNSLTXT,C' ' 
 MVC   CNSLTXT+1(42),CNSLTXT   
 MVC   CNSLTXT(20),=C'FILE - XXX OPEN.' 
 MVC   CNSLTXT+7(7),FILNM   
 LAXR4,CNSLMSG 
 LAXR5,50   
 BAL   XR11,CNSOT   
 B GOOD 

...and the following is the console subroutine and
storage definitions.  I don't see where the assembler code makes any
distinction regarding highlighting and holding.  Hints?  Thanks. 

* 
* CONSOL OUTPUT SUBROUTINE 
* 
*R4  = ADDR OF FIELD TO BE DISPLAYED   
*R5  = LENGTH OF FIELD TO BE DISPLAYED 
*R11 = LINKAGE REGISTER   
*

Re: zSeries Manpower Sizing

[Scott Ford]

MIPs has been around for at least 20 yrs ..PCI not sure...

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Feb 17, 2012, at 2:30 PM, "Tony's Comcast account"  
wrote:

> Wow, imagine running a PCI application on USS.  ;-)
> 
> 
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
> Of R.S.
> Sent: Friday, February 17, 2012 1:25 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: zSeries Manpower Sizing
> 
> W dniu 2012-02-17 19:46, George Henke pisze:
>> tyvm, both Radoslaw again and Jihad.
>> 
>> I had Wikied it but all I got back was Payment Card Industry, not even
>> Peripheral Component Interconnect.  And that did not fit the context, as
>> Radoslaw noted.
>> 
>> Maybe you would like to update Wiki.
>> 
>> Now all I need to know is how PCI translates into MIPS and MSUs.
>> 
>> Maybe if I google LSPR.
> 
> It is not clearly described, but 1 PCI = 1 MIPS. PCI is another name for 
> MIPS. Note that MIPS is MISLEADING.
> 
> BTW: I have never seen PCI as a processor power unit anywhere with the 
> exception to LSPR web page and IBM posters.
> 
> BTW: I have several MIPS/PCI/MSU posters in my office, and none from 
> Playboy or Hustler magazine. Is it normal?
> 
> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> --
> Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
> przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by
> jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste
> adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej
> przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie
> zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo,
> prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale
> usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
> 
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee authorised
> to forward it to the addressee, be advised that any dissemination, copying,
> distribution or any other similar activity is legally prohibited and may be
> punishable. If you received this e-mail by mistake please advise the sender
> immediately by using the reply facility in your e-mail software and delete
> permanently this e-mail including any copies of it either printed or saved
> to hard drive. 
> 
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00,
> fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
> Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru
> Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
> Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w
> caoci wpacony) wynosi 168.410.984 zotych.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: zSeries Manpower Sizing

[Anne & Lynn Wheeler]

stars...@mindspring.com (Lizette Koehler) writes:
> PCI has to do with Payments for Credit Cards and their security.

PCI was somewhat in response to the cal. state data breach discloser
(and later other states) legislation.

we were tangentially involved being, brought in to help wordsmith
the cal. state electronic signature legislation ... some past posts
http://www.garlic.com/~lynn/subpubkey.html#signature

some of the electronic signature participants were also heavily into
privacy issues and had done detailed privacy surveys ... #1 issue kept
coming up "identity theft" of the kind involving fraudulent transactions
from data breaches of one sort or another (skimming, evesdropping,
database compromise; etc ... involving account number
harvesting). little or nothing appeared to being done about such
activity and they hoped that the publicity from data breach
notifications might prompt countermeasures ... in addition to providing
victims the opportunities to do something. part of the issues was that
the owners of the large databases/data-streams ... that had the breaches
... wouldn't be the victims of the fraudulent financial transactions.

in any case, since the passage of the cal. legislation there have been
numerous federal data breach notification bills introduced (none yet
passing), about equally divided between those with similar notification
requirements and those that would eliminate requirement for notification
(in some cases, partially justified on industry actions like PCI).

a couple long-winded recent posts going into related issues of broken
paradigm
http://www.garlic.com/~lynn/2012b.html#70 Four Sources of Trust, Crypto Not 
Scaling
http://www.garlic.com/~lynn/2012b.html#71 Password shortcomings
http://www.garlic.com/~lynn/2012b.html#94 public key, encryption and trust

-- 
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: INFO IBM-MAIN

Re: Does HBDELETE forces tape mount??

[Mike Schwab]

If you issue the HDEL command againsts a migrated dataset, the older
backups are deleted and the last backup is usually deleted after 60
days.  If that is fast enough, you don't need to issue the HBDELETE
command.

On Fri, Feb 17, 2012 at 9:17 AM, Staller, Allan  wrote:
> HDELETE
>
> 
> and how about ML2 dsns??? If i do HRECALL against MIGRAT2 volume ??? is
> there a way of just invalid the entry in MCDS avoiding tape mounting ??
> 
>

-- 
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: INFO IBM-MAIN

Re: Archaic allocation in JCL (Was: Physical record size query)

[Mike Schwab]

What i usually do, is once I get the file created, is to set the
allocation to 10% more than the file size and secondary extents to 10%
of the file size.

First time around, CYL,(100,100),RLSE or some SWAG.

-- 
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: INFO IBM-MAIN

Re: What is CA-SRAM and what is it used for.

[Thomas Lawrence]

Thanks for the information. :D

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

Looking for (retired) IBM CE with System/360 experience

[Rich Alderson]

The Living Computer Museum project of Vulcan, Inc., is looking to hire an
expert on IBM System/360 hardware maintenance to guide the restoration of
a 360/40 which we have acquired.  The official job posting can be found at

https://jobs.vulcan.com/

as Sr. Systems Engineer (Vintage), job ID 2258, posted 13 Feb 2012.

(There doesn't appear to be any way to provide a link directly to the posting
 because of the programming model used.)

I'm happy to answer questions, in the group or offline.


Rich Alderson
Vintage Computing Sr. Systems Engineer
Vulcan, Inc.
505 5th Avenue S, Suite 900
Seattle, WA 98104

mailto:ri...@vulcan.com
mailto:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

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

Re: Authorized functions

[Tony Harminc]

On 16 February 2012 19:32, Walt Farrell  wrote:
> On Thu, 16 Feb 2012 14:42:01 -0700, Steve Comstock  
> wrote:
>
>>OK, just being a little crazy, what about EXEC PGM=MYASMPGM
>>which "does some stuff" and then does XCTL to the TMP? Would
>>that work?
>
> The last time I tried it (28+ years ago before I joined IBM) it was possible 
> to do that, if you were careful to pass all the proper data. I have no idea 
> if it would still work, nor whether IBM would consider it "supported".

A big chunk of the problem is that the TMP used to be just an
application program with some minor requirements to conform to a
slightly unusual environment. IBM had a book called Guide to Writing a
Terminal Monitor Program or a Command Processor, that explained in
detail how to write your own TMP if you wanted to.

At some point - I believe when TSO/E arrived - IBM effectively
withdrew the ability to write a TMP, by undocumenting some of the
required new interfaces, and making the existing code OCO, so there
were no examples. Some of this had to do with the security and APF
auth issues we are discussing, but certainly not all. I think probably
the timing was just bad; it was around the time of peak OCO-fever in
IBM, and I imagine there were hoops to go through in order to make any
new module or even control block non-OCO, even if it meant withdrawing
existing documented function.

But I digress again... The TMP is no longer just an application
program; it is part of the OS and its security infrastructure, and
although parts of how it works are documented, some is not at all,
much is not well, and some of the documentation makes incorrect claims
about the actual behaviour.

I very much doubt that a TMP can be invoked other than as the single
job step task in an address space; certainly not if you want to run
authorized commands or programs under it. XCTL does not provide
sufficient isolation from potentially dangerous unauthorized code.

Tony H.

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

Re: zSeries Manpower Sizing

[Tony's Comcast account]

Wow, imagine running a PCI application on USS.  ;-)



  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of R.S.
Sent: Friday, February 17, 2012 1:25 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: zSeries Manpower Sizing

W dniu 2012-02-17 19:46, George Henke pisze:
> tyvm, both Radoslaw again and Jihad.
>
> I had Wikied it but all I got back was Payment Card Industry, not even
> Peripheral Component Interconnect.  And that did not fit the context, as
> Radoslaw noted.
>
> Maybe you would like to update Wiki.
>
> Now all I need to know is how PCI translates into MIPS and MSUs.
>
> Maybe if I google LSPR.

It is not clearly described, but 1 PCI = 1 MIPS. PCI is another name for 
MIPS. Note that MIPS is MISLEADING.

BTW: I have never seen PCI as a processor power unit anywhere with the 
exception to LSPR web page and IBM posters.

BTW: I have several MIPS/PCI/MSU posters in my office, and none from 
Playboy or Hustler magazine. Is it normal?


-- 
Radoslaw Skorupka
Lodz, Poland


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

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

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

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

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

Re: zSeries Manpower Sizing

[Jihad Kawkabani]

George,
If you follow this Link: 
https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprzOS11MIJuly2010?OpenDocument&pathID=
It will give you a table in which you will see PCI values and their MSU 
equivalent for all Supported zSeries processors. At the top of the Web page 
there is a link to "LSPR measurement methodology"  explaining how these 
measurements are taken.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of George Henke
> Sent: Friday, February 17, 2012 01:46 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: zSeries Manpower Sizing
> 
> tyvm, both Radoslaw again and Jihad.
> 
> I had Wikied it but all I got back was Payment Card Industry, not even
> Peripheral Component Interconnect.  And that did not fit the context, as
> Radoslaw noted.
> 
> Maybe you would like to update Wiki.
> 
> Now all I need to know is how PCI translates into MIPS and MSUs.
> 
>

Regards,
Jihad K Kawkabani
Progressive Insurance
IT Systems Engineer Consultant
Voice: 440.395.0740
Cell: 440.465.2969

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

Re: zSeries Manpower Sizing

[R.S.]

W dniu 2012-02-17 19:46, George Henke pisze:

tyvm, both Radoslaw again and Jihad.

I had Wikied it but all I got back was Payment Card Industry, not even
Peripheral Component Interconnect.  And that did not fit the context, as
Radoslaw noted.

Maybe you would like to update Wiki.

Now all I need to know is how PCI translates into MIPS and MSUs.

Maybe if I google LSPR.


It is not clearly described, but 1 PCI = 1 MIPS. PCI is another name for 
MIPS. Note that MIPS is MISLEADING.


BTW: I have never seen PCI as a processor power unit anywhere with the 
exception to LSPR web page and IBM posters.


BTW: I have several MIPS/PCI/MSU posters in my office, and none from 
Playboy or Hustler magazine. Is it normal?



--
Radoslaw Skorupka
Lodz, Poland


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

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


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


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

Re: zSeries Manpower Sizing

[George Henke]

Wiki did not have that one either, just Payment Card Industry.

Maybe someone will care to update Wiki for posterity.

On Fri, Feb 17, 2012 at 2:04 PM, John Gilmore wrote:

> 'PCI' does not have a single, definitive interpretation.
>
> It is yet another overloaded acronym, one that, for sysprogs, often
> means 'Program-Controlled Interrupt'.
>
> On 2/17/12, George Henke  wrote:
> > tyvm, both Radoslaw again and Jihad.
> >
> > I had Wikied it but all I got back was Payment Card Industry, not even
> > Peripheral Component Interconnect.  And that did not fit the context, as
> > Radoslaw noted.
> >
> > Maybe you would like to update Wiki.
> >
> > Now all I need to know is how PCI translates into MIPS and MSUs.
> >
> > Maybe if I google LSPR.
> >
> > On Fri, Feb 17, 2012 at 11:04 AM, Jihad Kawkabani <
> > jihad_k_kawkab...@progressive.com> wrote:
> >
> >> PCI - Processor Capacity Index - First calculated/Introduced with the
> z/OS
> >> V1R9 LSPR(Large Systems Performance Reference).
> >>
> >> > -Original Message-
> >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> >> > Behalf Of George Henke
> >> > Sent: Friday, February 17, 2012 08:29 AM
> >> > To: IBM-MAIN@bama.ua.edu
> >> > Subject: Re: zSeries Manpower Sizing
> >> >
> >> > tyvm, Timothy, for your expert analysis.
> >> >
> >> > Please pardon my ignorance, but what is a PCI?
> >> >
> >> >
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >>
> >
> >
> >
> > --
> > George Henke
> > (C) 845 401 5614
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> John Gilmore, Ashland, MA 01721 - USA
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>



-- 
George Henke
(C) 845 401 5614

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

Re: zSeries Manpower Sizing

[John Gilmore]

'PCI' does not have a single, definitive interpretation.

It is yet another overloaded acronym, one that, for sysprogs, often
means 'Program-Controlled Interrupt'.

On 2/17/12, George Henke  wrote:
> tyvm, both Radoslaw again and Jihad.
>
> I had Wikied it but all I got back was Payment Card Industry, not even
> Peripheral Component Interconnect.  And that did not fit the context, as
> Radoslaw noted.
>
> Maybe you would like to update Wiki.
>
> Now all I need to know is how PCI translates into MIPS and MSUs.
>
> Maybe if I google LSPR.
>
> On Fri, Feb 17, 2012 at 11:04 AM, Jihad Kawkabani <
> jihad_k_kawkab...@progressive.com> wrote:
>
>> PCI - Processor Capacity Index - First calculated/Introduced with the z/OS
>> V1R9 LSPR(Large Systems Performance Reference).
>>
>> > -Original Message-
>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
>> > Behalf Of George Henke
>> > Sent: Friday, February 17, 2012 08:29 AM
>> > To: IBM-MAIN@bama.ua.edu
>> > Subject: Re: zSeries Manpower Sizing
>> >
>> > tyvm, Timothy, for your expert analysis.
>> >
>> > Please pardon my ignorance, but what is a PCI?
>> >
>> >
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>>
>
>
>
> --
> George Henke
> (C) 845 401 5614
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Gilmore, Ashland, MA 01721 - USA

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

Re: zSeries Manpower Sizing

[George Henke]

tyvm, both Radoslaw again and Jihad.

I had Wikied it but all I got back was Payment Card Industry, not even
Peripheral Component Interconnect.  And that did not fit the context, as
Radoslaw noted.

Maybe you would like to update Wiki.

Now all I need to know is how PCI translates into MIPS and MSUs.

Maybe if I google LSPR.

On Fri, Feb 17, 2012 at 11:04 AM, Jihad Kawkabani <
jihad_k_kawkab...@progressive.com> wrote:

> PCI - Processor Capacity Index - First calculated/Introduced with the z/OS
> V1R9 LSPR(Large Systems Performance Reference).
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> > Behalf Of George Henke
> > Sent: Friday, February 17, 2012 08:29 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: zSeries Manpower Sizing
> >
> > tyvm, Timothy, for your expert analysis.
> >
> > Please pardon my ignorance, but what is a PCI?
> >
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>



-- 
George Henke
(C) 845 401 5614

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

Re: 5 Byte Device Addresses?

[Shmuel Metz (Seymour J.)]

In
,
on 02/16/2012
   at 11:45 AM, John Gilmore  said:

>The original System/360 scheme was simple and in its way elegant.
>01F---decodable unambiguously into (multiplexor) channel 0, control
>unit 1, and that control unit's device F or 15

Actually it was ambiguos, lacking knowledge of the particular
controller. The address was cuu, where uu specified the controller and
the device, but there could be multiple controlles with the same 4
high bits and there could be controllers with more than 16 devices.
 
-- 
 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: INFO IBM-MAIN

Re: zSeries Manpower Sizing

[Sevetson, Phil]

I think you're right.  It was introduced to me the other way by someone who got 
it wrong, and I've had a mental block about it ever since.  Thank you for the 
correction.

--Phil Sevetson

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Field, Alan C.
Sent: Friday, February 17, 2012 11:16 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: zSeries Manpower Sizing

I think you really mean _P_ Payment Card Industry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Sevetson, Phil
Sent: Friday, February 17, 2012 09:41 
To: IBM-MAIN@bama.ua.edu
Subject: Re: zSeries Manpower Sizing

PCI: 
_P_ersonal 
_C_ard 
_I_ndustry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Lizette Koehler
Sent: Friday, February 17, 2012 10:32 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: zSeries Manpower Sizing

>
>tyvm, Timothy, for your expert analysis.
>
>Please pardon my ignorance, but what is a PCI?
>
>
>

PCI has to do with Payments for Credit Cards and their security.

The PCI Security Standards Council offers robust and comprehensive
standards and supporting materials to enhance payment card data
security. These materials include a framework of specifications, tools,
measurements and support resources to help organizations ensure the safe
handling of cardholder information at every step. The keystone is the
PCI Data Security Standard (PCI DSS), which provides an actionable
framework for developing a robust payment card data security process --
including prevention, detection and appropriate reaction to security
incidents.
 
 
For device vendors and manufacturers, the Council provides the PIN
Transaction Security (PTS) requirements, which contains a single set of
requirements for all personal identification number (PIN) terminals,
including POS devices, encrypting PIN pads and unattended payment
terminals. A list of approved PIN transaction devices can be accessed
here.
 
To help software vendors and others develop secure payment applications,
the Council maintains the Payment Application Data Security Standard
(PA-DSS) and a list of Validated Payment Applications.
 
The Council also provides training to professional firms and individuals
so that they can assist organizations with their compliance efforts. The
Council maintains public resources such as lists of Qualified Security
Assessors (QSAs), Payment Application Qualified Security Assessors
(PA-QSAs), and Approved Scanning Vendors (ASVs). Large firms seeking to
educate their employees can take advantage of the Internal Security
Assessor (ISA) education program.
 

Lizette

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

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

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

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[John Gilmore]

Paul Gilmartin's:


It would seem to me that when the time came to convert from 3330 to
3350 (e.g.), the simple path would have been to replace "TRK" with
"13030" (CYL slightly more complicated) and leave the other numbers
unchanged.  JCL so modified would work on either model during the
transition, and be suitable for any future DASD.


is not really wrongheaded.  It is an unfortunate oversimplification
for real DASD.  For them BLKSIZE= values could not be ignored.  If
they were in moving, for example, from 3350s to 3390s, it was
possible, indeed easy, to waste 30+ percent of the new devices'
capacity.

As I have already had occasion to note today, accurate DASD-capacity
calculations parametric in block are not difficult.  They require no
mastery of---choose the dubious metaphor you find more
congenial---either brain surgery or rocket science.  Dubious
approximations, on the other hand, always gave/give trouble.

On 2/17/12, Paul Gilmartin  wrote:
> On Fri, 17 Feb 2012 10:39:03 -0600, Mark Zelden wrote:
>>
>>Although it is a crude and inaccurate conversion,  one could use M instead
>> of CYL basically
>>1:1 and  would be sure to get enough space since 1M is about 1.42 CYLs.
>> If I did that at
>>least I could picture it in my head the same way I have been doing with
>> with CYL for
>>my entire MF career.   On a slightly larger scale, so what if I allocated
>> in M and ended up with
>>710 CYL instead of 500 CYL.  (typical for me to use (500,500) for
>> "large-ish" allocations).
>>
> It would seem to me that when the time came to convert from
> 3330 to 3350 (e.g.), the simple path would have been to replace
> "TRK" with "13030" (CYL slightly more complicated) and leave the
> other numbers unchanged.  JCL so modified would work on either
> model during the transition, and be suitable for any future DASD.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Gilmore, Ashland, MA 01721 - USA

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Paul Gilmartin]

On Fri, 17 Feb 2012 10:39:03 -0600, Mark Zelden wrote:
>
>Although it is a crude and inaccurate conversion,  one could use M instead of 
>CYL basically
>1:1 and  would be sure to get enough space since 1M is about 1.42 CYLs.   If I 
>did that at
>least I could picture it in my head the same way I have been doing with with 
>CYL for
>my entire MF career.   On a slightly larger scale, so what if I allocated in M 
>and ended up with
>710 CYL instead of 500 CYL.  (typical for me to use (500,500) for "large-ish" 
>allocations).
> 
It would seem to me that when the time came to convert from
3330 to 3350 (e.g.), the simple path would have been to replace
"TRK" with "13030" (CYL slightly more complicated) and leave the
other numbers unchanged.  JCL so modified would work on either
model during the transition, and be suitable for any future DASD.

-- gil

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Mark Zelden]

On Thu, 16 Feb 2012 23:57:44 -0800, Edward Jaffe  
wrote:

>On 2/13/2012 9:38 AM, Joel C. Ewing wrote:
>> Requiring application programmers to think in terms of tracks and cylinders
>> and to understand interaction between physical block size and track capacity
>> is indeed archaic, as are artificial restrictions on number of extents or
>> volumes.
>
>TRKs and CYLs? Most of our allocations are in MEGs. Doesn't everyone do that
>these days?
>
>SPACE=(1,(5,1),RLSE),AVGREC=MAllocate in MEGs
>
>
Not that I've seen.  A good portion of production JCL just uses a dataclas for 
various allocation 
amounts / defaults like "MB100E"  (100MB, extended format).But most 
production and 
almost all end user JCL (including sysprogs like myself) still use CYL.
Maybe because I
just copy other JCL to start with, and I guess I can just "picture" the amount 
it 
represents in my head.

Although it is a crude and inaccurate conversion,  one could use M instead of 
CYL basically
1:1 and  would be sure to get enough space since 1M is about 1.42 CYLs.   If I 
did that at
least I could picture it in my head the same way I have been doing with with 
CYL for
my entire MF career.   On a slightly larger scale, so what if I allocated in M 
and ended up with
710 CYL instead of 500 CYL.  (typical for me to use (500,500) for "large-ish" 
allocations).

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

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

Re: zSeries Manpower Sizing

[Field, Alan C.]

I think you really mean _P_ Payment Card Industry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Sevetson, Phil
Sent: Friday, February 17, 2012 09:41 
To: IBM-MAIN@bama.ua.edu
Subject: Re: zSeries Manpower Sizing

PCI: 
_P_ersonal 
_C_ard 
_I_ndustry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Lizette Koehler
Sent: Friday, February 17, 2012 10:32 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: zSeries Manpower Sizing

>
>tyvm, Timothy, for your expert analysis.
>
>Please pardon my ignorance, but what is a PCI?
>
>
>

PCI has to do with Payments for Credit Cards and their security.

The PCI Security Standards Council offers robust and comprehensive
standards and supporting materials to enhance payment card data
security. These materials include a framework of specifications, tools,
measurements and support resources to help organizations ensure the safe
handling of cardholder information at every step. The keystone is the
PCI Data Security Standard (PCI DSS), which provides an actionable
framework for developing a robust payment card data security process --
including prevention, detection and appropriate reaction to security
incidents.
 
 
For device vendors and manufacturers, the Council provides the PIN
Transaction Security (PTS) requirements, which contains a single set of
requirements for all personal identification number (PIN) terminals,
including POS devices, encrypting PIN pads and unattended payment
terminals. A list of approved PIN transaction devices can be accessed
here.
 
To help software vendors and others develop secure payment applications,
the Council maintains the Payment Application Data Security Standard
(PA-DSS) and a list of Validated Payment Applications.
 
The Council also provides training to professional firms and individuals
so that they can assist organizations with their compliance efforts. The
Council maintains public resources such as lists of Qualified Security
Assessors (QSAs), Payment Application Qualified Security Assessors
(PA-QSAs), and Approved Scanning Vendors (ASVs). Large firms seeking to
educate their employees can take advantage of the Internal Security
Assessor (ISA) education program.
 

Lizette

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

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

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

Re: zSeries Manpower Sizing

[Jihad Kawkabani]

PCI - Processor Capacity Index - First calculated/Introduced with the z/OS V1R9 
LSPR(Large Systems Performance Reference).

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of George Henke
> Sent: Friday, February 17, 2012 08:29 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: zSeries Manpower Sizing
> 
> tyvm, Timothy, for your expert analysis.
> 
> Please pardon my ignorance, but what is a PCI?
> 
> 

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Vernooij, CP - SPLXM]

"Paul Gilmartin"  wrote in message
news:<2410839884184451.wa.paulgboulderaim@bama.ua.edu>...
> On Fri, 17 Feb 2012 09:59:13 -0500, Scott Ford wrote:
> >
> >Me too, never even thought of megabytes until the pc slam dunk
artists came along, everyone I knew calculated their file size in tracks
or cyls. As someone tod me new world orderlol
> > 
> I would have expected that during technology transitions with a
> mixture of DASD geometries in a shop, bytes or records would
> have been the invariant metric of data set size, therefore the
> most convenient.  Perhaps it was just bigotry, evident in the
> characterization in the paragraph above: "We're dinos; we don't
> do megabytes!"
> 
> But then there's volume capacity which, in megabytes, is not
> invariant, even for a single volume of a single given model.
> 
> -- gil

No, it is just the 'change' that prevented adoption. In spite of all the
pro's, it has one con: it is different from what we are used to. And
that is usually a big trhreshold.

I have seen this several times in the past: once we had a simple
homewritten change management system. Then we changed to Netman and
everybody complained about all its shortcommings and difficulties. Then
we changed to Paragrine and everybody complained about it and said how
much better Netman was.

We are/were used to trks and cyls and everything different is worse
until proven otherwise.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Scott Ford]

Gil,

Worked with a math phd for a bunch of yrs and he preached records for 
allocations, not cyls or tracks. I guess everyone has an opinion...

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Feb 17, 2012, at 10:41 AM, Paul Gilmartin  wrote:

> On Fri, 17 Feb 2012 09:59:13 -0500, Scott Ford wrote:
>> 
>> Me too, never even thought of megabytes until the pc slam dunk artists came 
>> along, everyone I knew calculated their file size in tracks or cyls. As 
>> someone tod me new world orderlol
>> 
> I would have expected that during technology transitions with a
> mixture of DASD geometries in a shop, bytes or records would
> have been the invariant metric of data set size, therefore the
> most convenient.  Perhaps it was just bigotry, evident in the
> characterization in the paragraph above: "We're dinos; we don't
> do megabytes!"
> 
> But then there's volume capacity which, in megabytes, is not
> invariant, even for a single volume of a single given model.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: zSeries Manpower Sizing

[Scott Ford]

Tyvm Lizette didn't know what it was either. I have a ton of banking customers, 
you just made me a tad smarter...Ty

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Feb 17, 2012, at 10:32 AM, Lizette Koehler  wrote:

>> 
>> tyvm, Timothy, for your expert analysis.
>> 
>> Please pardon my ignorance, but what is a PCI?
>> 
>> 
>> 
> 
> PCI has to do with Payments for Credit Cards and their security.
> 
> The PCI Security Standards Council offers robust and comprehensive standards 
> and supporting materials to enhance payment card data security. These 
> materials include a framework of specifications, tools, measurements and 
> support resources to help organizations ensure the safe handling of 
> cardholder information at every step. The keystone is the PCI Data Security 
> Standard (PCI DSS), which provides an actionable framework for developing a 
> robust payment card data security process -- including prevention, detection 
> and appropriate reaction to security incidents.
> 
> 
> For device vendors and manufacturers, the Council provides the PIN 
> Transaction Security (PTS) requirements, which contains a single set of 
> requirements for all personal identification number (PIN) terminals, 
> including POS devices, encrypting PIN pads and unattended payment terminals. 
> A list of approved PIN transaction devices can be accessed here.
> 
> To help software vendors and others develop secure payment applications, the 
> Council maintains the Payment Application Data Security Standard (PA-DSS) and 
> a list of Validated Payment Applications.
> 
> The Council also provides training to professional firms and individuals so 
> that they can assist organizations with their compliance efforts. The Council 
> maintains public resources such as lists of Qualified Security Assessors 
> (QSAs), Payment Application Qualified Security Assessors (PA-QSAs), and 
> Approved Scanning Vendors (ASVs). Large firms seeking to educate their 
> employees can take advantage of the Internal Security Assessor (ISA) 
> education program.
> 
> 
> Lizette
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: zSeries Manpower Sizing

[R.S.]

Watch the context

https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprzOS19MIOct2008?OpenDocument&pathID=#Toc7

PCI stands for Processor capacity Index

2064-116 has 2882 PCI and 441 MSU.

PCI stands for many other meanings, including IT ones (Peripheral 
Commponent Interconnect).

--
Radoslaw Skorupka
Lodz, Poland




W dniu 2012-02-17 16:41, Sevetson, Phil pisze:

PCI:
_P_ersonal
_C_ard
_I_ndustry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Lizette Koehler
Sent: Friday, February 17, 2012 10:32 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: zSeries Manpower Sizing



tyvm, Timothy, for your expert analysis.

Please pardon my ignorance, but what is a PCI?





PCI has to do with Payments for Credit Cards and their security.

The PCI Security Standards Council offers robust and comprehensive standards 
and supporting materials to enhance payment card data security. These materials 
include a framework of specifications, tools, measurements and support 
resources to help organizations ensure the safe handling of cardholder 
information at every step. The keystone is the PCI Data Security Standard (PCI 
DSS), which provides an actionable framework for developing a robust payment 
card data security process -- including prevention, detection and appropriate 
reaction to security incidents.


For device vendors and manufacturers, the Council provides the PIN Transaction 
Security (PTS) requirements, which contains a single set of requirements for 
all personal identification number (PIN) terminals, including POS devices, 
encrypting PIN pads and unattended payment terminals. A list of approved PIN 
transaction devices can be accessed here.

To help software vendors and others develop secure payment applications, the 
Council maintains the Payment Application Data Security Standard (PA-DSS) and a 
list of Validated Payment Applications.

The Council also provides training to professional firms and individuals so 
that they can assist organizations with their compliance efforts. The Council 
maintains public resources such as lists of Qualified Security Assessors 
(QSAs), Payment Application Qualified Security Assessors (PA-QSAs), and 
Approved Scanning Vendors (ASVs). Large firms seeking to educate their 
employees can take advantage of the Internal Security Assessor (ISA) education 
program.


Lizette



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

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


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


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

Re: zSeries Manpower Sizing

[Scott Ford]

Yep that's the way I have always experienced the work environment. Worked on a 
10 way they had 60 ppl supporting it but the environment was huge to support ..

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Feb 17, 2012, at 8:23 AM, "van der Grijn, Bart (B)"  
wrote:

> The difficulty with the question is that there likely aren't a lot of large 
> zSeries mainframe-only shops in existence. There are large shops that run 
> large mainframes, but they likely run other platforms as well and a large 
> part of the manpower will be shared across platforms. 
> We have a z/OS sysprog team of 5-8 and a DB2 team of 6-9 (where the 3 are 
> shared z/OS and DB2). All other teams are not dedicated to Mainframe: Change 
> Integration, Operations, Security, network, Scheduling, Facilities, DR, help 
> desk, project management, auditing, etc.
> Depending on what you want to include, you end up with anything between 2 and 
> 200 people per CEC.
> 
> Bart 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of George Henke
> Sent: Thursday, February 16, 2012 4:19 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: zSeries Manpower Sizing
> 
> I am trying to find out how much staff, numbers and titles, eg z/OS, z/VM,
> VTAM/TCPIP, CICS, etc, are needed to run a large zSeries mainframe shop.
> 
> Would some of you be so kind as to share that information with me.
> 
> 
> -- 
> George Henke
> (C) 845 401 5614
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Paul Gilmartin]

On Fri, 17 Feb 2012 09:59:13 -0500, Scott Ford wrote:
>
>Me too, never even thought of megabytes until the pc slam dunk artists came 
>along, everyone I knew calculated their file size in tracks or cyls. As 
>someone tod me new world orderlol
> 
I would have expected that during technology transitions with a
mixture of DASD geometries in a shop, bytes or records would
have been the invariant metric of data set size, therefore the
most convenient.  Perhaps it was just bigotry, evident in the
characterization in the paragraph above: "We're dinos; we don't
do megabytes!"

But then there's volume capacity which, in megabytes, is not
invariant, even for a single volume of a single given model.

-- gil

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

Re: zSeries Manpower Sizing

[Sevetson, Phil]

PCI: 
_P_ersonal 
_C_ard 
_I_ndustry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Lizette Koehler
Sent: Friday, February 17, 2012 10:32 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: zSeries Manpower Sizing

>
>tyvm, Timothy, for your expert analysis.
>
>Please pardon my ignorance, but what is a PCI?
>
>
>

PCI has to do with Payments for Credit Cards and their security.

The PCI Security Standards Council offers robust and comprehensive standards 
and supporting materials to enhance payment card data security. These materials 
include a framework of specifications, tools, measurements and support 
resources to help organizations ensure the safe handling of cardholder 
information at every step. The keystone is the PCI Data Security Standard (PCI 
DSS), which provides an actionable framework for developing a robust payment 
card data security process -- including prevention, detection and appropriate 
reaction to security incidents.
 
 
For device vendors and manufacturers, the Council provides the PIN Transaction 
Security (PTS) requirements, which contains a single set of requirements for 
all personal identification number (PIN) terminals, including POS devices, 
encrypting PIN pads and unattended payment terminals. A list of approved PIN 
transaction devices can be accessed here.
 
To help software vendors and others develop secure payment applications, the 
Council maintains the Payment Application Data Security Standard (PA-DSS) and a 
list of Validated Payment Applications.
 
The Council also provides training to professional firms and individuals so 
that they can assist organizations with their compliance efforts. The Council 
maintains public resources such as lists of Qualified Security Assessors 
(QSAs), Payment Application Qualified Security Assessors (PA-QSAs), and 
Approved Scanning Vendors (ASVs). Large firms seeking to educate their 
employees can take advantage of the Internal Security Assessor (ISA) education 
program.
 

Lizette

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

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

Re: zSeries Manpower Sizing

[Lizette Koehler]

>
>tyvm, Timothy, for your expert analysis.
>
>Please pardon my ignorance, but what is a PCI?
>
>
>

PCI has to do with Payments for Credit Cards and their security.

The PCI Security Standards Council offers robust and comprehensive standards 
and supporting materials to enhance payment card data security. These materials 
include a framework of specifications, tools, measurements and support 
resources to help organizations ensure the safe handling of cardholder 
information at every step. The keystone is the PCI Data Security Standard (PCI 
DSS), which provides an actionable framework for developing a robust payment 
card data security process -- including prevention, detection and appropriate 
reaction to security incidents.
 
 
For device vendors and manufacturers, the Council provides the PIN Transaction 
Security (PTS) requirements, which contains a single set of requirements for 
all personal identification number (PIN) terminals, including POS devices, 
encrypting PIN pads and unattended payment terminals. A list of approved PIN 
transaction devices can be accessed here.
 
To help software vendors and others develop secure payment applications, the 
Council maintains the Payment Application Data Security Standard (PA-DSS) and a 
list of Validated Payment Applications.
 
The Council also provides training to professional firms and individuals so 
that they can assist organizations with their compliance efforts. The Council 
maintains public resources such as lists of Qualified Security Assessors 
(QSAs), Payment Application Qualified Security Assessors (PA-QSAs), and 
Approved Scanning Vendors (ASVs). Large firms seeking to educate their 
employees can take advantage of the Internal Security Assessor (ISA) education 
program.
 

Lizette

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

If somebody knows this:SysBinLog ?

[Miklos Szigetvari]

Hi

One of our customer is speaking about SysBinLog in z/OS
Maybe somebody knows what is this.

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

Re: Does HBDELETE forces tape mount??

[Staller, Allan]

HDELETE


and how about ML2 dsns??? If i do HRECALL against MIGRAT2 volume ??? is
there a way of just invalid the entry in MCDS avoiding tape mounting ??


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

Re: Does HBDELETE forces tape mount??

[Mark Jacobs]

On 02/17/12 10:05, af dc wrote:

and how about ML2 dsns??? If i do HRECALL against MIGRAT2 volume ??? is
there a way of just invalid the entry in MCDS avoiding tape mounting ??

A.Cecilio.


On Fri, Feb 17, 2012 at 2:57 PM, af dc  wrote:

   


The HDEL command does that trick for migrated datasets.

--
Mark Jacobs
Time Customer Service
Tampa, FL


Learn from yesterday, live for today, hope for tomorrow.
The important thing is to not stop questioning.

- Albert Einstein

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

Re: Does HBDELETE forces tape mount??

[af dc]

and how about ML2 dsns??? If i do HRECALL against MIGRAT2 volume ??? is
there a way of just invalid the entry in MCDS avoiding tape mounting ??

A.Cecilio.


On Fri, Feb 17, 2012 at 2:57 PM, af dc  wrote:

> sorry I meant dataset backup
>
>
> On Fri, Feb 17, 2012 at 2:32 PM, Staller, Allan wrote:
>
>> HBDELETE does not require a tape mount.
>>
>> BTW, ,HBDELETE deletes a dataset backup, not the tape. This is handled
>> by other processes.
>>
>> HTH,
>>
>> 
>> can you pls tell me if doing hbdelete against a tape volume does it
>> forces
>> a tape mount ???
>> 
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>>
>
>

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Scott Ford]

Guys,
Me too, never even thought of megabytes until the pc slam dunk artists came 
along, everyone I knew calculated their file size in tracks or cyls. As someone 
tod me new world orderlol

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Feb 17, 2012, at 9:32 AM, Steve Comstock  wrote:

> On 2/17/2012 12:57 AM, Edward Jaffe wrote:
>> On 2/13/2012 9:38 AM, Joel C. Ewing wrote:
>>> Requiring application programmers to think in terms of tracks and cylinders
>>> and to understand interaction between physical block size and track capacity
>>> is indeed archaic, as are artificial restrictions on number of extents or
>>> volumes.
>> 
>> TRKs and CYLs? Most of our allocations are in MEGs. Doesn't everyone do that
>> these days?
>> 
>> SPACE=(1,(5,1),RLSE),AVGREC=M Allocate in MEGs
>> 
> 
> I would have thought allocations in records or thousands of records,
> or millions of records, e.g.:
> 
>  SPACE=(440,(100,5),RLSE),AVGREG=M
> 
> allocate space for 100 million records of 440 bytes long.
> 
> 
> Folks responsible for an application usually have some rough idea
> of the number of records (right?) and they know the size of the
> records. Records relate to something concrete (customers,
> inventory, employees, etc.) whereas megabytes is more abstract.
> 
> 
> But, hey, I live in the ivory tower.
> 
> -- 
> 
> Kind regards,
> 
> -Steve Comstock
> The Trainer's Friend, Inc.
> 
> 303-355-2752
> http://www.trainersfriend.com
> 
> * To get a good Return on your Investment, first make an investment!
>  + Training your people is an excellent investment
> 
> * Try our tool for calculating your Return On Investment
>for training dollars at
>  http://www.trainersfriend.com/ROI/roi.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Edward Jaffe]

On 2/17/2012 6:32 AM, Steve Comstock wrote:

On 2/17/2012 12:57 AM, Edward Jaffe wrote:


TRKs and CYLs? Most of our allocations are in MEGs. Doesn't everyone do that
these days?

SPACE=(1,(5,1),RLSE),AVGREC=M Allocate in MEGs



I would have thought allocations in records or thousands of records,
or millions of records, e.g.:

  SPACE=(440,(100,5),RLSE),AVGREG=M

allocate space for 100 million records of 440 bytes long.


Like the folks in John McKown's shop, I have trouble dealing with space in terms 
of average record size and number of records. It seems overburdensome to have to 
worry about space at that level or detail. OTOH, I have no trouble at all 
knowing how many megabytes I'll need! :-)


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

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

Re: Does HBDELETE forces tape mount??

[af dc]

sorry I meant dataset backup

On Fri, Feb 17, 2012 at 2:32 PM, Staller, Allan wrote:

> HBDELETE does not require a tape mount.
>
> BTW, ,HBDELETE deletes a dataset backup, not the tape. This is handled
> by other processes.
>
> HTH,
>
> 
> can you pls tell me if doing hbdelete against a tape volume does it
> forces
> a tape mount ???
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Does HBDELETE forces tape mount??

[Mark Jacobs]

On 02/17/12 09:27, af dc wrote:

Hello,
can you pls tell me if doing hbdelete against a tape volume does it forces
a tape mount ???
I need to delete several hsm dsn backups that are in tape volumes, is there
a way to do that avoiding tape mounting ??

Many thx, A.Cecilio.

--

   


The tape doesn't need to be mounted. HSM just deletes the entry in its 
BCDS database, which logically deletes it from the backup tape volume.


--
Mark Jacobs
Time Customer Service
Tampa, FL


Learn from yesterday, live for today, hope for tomorrow.
The important thing is to not stop questioning.

- Albert Einstein

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Steve Comstock]

On 2/17/2012 12:57 AM, Edward Jaffe wrote:

On 2/13/2012 9:38 AM, Joel C. Ewing wrote:

Requiring application programmers to think in terms of tracks and cylinders
and to understand interaction between physical block size and track capacity
is indeed archaic, as are artificial restrictions on number of extents or
volumes.


TRKs and CYLs? Most of our allocations are in MEGs. Doesn't everyone do that
these days?

SPACE=(1,(5,1),RLSE),AVGREC=M Allocate in MEGs



I would have thought allocations in records or thousands of records,
or millions of records, e.g.:

  SPACE=(440,(100,5),RLSE),AVGREG=M

allocate space for 100 million records of 440 bytes long.


Folks responsible for an application usually have some rough idea
of the number of records (right?) and they know the size of the
records. Records relate to something concrete (customers,
inventory, employees, etc.) whereas megabytes is more abstract.


But, hey, I live in the ivory tower.

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

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

Re: Does HBDELETE forces tape mount??

[Staller, Allan]

HBDELETE does not require a tape mount.

BTW, ,HBDELETE deletes a dataset backup, not the tape. This is handled
by other processes.

HTH,


can you pls tell me if doing hbdelete against a tape volume does it
forces
a tape mount ???


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

Does HBDELETE forces tape mount??

[af dc]

Hello,
can you pls tell me if doing hbdelete against a tape volume does it forces
a tape mount ???
I need to delete several hsm dsn backups that are in tape volumes, is there
a way to do that avoiding tape mounting ??

Many thx, A.Cecilio.

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

Re: z/OS Feeding SolarWinds

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason
> Sent: Friday, February 17, 2012 4:18 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS Feeding SolarWinds
> 
> Jim
> 
> Your title could be restated as "The SNMP Agent supported by 
> z/OS 'feeding' the SNMP Manager which happens to be supported 
> by SolarWinds".
> 
> The point about the title change is that the "P" in "SNMP" 
> means "protocol" and thus SNMP is designed to support any old 
> IP platform as an SNMP agent and any old IP platform as an 
> SNMP manager and the two will work harmoniously together!

So true. In another message I told how we use it. We had some problems which 
the other side said was with us. So I simply redirected the SNMP messages from 
their server to my Linux desktop. I used "tcpdump" on my desktop to show them 
that z/OS was indeed sending out SNMP messages and that they were properly 
formatted. They then went back and figured out what was wrong with their 
server. But, around here, any intercommunication problem is automatically 
assumed to be a z/OS failure until proven otherwise. Because they __know__ that 
Windows always works correctly!

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

Re: z/OS Feeding SolarWinds

[McKown, John]

I've heard of Orion. We have it. We send SNMP traps to it from z/OS using 
CA-OPS/MVS. It opens tickets in CA-Unicenter for CA-7 tracked events. We use 
CA-GTS (ECHO processor) to write some of the CA-7 messages to the z/OS system 
log. CA-OPS/MVS has rules based on these messages which use the OPSCAWTO() 
function to send SNMP traps. It's really quite easy.

)MSG someid
)PROC
server=a.b.c.d
msg="Hello from z/OS"
xx=opscawto(server,msg,'d')
return "SUPPRESS" /* don't write to SYSLOG */

The CA-supplied ENF and ENFSNMPM must be running to do this.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Timothy Sipples
> Sent: Friday, February 17, 2012 2:57 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: z/OS Feeding SolarWinds
> 
> Sounds interesting, Jim. So you just need to emit some SNMP 
> for SolarWinds
> (Orion, specifically), correct?
> 
> You could take the "roll your own" approach. There's a fairly good
> introduction to SNMP here, to get acquainted:
> 
> http://www.ibm.com/support/docview.wss?uid=swg27007146
> 
> There's also some pretty good information if you search the IBM-MAIN
> archives for SNMP.
> 
> That said, it'd probably be easier to let your current 
> monitoring tools do
> the lifting, if possible, since presumably those work. What sort of
> monitoring tools do you have on z/OS, if any? Tivoli NetView, 
> for example?
> Also, let's brainstorm a bit on what statistics/metrics would be both
> "cool" and useful. There are lots of possibilities.
> 
> --
> --
> Timothy Sipples
> Resident Enterprise Architect (Based in Singapore)
> E-Mail: timothy.sipp...@us.ibm.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Edward Jaffe
> Sent: Friday, February 17, 2012 1:58 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Archaic allocation in JCL (Was: Physical record 
> size query)
> 
> On 2/13/2012 9:38 AM, Joel C. Ewing wrote:
> > Requiring application programmers to think in terms of 
> tracks and cylinders 
> > and to understand interaction between physical block size 
> and track capacity 
> > is indeed archaic, as are artificial restrictions on number 
> of extents or 
> > volumes. 
> 
> TRKs and CYLs? Most of our allocations are in MEGs. Doesn't 
> everyone do that 
> these days?
> 
> SPACE=(1,(5,1),RLSE),AVGREC=MAllocate in MEGs
> 
> -- 
> Edward E Jaffe

No. Our programmers allocate in CYLs. Why? "I understand what a cylinder is. 
This megabyte stuff just doesn't make sense to me." Seems weird, but they will 
say that they don't know how many records are going to be in a file, or how big 
the record may be when it is variable in length. But they __do__ have an 
estimate of how many cylinders it needs to have allocated. HUH? Any more, with 
SMS, we have the normal DATACLAS have a DVC value of 59 (maximum). The person 
who was the storage administrator simply told the programmers to use a 
"standard" allocation value and let the system take care of extending the 
dataset on a volume, and onto more volumes. This works about 95% of the time 
here. The other 5% of the time, the programmer needs to use a "really large" 
value for their DEFINE of a VSAM KSDS. But we know what those datasets are and 
how big they need to be. We are a fairly static shop on the z side any more. 
The "high level" application designers are all Windows trained and d!
 on't even consider how to use z/OS to accomplish company goals. Their response 
to almost anything is "z/OS can't do that". What they really mean is "I don't 
know how to get z/OS to do that, and I don't intend to learn either. I know 
Windows and so Windows is the answer."

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

Re: zSeries Manpower Sizing

[George Henke]

Excluding applications

On Thu, Feb 16, 2012 at 4:18 PM, George Henke  wrote:

> I am trying to find out how much staff, numbers and titles, eg z/OS, z/VM,
> VTAM/TCPIP, CICS, etc, are needed to run a large zSeries mainframe shop.
>
> Would some of you be so kind as to share that information with me.
>
>
> --
> George Henke
> (C) 845 401 5614
>



-- 
George Henke
(C) 845 401 5614

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

Re: zSeries Manpower Sizing

[Staller, Allan]

The largest MF shop I have worked for supported 10 sysplex, 44 lpars, at
least 20 processors, across 3 continents.

The support staff was (as best I can recall) z/OS and program products
including most vendor software (9), CICS/VTAM/TCPIP (6), IMS/DB2/MQ
(sysprog only) (5)

DBA's and other were under another manager.

HTH,

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

Re: Authorized functions

[McKown, John]

>From what little I understand, the TMP invoked via ADDRESS TSO is like the 
>"batch version" of TSO. The "batch version" of TSO cannot do terminal I/O. And 
>does not appear, to me, to implement things like "terminal interrupts" (aka 
>ATTN'ing out of a command). To do ISPF "interactive" work via an emulated 3270 
>would require your program to implement and script a TN3270 session and do a 
>3270s scripted LOGON to TSO like an end user would do. This would also mean 
>"only one session". Because "interactive" TSO uses an ENQ on SYSIKJUA  
>to "single thread". I have a memory of an option from the TSO pre-prompt exit 
>to turn off this ENQ. But reviewing the current documentation, I don't see it. 
>So either my memory is bad (ECC checks are common), or IBM has removed that 
>option.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Thursday, February 16, 2012 6:55 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Authorized functions
> 
> On Thu, 16 Feb 2012 15:40:40 -0600, Chris Craddock wrote:
> 
> >On Thu, Feb 16, 2012 at 3:33 PM, Scott Ford wrote:
> >>
> >> I dont want to knock IBM but for us developers this is UGLY ...
> >> Maybe the problem is they never intended for it to be 
> called that way ...
> >
> >Yes, exactly right  on both counts. Don't forget that TSO is 
> older than
> >dirt and all subsequent efforts to graft on functionality 
> are limited by
> >its original design assumptions. Modern it ain't.
> > 
> Actually, I suspect the roots go deeper than that.  The original
> design assumptions of OS/360 never included the requirement to
> support TSO; TSO was designed within the resulting constraints,
> and so on ...
> 
> John M's BPXWUNIX -> address TSO is the seed of a good idea.
> If only each of several concurrent BPXWUNIces addressing TSO
> could run ISPF attached to its own (emulated) 3270.  Ah, for
> something like the DIAL command in VM!
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

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

Re: zSeries Manpower Sizing

[George Henke]

tyvm, Timothy, for your expert analysis.

Please pardon my ignorance, but what is a PCI?


On Fri, Feb 17, 2012 at 2:27 AM, Timothy Sipples  wrote:

> George Henke observes:
> >The feedback I have gotten so far, based on a few private replies, is
> about
> >8 - 12 people per CEC.
>
> Maybe, but that doesn't mean when you double the number of CECs you would
> double the number of people, or vice versa. That is, you can't extrapolate
> linearly in either direction, as our meat computers subconsciously often
> do.
>
> For example, let's suppose you were a "big" shop in the year 2002 and you
> were running 10 z900 machines, each configured as 213 models with a PCI of
> 2888 each. So you had 28880 PCIs total, plus some coupling facility
> engines.
>
> Then assume you experienced 8% per year compound growth in capacity (with
> transaction volume growth, etc. -- holding the application set constant for
> this example) so that after a decade you'd end up with approximately 62350
> PCIs (28880*1.08^10). Well, that capacity would fit on a mere two CECs
> today: a pair of z196s, perhaps at capacity setting 742 each (31675 PCIs
> each). An ~80% reduction in floor space, which unfortunately probably got
> more than filled with more expensive and less reliable infrastructure. And
> actually, in practice, when you take 10 footprints down to 2 you tend to
> pick up some nice virtualization benefits, so that's probably too many
> PCIs, never mind possible zIIP and other benefits.
>
> So in that decade would you have also taken a staff of 100 people (10 per
> CEC) and reduced it to 20 people? That would be an order of magnitude jump
> in staff productivity per PCI over 10 years. That seems extreme. Perhaps
> you wouldn't have 100 people (if you started with 100), but I don't think
> you'd have as few as 20 either, ceteris paribus.
>
> I don't think there's any serious disagreement that the mainframe has led
> the way in providing huge productivity improvements just about any way you
> measure it. As a generalization, you mainframers are extraordinarily
> productive, both in comparison to your predecessors and in comparison to
> your non-mainframe peers. (Keep up the good work -- and more, please.)
>
> There are some analysts who have looked at this stuff and who concur with
> the sort of trends and characteristics I describe above. Mainframes are
> characterized by very strong scale economies. There are at least two ways
> to take advantage of that: be big(ger) -- more transactions, more volume,
> more batch with the same or similar application set -- and be broader --
> more applications sharing the same mainframe infrastructure. That doesn't
> mean you can't do fine financially and otherwise running a single
> application at low volumes, but you can do even better bigger and/or
> broader.
>
>
> 
> Timothy Sipples
> Resident Enterprise Architect (Based in Singapore)
> E-Mail: timothy.sipp...@us.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>



-- 
George Henke
(C) 845 401 5614

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

Re: zSeries Manpower Sizing

[van der Grijn, Bart (B)]

The difficulty with the question is that there likely aren't a lot of large 
zSeries mainframe-only shops in existence. There are large shops that run large 
mainframes, but they likely run other platforms as well and a large part of the 
manpower will be shared across platforms. 
We have a z/OS sysprog team of 5-8 and a DB2 team of 6-9 (where the 3 are 
shared z/OS and DB2). All other teams are not dedicated to Mainframe: Change 
Integration, Operations, Security, network, Scheduling, Facilities, DR, help 
desk, project management, auditing, etc.
Depending on what you want to include, you end up with anything between 2 and 
200 people per CEC.

Bart 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
George Henke
Sent: Thursday, February 16, 2012 4:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: zSeries Manpower Sizing

I am trying to find out how much staff, numbers and titles, eg z/OS, z/VM,
VTAM/TCPIP, CICS, etc, are needed to run a large zSeries mainframe shop.

Would some of you be so kind as to share that information with me.


-- 
George Henke
(C) 845 401 5614

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[John Gilmore]

Edward Jaffe has now made the crucial point.

Circumventions of any great need to know much about TRK and CYL issues
are available (and in one form or another have long been available).

That said, the geometry of real DASD was never an intellectually
challenging topic; and I grow ever more weary of this and other pleas
to spare applications programmers--and often now sysprogs too--any
need to know what they are doing and how to do it.

I miss any sense of proportion.  We were never dealing here with an
arbitrary and cruel requirement that intellectually challenged Arsenal
footballers master Pali and Prakrit in order to consult their rule
books.   (Indeed, and to the point,  the three Arsenal footballers I
have known well were not intellectually challenged.)

John Gilmore, Ashland, MA 01721 - USA

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

Re: z/OS Feeding SolarWinds

[Jan MOEYERSONS]

On Thu, 16 Feb 2012 17:05:45 -0600, Jim Marshall  wrote:

>One of our Cyber Security folks is putting up a "NOC" (Network Operations 
>Center) and they purchased something called SolarWinds.  Now they are on my 
>doorstep saying they want to scan my system along with DB2 and Oracle data 
>bases.

I am not sure what the question really is... Do they want to probe the z/OS in 
order to monitor all the processes that are going on in there? I believe that 
will not be easy... 

> This is COOL and then I asked how they intended to do this magic;  hey we can 
> accept SNMP traffic.

Who do you mean by "we"? Is that this Solarwind thing? If so, then the question 
boils down to sending out SNMP traps whenever something interesting is 
happening in z/OS. Sending traps is easy enough, but what are you going to use 
to decide when a trap needs sending? You'd require a monitoring tool à la 
Netview or something to do that, I guess. But if you have that, then what is 
the added value of Solarwinds?

>He said we already knew how to do all of this 

So they know all about z/OS, DB2, etc. ? Doesn't show on their website if you 
ask me. But I could be wrong of course.


Little war story: Some time ago, I was called out of bed by the operator on 
duty telling me that lots of CICS transaction were abending. Eventually, I 
found out that this was because network people had installed a port scanner and 
had let it loose on all the machines in the network. It took me even longer to 
convince them that "No, port 3087 is *NOT* trojan Such-and-So listening for 
commands from its master cracker."

Cheers,

Jantje.

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

Re: z/OS Feeding SolarWinds

[Chris Mason]

Jim

Your title could be restated as "The SNMP Agent supported by z/OS 'feeding' the 
SNMP Manager which happens to be supported by SolarWinds".

The point about the title change is that the "P" in "SNMP" means "protocol" and 
thus SNMP is designed to support any old IP platform as an SNMP agent and any 
old IP platform as an SNMP manager and the two will work harmoniously together!

-

You will find everything you need to know about how to set up "The SNMP Agent 
supported by z/OS" in 2.16, "Chapter 25. Simple Network Management Protocol" in 
the z/OS Communications Server IP Configuration Guide.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b3b0/2.16

Details can be found in 25.0, "Chapter 25. Simple Network Management Protocol" 
in the z/OS Communications Server IP Configuration Reference.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B4B0/25.0

You will find even more information in 7.0, "Managing TCP/IP network resources 
with SNMP" and several appendixes in the z/OS Communications Server IP System 
Administrator's Commands manual.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1C2A0/7.0

I have a suspicion your colleague who is dealing with the SolarWinds SNMP 
Manager product will have most interest in B.0, "Appendix B. Management 
Information Base (MIB) objects".

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1C2A0/B.0

-

As I said initially SNMP is a "protocol" and so is documented quite 
independently from IBM. Thus there is an - I hope - acceptable tutorial 
provided as a Wikipedia article:

http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol

-

Since this is very firmly a z/OS Communications Server IP question, the most 
appropriate forum is the following:

For IBMTCP-L subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO IBMTCP-L

Chris Mason

On Thu, 16 Feb 2012 17:05:45 -0600, Jim Marshall  wrote:

>One of our Cyber Security folks is putting up a "NOC" (Network Operations 
>Center) and they purchased something called SolarWinds.  Now they are on my 
>doorstep saying they want to scan my system along with DB2 and Oracle data 
>bases.   This is COOL and then I asked how they intended to do this magic;  
>hey we can accept SNMP traffic.
>
>He said we already knew how to do all of this (guess it was my age and grey 
>hair).Besides asking for contacts within SolarWinds, I thought I might 
>throw this out to the community and see if anything rings a bell.
>
>Appreciate any info one might offer as to what I can do to get some pretty 
>displays on the wall of the NOC and inspire awe in people.
>
>jim

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

Re: sadump (and autoipl)

[Jim Mulder]

> Talking of AUTOIPL and sadump, when I tested this, the only way to 
> see that sadump had finished was when the NIP messages came up on 
> the real console, indicating sadump was done. That's fine and dandy 
> when I am expecting an sadump, but what about when the sadump is 
> taken due to a real problem (and not me just v xcf,sadump,reipl)? 
> How can I see (without interrupting sadump) how far it had come? 
> Just open the operating system messages window on the HMC? 

  Since you have SMSYSC in the loadparm, SADMP should be happily
writing its usual progress messages to the operating system
messages window on the HMC.

> >It used to be that you would not get any paged out
> >storage dumped if you did that, but I fixed that in 
> >z/OS 1.9.
> Now he tells me! I had been standing there and thinking to just 
> reload sadump. The last time I did this I ended up with a nice 
> system trace of what sadump had done :-(. 
> What's the point of no return? In other words, when shouldn't I 
> reload sadump in order to get a dump with meaningful content for the
> problem I am sadumping for? (I think I understand the 4K pages in 
nucleus.)

  I don't think there is a point of no return.  SADMP only uses
4MB of storage for itself, and as long as there is some useable
DAT structure in place when you IPL SADMP, it will use the 4MB 
of real storage that was backing the 4MB of virtual storage
starting at virtual address 0100.  So no matter how many times
you reload, SADMP will be using the same 4MB of real storage,
and the rest of real storage is still from the z/OS system that
you were trying to dump.  When SADMP issues

AMD087I DUMP OF A PREVIOUS STAND-ALONE DUMP PROGRAM NOW COMPLETE
AMD088D REPLY 'T' TO TERMINATE, OR 'U' TO CONTINUE DUMPING. REPLY=

it means that SADMP has finished dumping all of the real storage 
that was in use by SADMP and the z/OS system that was being
dumped.  If you reply U, it will continue on to dump the
requested paged out storage, and then any real storage that
was not in use (i.e., on an available frame queue). 

  It used to be that you had to know how to do some
incantations in IPCS to make sense of one of these dumps, but
I changed SADMP in z/OS 1.10 to put a little but of extra 
information in the dump header record that z/OS 1.10 IPCS
uses to avoid the need for the incantations.

 These also used to be some potential problems when SADMP
had to use the store status data to determine whether it
the thing it was dumping had been running in ESA/390 mode,
or z/Architecture mode.  In z/OS 1.12, I changed z/OS IPL
and SADMP IPL processing to immediately switch into
z/Architecture mode, so that SADMP and IPCS can 
safely assume that the thing being dumped was z/Architecture.



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: INFO IBM-MAIN

Re: z/OS Feeding SolarWinds

[Timothy Sipples]

Sounds interesting, Jim. So you just need to emit some SNMP for SolarWinds
(Orion, specifically), correct?

You could take the "roll your own" approach. There's a fairly good
introduction to SNMP here, to get acquainted:

http://www.ibm.com/support/docview.wss?uid=swg27007146

There's also some pretty good information if you search the IBM-MAIN
archives for SNMP.

That said, it'd probably be easier to let your current monitoring tools do
the lifting, if possible, since presumably those work. What sort of
monitoring tools do you have on z/OS, if any? Tivoli NetView, for example?
Also, let's brainstorm a bit on what statistics/metrics would be both
"cool" and useful. There are lots of possibilities.


Timothy Sipples
Resident Enterprise Architect (Based in Singapore)
E-Mail: timothy.sipp...@us.ibm.com

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