Re: Question concerning CMF reporting of CPU Delay

[Vernooij, CP - SPLXM]

"O'Brien, David W.  [C] , NIH/CIT"  wrote in
message
news:..
.
> Thanks Mike, I was thinking that it might be better to consolidate the
2 Prod LPARs so that all of the workload operated under the same WLM
policy without the PRSM time slice.
> But that's not my call.
> 
> Thank You,

Time slice? Normally PR/SM is running interrupt driven, not time sliced
unless you tell configure it so.

If the 2 lpars run in the same sysplex, WLM can manage both lpars and
the workload in them.

But yes, it is probably more efficient to consolidate the lpars, if you
have not specific reason to separate them.

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

Re: 64 bit mode disabled

[Paul Gilmartin]

On Tue, 30 Nov 2010 23:09:00 -0600, Chris Craddock wrote:
>
>However, if you were imagining you would be executing code that was above
>4GiB, then forget it. z/OS doesn't support it at all. Even if you
>could somehow conspire to get some code into storage above the bar, you
>would not (in general) be able to execute it successfully because none of
>the major control blocks that manage dispatching work can support saving a
>full extended PSW, so while you might "get away with it" for a few
>instructions, the moment you took an interrupt you'd be toast. Hence the
>putative requirement to run disabled. For the purposes of this discussion
>you may assume that's just a bonehead idea.
>
As you've made it pretty clear, that's merely a software limitation.
Other operating systems such as z/VM and Linux for z run code --
how to say it?  "Above the bar" doesn't fit, since they have no
bar.  Well, up there, anyway.  And I understand that under z/OS,
Java has a special Papal dispensation to use storage within the
bar, I don't know whether for code or only for data.

As more code, and perhaps even sharable data get loaded into LPA,
will a 2GB virtual storage constraint soon become onerous?

I understand content supervision will nowadays load CSECTs above
the bar, and correctly relocate 64-bit ADCONs, but they'd better
be data only; no code.

-- gil

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

Re: I would love to know what went wrong at NAB

[Bruce Hewson]

A comment here:-

http://www.theaustralian.com.au/australian-it/human-error-triggered-nab-
software-corruption/story-e6frgakx-1225962953523


"The "file" was actually software code containing instructions on how systems 
should operate in the batch processing cycle."

would lead me to think someone had incorrectly modified the batch processing 
rules...like in TWS/OPC or CA-7.

Regards
Bruce Hewson

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

Re: I would love to know what went wrong at NAB

[Jim Phoenix]

Mike Schwab wrote:

On Tue, Nov 30, 2010 at 7:01 PM, Wayne Bickerdike  wrote:

  

My same source related the tale of a person in same bank who received
an EBCDIC file, opened it in Windows and saved it back as ASCII. The
file was duly transferred for processing on the mainframe. Most of the
packed data was garbaged ..

Oh my, dumb and dumber



Here is an idea to bounce around.  z/OS Unix System Services does a
lot of work converting ASCII to EBCDIC and back.  z/Linux works all in
ASCII.  Why not get 4 new instructions that work with PD<=> ASCII like
the PD <=> EBCDIC instructions PACK, UNPK, ED, EDMK, but with an A
suffix to denote ASCII character.  Conversion from Packed to binary
would be the same.  Assembler would get new instructions.  z/OS would
need to know if a file was ASCII for proper translation when printing
it.


  

Mike,

Introduced with the z900 were the PKA (Pack ASCII), PKU (Pack Unicode), 
UNPKA (Unpack ASCII), and UNPKU (Unpack Unicode) instructions.


--
| Jim Phoenix  | Voice:   (310) 338-0400 x316   |
| Senior Software Developer| Fax: (310) 338-0801|
| Phoenix Software International   ||
| 831 Parkview Drive North | jimphoe...@phoenixsoftware.com |
| El Segundo, CA 90245 | http://www.phoenixsoftware.com |

Opinions expressed by this individual are not necessarily those of the Company.

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

Re: 64 bit mode disabled

[Chris Craddock]

On Tue, Nov 30, 2010 at 9:43 PM, Gerhard Adam  wrote:

> How would you branch to code above the 2GB bar, since none is allowed
> there?
> The obvious problem being how you would even get it loaded up there.  If I
> recall, the fundamental problem is that the PSW cannot be saved with an
> address greater than 31-bit for the next instruction since neither the
> TCB's
> or RB's have a large enough area to store it.
>
>
> >I have a vague memory of reading, here or on the assembler mailing list,
> >that you would need to run disabled if you wanted to branch to code
> >located above the bar.  I also have a vague memory that the Wrath of
> >God would probably fall on you anyway if you tried it, disabled or not.
>


Clearing the air: No, the SAM instructions don't cause you to become
disabled. They just switch addressing mode. It is perfectly ok (normal even)
for ordinary garden variety programs to switch in and out of 64 bit
addressing mode. All z/OS code is loaded below 2GiB, so nothing fancy needs
to be done to branch into 64 bit code.

However, if you were imagining you would be executing code that was above
4GiB, then forget it. z/OS doesn't support it at all. Even if you
could somehow conspire to get some code into storage above the bar, you
would not (in general) be able to execute it successfully because none of
the major control blocks that manage dispatching work can support saving a
full extended PSW, so while you might "get away with it" for a few
instructions, the moment you took an interrupt you'd be toast. Hence the
putative requirement to run disabled. For the purposes of this discussion
you may assume that's just a bonehead idea.


-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

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

is out of the office.

[Keith Zawila]

I will be out of the office starting  11/30/2010 and will not return until
12/01/2010.

I will be out of the office Tuesday (Nov 30).  I will return on Wednesday
(Dec 1).   Thanks.



HCSC Company Disclaimer

The information contained in this communication is confidential, private,
proprietary, or otherwise privileged and is intended only for the use of
the addressee.  Unauthorized use, disclosure, distribution or copying is
strictly prohibited and may be unlawful.  If you have received this
communication in error, please notify the sender immediately at (312)
653-6000 in Illinois; (800)835-8699 in New Mexico; (918)560-3500 in
Oklahoma; or (972)766-6900 in Texas.

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

Re: I would love to know what went wrong at NAB

[Chris Craddock]

On Tue, Nov 30, 2010 at 10:39 PM, Chase, John  wrote:

> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of Shane
> >
> > As if.
> > Can't you just imagine a major Aussie Bank doing that. You were at
> Bank
> > of NSW when they had the IMS fiasco Steve - how much info on that got
> > out ? (via Bank press releases I mean :-)
>
> Yeh  It's probably a near-universal trait that "dirty laundry" is
> "washed" discreetly  :-)




This would be one of those rare cases where the story was big enough that
there wasn't a lot of room for discrete laundering. It was actually Westpac
by then (btw) and I was there too. That "event" wasn't a single outage, but
rather a series of them wound around failed restart/recovery processing that
eventually took several days to fully recover from. There wasn't any news
coverage at first, but the scale of the problem had made the press by the
second day. Once it had there was plenty of blame storming to go around. I
don't recall whether the bank actually issued press releases but their point
of view certainly did make it into the press coverage.



-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

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

Re: I would love to know what went wrong at NAB

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Shane
> 
> As if.
> Can't you just imagine a major Aussie Bank doing that. You were at
Bank
> of NSW when they had the IMS fiasco Steve - how much info on that got
> out ? (via Bank press releases I mean :-)

Yeh  It's probably a near-universal trait that "dirty laundry" is
"washed" discreetly  :-)

-jc-

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

Re: I would love to know what went wrong at NAB

[Mike Schwab]

On Tue, Nov 30, 2010 at 7:01 PM, Wayne Bickerdike  wrote:

> My same source related the tale of a person in same bank who received
> an EBCDIC file, opened it in Windows and saved it back as ASCII. The
> file was duly transferred for processing on the mainframe. Most of the
> packed data was garbaged ..
>
> Oh my, dumb and dumber

Here is an idea to bounce around.  z/OS Unix System Services does a
lot of work converting ASCII to EBCDIC and back.  z/Linux works all in
ASCII.  Why not get 4 new instructions that work with PD<=> ASCII like
the PD <=> EBCDIC instructions PACK, UNPK, ED, EDMK, but with an A
suffix to denote ASCII character.  Conversion from Packed to binary
would be the same.  Assembler would get new instructions.  z/OS would
need to know if a file was ASCII for proper translation when printing
it.

Shoot, do we want to limit this to just ASCII?  Could we do some sort
of Unicode translation?  Have GPR2 point to a memory area that
indicates how many bytes per digit, then the 10 characters for 0-9?
EDMK would overlay this address anyway, so ok for input.  Would we
want the number of digits?  I.E. 10 for decimal, 8 for octal, 16 for
hexadecimal (good for dumps!), up to 36 to encode numbers into a
character string in some way (a basic encoding technique).  Would
Oriental languages want more than 255 numbers?  Save the UNICODE value
in the owner field, or a new field in the VTOC?

2 number of Bytes per digit, 2 number of digits, Digit 0, Digit 1,
Digit 2, ..., Digit N.

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

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

Re: 64 bit mode disabled

[Gerhard Adam]

How would you branch to code above the 2GB bar, since none is allowed there?
The obvious problem being how you would even get it loaded up there.  If I
recall, the fundamental problem is that the PSW cannot be saved with an
address greater than 31-bit for the next instruction since neither the TCB's
or RB's have a large enough area to store it.


>I have a vague memory of reading, here or on the assembler mailing list,
>that you would need to run disabled if you wanted to branch to code
>located above the bar.  I also have a vague memory that the Wrath of
>God would probably fall on you anyway if you tried it, disabled or not.

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

Re: 64 bit mode disabled

[Gerhard Adam]

If you were disabled it wouldn't be a very practical way to maintain data
buffers.

No, you don't have to be authorized, nor disabled.

> From what I understand running in 64 bit mode (SAM64)  you have to run
disabled  does the
> SAM64 instruction do that

  

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

Re: 64 bit mode disabled

[Gainsford, Allen]

On Tue, Nov 30, 2010 at 6:40 PM, michealbutz wrote:

>> Hi,
>>
>>  From what I understand running in 64 bit mode (SAM64)  you have to run
>> disabled  does the
>> SAM64 instruction do that
>>
>
>From my understanding, a problem state program can run in AMODE 64.  I don't
>think it is a requirement to run disabled to use AMODE 64.

Problem-state programs can definitely run in AMODE 64 without being
disabled -- I've written a few that did so.

I have a vague memory of reading, here or on the assembler mailing list,
that you would need to run disabled if you wanted to branch to code
located above the bar.  I also have a vague memory that the Wrath of
God would probably fall on you anyway if you tried it, disabled or not.


Allen Gainsford
===
Info Developer, Banking Shared Services
HP Enterprise Services (South Pacific)
Office +64-4-474-5133 | Fax +64-4-474-5258 | Email allen.gainsf...@hp.com

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

Re: 64 bit mode disabled

[Sam Siegel]

On Tue, Nov 30, 2010 at 6:40 PM, michealbutz wrote:

> Hi,
>
>  From what I understand running in 64 bit mode (SAM64)  you have to run
> disabled  does the
> SAM64 instruction do that
>

>From my understanding, a problem state program can run in AMODE 64.  I don't
think it is a requirement to run disabled to use AMODE 64.

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

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

Re: 64 bit mode disabled

[Steve Comstock]

On 11/30/2010 7:40 PM, michealbutz wrote:

Hi,

  From what I understand running in 64 bit mode (SAM64)  you have to run 
disabled  does the
SAM64 instruction do that




It's not what we know that hurts us - it's what we know that ain't so.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
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 new 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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

64 bit mode disabled

[michealbutz]

Hi,

 From what I understand running in 64 bit mode (SAM64)  you have to run 
disabled  does the
SAM64 instruction do that

  

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

Re: Could we define ARM Couple datasesr and OMVS Couple dataset?

[ibmnew]

Staller

 Thank you very much!


ARM Couple datasesr and OMVS Couple dataset? 
 
1) Yes you can define these files and policies. A CF is not needed for
this.
2) an OMVS couple dataset would only be needed if there are multiple
images sharing HFS/ZFS files, See the "Setting up a SYSPLEX" books (I
believe this is a redbook)
HTH,

There isn't any Couple facility in our shop.it was monoplex
configuration
Could we define ARM Couple datasesr and OMVS Couple dataset in our shop?
 If ARM couple dataset could be defined,we could define some arm police
to 
restart some Adderspaces when they abend.If it cann't be defined,what
else 
methods could Automatic Restart the abend AS?
 Do we need to define OMVS Couple dataset in our shop?

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

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

Re: "FOTS1346 Permission denied, please try again"

[John McKown]

I'm way out of my league now, so this is just speculation on my part.
But did your test sftp go to the same site and user at that site? I just
wonder if it is possible if the problem is at the far end. I really
don't know, I'm just musing out loud. 

I am at home on my Linux system. Where I have a full OpenSSH setup. I
set up two ids for testing. Call them "local" and "remote" for fun. I
created a ssh key using "local". I put the public key in remote's .ssh
authorized_keys file. I could then do an sftp connection from local to
remote. But if I changed the filemode on remote's .ssh to other than
700, I could not use the cert (it asked for the UNIX password). Also, if
I changed the authorized_keys file in remote's .ssh subdirectory to
where anyone other than the user had write access to it, I could not use
the digital cert, but was prompted for the password. Now, if I disable
the use of passwords in /etc/ssh/sshd_config, then I cannot connect at
all.

What I'm getting at is that I __think__ there __might__ be a problem on
the far end for one of the ssh files.

On Tue, 2010-11-30 at 17:58 -0500, Leonard Sasso wrote:
> Changed the directory and file permissions, received the same error 
> messages.
> 
> 
> Thank You.
> 
> Len Sasso
> 
> 
> 
> RDC Operations - Systems Administrator
> CSC
> Information Technology Infrastructure Services (ITIS)
> | p: 518.257-4209 | m: 518.894-0879 | f: 518.257-4300 | lsa...@csc.com | 
> www.csc.com
> 
> This is a PRIVATE message. If you are not the intended recipient, please 
> delete without copying and kindly advise us by e-mail of the mistake in 
> delivery. 
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
> any order or other contract unless pursuant to explicit written agreement 
> or government initiative expressly permitting the use of e-mail for such 
> purpose.
> 
> 
> 
> From:
> Kirk Wolf 
> To:
> IBM-MAIN@bama.ua.edu
> Date:
> 11/30/2010 05:25 PM
> Subject:
> Re: "FOTS1346 Permission denied, please try again"
> 
> 
> 
> Gil is correct.  Even though you aren't using keys, OpenSSH will try to
> cache a prng in .ssh, so it should be 700.
> 
> Best to stay with these recommendations for file permissions:
>   http://dovetail.com/docs/sftp/sftp-webinar.pdf  slide 29  "Common
> Pitfalls"
> 
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
> 
> On Tue, Nov 30, 2010 at 4:09 PM, Paul Gilmartin 
> wrote:
> 
> > On Tue, 30 Nov 2010 16:32:48 -0500, Leonard Sasso wrote:
> >
> > >Does the production RACF id have an OMVS segment?  Yes
> > >Does it have a HOME subdirectory?  Yes
> > >Is there a .ssh subdirectory in the $HOME for this user?  Yes
> > >Is the UNIX filemode for .ssh subdirectory set to 700 or 600?  Set to 
> 770
> > >Are the files in the .ssh subdirectory all set to filemode 600?  Set to
> > >600 or 644 or 777
> > >Is .ssh and all its files owned by the production RACF id?  Yes
> > >
> > Those might be too permissive.  "For your protection" some
> > variants of SSL/SSH prohibit that any files in ~/.ssh, and
> > any directories in its path, be group writeable.  Stay with
> > 700 for directories and 600 for basefiles.
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
-- 
John McKown
Maranatha! <><

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

Re: I would love to know what went wrong at NAB

[Sam Siegel]

On Tue, Nov 30, 2010 at 5:01 PM, Wayne Bickerdike  wrote:

> Some information from a close source...
>
> It was a plain old S0C7 during their batch process.
>
> All Aussie banks use Cemtex ABA format which has been around for years
> as a transfer format between organisations. You would think that there
> is a validate step before running the transactions against their
> databases.
>
>
> A couple of things:
>
> Most of the support is now with the sub-continent...
> The previous grey-haired support staff were either laid off or moved
> to "greener pastures"
> Not many local staff are competent to manually reprocess or react to
> this situation.
>
> As a previous poster noted, probably the new transaction batch goes to
> a GDG, the failed process was missed and batch read yesterday's GDG
> and hence all the double transactions.
>
> My same source related the tale of a person in same bank who received
> an EBCDIC file, opened it in Windows and saved it back as ASCII. The
> file was duly transferred for processing on the mainframe. Most of the
> packed data was garbaged ..
>
> Oh my, dumb and dumber
>
> Frightening.

>
> On Wed, Dec 1, 2010 at 11:19 AM, Shane  wrote:
> > As if.
> > Can't you just imagine a major Aussie Bank doing that. You were at Bank
> > of NSW when they had the IMS fiasco Steve - how much info on that got
> > out ? (via Bank press releases I mean :-)
> >
> > Shane ...
> >
> > On Tue, 30 Nov 2010 18:52:08 +1100
> > Stephen Mednick wrote:
> >
> >> One wonders if a detailed explanation of what transpired will be
> >> forthcoming as was the case back in July when the DBS Bank in
> >> Singapore had a major outage.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
>
>
>
> --
> Wayne V. Bickerdike
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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

Re: I would love to know what went wrong at NAB

[Wayne Bickerdike]

Some information from a close source...

It was a plain old S0C7 during their batch process.

All Aussie banks use Cemtex ABA format which has been around for years
as a transfer format between organisations. You would think that there
is a validate step before running the transactions against their
databases.


A couple of things:

Most of the support is now with the sub-continent...
The previous grey-haired support staff were either laid off or moved
to "greener pastures"
Not many local staff are competent to manually reprocess or react to
this situation.

As a previous poster noted, probably the new transaction batch goes to
a GDG, the failed process was missed and batch read yesterday's GDG
and hence all the double transactions.

My same source related the tale of a person in same bank who received
an EBCDIC file, opened it in Windows and saved it back as ASCII. The
file was duly transferred for processing on the mainframe. Most of the
packed data was garbaged ..

Oh my, dumb and dumber


On Wed, Dec 1, 2010 at 11:19 AM, Shane  wrote:
> As if.
> Can't you just imagine a major Aussie Bank doing that. You were at Bank
> of NSW when they had the IMS fiasco Steve - how much info on that got
> out ? (via Bank press releases I mean :-)
>
> Shane ...
>
> On Tue, 30 Nov 2010 18:52:08 +1100
> Stephen Mednick wrote:
>
>> One wonders if a detailed explanation of what transpired will be
>> forthcoming as was the case back in July when the DBS Bank in
>> Singapore had a major outage.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Wayne V. Bickerdike

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

OSAM allocation question

[Veena, Sridhar]

Hi, 

 

Following is the allocation for one of our DB datasets...

 

DSN=PROD.OSAM.DATASET

DISP=(,CATLG),   

DCB=(RECFM=FB,LRECL=8192,BLKSIZE=8192),  

VOL=SER=(VOL1,VOL2,VOL3),  

SPACE=(CYL,(2500,400))   

 

The three volumes, VOL1, VOL2 and VOL3, are part of storage class
defined with 'Guaranteed Space = Yes' . The DB dataset got created with
3 extents and 7500 cylinders (2500 on each volume). 

 

My question is, if the DB dataset tries to grow beyond 7500 cylinders of
initial allocation, will it get any secondary allocation of 400
cylinders?!

 

Thanks & Rgds

Sridhar K Veena 

 


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

Re: CA1, tape pooling, and SMS controlled Libraries

[Russell Witt]

Darth,

Are both devices 841C and 8401 inside the same MDL and managed as part of
the same Storage Group? The problem with CA-1 subpooling and most
robotic/virtual libraries is that tapes are not mounted based on the
TMS001/TMS002 mount messages, but instead based on their own rules. Now, a
BTLS managed IBM robot does support a few sub-pools; their restriction is
that the name of the subpool must begin with SCRTCH followed by a number 1-9
(as in SCRTCH1 or SCRTCH2).

With a true manual environment (where the operator mounts the tapes), the
TMS001/2 mount message is intercepted by the operator. With a
robotic/virtual environment; this is not always the case. With a Oracle/STK
robot, they have added support for the TMS002 mount message. But I do not
believe that HDS MDL has support to mount the correct subpool tape based on
a TMS002 mount message.

Russell Witt
CA 1 L2 Support Manager

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on
Behalf Of Darth Keller
Sent: Tuesday, November 30, 2010 3:04 PM
To: IBM-MAIN@bama.ua.edu
Subject: CA1, tape pooling, and SMS controlled Libraries


We've recently installed an HDS MDL.  In the course of the installation,
we decided we wanted to stage things so that down the road we can do
remote replication of tape.  Basically we don't intend to replicate the
entire library - we'll replicate tapes which have been identified as
needing off-site vaulting.  We've done this by implementing CA1
sub-pooling which allows us to direct a sub-set of datasets to a specific
range of tape volsers.  The volser's to be vaulted all start with the
first character of 'V" and the sub-pool is named "DRVAULT".

The intention is that down the road at some point, we'll have another MDL
at a remote site and we'll use 'magic' HDS functionality to replicate the
"V" volumes to the remote MDL.

This has been running successfully since late July.  However, we've
recently had 2 different jobs abend because it appears that CA1 is calling
for a tape from the wrong aub-pool.  The job is re-submitted approx. 15
minutes later and runs successfully - no changes to the job, no changes to
the CA1 NSM table, no changes to the MDL in the 15 minute interval.

This is what the messages look like when it runs successfully:

*IEC501A M 841C,PRIVAT,SL,COMP,jobname,
*TMS002  IEC501A M 841C,DRVAULT,SL,COMP
 IECTMS9 841C,V95538,jobname,OUTFILE ,


The is the sequence of messages when it runs amok:

*IEC501A M 8401,PRIVAT,SL,COMP,jobname,
*TMS001  IEC501A M 8401,PRIVAT,SL,COMP,jobname,
 IECTMS3 8401,M33439,IS NOT SCRTCH (80)
 IEC518I SOFTWARE ERRSTAT: REJTMS   8401,M33439,SL,jobname,

So we opened an issue with CA1 & got the following response:
   "Since you have this defined as a manual tape library subpooling is not
supported.  CA1 subpooling is NOT supported with IBM SMS-managed tape
libraries (ATL or
MTL)."

I find this response interesting as I'm not seeing how an SMS Library
comes into play in this case -  the library is actually returning a
scratch tape from the pool CA1 is requesting - for some reason, it appears
to me that CA1 is sometimes requesting the wrong sub-pool.

So my question is anyone else using CA1 sub-pooling and SMS-managed tape
libraries?
thanks - dd keller

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

Re: I would love to know what went wrong at NAB

[Shane]

As if.
Can't you just imagine a major Aussie Bank doing that. You were at Bank
of NSW when they had the IMS fiasco Steve - how much info on that got
out ? (via Bank press releases I mean :-)

Shane ...

On Tue, 30 Nov 2010 18:52:08 +1100
Stephen Mednick wrote:

> One wonders if a detailed explanation of what transpired will be
> forthcoming as was the case back in July when the DBS Bank in
> Singapore had a major outage.

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

Re: "FOTS1346 Permission denied, please try again"

[Kirk Wolf]

>From the trace it looks like a password packet is being sent to the remote
system and is being rejected.

Can you logon to the same target system and userid from an interactive sftp
client?  Make sure that you use the same case in both the userid and
password. If so, then perhaps there is a problem with how you are reading
the password in your ASKPASS scriptmaybe you are getting extra garbage
characters in your password?  Try adding some debugging to your script like:

# read pw from a one-line file
pw=$(cat pwfile)
echo "length of pw is:" ${#pw} > /dev/fd2
# write pw to stdout for ssh consumption
echo $pw

If this still doesn't work, then you might want to look at the sshd logs
from the server to see why it rejected the login.   Maybe it has a
DenyHosts, etc.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com


On Tue, Nov 30, 2010 at 4:58 PM, Leonard Sasso  wrote:

> Changed the directory and file permissions, received the same error
> messages.
>
>
> Thank You.
>
> Len Sasso
>
>
>
> RDC Operations - Systems Administrator
> CSC
> Information Technology Infrastructure Services (ITIS)
> | p: 518.257-4209 | m: 518.894-0879 | f: 518.257-4300 | lsa...@csc.com |
> www.csc.com
>
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
> any order or other contract unless pursuant to explicit written agreement
> or government initiative expressly permitting the use of e-mail for such
> purpose.
>
>
>
> From:
> Kirk Wolf 
> To:
> IBM-MAIN@bama.ua.edu
> Date:
> 11/30/2010 05:25 PM
> Subject:
> Re: "FOTS1346 Permission denied, please try again"
>
>
>
> Gil is correct.  Even though you aren't using keys, OpenSSH will try to
> cache a prng in .ssh, so it should be 700.
>
> Best to stay with these recommendations for file permissions:
>  http://dovetail.com/docs/sftp/sftp-webinar.pdf  slide 29  "Common
> Pitfalls"
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> On Tue, Nov 30, 2010 at 4:09 PM, Paul Gilmartin
> wrote:
>
> > On Tue, 30 Nov 2010 16:32:48 -0500, Leonard Sasso wrote:
> >
> > >Does the production RACF id have an OMVS segment?  Yes
> > >Does it have a HOME subdirectory?  Yes
> > >Is there a .ssh subdirectory in the $HOME for this user?  Yes
> > >Is the UNIX filemode for .ssh subdirectory set to 700 or 600?  Set to
> 770
> > >Are the files in the .ssh subdirectory all set to filemode 600?  Set to
> > >600 or 644 or 777
> > >Is .ssh and all its files owned by the production RACF id?  Yes
> > >
> > Those might be too permissive.  "For your protection" some
> > variants of SSL/SSH prohibit that any files in ~/.ssh, and
> > any directories in its path, be group writeable.  Stay with
> > 700 for directories and 600 for basefiles.
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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

Re: "FOTS1346 Permission denied, please try again"

[Leonard Sasso]

Changed the directory and file permissions, received the same error 
messages.


Thank You.

Len Sasso



RDC Operations - Systems Administrator
CSC
Information Technology Infrastructure Services (ITIS)
| p: 518.257-4209 | m: 518.894-0879 | f: 518.257-4300 | lsa...@csc.com | 
www.csc.com

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



From:
Kirk Wolf 
To:
IBM-MAIN@bama.ua.edu
Date:
11/30/2010 05:25 PM
Subject:
Re: "FOTS1346 Permission denied, please try again"



Gil is correct.  Even though you aren't using keys, OpenSSH will try to
cache a prng in .ssh, so it should be 700.

Best to stay with these recommendations for file permissions:
  http://dovetail.com/docs/sftp/sftp-webinar.pdf  slide 29  "Common
Pitfalls"

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, Nov 30, 2010 at 4:09 PM, Paul Gilmartin 
wrote:

> On Tue, 30 Nov 2010 16:32:48 -0500, Leonard Sasso wrote:
>
> >Does the production RACF id have an OMVS segment?  Yes
> >Does it have a HOME subdirectory?  Yes
> >Is there a .ssh subdirectory in the $HOME for this user?  Yes
> >Is the UNIX filemode for .ssh subdirectory set to 700 or 600?  Set to 
770
> >Are the files in the .ssh subdirectory all set to filemode 600?  Set to
> >600 or 644 or 777
> >Is .ssh and all its files owned by the production RACF id?  Yes
> >
> Those might be too permissive.  "For your protection" some
> variants of SSL/SSH prohibit that any files in ~/.ssh, and
> any directories in its path, be group writeable.  Stay with
> 700 for directories and 600 for basefiles.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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



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

Re: "FOTS1346 Permission denied, please try again"

[Leonard Sasso]

Kirk:

We were successful using our Test Userid using SSH_ASKPASS along with the 
"-b" option.

We have "BatchMode no" in our custom ssh_config file.


-vvv log contents:

OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /u/home/lsasso/.ssh/PConfg
debug3: Seeding PRNG from /usr/lib/ssh/ssh-rand-helper
debug1: Rhosts Authentication disabled, originating port will not be 
trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to 216.115.171.196 Ý216.115.171.196¨ port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /u/home/lsasso/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-END'
debug3: key_read: missing keytype
debug1: identity file /u/home/lsasso/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /u/home/lsasso/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-END'
debug3: key_read: missing keytype
debug1: identity file /u/home/lsasso/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version 6.0.3.9 SSH 
Tectia Server
debug1: no match: 6.0.3.9 SSH Tectia Server
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
debug3: RNG is ready, skipping seeding
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: 
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-...@lysator.liu.se,ae
debug2: kex_parse_kexinit: 
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-...@lysator.liu.se,ae
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: 
aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc,seed-...@ssh.com,crypticore...@ssh.com
debug2: kex_parse_kexinit: 
aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc,seed-...@ssh.com,crypticore...@ssh.com
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,crypticore-...@ssh.com
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,crypticore-...@ssh.com
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: dh_gen_key: priv key bits set: 134/256
debug2: bits set: 518/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug3: check_host_in_hostfile: filename /u/home/lsasso/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host '216.115.171.196' is known and matches the RSA host key.
debug1: Found key in /u/home/lsasso/.ssh/known_hosts:1
debug2: bits set: 513/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /u/home/lsasso/.ssh/id_rsa (19b40098)
debug2: key: /u/home/lsasso/.ssh/id_dsa (19b400f8)
debug1: Authentications that can continue: 
gssapi-with-mic,password,publickey,keyboard-interactive
debug3: start over, passed a different l

Re: "FOTS1346 Permission denied, please try again"

[Kirk Wolf]

Gil is correct.  Even though you aren't using keys, OpenSSH will try to
cache a prng in .ssh, so it should be 700.

Best to stay with these recommendations for file permissions:
  http://dovetail.com/docs/sftp/sftp-webinar.pdf  slide 29  "Common
Pitfalls"

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, Nov 30, 2010 at 4:09 PM, Paul Gilmartin wrote:

> On Tue, 30 Nov 2010 16:32:48 -0500, Leonard Sasso wrote:
>
> >Does the production RACF id have an OMVS segment?  Yes
> >Does it have a HOME subdirectory?  Yes
> >Is there a .ssh subdirectory in the $HOME for this user?  Yes
> >Is the UNIX filemode for .ssh subdirectory set to 700 or 600?  Set to 770
> >Are the files in the .ssh subdirectory all set to filemode 600?  Set to
> >600 or 644 or 777
> >Is .ssh and all its files owned by the production RACF id?  Yes
> >
> Those might be too permissive.  "For your protection" some
> variants of SSL/SSH prohibit that any files in ~/.ssh, and
> any directories in its path, be group writeable.  Stay with
> 700 for directories and 600 for basefiles.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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

Re: CA1, tape pooling, and SMS controlled Libraries

[Mike Schwab]

On Tue, Nov 30, 2010 at 3:04 PM, Darth Keller  wrote:
> We've recently installed an HDS MDL.  In the course of the installation,
> we decided we wanted to stage things so that down the road we can do
> remote replication of tape.  Basically we don't intend to replicate the
> entire library - we'll replicate tapes which have been identified as
> needing off-site vaulting.  We've done this by implementing CA1
> sub-pooling which allows us to direct a sub-set of datasets to a specific
> range of tape volsers.  The volser's to be vaulted all start with the
> first character of 'V" and the sub-pool is named "DRVAULT".
>
> The intention is that down the road at some point, we'll have another MDL
> at a remote site and we'll use 'magic' HDS functionality to replicate the
> "V" volumes to the remote MDL.
>
> This has been running successfully since late July.  However, we've
> recently had 2 different jobs abend because it appears that CA1 is calling
> for a tape from the wrong aub-pool.  The job is re-submitted approx. 15
> minutes later and runs successfully - no changes to the job, no changes to
> the CA1 NSM table, no changes to the MDL in the 15 minute interval.
>
> This is what the messages look like when it runs successfully:
>
> *IEC501A M 841C,PRIVAT,SL,COMP,jobname,
> *TMS002  IEC501A M 841C,DRVAULT,SL,COMP
>  IECTMS9 841C,V95538,jobname,OUTFILE ,
>
>
> The is the sequence of messages when it runs amok:
>
> *IEC501A M 8401,PRIVAT,SL,COMP,jobname,
> *TMS001  IEC501A M 8401,PRIVAT,SL,COMP,jobname,
>  IECTMS3 8401,M33439,IS NOT SCRTCH (80)
>  IEC518I SOFTWARE ERRSTAT: REJTMS   8401,M33439,SL,jobname,
>
> So we opened an issue with CA1 & got the following response:
>   "Since you have this defined as a manual tape library subpooling is not
> supported.  CA1 subpooling is NOT supported with IBM SMS-managed tape
> libraries (ATL or
> MTL)."
>
> I find this response interesting as I'm not seeing how an SMS Library
> comes into play in this case -  the library is actually returning a
> scratch tape from the pool CA1 is requesting - for some reason, it appears
> to me that CA1 is sometimes requesting the wrong sub-pool.
>
> So my question is anyone else using CA1 sub-pooling and SMS-managed tape
> libraries?
> thanks - dd keller

Our site used to get this too, assigning volumes from the wrong pool.
Immediately after you get the error message see how many scratch tapes
you have and how many in the various sub pools.  You might be running
faster than the VTS is scratching tapes.

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

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

Re: “FOTS1346 Permission denied, please try again”

[Williamson, James R]

Is the production Userid defined to the remote system? 
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Leonard Sasso
Sent: Tuesday, November 30, 2010 2:59 PM
To: IBM-MAIN@bama.ua.edu
Subject: “FOTS1346 Permission denied, please try again”

Our Mainframe Batch job is successful using a Test Userid and Password to 
SSH to a remote host using password authentication (via askpass).  When we 
try the same job with the Production Userid and Password, we receive the 
following error: “FOTS1346 Permission denied, please try again”. This 
causes user authentication to fail. The SSH client then eventually fails 
with the error: “FOTS1373 Permission denied 
(publickey,password,keyboard-interactive)”. 

Per the IBM Ported Tools for z/OS User’s Guide (page 111 - # 22):

“Verify that you are not trying to use ssh while switched to another user 
ID. In other words, did you issue ssh after the su command? The original 
controlling terminal (displayed by the tty command) is owned by the user 
ID originally logged in. Your target user may not have permission to read 
from it.”

We are not issuing the “su” command (what is the “su” command)?

Any help would be appreciated.


Thank You.

Len Sasso



RDC Operations - Systems Administrator
CSC
Information Technology Infrastructure Services (ITIS)
| p: 518.257-4209 | m: 518.894-0879 | f: 518.257-4300 | lsa...@csc.com | 
www.csc.com

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

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

Re: HSM and SA VTS

[Billy R. Bingham]

I agree its not a bad thing. If we don't 
find why this is happening for the VTS and 
not for real tapes we will just have to 
define more virtual VOLSERs in the VTS.

Thanks for all the replys.


Billy
On 30 Nov 2010 at 13:33, Gibney, Dave 
wrote:

> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> > Behalf Of Billy R. Bingham
> > Sent: Tuesday, November 30, 2010 9:39 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: HSM and SA VTS
> > 
> > Hello all,
> > 
> > Just remember that I'm not z/OS literate,
> > but...
> > 
> > We just implemented a VTS from SecureAgent
> > and now when running HSM backups it seems
> > to be putting each DASD volume backed up
> > to a separate VTS tape. Does anyone have
> > any ideas what might be causing this or
> > what I should look at?
> 
> I concur with Mark, so what? This should be viewed as a good thing, IMO.
> 
> Dave Gibney
> Information Technology Services
> Washington State University
> 
> > 
> > 
> > Thanks,
> > 
> > Billy
> > 
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 



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

Re: "FOTS1346 Permission denied, please try again"

[Paul Gilmartin]

On Tue, 30 Nov 2010 16:32:48 -0500, Leonard Sasso wrote:

>Does the production RACF id have an OMVS segment?  Yes
>Does it have a HOME subdirectory?  Yes
>Is there a .ssh subdirectory in the $HOME for this user?  Yes
>Is the UNIX filemode for .ssh subdirectory set to 700 or 600?  Set to 770
>Are the files in the .ssh subdirectory all set to filemode 600?  Set to
>600 or 644 or 777
>Is .ssh and all its files owned by the production RACF id?  Yes
>
Those might be too permissive.  "For your protection" some
variants of SSL/SSH prohibit that any files in ~/.ssh, and
any directories in its path, be group writeable.  Stay with
700 for directories and 600 for basefiles.

-- gil

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

Re: "FOTS1346 Permission denied, please try again"

[McKown, John]

Well, the 770 on .ssh doesn't seem right to me, but I haven't looked at the 
OpenSSH source code.


http://www.openssh.org/faq.html

3.14 - I copied my public key to authorized_keys but public-key authentication 
still doesn't work.

Typically this is caused by the file permissions on $HOME, $HOME/.ssh or 
$HOME/.ssh/authorized_keys being more permissive than sshd allows by default.

In this case, it can be solved by executing the following on the server.

$ chmod go-w $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys $ chown `whoami` 
$HOME/.ssh/authorized_keys

If this is not possible for some reason, an alternative is to set StrictModes 
no in sshd_config, however this is not recommended.





--
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-m...@bama.ua.edu] On Behalf Of Leonard Sasso
> Sent: Tuesday, November 30, 2010 3:33 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: "FOTS1346 Permission denied, please try again"
> 
> Does the production RACF id have an OMVS segment?  Yes
> Does it have a HOME subdirectory?  Yes 
> Is there a .ssh subdirectory in the $HOME for this user?  Yes
> Is the UNIX filemode for .ssh subdirectory set to 700 or 600? 
>  Set to 770
> Are the files in the .ssh subdirectory all set to filemode 
> 600?  Set to 
> 600 or 644 or 777
> Is .ssh and all its files owned by the production RACF id?  Yes
> 
> 
> JCL:
> 
> //SASSCAQP JOB OPS,'SFTP TESTING',CLASS=1,MSGCLASS=X,USER=LSASSO, 
> //NOTIFY=LSASSO 
> /*JOBPARM S=TST1 
> //* 
> //SFTP EXEC PGM=BPXBATCH,REGION=0M, 
> // PARM=('sh sftp -vvv -F /u/home/lsasso/.ssh/config -b 
> /u/home/lsasso/ 
> // cmd.txt nymedicaid...@ftp.upd.caqh.org') 
> //* 
> //STDOUT   DD SYSOUT=*,LRECL=132,RECFM=F 
> //STDERR   DD SYSOUT=*,LRECL=132,RECFM=F 
> //STDENV   DD * 
> DISPLAY=FOO 
> SSH_ASKPASS=/u/home/lsasso/askpass.sh 
> //* 
> 
> 
> 
> Thank You.
> 
> Len Sasso
> 
> 
> 
> RDC Operations - Systems Administrator
> CSC
> Information Technology Infrastructure Services (ITIS)
> | p: 518.257-4209 | m: 518.894-0879 | f: 518.257-4300 | 
> lsa...@csc.com | 
> www.csc.com
> 
> This is a PRIVATE message. If you are not the intended 
> recipient, please 
> delete without copying and kindly advise us by e-mail of the 
> mistake in 
> delivery. 
> NOTE: Regardless of content, this e-mail shall not operate to 
> bind CSC to 
> any order or other contract unless pursuant to explicit 
> written agreement 
> or government initiative expressly permitting the use of 
> e-mail for such 
> purpose.
> 
> 
> 
> From:
> "McKown, John" 
> To:
> IBM-MAIN@bama.ua.edu
> Date:
> 11/30/2010 04:13 PM
> Subject:
> Re: "FOTS1346 Permission denied, please try  again"
> 
> 
> 
> It might be easier to see if you'd post the JCL and SYSIN 
> type input for 
> the failing step. Does the production RACF id have an OMVS 
> segment? Does 
> it have a HOME subdirectory? Is there a .ssh subdirectory in 
> the $HOME for 
> this user? Is the UNIX filemode for .ssh subdirectory set to 
> 700 or 600? 
> Are the files in the .ssh subdirectory all set to filemode 
> 600? Is .ssh 
> and all its files owned by the production RACF id? Just some 
> questions.
> 
> --
> 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-m...@bama.ua.edu] On Behalf Of Leonard Sasso
> > Sent: Tuesday, November 30, 2010 2:59 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: "FOTS1346 Permission denied, please try again"
> > 
> > Our Mainfram

Re: "FOTS1346 Permission denied, please try again"

[Kirk Wolf]

Leonard,

Were you successful using your test userid using SSH_ASKPASS along with the
"-b" option?
If you have your askpass script write something to stderr, you may find that
it is not being called.

This is because the "-b file" switch enables "-oBatchMode=yes", which
disables SSH_ASKPASS.

But if you do have "BatchMode yes" in your custom ssh_config file, then it
could be something else.  I would need to see the -vvv log to make any more
guesses :-)

Regards,

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> Here is some sample JCL that we include with (free) Co:Z SFTP that
solves this problem:

//RUNSFTP EXEC PGM=COZBATCH  (BPXBATCH replacement)
//STDIN DD *

# Customize these ...
coz_bin="/opt/dovetail/coz/bin"
remoteuser="uid"
server="remote.host.name"
servercp="ISO8859-1"
remotefile="/path/to/file"

# These can be used to read the ssh password from a (secured) dataset
# if you don't want to setup public/private keypairs
export PASSWD_DSN='//COZUSER.PASSWD(SITE1)'
export SSH_ASKPASS=$coz_bin/read_passwd_dsn.sh
export DISPLAY=none

ssh_opts="-oBatchMode=no"  # allows ssh to use SSH_ASKPASS program
ssh_opts="$ssh_opts -oConnectTimeout=60"
ssh_opts="$ssh_opts -oServerAliveInterval=60"
ssh_opts="$ssh_opts -oStrictHostKeyChecking=no" # accept initial host keys

# Invoke the Co:Z sftp client with an in-line batch of commands
# that downloads a remote file to a local DD.
# Note that "-oBatchMode=no" must be specified before "-b"
#  since ssh opts are first-sticky

$coz_bin/cozsftp  $ssh_opts -b- $remoteu...@$server < wrote:

> Does the production RACF id have an OMVS segment?  Yes
> Does it have a HOME subdirectory?  Yes
> Is there a .ssh subdirectory in the $HOME for this user?  Yes
> Is the UNIX filemode for .ssh subdirectory set to 700 or 600?  Set to 770
> Are the files in the .ssh subdirectory all set to filemode 600?  Set to
> 600 or 644 or 777
> Is .ssh and all its files owned by the production RACF id?  Yes
>
>
> JCL:
>
> //SASSCAQP JOB OPS,'SFTP TESTING',CLASS=1,MSGCLASS=X,USER=LSASSO,
> //NOTIFY=LSASSO
> /*JOBPARM S=TST1
> //*
> //SFTP EXEC PGM=BPXBATCH,REGION=0M,
> // PARM=('sh sftp -vvv -F /u/home/lsasso/.ssh/config -b /u/home/lsasso/
> // cmd.txt nymedicaid...@ftp.upd.caqh.org')
> //*
> //STDOUT   DD SYSOUT=*,LRECL=132,RECFM=F
> //STDERR   DD SYSOUT=*,LRECL=132,RECFM=F
> //STDENV   DD *
> DISPLAY=FOO
> SSH_ASKPASS=/u/home/lsasso/askpass.sh
> //*
>
>
>
> Thank You.
>
> Len Sasso
>
>
>
> RDC Operations - Systems Administrator
> CSC
> Information Technology Infrastructure Services (ITIS)
> | p: 518.257-4209 | m: 518.894-0879 | f: 518.257-4300 | lsa...@csc.com |
> www.csc.com
>
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
> any order or other contract unless pursuant to explicit written agreement
> or government initiative expressly permitting the use of e-mail for such
> purpose.
>
>
>
> From:
> "McKown, John" 
> To:
> IBM-MAIN@bama.ua.edu
> Date:
> 11/30/2010 04:13 PM
> Subject:
> Re: "FOTS1346 Permission denied, please try  again"
>
>
>
> It might be easier to see if you'd post the JCL and SYSIN type input for
> the failing step. Does the production RACF id have an OMVS segment? Does
> it have a HOME subdirectory? Is there a .ssh subdirectory in the $HOME for
> this user? Is the UNIX filemode for .ssh subdirectory set to 700 or 600?
> Are the files in the .ssh subdirectory all set to filemode 600? Is .ssh
> and all its files owned by the production RACF id? Just some questions.
>
> --
> 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-m...@bama.ua.edu] On Behalf Of Leonard Sasso
> > Sent: Tuesday, November 30, 2010 2:59 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: "FOTS1346 Permission denied, please try again"
> >
> > Our Mainframe Batch job is successful using a Test Userid and
> > Password to
> > SSH to a remote host using password authentication (via
> > askpass).  When we
> > try the same job with the Production Userid and Password, we
> > receive the
> > following error: "FOTS1346 Permiss

Re: HSM and SA VTS

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Billy R. Bingham
> Sent: Tuesday, November 30, 2010 9:39 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: HSM and SA VTS
> 
> Hello all,
> 
> Just remember that I'm not z/OS literate,
> but...
> 
> We just implemented a VTS from SecureAgent
> and now when running HSM backups it seems
> to be putting each DASD volume backed up
> to a separate VTS tape. Does anyone have
> any ideas what might be causing this or
> what I should look at?

I concur with Mark, so what? This should be viewed as a good thing, IMO.

Dave Gibney
Information Technology Services
Washington State University

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

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

Re: "FOTS1346 Permission denied, please try again"

[Leonard Sasso]

Does the production RACF id have an OMVS segment?  Yes
Does it have a HOME subdirectory?  Yes 
Is there a .ssh subdirectory in the $HOME for this user?  Yes
Is the UNIX filemode for .ssh subdirectory set to 700 or 600?  Set to 770
Are the files in the .ssh subdirectory all set to filemode 600?  Set to 
600 or 644 or 777
Is .ssh and all its files owned by the production RACF id?  Yes


JCL:

//SASSCAQP JOB OPS,'SFTP TESTING',CLASS=1,MSGCLASS=X,USER=LSASSO, 
//NOTIFY=LSASSO 
/*JOBPARM S=TST1 
//* 
//SFTP EXEC PGM=BPXBATCH,REGION=0M, 
// PARM=('sh sftp -vvv -F /u/home/lsasso/.ssh/config -b /u/home/lsasso/ 
// cmd.txt nymedicaid...@ftp.upd.caqh.org') 
//* 
//STDOUT   DD SYSOUT=*,LRECL=132,RECFM=F 
//STDERR   DD SYSOUT=*,LRECL=132,RECFM=F 
//STDENV   DD * 
DISPLAY=FOO 
SSH_ASKPASS=/u/home/lsasso/askpass.sh 
//* 



Thank You.

Len Sasso



RDC Operations - Systems Administrator
CSC
Information Technology Infrastructure Services (ITIS)
| p: 518.257-4209 | m: 518.894-0879 | f: 518.257-4300 | lsa...@csc.com | 
www.csc.com

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



From:
"McKown, John" 
To:
IBM-MAIN@bama.ua.edu
Date:
11/30/2010 04:13 PM
Subject:
Re: "FOTS1346 Permission denied, please try  again"



It might be easier to see if you'd post the JCL and SYSIN type input for 
the failing step. Does the production RACF id have an OMVS segment? Does 
it have a HOME subdirectory? Is there a .ssh subdirectory in the $HOME for 
this user? Is the UNIX filemode for .ssh subdirectory set to 700 or 600? 
Are the files in the .ssh subdirectory all set to filemode 600? Is .ssh 
and all its files owned by the production RACF id? Just some questions.

--
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-m...@bama.ua.edu] On Behalf Of Leonard Sasso
> Sent: Tuesday, November 30, 2010 2:59 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: "FOTS1346 Permission denied, please try again"
> 
> Our Mainframe Batch job is successful using a Test Userid and 
> Password to 
> SSH to a remote host using password authentication (via 
> askpass).  When we 
> try the same job with the Production Userid and Password, we 
> receive the 
> following error: "FOTS1346 Permission denied, please try again". This 
> causes user authentication to fail. The SSH client then 
> eventually fails 
> with the error: "FOTS1373 Permission denied 
> (publickey,password,keyboard-interactive)". 
> 
> Per the IBM Ported Tools for z/OS User's Guide (page 111 - # 22):
> 
> "Verify that you are not trying to use ssh while switched to 
> another user 
> ID. In other words, did you issue ssh after the su command? 
> The original 
> controlling terminal (displayed by the tty command) is owned 
> by the user 
> ID originally logged in. Your target user may not have 
> permission to read 
> from it."
> 
> We are not issuing the "su" command (what is the "su" command)?
> 
> Any help would be appreciated.
> 
> 
> Thank You.
> 
> Len Sasso
> 
> 
> 
> RDC Operations - Systems Administrator
> CSC
> Information Technology Infrastructure Services (ITIS)
> | p: 518.257-4209 | m: 518.894-0879 | f: 518.257-4300 | 
> lsa...@csc.com | 
> www.csc.com
> 
> This is a PRIVATE message. If you are not the intended 
> recipient, please 
> delete without copying and kindly advise us by e-mail of the 
> mistake in 
> delivery. 
> NOTE: Regardless of content, this e-mail shall not operate to 
> bind CSC to 
> any order or other contract unless pursuant to explicit 
> written agreement 
> or government initiative expressly permitting the use of 
> e-mail for such 
> purpose.
> 

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



-

Re: "FOTS1346 Permission denied, please try again"

[McKown, John]

It might be easier to see if you'd post the JCL and SYSIN type input for the 
failing step. Does the production RACF id have an OMVS segment? Does it have a 
HOME subdirectory? Is there a .ssh subdirectory in the $HOME for this user? Is 
the UNIX filemode for .ssh subdirectory set to 700 or 600? Are the files in the 
.ssh subdirectory all set to filemode 600? Is .ssh and all its files owned by 
the production RACF id? Just some questions.

--
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-m...@bama.ua.edu] On Behalf Of Leonard Sasso
> Sent: Tuesday, November 30, 2010 2:59 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: "FOTS1346 Permission denied, please try again"
> 
> Our Mainframe Batch job is successful using a Test Userid and 
> Password to 
> SSH to a remote host using password authentication (via 
> askpass).  When we 
> try the same job with the Production Userid and Password, we 
> receive the 
> following error: "FOTS1346 Permission denied, please try again". This 
> causes user authentication to fail. The SSH client then 
> eventually fails 
> with the error: "FOTS1373 Permission denied 
> (publickey,password,keyboard-interactive)". 
> 
> Per the IBM Ported Tools for z/OS User's Guide (page 111 - # 22):
> 
> "Verify that you are not trying to use ssh while switched to 
> another user 
> ID. In other words, did you issue ssh after the su command? 
> The original 
> controlling terminal (displayed by the tty command) is owned 
> by the user 
> ID originally logged in. Your target user may not have 
> permission to read 
> from it."
> 
> We are not issuing the "su" command (what is the "su" command)?
> 
> Any help would be appreciated.
> 
> 
> Thank You.
> 
> Len Sasso
> 
> 
> 
> RDC Operations - Systems Administrator
> CSC
> Information Technology Infrastructure Services (ITIS)
> | p: 518.257-4209 | m: 518.894-0879 | f: 518.257-4300 | 
> lsa...@csc.com | 
> www.csc.com
> 
> This is a PRIVATE message. If you are not the intended 
> recipient, please 
> delete without copying and kindly advise us by e-mail of the 
> mistake in 
> delivery. 
> NOTE: Regardless of content, this e-mail shall not operate to 
> bind CSC to 
> any order or other contract unless pursuant to explicit 
> written agreement 
> or government initiative expressly permitting the use of 
> e-mail for such 
> purpose.
> 

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

CA1, tape pooling, and SMS controlled Libraries

[Darth Keller]

We've recently installed an HDS MDL.  In the course of the installation, 
we decided we wanted to stage things so that down the road we can do 
remote replication of tape.  Basically we don't intend to replicate the 
entire library - we'll replicate tapes which have been identified as 
needing off-site vaulting.  We've done this by implementing CA1 
sub-pooling which allows us to direct a sub-set of datasets to a specific 
range of tape volsers.  The volser's to be vaulted all start with the 
first character of 'V" and the sub-pool is named "DRVAULT". 

The intention is that down the road at some point, we'll have another MDL 
at a remote site and we'll use 'magic' HDS functionality to replicate the 
"V" volumes to the remote MDL. 

This has been running successfully since late July.  However, we've 
recently had 2 different jobs abend because it appears that CA1 is calling 
for a tape from the wrong aub-pool.  The job is re-submitted approx. 15 
minutes later and runs successfully - no changes to the job, no changes to 
the CA1 NSM table, no changes to the MDL in the 15 minute interval.

This is what the messages look like when it runs successfully:

*IEC501A M 841C,PRIVAT,SL,COMP,jobname,
*TMS002  IEC501A M 841C,DRVAULT,SL,COMP
 IECTMS9 841C,V95538,jobname,OUTFILE ,


The is the sequence of messages when it runs amok:

*IEC501A M 8401,PRIVAT,SL,COMP,jobname,
*TMS001  IEC501A M 8401,PRIVAT,SL,COMP,jobname,
 IECTMS3 8401,M33439,IS NOT SCRTCH (80) 
 IEC518I SOFTWARE ERRSTAT: REJTMS   8401,M33439,SL,jobname,

So we opened an issue with CA1 & got the following response:
   "Since you have this defined as a manual tape library subpooling is not
supported.  CA1 subpooling is NOT supported with IBM SMS-managed tape 
libraries (ATL or
MTL)."

I find this response interesting as I'm not seeing how an SMS Library 
comes into play in this case -  the library is actually returning a 
scratch tape from the pool CA1 is requesting - for some reason, it appears 
to me that CA1 is sometimes requesting the wrong sub-pool.

So my question is anyone else using CA1 sub-pooling and SMS-managed tape 
libraries?
thanks - dd keller



This e-mail message and all attachments transmitted with it may
contain legally privileged and/or confidential information intended
solely for the use of the addressee(s). If the reader of this
message is not the intended recipient, you are hereby notified that
any reading, dissemination, distribution, copying, forwarding or
other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please
notify the sender immediately and delete this message and all
copies and backups thereof. Thank you.

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

“FOTS1346 Permission denied, please try again”

[Leonard Sasso]

Our Mainframe Batch job is successful using a Test Userid and Password to 
SSH to a remote host using password authentication (via askpass).  When we 
try the same job with the Production Userid and Password, we receive the 
following error: “FOTS1346 Permission denied, please try again”. This 
causes user authentication to fail. The SSH client then eventually fails 
with the error: “FOTS1373 Permission denied 
(publickey,password,keyboard-interactive)”. 

Per the IBM Ported Tools for z/OS User’s Guide (page 111 - # 22):

“Verify that you are not trying to use ssh while switched to another user 
ID. In other words, did you issue ssh after the su command? The original 
controlling terminal (displayed by the tty command) is owned by the user 
ID originally logged in. Your target user may not have permission to read 
from it.”

We are not issuing the “su” command (what is the “su” command)?

Any help would be appreciated.


Thank You.

Len Sasso



RDC Operations - Systems Administrator
CSC
Information Technology Infrastructure Services (ITIS)
| p: 518.257-4209 | m: 518.894-0879 | f: 518.257-4300 | lsa...@csc.com | 
www.csc.com

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

Re: Z10 BC SNA Console

[Carlos Bodra - Pessoal]

Hello,

Iff you have OSA-E 1000BaseT look for in redbook site for OSA-ICC. It 
describes step by step how to configure it.


Carlos Bodra
IBM zSeries Certified Specialist
Sao Paulo - Brazil


Em 30/11/2010 15:42, SrinivasG escreveu:

Hi,

On the Z800 , we had a separate 2074 controller for SNA Connectivity. In the 
Z10BC , I understand , its integrated into the HMC. How do I configure the same 
for an LPAR? Is there documentation that describes it? I have looked everywhere 
but could not find it. Any pointers?

Regards,
Srinivas G

 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are 
not
to copy, disclose, or distribute this e-mail or its contents to any other 
person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has 
taken
every reasonable precaution to minimize this risk, but is not liable for any 
damage
you may sustain as a result of any virus in this e-mail. You should carry out 
your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this 
e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

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


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

Re: SDSF display sysout

[Ron Wells]

Hayim > thanks...racf person looking into it




From:   Hayim Sokolsky 
To: IBM-MAIN@bama.ua.edu
Date:   11/30/2010 01:27 PM
Subject:Re: SDSF display sysout
Sent by:IBM Mainframe Discussion List 



The  value is set via SETROPTS NJEUNKNOWN. It represents the 
non-ownership of NJE jobs and sysout. It can not be set to an actual RACF 
UserID or group.

RACFVARS &RACLNDE - is a bypass of translation. Putting a JES (or RSCS) 
node in &RACLNDE prevents any substitution of NJE information. Only add 
the LOCAL JES node to &RACLNDE.

The RACF NODES class is used to allow, as well as translate or adjust NJE 
ownership. If you wish to take the AS400 sysout and assign a valid owning 
UserID, use the following profiles:

RDEF NODES as400node.USERS.*  UACC(CONTROL) ADDMEM(otherid) 
RDEF NODES as400node.GROUP%.*  UACC(READ) ADDMEM(&DFLTGRP)

as400node - replace with the actual NJE node name for the AS400
otherid - replace with the local UserID you want to own the sysout.

The GROUP% profile is not necessary if you have already defined:
RDEF NODES *.GROUP%.* UACC(READ) ADDMEM(&DFLTGRP)



Hayim
_
Hayim Sokolsky, CISSP
Mainframe Security Architect
DTCC Corporate Information Security
18301 Bermuda Green Dr, MS 1-CIS
Tampa FL 33647-1760

Tel. (813) 470-2177

IBM Mainframe Discussion List  wrote on 2010.11.30 
14:05:39:

> >Have sysout transfered--NJE--from an AS400 ... the OWNER filed shows 
> >  Where would this default becoming from..and can it be 
altered?
> >
> If you have RACF then I think it is the RACLNODE definitions for sysout.
> 
> Though I could be wrong.
> 
> Lizette
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html


_

DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.

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

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

Re: HSM and SA VTS

[Schwarz, Barry A]

Could the answer be this partial quote from Chapter 10 of the Implementation 
and Customization manual:

"Initial and Subsequent Selection of Dump Tapes
Because dump processing always selects an empty tape"

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Billy R. Bingham
Sent: Tuesday, November 30, 2010 9:39 AM
To: IBM-MAIN@bama.ua.edu
Subject: HSM and SA VTS

Hello all,

Just remember that I'm not z/OS literate,
but...

We just implemented a VTS from SecureAgent
and now when running HSM backups it seems
to be putting each DASD volume backed up
to a separate VTS tape. Does anyone have
any ideas what might be causing this or
what I should look at?

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

Re: A New Threat for password hacking

[Ed Gould]

--- On Mon, 11/29/10, McKown, John  wrote:

From: McKown, John 
Subject: Re: A New Threat for password hacking
To: IBM-MAIN@bama.ua.edu
Date: Monday, November 29, 2010, 9:57 AM

Each to his own. I prefer "the human touch" on password resets. But I'm an old 
paranoid . In my arrogance, somebody who cannot remember their RACF 
password likely can't remember their own name, either. A passphrase may be more 
difficult. But 8 stupid characters, max? Sure, it could be forgotten early on. 
And after a vacation. But we've had literally 8 or 10 password reset requests 
in a row from some of our off-shore users. Personally, I think they violate our 
standards and are sharing ids. But I can't prove it.

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


John:A couple of sites I use on the internet now use phrase checking. What I 
have found is that they are inconsistant in checking the response which makes 
it really confusing. Example: Birth City:Some sites insist on capital letters 
eg New Yorkwhile some sites do not care if one types: new york I do not know if 
it is on purpose that it matters or what.I certianly hope IBM does not care.
Ed





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

Re: SDSF display sysout

[Hayim Sokolsky]

The  value is set via SETROPTS NJEUNKNOWN. It represents the 
non-ownership of NJE jobs and sysout. It can not be set to an actual RACF 
UserID or group.

RACFVARS &RACLNDE - is a bypass of translation. Putting a JES (or RSCS) 
node in &RACLNDE prevents any substitution of NJE information. Only add 
the LOCAL JES node to &RACLNDE.

The RACF NODES class is used to allow, as well as translate or adjust NJE 
ownership. If you wish to take the AS400 sysout and assign a valid owning 
UserID, use the following profiles:

RDEF NODES as400node.USERS.*  UACC(CONTROL) ADDMEM(otherid) 
RDEF NODES as400node.GROUP%.*  UACC(READ) ADDMEM(&DFLTGRP)

as400node - replace with the actual NJE node name for the AS400
otherid - replace with the local UserID you want to own the sysout.

The GROUP% profile is not necessary if you have already defined:
RDEF NODES *.GROUP%.* UACC(READ) ADDMEM(&DFLTGRP)



Hayim
_
Hayim Sokolsky, CISSP
Mainframe Security Architect
DTCC Corporate Information Security
18301 Bermuda Green Dr, MS 1-CIS
Tampa FL 33647-1760

Tel. (813) 470-2177

IBM Mainframe Discussion List  wrote on 2010.11.30 
14:05:39:

> >Have sysout transfered--NJE--from an AS400 ... the OWNER filed shows 
> >  Where would this default becoming from..and can it be 
altered?
> >
> If you have RACF then I think it is the RACLNODE definitions for sysout.
> 
> Though I could be wrong.
> 
> Lizette
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html


_

DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.

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

Re: SDSF display sysout

[Ron Wells]

this is in z/os racf??ask racf guy...unsure where it maybe...



From:   Lizette Koehler 
To: IBM-MAIN@bama.ua.edu
Date:   11/30/2010 01:07 PM
Subject:Re: SDSF display sysout
Sent by:IBM Mainframe Discussion List 



>Have sysout transfered--NJE--from an AS400 ... the OWNER filed shows 
>  Where would this default becoming from..and can it be altered?
>
If you have RACF then I think it is the RACLNODE definitions for sysout.

Though I could be wrong.

Lizette

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

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

Re: Question concerning CMF reporting of CPU Delay

[O'Brien, David W. (NIH/CIT) [C]]

Thanks Scott, That's what I thought but couldn't find documented.

Thank You,
Dave O'Brien
NIH Contractor

From: Scott Rowe [scott.r...@joann.com]
Sent: Tuesday, November 30, 2010 1:46 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Question concerning CMF reporting of CPU Delay

Assuming that CMF works the same as RMF, yes, the CPU delay % indicates the
% of samples taken where the workload was waiting to use a LP.  This
calculation has no visibility to the physical CPs.

On Tue, Nov 30, 2010 at 10:51 AM, O'Brien, David W. (NIH/CIT) [C] <
obrie...@mail.nih.gov> wrote:

> Back to my original question, if LPARa has a weight of 30 and is 100% busy
> but is only getting 50% physical then the CPU delay % should be 50%. However
> CMF is reporting 2-3% which leads me to conclude that CMF is only computing
> wait for Logical Processors within the LPAR.
>
> Thank You,
> Dave O'Brien
> NIH Contractor
> 
> From: Vernooij, CP - SPLXM [kees.verno...@klm.com]
> Sent: Tuesday, November 30, 2010 10:46 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Question concerning CMF reporting of CPU Delay
>
> Similar calculation: the lpar uses 90% of its allocated resources, which
> is 35-45% of the machine as being distributed by pr/sm based on weigths
> and Lpar demands.
>
> I see this in our test lpars: they are 90-100% busy, yet use 10% of the
> machine according to weights if demand by other Lpars is heavy.
>
> Kees.
>
>
> "O'Brien, David W.  [C] , NIH/CIT"  wrote in
> message
> news:..
> .
> > Hi Kees,
> >
> > 3 physical CPs
> > 2 Prod LPARs each with 3 LPs
> > 1 Test LPAR with 2 LPs
> > 1 Sandbox with 1 LP
> >
> > So we have 9 LPs competing for 3 CPs. Fortunately 3 of those LPs are
> little used.
> > The relative weights of the Prod LPARs are 45 and 30.
> > The LPAR reporting the problem is the one with 30, no surprise there.
> > The Test LPAR has a weight of 15 while the Sandbox has a weight of 10
> and seldom use their relative share.
> >
> > I have suggested that a 2:1 LP to CP ratio would be more efficient but
> was told the faster CP make the 2:1 ratio obsolete. Makes no sense to me
> but then I'm the DASD guy. Every problem is HSM until proven otherwise.
> >
> > Thank You,
> > Dave O'Brien
> > NIH Contractor
> > 
> > From: Vernooij, CP - SPLXM [kees.verno...@klm.com]
> > Sent: Tuesday, November 30, 2010 10:18 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: Question concerning CMF reporting of CPU Delay
> >
> > "O'Brien, David W.  [C] , NIH/CIT"  wrote in
> > message
> >
> news:..
> > .
> > > We had a situation where our M204 users reported a delay but CMF
> shows
> > the main delay as CPU but at a relatively low %.
> > >
> > > Question - Does CMF only report CPU delay for the Logical Processors
> > in that particular LPAR?
> > > The LPAR is question often shows CPU usage of 90+%, while the CMF
> > LPARSTAR view shows a physical cpu% of 35-45%.
> > >
> > > Is it possible that the delay at the Physical processor is not
> > reported, or reported in a different view?
> > >
> > > Thank You,
> > > Dave O'Brien
> > > NIH Contractor
> > >
> >
> > How many logical processors does the Lpar have and how many physical
> > processors does the machine have? If this ratio is 1:2, 90% lpar
> > utilization means 45% machine utilization.
> >
> > 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: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: 

Re: Question concerning CMF reporting of CPU Delay

[O'Brien, David W. (NIH/CIT) [C]]

Thanks Mike, I was thinking that it might be better to consolidate the 2 Prod 
LPARs so that all of the workload operated under the same WLM policy without 
the PRSM time slice.
But that's not my call.

Thank You,
Dave O'Brien
NIH Contractor

From: Mike Schwab [mike.a.sch...@gmail.com]
Sent: Tuesday, November 30, 2010 1:28 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Question concerning CMF reporting of CPU Delay

On Tue, Nov 30, 2010 at 9:35 AM, O'Brien, David W. (NIH/CIT) [C]
 wrote:
> Hi Kees,
>
> 3 physical CPs
> 2 Prod LPARs each with 3 LPs
> 1 Test LPAR with 2 LPs
> 1 Sandbox with 1 LP
>
> So we have 9 LPs competing for 3 CPs. Fortunately 3 of those LPs are little 
> used.
> The relative weights of the Prod LPARs are 45 and 30.

Maybe a 42 / 33 weight would work a little bit better?

> The LPAR reporting the problem is the one with 30, no surprise there.
> The Test LPAR has a weight of 15 while the Sandbox has a weight of 10 and 
> seldom use their relative share.
>
> I have suggested that a 2:1 LP to CP ratio would be more efficient but was 
> told the faster CP make the 2:1 ratio obsolete. Makes no sense to me but then 
> I'm the DASD guy. Every problem is HSM until proven otherwise.
>
> Thank You,
> Dave O'Brien
> NIH Contractor

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

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

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

Re: SDSF display sysout

[Lizette Koehler]

>Have sysout transfered--NJE--from an AS400 ... the OWNER filed shows 
>  Where would this default becoming from..and can it be altered?
>
If you have RACF then I think it is the RACLNODE definitions for sysout.

Though I could be wrong.

Lizette

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

SDSF display sysout

[Ron Wells]

Have sysout transfered--NJE--from an AS400 ... the OWNER filed shows 
  Where would this default becoming from..and can it be altered?

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

Re: VTFM vs TMM

[techie well wisher]

Tiering within the array is the best approach with replication. Synchronous
or Asynchronous, Tiering within the array provides better consistent point
at the recovery site.

On Tue, Nov 23, 2010 at 11:49 AM, Ron Hawkins  wrote:

> Techie well wisher,
>
> >
> > Thanks everyone. Much appreciated. With TMM, of course it goes to
> expensive
> > z/os disk, but we do have the option of tiering within the array, such as
> > using 1tb drives Raid6 and then hsm them to replicated vts later.
> [Ron Hawkins]
> That's not actually true. Cheaper midrange disk arrays can be virtualized
> by
> DASD controllers using a plethora of cheaper brands and models, and TMM can
> be tiered outside of the array without any appliance except the array
> itself.
>
> Internal SATA is an optional tier for those controllers that do not support
> virtualization of Mainframe volumes.
>
>
> Ron
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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

Re: Question concerning CMF reporting of CPU Delay

[Scott Rowe]

Assuming that CMF works the same as RMF, yes, the CPU delay % indicates the
% of samples taken where the workload was waiting to use a LP.  This
calculation has no visibility to the physical CPs.

On Tue, Nov 30, 2010 at 10:51 AM, O'Brien, David W. (NIH/CIT) [C] <
obrie...@mail.nih.gov> wrote:

> Back to my original question, if LPARa has a weight of 30 and is 100% busy
> but is only getting 50% physical then the CPU delay % should be 50%. However
> CMF is reporting 2-3% which leads me to conclude that CMF is only computing
> wait for Logical Processors within the LPAR.
>
> Thank You,
> Dave O'Brien
> NIH Contractor
> 
> From: Vernooij, CP - SPLXM [kees.verno...@klm.com]
> Sent: Tuesday, November 30, 2010 10:46 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Question concerning CMF reporting of CPU Delay
>
> Similar calculation: the lpar uses 90% of its allocated resources, which
> is 35-45% of the machine as being distributed by pr/sm based on weigths
> and Lpar demands.
>
> I see this in our test lpars: they are 90-100% busy, yet use 10% of the
> machine according to weights if demand by other Lpars is heavy.
>
> Kees.
>
>
> "O'Brien, David W.  [C] , NIH/CIT"  wrote in
> message
> news:..
> .
> > Hi Kees,
> >
> > 3 physical CPs
> > 2 Prod LPARs each with 3 LPs
> > 1 Test LPAR with 2 LPs
> > 1 Sandbox with 1 LP
> >
> > So we have 9 LPs competing for 3 CPs. Fortunately 3 of those LPs are
> little used.
> > The relative weights of the Prod LPARs are 45 and 30.
> > The LPAR reporting the problem is the one with 30, no surprise there.
> > The Test LPAR has a weight of 15 while the Sandbox has a weight of 10
> and seldom use their relative share.
> >
> > I have suggested that a 2:1 LP to CP ratio would be more efficient but
> was told the faster CP make the 2:1 ratio obsolete. Makes no sense to me
> but then I'm the DASD guy. Every problem is HSM until proven otherwise.
> >
> > Thank You,
> > Dave O'Brien
> > NIH Contractor
> > 
> > From: Vernooij, CP - SPLXM [kees.verno...@klm.com]
> > Sent: Tuesday, November 30, 2010 10:18 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: Question concerning CMF reporting of CPU Delay
> >
> > "O'Brien, David W.  [C] , NIH/CIT"  wrote in
> > message
> >
> news:..
> > .
> > > We had a situation where our M204 users reported a delay but CMF
> shows
> > the main delay as CPU but at a relatively low %.
> > >
> > > Question - Does CMF only report CPU delay for the Logical Processors
> > in that particular LPAR?
> > > The LPAR is question often shows CPU usage of 90+%, while the CMF
> > LPARSTAR view shows a physical cpu% of 35-45%.
> > >
> > > Is it possible that the delay at the Physical processor is not
> > reported, or reported in a different view?
> > >
> > > Thank You,
> > > Dave O'Brien
> > > NIH Contractor
> > >
> >
> > How many logical processors does the Lpar have and how many physical
> > processors does the machine have? If this ratio is 1:2, 90% lpar
> > utilization means 45% machine utilization.
> >
> > 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: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 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 materi

Re: spool to spool output transfer

[Jousma, David]

Node number is the same too.

_
Dave Jousma
Assistant Vice President, Mainframe Services
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB1G
p 616.653.8429
f 616.653.8497


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Bob Shannon
Sent: Tuesday, November 30, 2010 1:36 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: spool to spool output transfer

> Doesn't NJE over IP have the same restrictions as standard NJE of
>connecting two nodes of the same name?

I overlooked that detail. You should be able to use a node number as
long as they are different.

Bob Shannon
Rocket Software

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: spool to spool output transfer

[Bob Shannon]

> Doesn't NJE over IP have the same restrictions as standard NJE of
>connecting two nodes of the same name?

I overlooked that detail. You should be able to use a node number as long as 
they are different.

Bob Shannon
Rocket Software

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

Re: spool to spool output transfer

[Jousma, David]

Doesn't NJE over IP have the same restrictions as standard NJE of
connecting two nodes of the same name?

_
Dave Jousma
Assistant Vice President, Mainframe Services
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB1G
p 616.653.8429
f 616.653.8497

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Bob Shannon
Sent: Tuesday, November 30, 2010 1:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: spool to spool output transfer

1. NJE over TCP would result in one hop (assuming IP connectivity
between the two MASs)
2. If it's a one-time exercise, can you do a spool unload/reload?

Bob Shannon
Rocket Software

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Question concerning CMF reporting of CPU Delay

[Mike Schwab]

On Tue, Nov 30, 2010 at 9:35 AM, O'Brien, David W. (NIH/CIT) [C]
 wrote:
> Hi Kees,
>
> 3 physical CPs
> 2 Prod LPARs each with 3 LPs
> 1 Test LPAR with 2 LPs
> 1 Sandbox with 1 LP
>
> So we have 9 LPs competing for 3 CPs. Fortunately 3 of those LPs are little 
> used.
> The relative weights of the Prod LPARs are 45 and 30.

Maybe a 42 / 33 weight would work a little bit better?

> The LPAR reporting the problem is the one with 30, no surprise there.
> The Test LPAR has a weight of 15 while the Sandbox has a weight of 10 and 
> seldom use their relative share.
>
> I have suggested that a 2:1 LP to CP ratio would be more efficient but was 
> told the faster CP make the 2:1 ratio obsolete. Makes no sense to me but then 
> I'm the DASD guy. Every problem is HSM until proven otherwise.
>
> Thank You,
> Dave O'Brien
> NIH Contractor

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

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

Re: spool to spool output transfer

[David Andrews]

On Tue, 2010-11-30 at 13:09 -0500, Jousma, David wrote:
> Looking for ideas for doing spool to spool transfer of output NOT using
> NJE.

Maybe Sine Nomine's NJE/IP Bridge package would be useful here?
http://www.sinenomine.net/products/vm/njeip

-- 
David Andrews
A. Duda and Sons, Inc.
david.andr...@duda.com

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

Re: spool to spool output transfer

[Bob Shannon]

1. NJE over TCP would result in one hop (assuming IP connectivity between the 
two MASs)
2. If it's a one-time exercise, can you do a spool unload/reload?

Bob Shannon
Rocket Software

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

Re: DFHSM MIGRATE MYSTERY - SOLVED

[willie bunter]

Joel,
 
We finally found the reason to this problem.  There is an exit placed so as to 
prevent certain HLQ qualifiers migration to ML1 from ML0.  This exit was placed 
by the customer in the ARCMD9 parmlib.  I was convinced that there was a 
problem with the Management Class settings.  I am guilty of leaping before I 
looked.  A lesson well learned.
 
Thanks again to you and all those posters who took the time to answer my 
question.

--- On Sat, 11/27/10, Joel C. Ewing  wrote:


From: Joel C. Ewing 
Subject: Re: DFHSM MIGRATE MYSTERY
To: IBM-MAIN@bama.ua.edu
Received: Saturday, November 27, 2010, 10:42 AM


If everything is as you described, I'm not sure why your system should behave 
differently than mine.  Perhaps there is some subtle parameter in HSM that I've 
forgotten about, but the rules as I understand them and as they work on my 
configuration are:

MGMTCLAS "Primary Days" and "Level 1" days only apply to space management 
auto-migration and are ignored when command (HMIG) migration is used.   Other 
MGMTCLAS attributes, such as auto-backup, continue to be honored and are 
unaffected by whether HMIG is used or not.

If auto-backup is turned off, HMIG does not check to see if any backups exist 
and
HMIG dataset               will move dataset on  primary  to ML1
HMIG dataset ML2           will move dataset on primary or ML1 to ML2

If auto-backup is turned on, and no backup exists
HMIG dataset               will move dataset on primary to ML1
HMIG dataset ML2           will fail with ARC1280I if dataset on
         primary or ML1 and no move is done

If auto-backup is turned on, and backup exists
HMIG dataset              will move dataset on primary to ML1
HMIG dataset ML2          will move dataset on primary or ML1 to ML2

If I understand your previous posts correctly, you indicated that with 
auto-backup on and no backup yet, "HMIG dsn ML2" migrated the dataset to ML1.  
This does not happen on my system.  I  get ARC1280I and no migration for this 
case.  I would get a migration to ML1 and no error only if the command "HMIG 
dsn" (with no "ML2") had been used under those conditions.  The primary and 
level 1 days in MGMTCLAS are irrelevant to HMIG operation in either case - they 
only affect auto-migration.

On most recent case indicated, where a backup is known to exist, the command 
"HMIG dsn ML2" should always force migration to ML2.  You don't explicitly say 
whether in the last case your dataset ends up on ML2 or ML1, but on my system 
it ends up on ML2 and this is where the documentation says it should end up.  
Again the primary and level 1 days in MGMTCLAS are irrelevant to HMIG operation 
- they only affect auto-migration.

This is the behavior of the HMIGRATE command as documented in Chapter 18, 
"DFHSM Managing your Own Data":
    "The data set migrates to a level 1 migration volume unless you specify the 
MIGRATIONLEVEL2 parameter in the command or you are in an environment that 
migrates directly to migration level 2 volumes" [this latter reference is to an 
HSM system with no ML1 space defined, which is obviously not the case in the 
current discussions - JCE]
    and
    "... MIGRATIONLEVEL2 is an optional parameter you use to migrate a data set 
from a level 0 volume or a migration level 1 volume to a migration level 2 
volume. The MIGRATIONLEVEL2 parameter must be specified if you are migrating an 
already migrated data set."

Note there is NO mention of any interaction with the MGMTCLAS definitions.  
Don't assume an interaction when none is documented.

The descriptions of the MGMTCLAS options for primary and level 1 days in "DFSMS 
Storage Administration Reference" are perhaps not as clearly worded as they 
could be.  These are documented as applying to "normal" migration.  In this 
context "normal" means space management or auto-migration.  In other words, 
these parameters do NOT apply to manual command migration, which is only 
designed to handle exceptions to "normal" processing.

This is the way MGMTCLAS and HMIGRATE are designed to interact and the way they 
do interact on my z/OS system.
  Joel C. Ewing

On 11/24/2010 10:45 AM, willie bunter wrote:
> Joel,
> 
> I did a manual BACKDS command of the dsn.  Next I did a LISTCAT of the dsn 
> and it shows LBACKUP ---2010.328.0643.  I did a HMIG dsn ML2 . I did a 
> LISTCAT again and it shows LBACKUP ---.XXX.
> However when I do HLIST of the dsn it shows the backup 10/11/24 06:43:55
> I am not sure why this is happening.  I also noted that if I issue the HMIG 
> dsn ML2 the MANAGEMENT CLASS Migration Attributes is being ignored even 
> though I have specified
> the following:
> Primary Days Non-usage  . : 3
> Level 1 Days Date/Days  . : 2
> Command or Auto Migrate . : BOTH
> 
> As an earlier poster had mentioned that if a manual Migrate ML2 command is 
> issued to migrate the dsn, it overrides the Migration attributes.  This 
> storage group is exempt from Auto Migrate but it does have Auto Backup turned 
> on

spool to spool output transfer

[Jousma, David]

All,

Looking for ideas for doing spool to spool transfer of output NOT using
NJE.Issue is transferring output between two different MAS-plex of
the same node-name.  NJE would work if multi-hopped, NODE-A connected to
NODE-B, NODE-B connected to NODE-C, and finally NODE-C connects to the
other NODE-A, but that is too many hops in my opinion.  

Looking for other creative, supportable methods to solve this.   Already
thinking about:

-   Automated spool offload to dataset, FTP to remote site, spool
reload
-   ??

Assumptions:

-   Maintain print characteristics
-   both spools have the same node name, that's why is not the first
option
-   cannot change node name due to external customer connections
-   existing external connections are using Enterprise Extender, and
the IP's of the separate hosts ARE different, so no conflict externally.





_
Dave Jousma
Assistant Vice President, Mainframe Services
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB1G
p 616.653.8429
f 616.653.8497


This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: HSM and SA VTS

[Ulrich Krueger]

Take a look at your DFHSM ARCCMDxx member ... the parameter MARKFULL comes
to mind, as a setting to indicate if a DFHSM tape should be marked as full
at the conclusion of a DFHSM function or if it should be kept available for
another function to add more data later. 
Also make sure that VTS settings do allow for "MOD" - type operation of
adding data to an existing virtual tape volume.


Regards,
Ulrich Krueger


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Billy R. Bingham
Sent: Tuesday, November 30, 2010 9:39 AM
To: IBM-MAIN@bama.ua.edu
Subject: HSM and SA VTS

Hello all,

Just remember that I'm not z/OS literate, 
but...

We just implemented a VTS from SecureAgent 
and now when running HSM backups it seems 
to be putting each DASD volume backed up 
to a separate VTS tape. Does anyone have 
any ideas what might be causing this or 
what I should look at?


Thanks,

Billy

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

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

Re: upgrade to pcomm 5.9 cant login..more

[Chris Mason]

John

We haven't been given either the configuration much less the relevant 
definitions here but you may be getting close to the explanation to why CICS 
works and TSO doesn't.

After I mentioned "mystery" here I went back to close the window for the 
Technote and noticed that the problem arises when the LU type is 0 rather 
than 2. I'd need to check the likely flows in order to work out why "query" 
appears in the TSO message when the problem is documented as being 
associated with the BIND request. However, that's what the Technote says 
and also what is stated in 3174 Establishment Controller Status Codes, GA27-
3832-08:

http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/cn7s8001/2.23

So what may have happened here is that Larry's "initial login screen" (spelling 
corrected!) is, when given the correct name, an Unformatted System Services 
(USS) message 10. It may be that, when CICS is entered, the command 
generated is

LOGON APPLID(cics)LOGMODE(cicsmode)

and when TSO is entered, the command generated is

LOGON APPLID(tso)LOGMODE(tsomode)

where
- "cics" is the required LU name for the primary LU supporting the CICS 
application
- "tso" is the required LU name for the primary LU supporting the TSO 
application
- "cicsmode" selects a mode table entry where the LU type is 2
- "tsomode" selects a mode table entry where the LU type is 0

Note that, as implied by the Technote, a TN3270 server is being used with a 
TCP connection to PCOMM behaving as a TN3270 client, the mode name 
specified by the USS command overrides the mode table entry name 
configured in the TN3270 server, possibly according to the famous Table 
33, "Device type and logmode table", in z/OS Communications Server IP 
Configuration Reference.

So, with a few guesses since the full story is rarely told in an initiating 
post, 
the "mystery" may be explained.

Your "experience" may well be correct but always - *always* - remember that 
the BIND image originates from the secondary LU in the session. It may be 
that CICS can be configured to ignore the BIND image originating from the 
secondary LU in the session but, generally, these days I believe the BIND 
image is used dynamically to specify the TCTTE parameters.

Another point I can't quite understand about your post is a suggestion that 
there is some variation in the BIND parameters transaction by transaction. 
Please remember that the BIND parameters apply to the *session* during 
which there are multiple transactions. It's at the start of the *session* that 
the "query" exchange takes place.

Chris Mason

On Tue, 30 Nov 2010 11:14:22 -0600, Chase, John  
wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of Chris Mason
>>
>> Larry
>>
>> This may help:
>>
>> PROG723 error on IBM Personal Communications 3270 Telnet session
>>
>> http://www-01.ibm.com/support/docview.wss?uid=swg21251200
>>
>> Note the relevant "Software version"s
>>
>> Why CICS works and TSO doesn't would still be a mystery however!
>
>In my experience, most CICS transactions (COBOL using BMS) are written
>to only the basic "Model 2" 24x80 screen size, and are "mapped" to a
>PROFILE that does not specify any "alternate screen size"; and if the
>"terminal" is LOGAPPL'd to a CICS region, probably include a MODEENT
>that has the "query bit" unset (i.e., PSERVIC=x'0200').  Thus, CICS
>likely uses only the "default" screen size and avoids sending the QUERY
>structured field in the first place.
>
>-jc-
>
>>
>> Chris Mason
>>
>> On Tue, 30 Nov 2010 07:52:11 -0600, Larry Macioce
>>  wrote:
>>
>> >we want to have everyone login securely and we were at pcomm5.7.
>> >I have loaded pcom5.9 tired to login but it is failing with caveats
>> >I get the inital login screen
>> >1) when I try to login to tso in get a prog723. The log shows:
>> >IKT112I SENDERROR DURING QUERY PROCESSING FOR TSO0011 ,
>> >RPLRTNCD=0C,  RPLFDB2=0B,SENSE=0001
>> >
>> >BUT I can log into cics no problems. This tells me my tso appl has a
>problem
>> >but I don't know what it might be.
>> >TIA
>> >Mace

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

Re: Z10 BC SNA Console

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of SrinivasG
> Sent: Tuesday, November 30, 2010 11:43 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Z10 BC SNA Console
> 
> Hi,
> 
> On the Z800 , we had a separate 2074 controller for SNA 
> Connectivity. In the Z10BC , I understand , its integrated 
> into the HMC. How do I configure the same for an LPAR? Is 
> there documentation that describes it? I have looked 
> everywhere but could not find it. Any pointers?
> 
> Regards,
> Srinivas G

There is an integrated 3270 emulator on the HMC. However, it is __NOT__ 
supported by z/OS. I know that z/VM supports it. z/VM calls this the "SYSG" 
console. I don't know z/VSE at all. So if you're running z/OS on the z10, and 
you want 3270 consoles, then you need to retain the 2074 or use an ICC (an OSA 
which runs TN3270 emulation and emulates a local 3270 controller) or use 
something like a Visara. We have had a Visara (ESCON channel attached 3174 type 
controller) since we had our z800. It still works well for us.

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

Re: Z10 BC SNA Console

[Mark Zelden]

On Tue, 30 Nov 2010 23:12:32 +0530, SrinivasG  wrote:

>Hi,
>
>On the Z800 , we had a separate 2074 controller for SNA Connectivity. In
the Z10BC , I understand , its integrated into the HMC. How do I configure
the same for an LPAR? Is there documentation that describes it? I have
looked everywhere but could not find it. Any pointers?
>

Try this RedBook:

OSA-Express Integrated Console Controller Implementation Guide
http://www.redbooks.ibm.com/abstracts/sg246364.html?Open

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

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

Re: HSM and SA VTS

[Mark Zelden]

On Tue, 30 Nov 2010 11:39:16 -0600, Billy R. Bingham
 wrote:

>Hello all,
>
>Just remember that I'm not z/OS literate,
>but...
>
>We just implemented a VTS from SecureAgent
>and now when running HSM backups it seems
>to be putting each DASD volume backed up
>to a separate VTS tape. Does anyone have
>any ideas what might be causing this or
>what I should look at?
>
>

1) No, but since it is virtual tape it shouldn't matter and may be by 
design.

2) Since you "just implemented", isn't the vendor providing support
for your questions related to implementation?   

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

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

Z10 BC SNA Console

[SrinivasG]

Hi,

On the Z800 , we had a separate 2074 controller for SNA Connectivity. In the 
Z10BC , I understand , its integrated into the HMC. How do I configure the same 
for an LPAR? Is there documentation that describes it? I have looked everywhere 
but could not find it. Any pointers?

Regards,
Srinivas G

 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not 
to copy, disclose, or distribute this e-mail or its contents to any other 
person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has 
taken 
every reasonable precaution to minimize this risk, but is not liable for any 
damage 
you may sustain as a result of any virus in this e-mail. You should carry out 
your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this 
e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

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

HSM and SA VTS

[Billy R. Bingham]

Hello all,

Just remember that I'm not z/OS literate, 
but...

We just implemented a VTS from SecureAgent 
and now when running HSM backups it seems 
to be putting each DASD volume backed up 
to a separate VTS tape. Does anyone have 
any ideas what might be causing this or 
what I should look at?


Thanks,

Billy

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

Re: Z10 BC issue

[SrinivasG]

Thanks Mike for the answer.

Regards,
Srinivas G



-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Mike Schwab
Sent: Tuesday, November 30, 2010 12:45 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Z10 BC issue

You init a volume on the new machine with a 1 track vtoc and volser,
vary it online, and the restore has a dd statement with dasd volser.
The physical restore will overwrite the VTOC you created with ICKDSF.

If you don't have a running system connected to the new dasd, you can
do a Stand Alone ICKDSF and Stand Alone ADRDSSU.

On Mon, Nov 29, 2010 at 9:12 AM, SrinivasG  wrote:
> Thanks Brian for the answers.
>
> Will it be ok restoring the volumes for the first time from ZOS? How does the 
> restore job know on which device address to restore the ZVM volume? Same for 
> the Linux Volumes?
>
> I will check the ZVM and Z Linux lists as well as suggested by you.
>
> Regards,
> Srinivas G
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf 
> Of Brian Westerman
> Sent: Monday, November 29, 2010 4:59 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Z10 BC issue
>
> Assuming that you have made the changes to the z/VM system (if any are
> required) so that it also understands the new device addresses, everything
> will be fine once you get the backup job set up correctly for the VM volumes
> (see below).
>
> Make sure that you take Physical volume backups of the packs (not logical)
> and restore them as FULL volume.  For VM volumes you (should) specify
> CPVOLUME to let DSS know that it's playing with a VM volume :
> 3390 mod3:
> DUMP -
>     INDD(DASD)            -
>     OUTDD(TAPE1)          -
>     ADMINISTRATOR         -
>     CONCURRENT            -
>     CPVOLUME              -
>     OPTIMIZE(4)           -
>     TRKS(0,0,3338,14)
>
> 3390 mod9
> DUMP -
>     INDD(DASD)            -
>     OUTDD(TAPE1)          -
>     ADMINISTRATOR         -
>     CONCURRENT            -
>     CPVOLUME              -
>     OPTIMIZE(4)           -
>     TRKS(0,0,10016,14)
>
>
> You can get a full description of how to do this type of copy on the VM list
> and the Linux list has a similar one for copying the Linux volumes (which
> doesn't use the CPVOLUME, it's just a full physical backup and restore)
>
> Brian
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>  CAUTION - Disclaimer *
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
> for the use of the addressee(s). If you are not the intended recipient, please
> notify the sender by e-mail and delete the original message. Further, you are 
> not
> to copy, disclose, or distribute this e-mail or its contents to any other 
> person and
> any such actions are unlawful. This e-mail may contain viruses. Infosys has 
> taken
> every reasonable precaution to minimize this risk, but is not liable for any 
> damage
> you may sustain as a result of any virus in this e-mail. You should carry out 
> your
> own virus checks before opening the e-mail or attachment. Infosys reserves the
> right to monitor and review the content of all messages sent to or from this 
> e-mail
> address. Messages sent to or from this e-mail address may be stored on the
> Infosys e-mail system.
> ***INFOSYS End of Disclaimer INFOSYS***
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



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

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

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

Re: upgrade to pcomm 5.9 cant login..more

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Chris Mason
> 
> Larry
> 
> This may help:
> 
> PROG723 error on IBM Personal Communications 3270 Telnet session
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg21251200
> 
> Note the relevant "Software version"s
> 
> Why CICS works and TSO doesn't would still be a mystery however!

In my experience, most CICS transactions (COBOL using BMS) are written
to only the basic "Model 2" 24x80 screen size, and are "mapped" to a
PROFILE that does not specify any "alternate screen size"; and if the
"terminal" is LOGAPPL'd to a CICS region, probably include a MODEENT
that has the "query bit" unset (i.e., PSERVIC=x'0200').  Thus, CICS
likely uses only the "default" screen size and avoids sending the QUERY
structured field in the first place.

-jc-

> 
> Chris Mason
> 
> On Tue, 30 Nov 2010 07:52:11 -0600, Larry Macioce
>  wrote:
> 
> >we want to have everyone login securely and we were at pcomm5.7.
> >I have loaded pcom5.9 tired to login but it is failing with caveats
> >I get the inital login screen
> >1) when I try to login to tso in get a prog723. The log shows:
> >IKT112I SENDERROR DURING QUERY PROCESSING FOR TSO0011 ,
> >RPLRTNCD=0C,  RPLFDB2=0B,SENSE=0001
> >
> >BUT I can log into cics no problems. This tells me my tso appl has a
problem
> >but I don't know what it might be.
> >TIA
> >Mace
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: upgrade to pcomm 5.9 cant login..more

[Chris Mason]

Larry

This may help:

PROG723 error on IBM Personal Communications 3270 Telnet session

http://www-01.ibm.com/support/docview.wss?uid=swg21251200

Note the relevant "Software version"s

Why CICS works and TSO doesn't would still be a mystery however!

Chris Mason

On Tue, 30 Nov 2010 07:52:11 -0600, Larry Macioce 
 wrote:

>we want to have everyone login securely and we were at pcomm5.7.
>I have loaded pcom5.9 tired to login but it is failing with caveats
>I get the inital login screen
>1) when I try to login to tso in get a prog723. The log shows:
>IKT112I SENDERROR DURING QUERY PROCESSING FOR TSO0011 ,
>RPLRTNCD=0C,  RPLFDB2=0B,SENSE=0001
>
>BUT I can log into cics no problems. This tells me my tso appl has a problem
>but I don't know what it might be.
>TIA
>Mace

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

Re: Question concerning CMF reporting of CPU Delay

[O'Brien, David W. (NIH/CIT) [C]]

Back to my original question, if LPARa has a weight of 30 and is 100% busy but 
is only getting 50% physical then the CPU delay % should be 50%. However CMF is 
reporting 2-3% which leads me to conclude that CMF is only computing wait for 
Logical Processors within the LPAR.

Thank You,
Dave O'Brien
NIH Contractor

From: Vernooij, CP - SPLXM [kees.verno...@klm.com]
Sent: Tuesday, November 30, 2010 10:46 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Question concerning CMF reporting of CPU Delay

Similar calculation: the lpar uses 90% of its allocated resources, which
is 35-45% of the machine as being distributed by pr/sm based on weigths
and Lpar demands.

I see this in our test lpars: they are 90-100% busy, yet use 10% of the
machine according to weights if demand by other Lpars is heavy.

Kees.


"O'Brien, David W.  [C] , NIH/CIT"  wrote in
message
news:..
.
> Hi Kees,
>
> 3 physical CPs
> 2 Prod LPARs each with 3 LPs
> 1 Test LPAR with 2 LPs
> 1 Sandbox with 1 LP
>
> So we have 9 LPs competing for 3 CPs. Fortunately 3 of those LPs are
little used.
> The relative weights of the Prod LPARs are 45 and 30.
> The LPAR reporting the problem is the one with 30, no surprise there.
> The Test LPAR has a weight of 15 while the Sandbox has a weight of 10
and seldom use their relative share.
>
> I have suggested that a 2:1 LP to CP ratio would be more efficient but
was told the faster CP make the 2:1 ratio obsolete. Makes no sense to me
but then I'm the DASD guy. Every problem is HSM until proven otherwise.
>
> Thank You,
> Dave O'Brien
> NIH Contractor
> 
> From: Vernooij, CP - SPLXM [kees.verno...@klm.com]
> Sent: Tuesday, November 30, 2010 10:18 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Question concerning CMF reporting of CPU Delay
>
> "O'Brien, David W.  [C] , NIH/CIT"  wrote in
> message
>
news:..
> .
> > We had a situation where our M204 users reported a delay but CMF
shows
> the main delay as CPU but at a relatively low %.
> >
> > Question - Does CMF only report CPU delay for the Logical Processors
> in that particular LPAR?
> > The LPAR is question often shows CPU usage of 90+%, while the CMF
> LPARSTAR view shows a physical cpu% of 35-45%.
> >
> > Is it possible that the delay at the Physical processor is not
> reported, or reported in a different view?
> >
> > Thank You,
> > Dave O'Brien
> > NIH Contractor
> >
>
> How many logical processors does the Lpar have and how many physical
> processors does the machine have? If this ratio is 1:2, 90% lpar
> utilization means 45% machine utilization.
>
> 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: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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 

Re: I would love to know what went wrong at NAB

[Ted MacNEIL]

>I'd bet that the upgrade was to the application system, not the mainframe, and 
>something was wrong in a new application program that corrupted the file.

I wouldn't take the opposite of that bet!

>I'm wondering why it took 5 days to recover.

Since, upon reading the article, I see that INFOSYS was I don't have to wonder.

>It sounds like a proper backup/backout procedure wasn't in place in case of a 
>failure like this.

In my experience, these off-shore application providers treat the application 
lightly, and don't seem to have the urgency regarding the security and 
integrity of either the programmes or the data that the original IT staff did.

-
Ted MacNEIL
eamacn...@yahoo.ca

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

Re: Question concerning CMF reporting of CPU Delay

[Vernooij, CP - SPLXM]

Similar calculation: the lpar uses 90% of its allocated resources, which
is 35-45% of the machine as being distributed by pr/sm based on weigths
and Lpar demands.

I see this in our test lpars: they are 90-100% busy, yet use 10% of the
machine according to weights if demand by other Lpars is heavy.

Kees.


"O'Brien, David W.  [C] , NIH/CIT"  wrote in
message
news:..
.
> Hi Kees,
> 
> 3 physical CPs
> 2 Prod LPARs each with 3 LPs
> 1 Test LPAR with 2 LPs
> 1 Sandbox with 1 LP
> 
> So we have 9 LPs competing for 3 CPs. Fortunately 3 of those LPs are
little used.
> The relative weights of the Prod LPARs are 45 and 30. 
> The LPAR reporting the problem is the one with 30, no surprise there.
> The Test LPAR has a weight of 15 while the Sandbox has a weight of 10
and seldom use their relative share.
> 
> I have suggested that a 2:1 LP to CP ratio would be more efficient but
was told the faster CP make the 2:1 ratio obsolete. Makes no sense to me
but then I'm the DASD guy. Every problem is HSM until proven otherwise.
>  
> Thank You,
> Dave O'Brien
> NIH Contractor
> 
> From: Vernooij, CP - SPLXM [kees.verno...@klm.com]
> Sent: Tuesday, November 30, 2010 10:18 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Question concerning CMF reporting of CPU Delay
> 
> "O'Brien, David W.  [C] , NIH/CIT"  wrote in
> message
>
news:..
> .
> > We had a situation where our M204 users reported a delay but CMF
shows
> the main delay as CPU but at a relatively low %.
> >
> > Question - Does CMF only report CPU delay for the Logical Processors
> in that particular LPAR?
> > The LPAR is question often shows CPU usage of 90+%, while the CMF
> LPARSTAR view shows a physical cpu% of 35-45%.
> >
> > Is it possible that the delay at the Physical processor is not
> reported, or reported in a different view?
> >
> > Thank You,
> > Dave O'Brien
> > NIH Contractor
> >
> 
> How many logical processors does the Lpar have and how many physical
> processors does the machine have? If this ratio is 1:2, 90% lpar
> utilization means 45% machine utilization.
> 
> 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: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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 mess

Re: A New Threat for password hacking

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Clark Morris
> Sent: Tuesday, November 30, 2010 9:27 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: A New Threat for password hacking
> 
> On 29 Nov 2010 08:43:23 -0800, in bit.listserv.ibm-main you wrote:
> 
> >I would tend to agree with ' they violate our standards and 
> are sharing ids'. Security is not priority one in some other 
> countries. (At least not OUR security).
> 
> Security is not that high a priority in many organizations where the
> mantra is get the job done whatever it takes.  If the security
> department is too restrictive and viewed as being a major roadblock,
> the other departments will get creative.
> 
> If you have a product that insists on special characters in passwords,
> this can be a major pain given the variability of code points for many
> of the characters.  Also how many passwords do you have to remember?  
> 
> Clark Morris

Personally? About 5: (1) Work LAN; (2) Work mainframe; (3) Work "benefits" web 
site (outsourced); (4) home LAN; (4) Amazon; (5) home/ISP email. Those are the 
ones I use most of the time. I have a USB flash drive which is ext4 formatted 
and uses a GPT partition table which contains an encrypted file which contains 
my other passwords (i.e. just confuses Windows users). And I have a backup of 
that encrypted file at home in a couple of places. Hope I never forget __that__ 
password! Not that I am likely to do so. And it is, for all intents and 
purposes, unguessable by anyone. No, I won't say more on that or why I would 
say it. Of course, it could be cracked by somebody like Abbie Sciuto (and maybe 
the NSA or FBI) in just a few minutes .

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

Re: Question concerning CMF reporting of CPU Delay

[O'Brien, David W. (NIH/CIT) [C]]

Hi Kees,

3 physical CPs
2 Prod LPARs each with 3 LPs
1 Test LPAR with 2 LPs
1 Sandbox with 1 LP

So we have 9 LPs competing for 3 CPs. Fortunately 3 of those LPs are little 
used.
The relative weights of the Prod LPARs are 45 and 30. 
The LPAR reporting the problem is the one with 30, no surprise there.
The Test LPAR has a weight of 15 while the Sandbox has a weight of 10 and 
seldom use their relative share.

I have suggested that a 2:1 LP to CP ratio would be more efficient but was told 
the faster CP make the 2:1 ratio obsolete. Makes no sense to me but then I'm 
the DASD guy. Every problem is HSM until proven otherwise.
 
Thank You,
Dave O'Brien
NIH Contractor

From: Vernooij, CP - SPLXM [kees.verno...@klm.com]
Sent: Tuesday, November 30, 2010 10:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Question concerning CMF reporting of CPU Delay

"O'Brien, David W.  [C] , NIH/CIT"  wrote in
message
news:..
.
> We had a situation where our M204 users reported a delay but CMF shows
the main delay as CPU but at a relatively low %.
>
> Question - Does CMF only report CPU delay for the Logical Processors
in that particular LPAR?
> The LPAR is question often shows CPU usage of 90+%, while the CMF
LPARSTAR view shows a physical cpu% of 35-45%.
>
> Is it possible that the delay at the Physical processor is not
reported, or reported in a different view?
>
> Thank You,
> Dave O'Brien
> NIH Contractor
>

How many logical processors does the Lpar have and how many physical
processors does the machine have? If this ratio is 1:2, 90% lpar
utilization means 45% machine utilization.

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

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

Re: A New Threat for password hacking

[Clark Morris]

On 29 Nov 2010 08:43:23 -0800, in bit.listserv.ibm-main you wrote:

>I would tend to agree with ' they violate our standards and are sharing ids'. 
>Security is not priority one in some other countries. (At least not OUR 
>security).

Security is not that high a priority in many organizations where the
mantra is get the job done whatever it takes.  If the security
department is too restrictive and viewed as being a major roadblock,
the other departments will get creative.

If you have a product that insists on special characters in passwords,
this can be a major pain given the variability of code points for many
of the characters.  Also how many passwords do you have to remember?  

Clark Morris
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
>McKown, John
>Sent: Monday, November 29, 2010 10:58 AM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: A New Threat for password hacking
>
>Each to his own. I prefer "the human touch" on password resets. But I'm an old 
>paranoid . In my arrogance, somebody who cannot remember their RACF 
>password likely can't remember their own name, either. A passphrase may be 
>more difficult. But 8 stupid characters, max? Sure, it could be forgotten 
>early on. And after a vacation. But we've had literally 8 or 10 password reset 
>requests in a row from some of our off-shore users. Personally, I think they 
>violate our standards and are sharing ids. But I can't prove it.
>
>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-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
>> Sent: Monday, November 29, 2010 9:44 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: A New Threat for password hacking
>> 
>> On Mon, 29 Nov 2010 05:27:56 -0600, John McKown wrote:
>> >
>> >What gets me on this is that, in the recent past, some people at work 
>> >were wanting an "automatic resume" of any RACF id which got too many 
>> >password violations after some interval - like 10 minutes. So try "n"
>> >times, wait "m" minutes, rinse and repeat. Luckily this was killed.
>> >
>> The proposal isn't totally unreasonable in that it multiplies the time 
>> required for a brute force attack by a few orders of magnitude.
>> I knew a product which imposed an escalating lockout time before retry 
>> for each unsuccessful attempt.
>> 
>> -- gil
>> 

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

Re: Question concerning CMF reporting of CPU Delay

[Vernooij, CP - SPLXM]

"O'Brien, David W.  [C] , NIH/CIT"  wrote in
message
news:..
.
> We had a situation where our M204 users reported a delay but CMF shows
the main delay as CPU but at a relatively low %.
> 
> Question - Does CMF only report CPU delay for the Logical Processors
in that particular LPAR?
> The LPAR is question often shows CPU usage of 90+%, while the CMF
LPARSTAR view shows a physical cpu% of 35-45%.
> 
> Is it possible that the delay at the Physical processor is not
reported, or reported in a different view?
> 
> Thank You,
> Dave O'Brien
> NIH Contractor
> 

How many logical processors does the Lpar have and how many physical
processors does the machine have? If this ratio is 1:2, 90% lpar
utilization means 45% machine utilization.

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

Question concerning CMF reporting of CPU Delay

[O'Brien, David W. (NIH/CIT) [C]]

We had a situation where our M204 users reported a delay but CMF shows the main 
delay as CPU but at a relatively low %.

Question - Does CMF only report CPU delay for the Logical Processors in that 
particular LPAR?
The LPAR is question often shows CPU usage of 90+%, while the CMF LPARSTAR view 
shows a physical cpu% of 35-45%.

Is it possible that the delay at the Physical processor is not reported, or 
reported in a different view?

Thank You,
Dave O'Brien
NIH Contractor

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

Re: IEFBR14

[Robert A. Rosenberg]

At 17:55 -0500 on 11/29/2010, J R wrote about Re: IEFBR14:


 > > Date: Mon, 29 Nov 2010 16:08:33 +

 > From: bi...@mainstar.com
 > Subject: Re: IEFBR14
 > To: IBM-MAIN@bama.ua.edu
 >
 > He meant three possible instructions that only occupied two 
bytes of storage, I believe ("All three required the same memory 
and processing cycles. They were equal and interchangeable."). LA 
is a 4-byte instruction. A number of 4-byte instructions that were 
available way back when comes to mind: e.g., L R15,=F'0'; LM 
R15,R15,=F'0'.

 >
 > > Each byte of "core" storage in the 1960s was extremely scarce. 
He also omitted Subtract Logical Register 15,15, which is a 2-byte 
instruction and which executed slightly faster on a S/360 model 30 
than Subtract Register.


Since load module sizes are multiples of 8 bytes, LA could be used 
without going over the 8 byte minimum. Both L and LM need the =F'0' 
and thus would produce a 10 byte Load Module. In this case the module 
size (ie: The Core Usage) is only important if you are placing 
IEFBR14 into the LPA - Otherwise both an 8 byte and 16 byte version 
will fit into the partition and thus take the same amount of memory. 
The instruction size DOES matter if you have a multi-instruction (ie: 
normal) program where using a longer instruction in lieu of a shorter 
one that can produce the same result can push the program size over a 
size boundary and thus use "more" memory.


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

Re: upgrade to pcomm 5.9 cant login..more

[Larry Macioce]

Thank you Juergen, but there is a problem with our contract at the moment 
and the best we can do is 5.9 with fixes.
We can not even login unsecure  to tso.
Thanks
Larry

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

Re: upgrade to pcomm 5.9 cant login..more

[Juergen Keller]

Larry,
you should upgrade to 6.0 and not 5.9. We tested 5.9 when switching to 
secure-sessions and had some problems. They are fixed in 6.0. It runs now 
without any problems.
Juergen

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

upgrade to pcomm 5.9 cant login..more

[Larry Macioce]

we want to have everyone login securely and we were at pcomm5.7.
I have loaded pcom5.9 tired to login but it is failing with caveats
I get the inital login screen
1) when I try to login to tso in get a prog723. The log shows:
IKT112I SENDERROR DURING QUERY PROCESSING FOR TSO0011 , 
RPLRTNCD=0C,  RPLFDB2=0B,SENSE=0001 

BUT I can log into cics no problems. This tells me my tso appl has a problem  
but I don't know what it might be.
TIA
Mace 

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

Re: I would love to know what went wrong at NAB

[Shmuel Metz (Seymour J.)]

In , on 11/30/2010
   at 12:54 AM, Sheldon Davis  said:

>I would love to know how a corrupt system file in a parrallel sysplex
>can affect  a payroll system

Why? That's not what the article claims. "a corrupted file on an IBM
mainframe system" is quite different from "a corrupt system file".
>From the article it was a payment processing file.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IEFBR14

[Shmuel Metz (Seymour J.)]

In , on 11/29/2010
   at 11:44 AM, J R  said:

>He also omitted Exclusive Or (XR 15,15),

The quoted text is in your reply:

  There were three possible instructions that could be used to
  zero R15: ``Clear Register R15'', ``Subtract Register R15,R15'',
  and ``Exclusive Or Register R15,R15''. 

His list is missing SLR, but it include SR and XR, along with the
imaginary Clear.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: A New Threat for password hacking

[Shmuel Metz (Seymour J.)]

In ,
on 11/29/2010
   at 09:57 AM, "McKown, John"  said:

>Each to his own. I prefer "the human touch" on password resets. But
>I'm an old paranoid . In my arrogance, somebody who cannot
>remember their RACF password likely can't remember their own name,
>either. A passphrase may be more difficult. But 8 stupid characters,
>max?

One of the curses of the computer industry is people who believe that
their &foo[1] is the only one, and aren't concerned about what happens
when &bar has to use both your &foo and &baz's &foo. Eith characters
isn't very much to remember if you only have one password. By the time
you have half a dozen, it becomes an issue.

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

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

Re: Could we define ARM Couple datasesr and OMVS Couple dataset?

[Staller, Allan]

1) Yes you can define these files and policies. A CF is not needed for
this.
2) an OMVS couple dataset would only be needed if there are multiple
images sharing HFS/ZFS files, See the "Setting up a SYSPLEX" books (I
believe this is a redbook)

HTH,


There isn't any Couple facility in our shop.it was monoplex
configuration

Could we define ARM Couple datasesr and OMVS Couple dataset in our shop?


 If ARM couple dataset could be defined,we could define some arm police
to 

restart some Adderspaces when they abend.If it cann't be defined,what
else 

methods could Automatic Restart the abend AS?

 Do we need to define OMVS Couple dataset in our shop?


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

Re: I would love to know what went wrong at NAB

[Kelman, Tom]

A detailed explanation would be nice.  The way this article reads it's
the "mainframe" that's at fault. As though this wouldn't have happened
if the platform had been something other than the mainframe.  However,
I'd bet that the upgrade was to the application system, not the
mainframe, and something was wrong in a new application program that
corrupted the file. I'm wondering why it took 5 days to recover.  It
sounds like a proper backup/backout procedure wasn't in place in case of
a failure like this.

Tom Kelman
Capacity Planning
Commerce Bank, Kansas City

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Stephen Mednick
Sent: Tuesday, November 30, 2010 1:52 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: I would love to know what went wrong at NAB

One wonders if a detailed explanation of what transpired will be
forthcoming
as was the case back in July when the DBS Bank in Singapore had a major
outage.

http://www.dbs.com/newsroom/2010/press100804.aspx

Stephen Mednick
Computer Supervisory Services
Sydney, Australia
 
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf
Of Sheldon Davis
Sent: Tuesday, 30 November 2010 5:54 PM
To: IBM-MAIN@bama.ua.edu
Subject: I would love to know what went wrong at NAB

I would love to know how a corrupt system file in a parrallel sysplex
can
affect a payroll system

http://www.channelregister.co.uk/2010/11/29/nab_mainframe_cockup/

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


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

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

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

Re: I would love to know what went wrong at NAB

[Steve Comstock]

On 11/30/2010 12:52 AM, Stephen Mednick wrote:

One wonders if a detailed explanation of what transpired will be forthcoming
as was the case back in July when the DBS Bank in Singapore had a major
outage.

http://www.dbs.com/newsroom/2010/press100804.aspx

Stephen Mednick
Computer Supervisory Services
Sydney, Australia


Wow! I've never seen anything like that. Thanks for the link.




-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Sheldon Davis
Sent: Tuesday, 30 November 2010 5:54 PM
To: IBM-MAIN@bama.ua.edu
Subject: I would love to know what went wrong at NAB

I would love to know how a corrupt system file in a parrallel sysplex can
affect a payroll system

http://www.channelregister.co.uk/2010/11/29/nab_mainframe_cockup/





--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
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 new 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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Allocating SANDBOX Coupling Facility LPARs on across 2 CPCs

[Staller, Allan]

Assuming there are sufficient CF connections, I see no issue.


We are in the process of upgrading from a z900 to a Z9. Bothr CECs
contain a 
Production CF LPAR, Production and Development LPAR. The second CEC also

contains 2 Sandbox CF LPARs and 2 Sandbox LPARs.

We want to move 1 Sandbox CF LPAR and 1 Sandbox LPAR to the first CEC. 
Shared CPs is assigned to the Sandbox CF LPARs and it is capped.  

Is there any pittfalls that we need to be aware of ? Is this possible ?


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

Field that contains timestamp of when current jobstep started?

[Binyamin Dissen]

IIRC there is a field which has the timestamp of when the current step
started, but I cannot seem to find it.

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: I would love to know what went wrong at NAB

[Andrew Rowley]

On 30/11/2010 6:12 PM, Mike Schwab wrote:


That was not payroll.  That was a bank.  They screwed up all
transactions for a week after a conversion and fallback.  I would be
really curious as to how the database was functioning without crashing
while processing all those bad transactions.

Almost like they were processing the same old (duplicate) transactions
(?same GDG?) on one system while another system was putting new
transactions into newer files (GDG +1) which the other system did not
see (many missing transactions).  Maybe if they said which days were
repeated and which days were missed we could learn more?

Does the sysplex carry catalog updates (new file names) across
systems?  Are there Coupling Facility links that spread catalog
updates to other systems?


My speculation based on what has been in the news is that they had some 
sort of error processing their overnight batch transactions, and their 
error recovery also failed.


Then they would have had the problem of reversing the updates from the 
failed batch update and rerunning it, while still allowing new 
transactions into the database so that the bank could keep functioning.


It's the sort of problem that you would hope that banks are prepared 
for, but it still sounds like it could give you headaches.


I am also curious to know more.

--

Andrew Rowley
Black Hill Software Pty. Ltd.
Phone: +61 413 302 386

EasySMF for z/OS: Interactive SMF Reports on Your PC
http://www.smfreports.com

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

Re: zOSe and z10 - Urgent

[Brian Westerman]

I wonder if I could get a button that says that to wear.

Brian

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

Re: smf reporting

[Mike Wood]

Tim, Depending what you want to do and which records, one option could be to
use the Report Generator - Option G under ISMF.
It uses assembler mapping macros to help drive creation of reports based on
ICETOOL.  Prior to this life it was the DFSMSrmm report generator.

Mike Wood   RMM Development

On Wed, 24 Nov 2010 11:25:12 -0500, Tim Brown  wrote:

>What are all the options these days for reporting via smf records.
>Isnt there an RMF pc base reporting tool ?
>
>
>Thanks
>
>Tim Brown

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

Could we define ARM Couple datasesr and OMVS Couple dataset?

[ibmnew]

Hi all

 There isn't any Couple facility in our shop.it was monoplex  configuration

Could we define ARM Couple datasesr and OMVS Couple dataset in our shop? 

 If ARM couple dataset could be defined,we could define some arm police to 

restart some Adderspaces when they abend.If it cann't be defined,what else 

methods could Automatic Restart the abend AS?

 Do we need to define OMVS Couple dataset in our shop?

Thanks a lot!

Best Regards,

Jason Cai

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

Re: IEC614I RENAME FAILED - RC 008, DIAGNOSTIC INFORMATION IS (04100C04)

[ibmnew]

hi 

 We didn't do anything in the RACF and we didn't get any RACF error messages.

We discon the catalog we defined and delete the SSA we defined 

We reinstall z/OS 1.11 using Servpac again.Everything is ok. 

It is very strange.

Thanks a lot!


Best Regards,

Cai Jin Song 



 
On Tue, 9 Nov 2010 19:51:10 +0800, ibmnew  wrote:
>When we install z/OS 1.11 using Servpac,we want to rename
SSA.PLEXBDZ3.XCF01 to PLEXBDZ3.XCF01 as below.
>
>IEC614I RENAME FAILED  was occurred.Please see the following message.
>
>
>IEC614I RENAME FAILED - RC 008, DIAGNOSTIC INFORMATION IS (04100C04),  258
>258 ALTCAT,BD3CD2,SSA.PLEXBDZ3.XCF01
>
> ALTER -
>   SSA.PLEXBDZ3.XCF01 -
>   NEWNM(PLEXBDZ3.XCF01) -
>   CAT(CAT.MASTER.PLEXBDZ3)
>0IDC3014I CATALOG ERROR
> IDC3009I ** VSAM CATALOG RETURN CODE IS 98 - REASON CODE IS IGG0CLE6-8
> IDC0532I **ENTRY SSAMC3.PLEXBDZ3.XCF01 NOT ALTERED
>0IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8
My guess: SSA.PLEXBDZ3.XCF01 is protected by a generic RACF profile.
PLEXBDZ3.XCF01 would not be protected by a generic profile. Therefore the
RENAME would remove protection for the data set, and we do not allow that to
happen.
Note that you do not get any RACF error messages occur for this case, only
the IEC message.
-- 
Walt Farrell
IBM STSM, z/OS Security Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

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