Naspa - Technical Support magazine

[John Blythe Reid]

Does anyone know if Technical Support magazine is still being published ? It
stopped about three years ago but I saw that it re-appeared in June last
year. Looking at the Naspa web-site  it doesn't mention it as one of the
membership benefits. I always thought it was a pretty good magazine so I
thought it a pity that it stopped.

Bye for now,
John.



-- 
John Blythe Reid,
Técnico de Sistemas de z/OS y de Sistemas Transaccionales,
Barcelona,
España.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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

[Brian Westerman]

It's kind of difficult to use a brute force attack when RACF revokes the ID
after a site specified number of attempts.  Assuming the site doesn't allow
1 or 2 character passwords (you don't do you), even if the site were to
allow 100 attempts, it's statistically a REALLY long shot to guess the
password.  I would imagine that most sites have 3 or 4 as the number of
attempts, making the probability for success of a brute force attack too
remote to consider as they wouldn't even get out of the single character
attempts.  

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

[Andrew Rowley]

On 25/11/2010 3:25 AM, Tim Brown wrote:

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


You might be interested in looking at EasySMF, which is PC based. It 
brings the information from different record types together, so you can 
jump from RMF reports to viewing the type 30 information from work 
running at that time etc.


http://www.smfreports.com

Regards

Andrew Rowley

--

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: A New Threat for password hacking

[Binyamin Dissen]

On Mon, 29 Nov 2010 04:39:54 -0600 Brian Westerman
 wrote:

:>It's kind of difficult to use a brute force attack when RACF revokes the ID
:>after a site specified number of attempts.  Assuming the site doesn't allow
:>1 or 2 character passwords (you don't do you), even if the site were to
:>allow 100 attempts, it's statistically a REALLY long shot to guess the
:>password.  I would imagine that most sites have 3 or 4 as the number of
:>attempts, making the probability for success of a brute force attack too
:>remote to consider as they wouldn't even get out of the single character
:>attempts.  

If you have the offload, you can make as many attempts as you wish.

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

David Debevec is out of the office

[David DeBervec]

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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]

That's a good point I suppose, but I think he's just worried about being
able to move his production system to a hardware platform so that he can
convert to something a bit more recent without bending over backwards and
doing back flips.  

The session at SHARE that I will be presenting this year covers those types
of conversions (Long-Jump) which are conversions beyond the 3-release
"rule".  I think converting from 1.6 to 1.10 (or 11 or 12) certainly falls
under that.  

I was wondering if (during the session) it would be beneficial if I should
mention the hardware aspects (and pitfalls) that sites run into instead of
just the software side.  It was more common a few years ago when 967x and
multiprise sites "couldn't" move beyond (1.1 (or 1.4 for the multiprise)),
and the IBM "rule-book" said they couldn't install it on a z/9 in
preparation for moving to the "current" release.  Now with z/10 and z/196
the wheel turns yet again and many sites will find themselves in the same
boat they were in with the 967x's and Multiprise boxes, only worse because
it will be a self-imposed boat built with "vague restrictions" and not fact.
 That's good for us consultants, but bad for IBM's image.  I can understand
making the mistake the first time with s/360's or the second time with
s/370, and maybe even a third time with the 43xx boxes or even one last time
the next time with the 967x and Multiprise boxes, but now we have a whole
group of z/series boxes that I can already see are going to be in an
artificial and virtual world of hurt.  The sad part is that much of it is
not even a "real" hurt because the terms "not supported" and "won't work"
have entirely different meanings and a lot of people, (not just at IBM) seem
to not understand the difference.

The "real" world is that I just finished (in October) converting a
university from OS/390 2.9 to z/OS 1.11 and moved them from their MP3000-H70
to a (new) z/10 and it took less than 3 months from start to finish, and
most of that was in planning and testing.  The most experienced systems
programmer on site there had 2 years of experience.  They didn't even know
about the "3 release rule" so the conversion went off without a hitch.

Maybe we should rename my session to z/OS conversion FUD-Buster, what do you
think?

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: Naspa - Technical Support magazine

[John McKown]

I think it is PDF only via the web site. But I don't think it's monthly
any more.

On Mon, 2010-11-29 at 11:06 +0100, John Blythe Reid wrote:
> Does anyone know if Technical Support magazine is still being published ? It
> stopped about three years ago but I saw that it re-appeared in June last
> year. Looking at the Naspa web-site  it doesn't mention it as one of the
> membership benefits. I always thought it was a pretty good magazine so I
> thought it a pity that it stopped.
> 
> Bye for now,
> John.
> 
> 
> 
-- 
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: A New Threat for password hacking

[Robert S. Hansel (RSH)]

John,

I believe RACF only uses single DES, not Triple DES.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com

-
2011 RACF Training
> Intro & Basic Admin - WebEx  - JAN 24-28
> Securing z/OS Unix  - WebEx  - FEB 8-10
> Audit for Results   - Boston - APR 12-14
> Intro & Basic Admin - Boston - MAY 10-12
Visit our website for registration & details
-

-Original Message-
Date:Sun, 28 Nov 2010 19:37:37 -0600
From:John McKown 
Subject: Re: A New Threat for password hacking

RACF password encryption is explained here:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza290/3.3.1

It uses Triple DES where the password is a key to encrypt the userid,
which encrypted value is then stored in the DB. So two different users
with the same password would have two different encrypted values. It
also states it is a "one way" encryption. There is no way to "back out".
To crack a password would require having the unencrypted RACF id, the
encrypted stored value, and the exact algorithm. Now, I'm not a
cryptographer, but I don't think you can use that information to
recreate a valid password easily. So you're more likely to try a brute
force dictionary attack. Again, using an NSA quality supercomputer, I
have no idea how long this would take. I think I'd just play the lotto
and win sooner. But that is my ignorance speaking.

On Sun, 2010-11-28 at 19:15 -0600, Paul Gilmartin wrote:
> On Sun, 28 Nov 2010 15:56:36 -0600, Russell Witt wrote:
>
> >Easy to say "do not share your RACF db"; harder in reality. Most sites
> >believe they are safe because their RACF db is security protected and the
> >dasd is not shared. And then completely forget that backups (to physical
or
> >virtual tape) contain the exact same information. And quite often the DSN
> >used for the backup tapes is some type of dasd-manager HLQ, since it was
> >most likely a full-volume backup that happen'ed to contain the RACF db.
And
> >even if the HLQ for the full-volume backups is read-protected; it is
still
> >far easier to hack a tape dataset. Often, tape libraries (physical and
> >virtual) are shared with less-secure test machines and quite often even
with
> >non z/OS systems. Granted, you will need the physical layout of the RACF
db;
> >but not the entire layout. Just enough to identify where the passphrases
are
> >maintained.
> >
> Aren't the passwords encrypted?  But how strong is the encryption?
>
> It would be peculiarly pointless to store fewer bits of the encrypted
> password than are used in the encrypting key.
>
> -- 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
--
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: A New Threat for password hacking

[John McKown]

On Mon, 2010-11-29 at 04:39 -0600, Brian Westerman wrote:
> It's kind of difficult to use a brute force attack when RACF revokes the ID
> after a site specified number of attempts.  Assuming the site doesn't allow
> 1 or 2 character passwords (you don't do you), even if the site were to
> allow 100 attempts, it's statistically a REALLY long shot to guess the
> password.  I would imagine that most sites have 3 or 4 as the number of
> attempts, making the probability for success of a brute force attack too
> remote to consider as they wouldn't even get out of the single character
> attempts.  
> 
> Brian
> 

I was thinking more of an off-line attack by having captured some sort
of dump of the database. 

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. They
also want a "Web like" interface so that a person could reset their own
password via their browser. Luckily, we were able to kill most of this
stuff with HIPAA requirements. And the "dangling of multi-million dollar
penalities" should this be used to crack our system.

-- 
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: Z10 BC issue

[Brian Westerman]

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

Re: A New Threat for password hacking

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen
> 
> On Mon, 29 Nov 2010 04:39:54 -0600 Brian Westerman
>  wrote:
> 
> :>It's kind of difficult to use a brute force attack when RACF revokes
the ID
> :>after a site specified number of attempts.  Assuming the site
doesn't allow
> :>1 or 2 character passwords (you don't do you), even if the site were
to
> :>allow 100 attempts, it's statistically a REALLY long shot to guess
the
> :>password.  I would imagine that most sites have 3 or 4 as the number
of
> :>attempts, making the probability for success of a brute force attack
too
> :>remote to consider as they wouldn't even get out of the single
character
> :>attempts.
> 
> If you have the offload, you can make as many attempts as you wish.

But the "offload" (did you mean "unload", as produced by IRRDBU00?)
doesn't contain the password

If you meant "backup", then your point is valid.

-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: zOSe and z10 - Urgent

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Brian Westerman
> 
> [ snip ]
> 
> Maybe we should rename my session to z/OS conversion FUD-Buster, what
do you
> think?

"FUDSI" -- includes "Superstition" and "Ignorance", both of which
frequently accompany FUD...  :-)

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

[Shmuel Metz (Seymour J.)]

In , on 11/28/2010
   at 10:27 PM, Avram Friedman  said:

>It is reasonable to think the original IEFBR14 was customer or field
>developed  in a lanuage other than assembler.

Not given the name.
 
-- 
 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/28/2010
   at 10:57 PM, Avram Friedman  said:

>http://www.miketaylor.org.uk/tech/oreilly/more-iefbr14.html >From one
>of the two IBM co-authors
>Note not part of the original OS spec added as an after thought

Given the following quote, his memory is not reliable:

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

There is, of course, no "Clear Register" instruction. The third
obvious instruction is LA.
 
-- 
 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

[McKown, John]

Could well be. I vaguely remember something about Triple DES somewhere. But my 
mind is a bit "loose" right now on meds.

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 Robert S. Hansel (RSH)
> Sent: Monday, November 29, 2010 5:25 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: A New Threat for password hacking
> 
> John,
> 
> I believe RACF only uses single DES, not Triple DES.
> 
> Regards, Bob
> 
> Robert S. Hansel
> Lead RACF Specialist
> RSH Consulting, Inc.
> 617-969-8211
> www.linkedin.com/in/roberthansel
> www.rshconsulting.com
> 
> -
> 2011 RACF Training
> > Intro & Basic Admin - WebEx  - JAN 24-28
> > Securing z/OS Unix  - WebEx  - FEB 8-10
> > Audit for Results   - Boston - APR 12-14
> > Intro & Basic Admin - Boston - MAY 10-12
> Visit our website for registration & details
> -
> 
> -Original Message-
> Date:Sun, 28 Nov 2010 19:37:37 -0600
> From:John McKown 
> Subject: Re: A New Threat for password hacking
> 
> RACF password encryption is explained here:
> 
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ich
> za290/3.3.1
> 
> It uses Triple DES where the password is a key to encrypt the userid,
> which encrypted value is then stored in the DB. So two different users
> with the same password would have two different encrypted values. It
> also states it is a "one way" encryption. There is no way to 
> "back out".
> To crack a password would require having the unencrypted RACF id, the
> encrypted stored value, and the exact algorithm. Now, I'm not a
> cryptographer, but I don't think you can use that information to
> recreate a valid password easily. So you're more likely to try a brute
> force dictionary attack. Again, using an NSA quality supercomputer, I
> have no idea how long this would take. I think I'd just play the lotto
> and win sooner. But that is my ignorance speaking.
> 
> On Sun, 2010-11-28 at 19:15 -0600, Paul Gilmartin wrote:
> > On Sun, 28 Nov 2010 15:56:36 -0600, Russell Witt wrote:
> >
> > >Easy to say "do not share your RACF db"; harder in 
> reality. Most sites
> > >believe they are safe because their RACF db is security 
> protected and the
> > >dasd is not shared. And then completely forget that 
> backups (to physical
> or
> > >virtual tape) contain the exact same information. And 
> quite often the DSN
> > >used for the backup tapes is some type of dasd-manager 
> HLQ, since it was
> > >most likely a full-volume backup that happen'ed to contain 
> the RACF db.
> And
> > >even if the HLQ for the full-volume backups is 
> read-protected; it is
> still
> > >far easier to hack a tape dataset. Often, tape libraries 
> (physical and
> > >virtual) are shared with less-secure test machines and 
> quite often even
> with
> > >non z/OS systems. Granted, you will need the physical 
> layout of the RACF
> db;
> > >but not the entire layout. Just enough to identify where 
> the passphrases
> are
> > >maintained.
> > >
> > Aren't the passwords encrypted?  But how strong is the encryption?
> >
> > It would be peculiarly pointless to store fewer bits of the 
> encrypted
> > password than are used in the encrypting key.
> >
> > -- 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
> --
> 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
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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

[McKown, John]

Correct. I meant FDR or DFDSS or even IRRUTnnn unload. Not IRRDBU00.

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 Chase, John
> Sent: Monday, November 29, 2010 6:54 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: A New Threat for password hacking
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen
> > 
> > On Mon, 29 Nov 2010 04:39:54 -0600 Brian Westerman
> >  wrote:
> > 
> > :>It's kind of difficult to use a brute force attack when 
> RACF revokes
> the ID
> > :>after a site specified number of attempts.  Assuming the site
> doesn't allow
> > :>1 or 2 character passwords (you don't do you), even if 
> the site were
> to
> > :>allow 100 attempts, it's statistically a REALLY long shot to guess
> the
> > :>password.  I would imagine that most sites have 3 or 4 as 
> the number
> of
> > :>attempts, making the probability for success of a brute 
> force attack
> too
> > :>remote to consider as they wouldn't even get out of the single
> character
> > :>attempts.
> > 
> > If you have the offload, you can make as many attempts as you wish.
> 
> But the "offload" (did you mean "unload", as produced by IRRDBU00?)
> doesn't contain the password
> 
> If you meant "backup", then your point is valid.
> 
> -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
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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: DITTO Alternative

[Joseph Butz]

Hi Ken,

Not a DITTO replacement, but if you have the FDR product, you also have 
program FDRDSF with the PRINT function that provides an option to print the 
contents of disk tracks by data set name (generic or absolute) or by absolute 
track addresses.

Joe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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: DITTO Alternative

[Bill Fairchild]

It used to be that you could get SPZAP to work within the VTOC by specifying 
//SYSLIB DD DSN=FORMAT4.DSCB (or something like that), which SPZAP changed into 
a DSN of 44'04'X before it began searching the VTOC for the desired DSN.  Since 
the Format 4 DSCB's 44-byte key contains 44 bytes of X'04', all allocated 
"real" data sets have their 44-byte DSName within the 44-byte key of their 
Format 1 DSCB, and since the extent descriptors in a Format 1 DSCB are at the 
same offset as the one extent descriptor in the F4 DSCB for the VTOC, then 
SPZAP needed very little extra logic to process a VTOC as if it were a normally 
allocated data set.  The real issue now is security.

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Thursday, November 25, 2010 10:27 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: DITTO Alternative

In
<77142d37c0c3c34da0d7b1da7d7ca34308802...@nwt-s-mbx2.rocketsoftware.com>,
on 11/24/2010
   at 09:07 PM, Bill Fairchild  said:

>only tracks in allocated data sets and/or the VTOC can be displayed

Is that stil true when the dsname is 44'04'X?
 
-- 
 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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 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

Re: A New Threat for password hacking

[Paul Gilmartin]

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: A New Threat for password hacking

[McKown, John]

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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

[Bill Fairchild]

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.

But you are right; there is no Clear Register instruction.

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Monday, November 29, 2010 7:25 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14

In , on 11/28/2010
   at 10:57 PM, Avram Friedman  said:

>http://www.miketaylor.org.uk/tech/oreilly/more-iefbr14.html >From one
>of the two IBM co-authors
>Note not part of the original OS spec added as an after thought

Given the following quote, his memory is not reliable:

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

There is, of course, no "Clear Register" instruction. The third
obvious instruction is LA.
 
-- 
 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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

[Veilleux, Jon L]

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

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

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

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

Re: IEFBR14

[J R]

He also omitted Exclusive Or (XR 15,15), unless that's what he meant by "Clear 
Register".  

 
> 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.
> 
> But you are right; there is no Clear Register instruction.
> 
> Bill Fairchild
> Rocket Software
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf 
> Of Shmuel Metz (Seymour J.)
> Sent: Monday, November 29, 2010 7:25 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEFBR14
> 
> In , on 11/28/2010
> at 10:57 PM, Avram Friedman  said:
> 
> >http://www.miketaylor.org.uk/tech/oreilly/more-iefbr14.html >From one
> >of the two IBM co-authors
> >Note not part of the original OS spec added as an after thought
> 
> Given the following quote, his memory is not reliable:
> 
> 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''. 
> 
> There is, of course, no "Clear Register" instruction. The third
> obvious instruction is LA.
> 
> -- 
> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email 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: IEFBR14

[Chase, John]

Wasn't there also a requirement that whatever means was chosen to zero
Reg15 also set the condition code to zero?


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of J R
> Sent: Monday, November 29, 2010 10:44 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEFBR14
> 
> He also omitted Exclusive Or (XR 15,15), unless that's what he meant
by "Clear Register".
> 
> 
> > 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.
> >
> > But you are right; there is no Clear Register instruction.
> >
> > Bill Fairchild
> > Rocket Software
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Shmuel Metz (Seymour
> J.)
> > Sent: Monday, November 29, 2010 7:25 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: IEFBR14
> >
> > In , on 11/28/2010
> > at 10:57 PM, Avram Friedman  said:
> >
> > >http://www.miketaylor.org.uk/tech/oreilly/more-iefbr14.html >From
one
> > >of the two IBM co-authors
> > >Note not part of the original OS spec added as an after thought
> >
> > Given the following quote, his memory is not reliable:
> >
> > 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''.
> >
> > There is, of course, no "Clear Register" instruction. The third
> > obvious instruction is LA.
> >
> > --
> > 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
> >
> >
--
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email 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: IEFBR14

[Bill Fairchild]

Read the linked article again.  He did mention XR.

" 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''."

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
J R
Sent: Monday, November 29, 2010 10:44 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14

He also omitted Exclusive Or (XR 15,15), unless that's what he meant by "Clear 
Register".  

 
> 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.
> 
> But you are right; there is no Clear Register instruction.
> 
> Bill Fairchild
> Rocket Software
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf 
> Of Shmuel Metz (Seymour J.)
> Sent: Monday, November 29, 2010 7:25 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEFBR14
> 
> In , on 11/28/2010
> at 10:57 PM, Avram Friedman  said:
> 
> >http://www.miketaylor.org.uk/tech/oreilly/more-iefbr14.html >From one
> >of the two IBM co-authors
> >Note not part of the original OS spec added as an after thought
> 
> Given the following quote, his memory is not reliable:
> 
> 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''. 
> 
> There is, of course, no "Clear Register" instruction. The third
> obvious instruction is LA.
> 
> -- 
> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email 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: IEFBR14

[Binyamin Dissen]

On Mon, 29 Nov 2010 11:22:43 -0600 "McKown, John"
 wrote:

:>> -Original Message-
:>> From: IBM Mainframe Discussion List 
:>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant
:>> Sent: Monday, November 29, 2010 11:11 AM
:>> To: IBM-MAIN@bama.ua.edu
:>> Subject: Re: IEFBR14
 
:>> On Mon, 29 Nov 2010 10:51:19 -0600, Chase, John wrote:
 
:>> >Wasn't there also a requirement that whatever means was 
:>> chosen to zero
:>> >Reg15 also set the condition code to zero?
 
:>> The condition code for the step is set from the value in register 15. 
:>> There is no connection between that and the condition code bits in 
:>> the PSW.  No, there was no requirement to set the CC bits in the PSW.

:>Now that would be interesting, tho. Most code does something like:

:>  CALL SOMEPGM,...
:>  LTR 15,15
:>  BNZ ERROR

:>Imagine if IBM had stated that that subroutine linkage should set the CC as 
well as the RC in 15 so that the code could have been shorted to:

:>  CALLSOMEPGM,...
:>  BNZ ERROR

:>I saved 2 bytes and one instruction. Today, who cares? On an old S/360??? 

IIRC, that is how it works in CP (VM). But it required the called routine to
set the CC, typically via SPM.

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

[Tom Marchant]

On Mon, 29 Nov 2010 10:51:19 -0600, Chase, John wrote:

>Wasn't there also a requirement that whatever means was chosen to zero
>Reg15 also set the condition code to zero?

The condition code for the step is set from the value in register 15. 
There is no connection between that and the condition code bits in 
the PSW.  No, there was no requirement to set the CC bits in the PSW.

-- 
Tom Marchant

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

Re: IEFBR14

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant
> Sent: Monday, November 29, 2010 11:11 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEFBR14
> 
> On Mon, 29 Nov 2010 10:51:19 -0600, Chase, John wrote:
> 
> >Wasn't there also a requirement that whatever means was 
> chosen to zero
> >Reg15 also set the condition code to zero?
> 
> The condition code for the step is set from the value in register 15. 
> There is no connection between that and the condition code bits in 
> the PSW.  No, there was no requirement to set the CC bits in the PSW.
> 
> -- 
> Tom Marchant

Now that would be interesting, tho. Most code does something like:

CALL SOMEPGM,...
LTR 15,15
BNZ ERROR

Imagine if IBM had stated that that subroutine linkage should set the CC as 
well as the RC in 15 so that the code could have been shorted to:

CALLSOMEPGM,...
BNZ ERROR

I saved 2 bytes and one instruction. Today, who cares? On an old S/360??? 

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

[Bill Fairchild]

The called program can also set the condition code simultaneously to clearing 
R15 with the appropriate single instruction.  SR does both.  If SR 15,15 is 
immediately followed by BR 14 or the appropriate return instruction, there is 
no need for the SPM, although there may be other bits that CP is setting with 
the SPM.

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Binyamin Dissen
Sent: Monday, November 29, 2010 11:31 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14


:>  CALLSOMEPGM,...
:>  BNZ ERROR

:>I saved 2 bytes and one instruction. Today, who cares? On an old S/360??? 

IIRC, that is how it works in CP (VM). But it required the called routine to
set the CC, typically via SPM.

--
Binyamin Dissen 
http://www.dissensoftware.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

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

Migration from EC 3 to EC 4.2

[Lizette Koehler]

I am z/OS V1.11 

I am in the process of working on upgrading COBOL from Enterprise COBOL V3 to 
V4.2

I have been reading the Share presnetations, Migration Guides, and 
miscellaneous documents.

Does anyone have any gotchas on migrating from V3 to V4.2?

Only major change I see is the XML improvements, but everything else looks okay.

Thanks

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

Re: IEFBR14

[Dan Skomsky, Police Support Technology]

I have worked on some systems where the CC was the standard response
mechanism from CALL'd subroutines.  Example:

CALLSENDALL,(INBUFF,OURBUFF,...)
BZ  SUCCESS
BH  OVERFLOW
BL  SNDSHORT
BO  TRYAGAIN

This is common technique with some real-time I/O and "State Table" driven
systems.  As long as there are only a limited number of possible system
states, this technique is bullet proof.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Binyamin Dissen
Sent: Monday, November 29, 2010 11:31 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14

On Mon, 29 Nov 2010 11:22:43 -0600 "McKown, John"
 wrote:

:>> -Original Message-
:>> From: IBM Mainframe Discussion List :>> [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Tom Marchant :>> Sent: Monday, November 29, 2010 11:11 AM :>> To:
IBM-MAIN@bama.ua.edu :>> Subject: Re: IEFBR14
 
:>> On Mon, 29 Nov 2010 10:51:19 -0600, Chase, John wrote:
 
:>> >Wasn't there also a requirement that whatever means was :>> chosen to
zero :>> >Reg15 also set the condition code to zero?
 
:>> The condition code for the step is set from the value in register 15. 
:>> There is no connection between that and the condition code bits in :>>
the PSW.  No, there was no requirement to set the CC bits in the PSW.

:>Now that would be interesting, tho. Most code does something like:

:>  CALL SOMEPGM,...
:>  LTR 15,15
:>  BNZ ERROR

:>Imagine if IBM had stated that that subroutine linkage should set the CC
as well as the RC in 15 so that the code could have been shorted to:

:>  CALLSOMEPGM,...
:>  BNZ ERROR

:>I saved 2 bytes and one instruction. Today, who cares? On an old S/360??? 

IIRC, that is how it works in CP (VM). But it required the called routine to
set the CC, typically via SPM.

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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

[Bill Fairchild]

That condition would eliminate the SLR that I suggested in an earlier post, as 
well as LA, but I don't know if that condition existed.  I do know that the 
module was supposed to return zero in R15 for proper processing by the 
Initiator/Terminator.

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Chase, John
Sent: Monday, November 29, 2010 10:51 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14

Wasn't there also a requirement that whatever means was chosen to zero
Reg15 also set the condition code to zero?


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of J R
> Sent: Monday, November 29, 2010 10:44 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEFBR14
> 
> He also omitted Exclusive Or (XR 15,15), unless that's what he meant
by "Clear Register".
> 
> 
> > 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.
> >
> > But you are right; there is no Clear Register instruction.
> >
> > Bill Fairchild
> > Rocket Software
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Shmuel Metz (Seymour
> J.)
> > Sent: Monday, November 29, 2010 7:25 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: IEFBR14
> >
> > In , on 11/28/2010
> > at 10:57 PM, Avram Friedman  said:
> >
> > >http://www.miketaylor.org.uk/tech/oreilly/more-iefbr14.html >From
one
> > >of the two IBM co-authors
> > >Note not part of the original OS spec added as an after thought
> >
> > Given the following quote, his memory is not reliable:
> >
> > 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''.
> >
> > There is, of course, no "Clear Register" instruction. The third
> > obvious instruction is LA.
> >
> > --
> > 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
> >
> >
--
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email 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: Migration from EC 3 to EC 4.2

[Mark Jacobs]

On 11/29/10 13:26, Lizette Koehler wrote:

I am z/OS V1.11

I am in the process of working on upgrading COBOL from Enterprise COBOL V3 to 
V4.2

I have been reading the Share presnetations, Migration Guides, and 
miscellaneous documents.

Does anyone have any gotchas on migrating from V3 to V4.2?

Only major change I see is the XML improvements, but everything else looks okay.

Thanks

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

   


Just make sure you have the LE support for the new COBOL in production also.

--
Mark Jacobs
Time Customer Service
Tampa, FL


Santa Claus: What would you like for Christmas?
Little girl on his lap: My own credit card.

Brazil (1985)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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

[Mary Anne Matyaz]

Wow. Is it possible he looked at CLR R1,R2 ...  and thought it meant
clear??? I mean, I don't see how even a half fast programmer wouldn't know
that, so it seems incomprehensible to me, but I can't come up with any other
plausible reasons. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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

[Tom Marchant]

On Mon, 29 Nov 2010 16:08:33 +, Bill Fairchild wrote:

>Each byte of "core" storage in the 1960s was extremely scarce.

True, but since a CSECT always begins on a doubleword boundary 
and is an integral number of doublewords in length, it doesn't really 
matter whether the program is 4 or 6 bytes long.

-- 
Tom Marchant

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

Re: Z10 BC issue

[Mike Schwab]

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

Re: Migration from EC 3 to EC 4.2

[Steve Comstock]

On 11/29/2010 11:26 AM, Lizette Koehler wrote:

I am z/OS V1.11

I am in the process of working on upgrading COBOL from Enterprise COBOL V3 to 
V4.2

I have been reading the Share presnetations, Migration Guides, and 
miscellaneous documents.

Does anyone have any gotchas on migrating from V3 to V4.2?

Only major change I see is the XML improvements, but everything else looks okay.

Thanks

Lizette


I see Mark Jacobs already pointed out the only installtion
gotcha' that I'm aware of when doing this upgrade.


Now, ahem, what are you doing to train your programmers to
be aware of and use the new features? It's probably not
your area of concern, but you might pass this on to the
right people in your organization:

Our two courses "Enterprise COBOL Update" and "Enterprise
COBOL Unicode and XML Support" might be of interest.


Enterpise COBOL Update is a two-day course that describes
the changes to COBOL from VS COBOL II up through Enterprise
COBOL V4.2 on a release-by-release basis, including practical
hands-on labs. Details at:

  http://www.trainersfriend.com/COBOL_Courses/d704descr.htm



Enterprise COBOL Unicode and XML Support is also a two-day
course, but this focuses on how to work with Unicode (and
ASCII) from COBOL programs as well as how to parse XML and
generate XML from a COBOL program. Changes introduced with
each version of Enterpise COBOL are discussed. There are
ten hands on labs! Details at:

  http://www.trainersfriend.com/COBOL_Courses/d705descr.htm





--

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: A New Threat for password hacking

[R.S.]

W dniu 2010-11-29 16:43, Paul Gilmartin pisze:

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.


The proposal is *very* reasonable. Such functionality could be very 
convenient and it's NOT security breach. Note: YOU CAN SWITCH IT OFF!
A choice is good. For those who do not accept such solution the 
functionality would be disabled. For others that means saved FTE's. IMHO 
it's better (safer) that "self service password reset".


Would I switch it on? I wouldn't decide, IT'S NOT MY DOG. ;-)
My dog is to abide by (observe) the rules.

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 16.07.2010 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.248.328 złotych. 


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

Re: DITTO Alternative

[Rick Fochtman]

Shmuel Metz (Seymour J.) wrote:


In
<77142d37c0c3c34da0d7b1da7d7ca34308802...@nwt-s-mbx2.rocketsoftware.com>,
on 11/24/2010
  at 09:07 PM, Bill Fairchild  said:

 


only tracks in allocated data sets and/or the VTOC can be displayed
   



Is that stil true when the dsname is 44'04'X?

 


Yes

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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

[J R]

Doh!  How did I miss that?  

I stand corrected.  My apologies.  


 
> Date: Mon, 29 Nov 2010 18:08:01 +
> From: bi...@mainstar.com
> Subject: Re: IEFBR14
> To: IBM-MAIN@bama.ua.edu
> 
> Read the linked article again. He did mention XR.
> 
> " 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''."
> 
> Bill Fairchild
> Rocket Software
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf 
> Of J R
> Sent: Monday, November 29, 2010 10:44 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IEFBR14
> 
> He also omitted Exclusive Or (XR 15,15), unless that's what he meant by 
> "Clear Register". 
> 
> 
> > 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.
> > 
> > But you are right; there is no Clear Register instruction.
> > 
> > Bill Fairchild
> > Rocket Software
> > 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf 
> > Of Shmuel Metz (Seymour J.)
> > Sent: Monday, November 29, 2010 7:25 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: IEFBR14
> > 
> > In , on 11/28/2010
> > at 10:57 PM, Avram Friedman  said:
> > 
> > >http://www.miketaylor.org.uk/tech/oreilly/more-iefbr14.html >From one
> > >of the two IBM co-authors
> > >Note not part of the original OS spec added as an after thought
> > 
> > Given the following quote, his memory is not reliable:
> > 
> > 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''. 
> > 
> > There is, of course, no "Clear Register" instruction. The third
> > obvious instruction is LA.
> > 
> > -- 
> > 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

[Ted MacNEIL]

>IMHO it's better (safer) that "self service password reset".

A full service reset could be costly.
I was once a customer of a service provider that charged us for each reset.
Each year we paid them twice as much as the cost of a self-service solution.

And, we're not talking about one of the cheap ones.
We're talking about a redundant server with connections to windows, z, *nix, 
including LINUX, active directory, and things we didn't have.

They can be very secure.
We had 3-question challenge response, full profiling of users -- the works.

-
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

Allocating SANDBOX Coupling Facility LPARs on across 2 CPCs

[Jaco Kruger]

Hello,

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 ?

Regards  

Jaco Kruger

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

I would love to know what went wrong at NAB

[Sheldon Davis]

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

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

[Mike Schwab]

On Tue, Nov 30, 2010 at 12:54 AM, Sheldon Davis  wrote:
> 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/

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?

-- 
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: I would love to know what went wrong at NAB

[Stephen Mednick]

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