date:20120327

Yes, we know, you're a vendor.
Please name few the most popular viruses for z/OS and two-three AV
programs for z/OS. ;-)))

"Intergrity vulnerability" - also, please name few popular, please omit
those which stem from administrator mistakes.

The integrity vulnerabilities *could* lead to viruses which would
exploit such vulnerabilities. In other words no vulnerabilities - no
malware, but existence of the hole does not imply existence of virus
exploiting that hole.
Last but not least: AV software is for virus finding, not for hole
clogging. Yes, today AV suites do contain additional modules, even
"parent control filters" or firewalls, but we don't talk about such
software.

I sustain my opinion: it is not mainframe problem. People who demand
non-existent software to be present are not mainframe problem.

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-03-28 00:11, Ray Overby pisze:

Every z/os system today has integrity vulnerabilities on it that if
exploited would allow users with access to that system to crash that
system or bypass installation controls and access any protected resource
on that system regardless of the installed ESM. They would be able to do
so with little to no audit trail.

What part of this is not a mainframe problem?

Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007

On 3/27/2012 13:25 PM, R.S. wrote:

W dniu 2012-03-27 17:06, Greg Dorner pisze:

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects
against malicious software (viruses, worms, trojans, etc.).

Does anyone know of a product that does this? I heard that McAfee is
coming out with a z/OS product "later this year", but I called them
and they had no idea what I was talking about.

z/OS, with proper security controls (and believe me - we have LOTS!)
should not have to worry about such things, at least that's what I've
always heard.

Any input on this topic would be GREATLY appreciated!!

This is NOT mainframe problem.

Indeed, you have problem with uneducated auditors. Maybe stupid ones.
Your problem is how to prove that requirement is both stupid and
impossible to fulfill.

We can provide you some arguments, like
- there are no such products
- there are no viruses, trojans or other malware for z/OS and it have
never been last 47 years. (I said 'z/OS', so the only VM worm does not
count)
- no mainframe installation use such product
- you have RACF *SECURITY SERVER* (or TS or ACF2)

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

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

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

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

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

Re: Malicious Software Protection

2012-03-27 Thread Mark Douglas (CITEC)

That Xmas EXEC story was still hot news at IBM Sydney in Christmas 1989. They 
warned us not to code such inadvertent viruses (pardon, virii) despite the best 
of intentions by its author.

Cheers,
MARK DOUGLAS 
Senior IT Support Consultant
Mainframe

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Anne & Lynn Wheeler
Sent: Wednesday, 28 March 2012 2:21 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Malicious Software Protection

scott_j_f...@yahoo.com (Scott Ford) writes:
> You can't be serious...never never heard of anyone developing a virus
> for mainframes, I understand the fear, but firewalls, network apps do
> rat in front of the mainframe

this discussion group, mailing list originated on BITNET ... recent
discussion (with wiki references)
http://www.garlic.com/~lynn/2012e.html#19 Inventor of e-mail honored by 
Smithsonian

really long winded recent post in linkedin MainframeZone group
http://www.garlic.com/~lynn/2012d.html#49 Do you know where all your sensitive 
data is located?

mentions the "xmas" exec nov1987 ... reference from vmshare archive
http://vm.marist.edu/~vmshare/browse?fn=CHRISTMA&ft=PROB

was almost exactly a year before the morris worm on the internet.

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

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

* Disclaimer *

The contents of this electronic message and any attachments are intended only 
for the addressee and may contain privileged or confidential information. They 
may only be used for the purposes for which they were supplied. If you are not 
the addressee, you are notified that any transmission, distribution, 
downloading, printing or photocopying of the contents of this message or 
attachments is strictly prohibited. The privilege of confidentiality attached 
to this message and attachments is not waived, lost or destroyed by reason of 
mistaken delivery to you. If you receive this message in error please notify 
the sender by return e-mail or telephone.

Please note: the Department of Public Works carries out automatic software 
scanning, filtering and blocking of E-mails and attachments (including emails 
of a personal nature) for detection of viruses, malicious code, SPAM, 
executable programs or content it deems unacceptable. All reasonable 
precautions will be taken to respect the privacy of individuals in accordance 
with the Information Privacy Act 2009 (Qld). Personal information will only be 
used for official purposes, e.g. monitoring Departmental Personnel's compliance 
with Departmental Policies. Personal information will not be divulged or 
disclosed to others, unless authorised or required by Departmental Policy 
and/or law.

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

Re: FRBACKUP Still Not Working...

2012-03-27 Thread Tidy, David (D)

In this situation, we have used the TSO command: TSO "fcwithdr tdevn()"  
with some success. I'm afraid that is just a way around the problem rather than 
an explanation of what exactly the problem is.

Best regards,
David Tidy  
IS Technical Management/SAP-Mf  
Dow Benelux B.V.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
George Rodriguez
Sent: 27 March 2012 19:31
To: IBM-MAIN@bama.ua.edu
Subject: FRBACKUP Still Not Working...

Since I now know that the problem is NOT hardware related, I've tried
everything to figure out what the problem is. I've installed the patch that
helps in problem determination (PATCH .FRGCB.+9 BITS(.1..)) and what I
get follows:

ARC1809I VOLUME CP00AA IS NOT A FAST REPLICATION CANDIDATE FOR L0 VOLUME
PPRD46, VER=0012, RC=0002

and the RC=0002 says:

volser1 is already paired with another source volume

...

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

Re: Malicious Software Protection

2012-03-27 Thread Blaicher, Christopher Y.

When writing an SVC one must be very careful.  The SVC you describe was poorly 
constructed and did not follow guidelines, admittedly not clearly stated as 
such, in the Authorized Assembler Services Manual.  Yes, R13 is the same as 
when the SVC was called, but from the manual:

When a type 2, 3, or 4 SVC routine receives control, register 5 contains the 
address of the SVRB.
This SVRB contains a 48-byte "extended save area," RBEXSAVE, for use by the SVC 
routine.

To use the caller's save area is not good programming.  After all, for most, if 
not all, system SVC's there is no requirement that R13 points at a save area.  
Most callable services do require a save area pointed to by R13 but then they 
are still in the user's key when they do the STM.

I never store into anything passed without verifying its validity and being in 
the key of the caller. I prefer to pass back information in registers.

Yes, there are probably a lot of shops out there that have a 'give me God-like 
powers' SVC, and they deserve what they get.

Is anything bullet-proof?  Probably not, but with the layers of control and 
with good coding, it is very tough to break through, especially from the 
outside.  There is little you can do to protect yourself from a disgruntled 
systems programmer.  After all, they have the keys to the kingdom.

This represents my personal opinion.

Chris Blaicher
Senior Software Engineer, Software Services
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com

Check out our Knowledge Base at www.syncsort.com/support

Syncsort aims for the best product and service experience.
We welcome your feedback.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Ray Overby
Sent: Tuesday, March 27, 2012 6:28 PM
To: MVS List Server 1
Subject: Re: Malicious Software Protection

I am a vendor so take my post with a grain of salt. For those that don't like 
vendors to respond stop reading now.. (flame on)

In my opinion there are some misconceptions about the ability of an ESM product 
to mitigate integrity based vulnerabilities and why this should be a concern 
for you. In general, your ESM product will not be able to help you much when 
dealing with these types of vulnerabilities. I will try and explain by example 
based on several real world integrity vulnerabilities what I mean.

Lets say there is a SVC that when you IPL your z/OS system it is installed and 
available for use (i.e - any one can issue the SVC). The SVC either came with 
z/OS or your system programmers installed it because of an ISV product your 
company purchased or its an in-house written program. For this example lets 
assume one of your TSO users will attempt to exploit this vulnerability. The 
TSO user has no extra-ordinary security privileges.

Like any SVC when invoked it will get control in an authorized state (PSW Key 
0). Further this SVC issues a STM instruction very early in the SVC code 
storing into where ever R13 points to. This type of defect is easily exploited 
writing a simple program (could have been posted on the
web) that would issue the SVC and:

-Just before the SVC is issued point the unauthorized program's R13
to some critical memory location. When the SVC code executes it will modify the 
storage pointed to by unauthorized program's R13. If the system does not crash 
right away then put it into a loop and reissue the svc with R13 pointing at 
different areas. Eventually you will crash the system.

-Just before the SVC is issued point the unauthorized program's R13
to your security credentials, preload your registers with appropriate values, 
and have the SVC update your security credentials for you.

Note that it does not matter if the SVC "worked" or not. As long as the STM 
instruction was executed (it always was) then whatever went on later did not 
matter.

On a RACF system you could exploit this integrity vulnerability by dynamically 
elevating your security authority by enabling RACF privileged attribute for 
your ACEE. You would be able to do similar actions on a TSS or ACF2 protected 
system as well. According to IBM documentation RACF privileged users have 
access to any RACF protected resource without logging. Even if there are 
exceptions to this you could suppress WTO's and any SMF records as well (with a 
little more work).
Once the TSO user has dynamically elevated their security authority they can 
then access whatever ESM protected resource they want. With no audit trail. Or 
you could modify your security credentials to be the high powered system's 
programmer or security officer and let the logging occur. This may get you 
through any system exits you have in place that check for those users.;-)

Based on these real world examples I was able to write that program:

-Dynamically elevated TSO users ESM security authority
-Access ESM protected

Re: z/os every two years

2012-03-27 Thread Skip Robinson

We heard it stated at SHARE so often by so many very well-placed IBM folks 
that it's inconceivable that it will transpire otherwise. 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

From:   Mike Schwab 
To: IBM-MAIN@bama.ua.edu
Date:   03/27/2012 06:09 PM
Subject:Re: z/os every two years
Sent by:IBM Mainframe Discussion List 

Not official.  But plan on it.  Official releases in Sept of odd years.

On Tue, Mar 27, 2012 at 7:17 PM, Andy White  wrote:
> Does anyone know when IBM is going to make this official? It is 
official?
> I am putting together 2013 projects and we normally up to now did 
upgrades
> once a year.
>
> 
http://blogs.realdolmen.com/experts/2012/03/13/a-new-zos-release-every-2-year/

>
> Andy S. White

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

Re: Malicious Software Protection

2012-03-27 Thread Rob Schramm

If everyone were as concerned with system integrity, Ray would be out
of a job and I would sleep better.  That presentation still wakes me
up at night.

Rob Schramm



On Tue, Mar 27, 2012 at 11:06 PM, Russell Witt  wrote:
> Greg,
>
> Others have given you more information than you probably wanted, but I am
> going to add one more. To the list of 11 items that Elardus supplied earlier
> in the day, I would add one more. His number 10 - Give them IBM's Statement
> of Integrity. APAR reasons for security are hidden and you are usually asked
> to apply them because of some 'vulnurability' which IBM usually declines to
> divulge. - should be enhanced to say "Give them a IBM's Statement Of
> Integrity as well as the Statement of Integrity for every other OEM software
> product you have installed as well as every in-house written application you
> have installed." While such a Statement does not 100% guarantee that no
> exposure exits; it does give the guarantee that if an exposure is found it
> will be corrected just as soon as possible. Any vendor that does not have
> such a Statement on file that they can readily supply indicates that they
> haven't given this subject much thought.
>
> Russell Witt
> CA 1 Support Manager
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
> Of Greg Dorner
> Sent: Tuesday, March 27, 2012 10:07 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Malicious Software Protection
>
> Dear IBM-MAINers,
>
> Our auditors are insisting that we install a product that protects against
> malicious software (viruses, worms, trojans, etc.).
>
> Does anyone know of a product that does this? I heard that McAfee is coming
> out with a z/OS product "later this year", but I called them and they had no
> idea what I was talking about.
>
> z/OS, with proper security controls (and believe me - we have LOTS!) should
> not have to worry about such things, at least that's what I've always heard.
>
> Any input on this topic would be GREATLY appreciated!!
>
> Thanks,
> Greg Dorner, WPS Insurance Corp.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: A z/OS Redbook Corrected - just about!

2012-03-27 Thread Alan Altmark

On Mon, 26 Mar 2012 22:34:01 -0400, J R  wrote:

>I agree, why not zUnix?  Or z/Unix?

While I enjoy the "USS Naming Wars" immensely (NOT), this particular question 
gets old, and I thought the answer would be obvious:  You cannot take other 
peoples' trademarks and alter them or use them without permission.

UNIX is a registered trademark of the Open Group.  While it is convenient to 
call something UNIX System Services, it doesn't really stand by itself.  The OS 
in question is not UNIX, but it is the UNIX-branded part of z/OS.  It SHOULD 
have the word z/OS in it.  I mean, perhaps the listener thinks you mean LINUX!

Someone else mentioned POSIX, a registered trademark of the IEEE.  They, 
working with the Open Group, will grant permission to use the POSIX mark "to 
certify that [...] computer operating systems comply with standards of 
interoperability and portability based upon the UNIX operating system."  

Back in 2002, IBM cancelled its OpenEdition trademark (I vaguely remember 
reading in the media about some dispute with some other company.)  In z/VM, it 
is called Open Extensions.

Sure, some the names IBM comes up with are strange, to say the least, but they 
are not just random strings of characters.   That is, there's a method to the 
madness, to be certain, but it's our particular *brand* of madness!  :-)

Alan Altmark
IBM

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

Re: Malicious Software Protection

2012-03-27 Thread Russell Witt

Greg,

Others have given you more information than you probably wanted, but I am
going to add one more. To the list of 11 items that Elardus supplied earlier
in the day, I would add one more. His number 10 - Give them IBM's Statement
of Integrity. APAR reasons for security are hidden and you are usually asked
to apply them because of some 'vulnurability' which IBM usually declines to
divulge. - should be enhanced to say "Give them a IBM's Statement Of
Integrity as well as the Statement of Integrity for every other OEM software
product you have installed as well as every in-house written application you
have installed." While such a Statement does not 100% guarantee that no
exposure exits; it does give the guarantee that if an exposure is found it
will be corrected just as soon as possible. Any vendor that does not have
such a Statement on file that they can readily supply indicates that they
haven't given this subject much thought.

Russell Witt
CA 1 Support Manager

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Greg Dorner
Sent: Tuesday, March 27, 2012 10:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Malicious Software Protection

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects against
malicious software (viruses, worms, trojans, etc.).

Does anyone know of a product that does this? I heard that McAfee is coming
out with a z/OS product "later this year", but I called them and they had no
idea what I was talking about.

z/OS, with proper security controls (and believe me - we have LOTS!) should
not have to worry about such things, at least that's what I've always heard.

Any input on this topic would be GREATLY appreciated!!

Thanks, 
Greg Dorner, WPS Insurance Corp.

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

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

Re: Malicious Software Protection

2012-03-27 Thread Ray Overby

There are many reasons for these types of defects. The programmer(s) in 
these cases to the best of my knowledge were actually very experienced 
z/OS developers. Very competent people. In my experience it is a matter 
of when not if these type of issues occur when you are responsible for 
developing and maintaining this type of code. It requires a constant 
vigilance to make sure these types of errors don't get out into the 
field. Even then it only takes a single "error" that could compromise 
the system integrity. It is a difficult job.




Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007


On 3/27/2012 19:30 PM, Gerhard Postpischil wrote:

On 3/27/2012 7:27 PM, Ray Overby wrote:

Like any SVC when invoked it will get control in an authorized
state (PSW Key 0). Further this SVC issues a STM instruction
very early in the SVC code storing into where ever R13 points
to. This type of defect is easily exploited writing a simple
program (could have been posted on the web) that would issue the
SVC and:


Defect is the correct description; your SVC sounds as though written 
by an incompetent programmer. User's registers are preserved in the RB 
(PRB, SVRB), where they are protected, rather than the save area. 
Off-hand I can't recall any SVC that needs R13 to point to a save 
area, rather there are cases where R13 is destroyed.


Gerhard Postpischil
Bradford, VT

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



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

Re: z/os every two years

Not official.  But plan on it.  Official releases in Sept of odd years.

On Tue, Mar 27, 2012 at 7:17 PM, Andy White  wrote:
> Does anyone know when IBM is going to make this official? It is official?
> I am putting together 2013 projects and we normally up to now did upgrades
> once a year.
>
> http://blogs.realdolmen.com/experts/2012/03/13/a-new-zos-release-every-2-year/
>
> Andy S. White

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

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

Re: Malicious Software Protection

2012-03-27 Thread Gerhard Postpischil


On 3/27/2012 7:27 PM, Ray Overby wrote:

Like any SVC when invoked it will get control in an authorized
state (PSW Key 0). Further this SVC issues a STM instruction
very early in the SVC code storing into where ever R13 points
to. This type of defect is easily exploited writing a simple
program (could have been posted on the web) that would issue the
SVC and:


Defect is the correct description; your SVC sounds as though 
written by an incompetent programmer. User's registers are 
preserved in the RB (PRB, SVRB), where they are protected, 
rather than the save area. Off-hand I can't recall any SVC that 
needs R13 to point to a save area, rather there are cases where 
R13 is destroyed.


Gerhard Postpischil
Bradford, VT

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

z/os every two years

2012-03-27 Thread Andy White

Does anyone know when IBM is going to make this official? It is official? 
I am putting together 2013 projects and we normally up to now did upgrades 
once a year.

http://blogs.realdolmen.com/experts/2012/03/13/a-new-zos-release-every-2-year/



Andy S. White

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

Re: Malicious Software Protection

2012-03-27 Thread Ray Overby

I am a vendor so take my post with a grain of salt. For those that don't 
like vendors to respond stop reading now.. (flame on)


In my opinion there are some misconceptions about the ability of an ESM 
product to mitigate integrity based vulnerabilities and why this should 
be a concern for you. In general, your ESM product will not be able to 
help you much when dealing with these types of vulnerabilities. I will 
try and explain by example based on several real world integrity 
vulnerabilities what I mean.


Lets say there is a SVC that when you IPL your z/OS system it is 
installed and available for use (i.e - any one can issue the SVC). The 
SVC either came with z/OS or your system programmers installed it 
because of an ISV product your company purchased or its an in-house 
written program. For this example lets assume one of your TSO users will 
attempt to exploit this vulnerability. The TSO user has no 
extra-ordinary security privileges.


Like any SVC when invoked it will get control in an authorized state 
(PSW Key 0). Further this SVC issues a STM instruction very early in the 
SVC code storing into where ever R13 points to. This type of defect is 
easily exploited writing a simple program (could have been posted on the 
web) that would issue the SVC and:


-Just before the SVC is issued point the unauthorized program's R13 
to some critical memory location. When the SVC code executes it will 
modify the storage pointed to by unauthorized program's R13. If the 
system does not crash right away then put it into a loop and reissue the 
svc with R13 pointing at different areas. Eventually you will crash the 
system.


-Just before the SVC is issued point the unauthorized program's R13 
to your security credentials, preload your registers with appropriate 
values, and have the SVC update your security credentials for you.


Note that it does not matter if the SVC "worked" or not. As long as the 
STM instruction was executed (it always was) then whatever went on later 
did not matter.


On a RACF system you could exploit this integrity vulnerability by 
dynamically elevating your security authority by enabling RACF 
privileged attribute for your ACEE. You would be able to do similar 
actions on a TSS or ACF2 protected system as well. According to IBM 
documentation RACF privileged users have access to any RACF protected 
resource without logging. Even if there are exceptions to this you could 
suppress WTO's and any SMF records as well (with a little more work). 
Once the TSO user has dynamically elevated their security authority they 
can then access whatever ESM protected resource they want. With no audit 
trail. Or you could modify your security credentials to be the high 
powered system's programmer or security officer and let the logging 
occur. This may get you through any system exits you have in place that 
check for those users.;-)


Based on these real world examples I was able to write that program:

-Dynamically elevated TSO users ESM security authority
-Access ESM protected resources the TSO user was not specifically 
authorized to by the installation

-Suppress any WTO's or SMF about the activity for the TSO user.

The ESM products did not stop the TSO user from exploiting this 
vulnerability. Nor did they provide any audit trail for accessing the 
protected resource the TSO user was not authorized for. No system data 
sets were updated. No APF authorized library were updated. The program 
does not require link edit with AC(1). In this case there was nothing 
the ESM's could do.


The places where this work was done had stringent security requirements, 
internal/external auditors, periodic security reviews, and were very 
diligent in implementing their computer security. Yet with the exploit 
of this vulnerabliit the TSO user bypassed all of the installations 
controls and left no audit trail for later analysis. With this program 
the TSO user was able to compromise all data on that system as well we 
the system itself. What if that data was secret government or military 
data, or was credit card or insurance company customer data? That would 
violate ever compliance standard there is!


Unfortunately, there are integrity based vulnerabilities similar to this 
that are on your z/OS system today. Your ESM controls will not help you 
if they are exploited. If you are not concerned that your users can 
crash your z/OS system at any time (maliciously or accidentally) OR your 
users can access any ESM protect resources regardless of installation 
controls with no logging or auditing then by all means ignore the issue. 
It does not mean it is not true.


Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007


On 3/27/2012 15:06 PM, Joel C. Ewing wrote:
Yes, it is true that if you could introduce a trojan into an APF 
library you could compromise z/OS, and that this might be possible:


If you don't have RACF or equiva

Re: Malicious Software Protection

Yes, and no.
Yes, any virus scanner provide some security (at least neutral, usually
positive).
No, because such virus cannot occur (pop up) on the mainframe, mainframe
cannot be infected (I think we agree with that). So, some other system
had to send it to mainframe previously; mainframe only forwarded it
further. DON'T KILL MESSENGER ;-)
So, the sending (to mainframe) system should be responsible for virus
scanning, otherwise ...mainframe is also not responsible ;-)

And, IHMO, sending data outside has no meaning here. All data should be
virus-free, otherwise we talk about toys, not serious business systems.
Does it mean that everything and everywhere should be virus-scanned? NO,
it would be senseless.

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-03-27 21:46, Thomas Kern pisze:

I must disagree with your second argument. If your mainframe does not provide
data to
anyone outside of your control, then okay. But if you deliver data to outsider,
the public
in particular, I feel you have a duty to make sure that the data you provide
does not
include a virus that might affect their system even if it cannot affect your
mainframe. A
mainframe webserver delivering windows viruses (virusi?) to the public does not
help our
reputations.

Even though we have an anti-virus program running on every workstation in our
agency, I
still do not trust all of the files these people upload to my mainframe (or
linux/x86)
server for distribution to outsiders. I want to scan all of these files ONE
MORE TIME
before making them available. I would prefer to do this on an x86 server than
spend
mainframe cycles.

Similar precautions should be applied to files received from the outside world.
No one
should get to them before they get scanned. All failures in the scan need to be
further
quarantined until a security (anti-virus) expert looks at the files.

/Thomas Kern
/on contract to
/U.S. Dept of Energy
/301-903-2211 (Office)
/301-905-6427 (Mobile)

On 3/27/2012 14:25, R.S. wrote:

W dniu 2012-03-27 17:06, Greg Dorner pisze:

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects against
malicious
software (viruses, worms, trojans, etc.).

Does anyone know of a product that does this? I heard that McAfee is coming out
with a
z/OS product "later this year", but I called them and they had no idea what I
was
talking about.

z/OS, with proper security controls (and believe me - we have LOTS!) should not
have to
worry about such things, at least that's what I've always heard.

Any input on this topic would be GREATLY appreciated!!

This is NOT mainframe problem.

Indeed, you have problem with uneducated auditors. Maybe stupid ones.
Your problem is how to prove that requirement is both stupid and impossible to
fulfill.

We can provide you some arguments, like
- there are no such products
- there are no viruses, trojans or other malware for z/OS and it have never
been last 47
years. (I said 'z/OS', so the only VM worm does not count)
- no mainframe installation use such product
- you have RACF *SECURITY SERVER* (or TS or ACF2)

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

Re: A z/OS Redbook Corrected - just about!

Well, I know a corporation where everyone use "Tivoli" to name one of 
Tivoli-branded product. To be more funny, they use much more Tivoli 
products.
I also met a guy who used 'Websphere' to call MQ. Ooops, I'm sorry: 
Websphere MQ.


While I can live with "IBM Tivoli Optim" products, but I'm still 
forgetting new names for PPRC, XRC, etc. And 3494 successor (3584, more 
commonly known as TS3500).


--
Radoslaw Skorupka
Lodz, Poland



W dniu 2012-03-27 23:00, Hylton Tom P pisze:

They ran out of W's so couldn't use Websphere anymore?



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Dick Bond
Sent: Tuesday, March 27, 2012 11:04 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: A z/OS Redbook Corrected - just about!

This could go another route and ask why every IBM product that is "old",
"new" or "purchased via OEM", seems to be given the Tivoli brand name?   ;-)

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




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

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


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


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

Re: Malicious Software Protection

2012-03-27 Thread Ray Overby

Every z/os system today has integrity vulnerabilities on it that if 
exploited would allow users with access to that system to crash that 
system or bypass installation controls and access any protected resource 
on that system regardless of the installed ESM. They would be able to do 
so with little to no audit trail.


What part of this is not a mainframe problem?

Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007


On 3/27/2012 13:25 PM, R.S. wrote:

W dniu 2012-03-27 17:06, Greg Dorner pisze:

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects 
against malicious software (viruses, worms, trojans, etc.).


Does anyone know of a product that does this? I heard that McAfee is 
coming out with a z/OS product "later this year", but I called them 
and they had no idea what I was talking about.


z/OS, with proper security controls (and believe me - we have LOTS!) 
should not have to worry about such things, at least that's what I've 
always heard.


Any input on this topic would be GREATLY appreciated!!


This is NOT mainframe problem.

Indeed, you have problem with uneducated auditors. Maybe stupid ones.
Your problem is how to prove that requirement is both stupid and 
impossible to fulfill.



We can provide you some arguments, like
- there are no such products
- there are no viruses, trojans or other malware for z/OS and it have 
never been last 47 years. (I said 'z/OS', so the only VM worm does not 
count)

- no mainframe installation use such product
- you have RACF *SECURITY SERVER* (or TS or ACF2)




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

Re: Malicious Software Protection

2012-03-27 Thread Killian, Gregory

There is an antivirus product for the mainframe which I have used in the
past. While it does not check the mainframe for viruses, per se, it does
scan mainframe email and filter viruses out. Check out:

http://www.thefreelibrary.com/Trend+Micro+First+to+Announce+Mainframe+Vi
rus+Protection%3B+Leading...-a020770290
http://www.trendmicro.com/us/boxes/lightboxes/20111202082421.html



Greg Killian @ work 
Washington State Department of Transportation
310 Maple Park Ave SE
P.O. Box 47427
Olympia, WA 98504-7427
360-705-7670 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of McKown, John
Sent: Tuesday, March 27, 2012 11:42 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Malicious Software Protection

True. For users which have RACF SPECIAL, a WTOR is written to the z/OS
console. Of course, in our shop, nobody monitors the z/OS consoles. And
the shop is totally "dark" on the weekends.

Naturally, I have a very weird way to do something about this. Which I
will not document or tell to anyone.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

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

Re: Malicious Software Protection

Hal,

Me too

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



On Mar 27, 2012, at 4:30 PM, Hal Merritt  wrote:

> Actually, Greg's point number 2 is spot on.  
> 
> Upon close inspection, they actually be asking for some change control / 
> management approval to protect sensitive load and source libraries. 
> 
> Over the years, I've found it helpful to not jump to conclusions when 
> presented with such. Rather, press for details, and keep pressing until you 
> get something understandable. Often as not, it turns out to be something 
> completely different. 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Elardus Engelbrecht
> Sent: Tuesday, March 27, 2012 11:30 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Malicious Software Protection
> 
> Greg Dorner wrote:
> 
>> Our auditors are insisting that we install a product that protects against 
>> malicious software (viruses, worms, trojans, etc.).
> 
> Groan, you can replace/fire those auditors as mentioned earlier in this 
> thread, but ... ;-D
> 
> You have several choices.
> 
> 1. Ask them to give reasons, examples and recommended vendors of such 
> software. 
> 
> 2. Ask them to define malicious software, despite your description above. 
> Seriously.
> 
> 3. For native z/OS, they will have a hard way to get any vendors at all which 
> can supply such software. Tell me if you can catch these vendors.
> 
> 4. Despite point 3, there are 'scanners' which can search z/OS on various 
> areas to look for 'holes'. They cost $$$ and is vendor specific. 
> 
> 5. Get 'penetration teams' or 'white hat hackers'. You have lots of $$$, do 
> you? :-)
> 
> 6. z/OS has very good security measures provided you have your controls in 
> place. APF, parmlib settings, RACF, SMF, etc. are examples. See other's 
> replies on this fact.
> 
> 7. Speaking of RACF, there are third party RACF [or other ESM] administration 
> and audit tools which could ease your work.
> 
> 8. Weakest links are usually 'insiders'. They are the greatest threats unless 
> I'm mistaken. They are usually after your 'live and sensitive production' 
> data.
> 
> 9. For z/Linux, USS, etc, there MAY be commercial or open-source antivirus 
> software available, AFAIK.
> (USS - Unix System Service(s) - for those TLA haters... :-D )
> 
> 10. Give them IBM's Statement of Integrity. APAR reasons for security are 
> hidden and you are usually asked to apply them because of some 
> 'vulnurability' which IBM usually declines to divulge.
> 
> 11. Ask those auditors if they have any tools to do the checks for such tools 
> against malicous software THEMSELVES! This will silence them properly!
> 
>> z/OS, with proper security controls (and believe me - we have LOTS!) should 
>> not have to worry about such things, at least that's what I've always heard.
> 
> Of course, but see above.
> 
>> Any input on this topic would be GREATLY appreciated!!
> 
> As Ted MacNeil insists, the auditors only RECOMMENDS, it is your management 
> who can APPLY those recommendations.
> 
> HTH!
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@bama.ua.edu with the message: INFO IBM-MAIN
> NOTICE: This electronic mail message and any files transmitted with it are 
> intended
> exclusively for the individual or entity to which it is addressed. The 
> message, 
> together with any attachment, may contain confidential and/or privileged 
> information.
> Any unauthorized review, use, printing, saving, copying, disclosure or 
> distribution 
> is strictly prohibited. If you have received this message in error, please 
> immediately advise the sender by reply email and delete all copies.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: z/OS ftp and Unicode

On Tue, 27 Mar 2012 15:43:18 -0500, Norbert Friemel wrote:
>
>UTF-8 is a variable-width encoding (1 to 4 Bytes/"octets" per character), it's 
>not a single byte character set. "sbdataconn" specifies single byte encoding.
>Use "site encoding=mbcs" and "site mbdataconn=(IBM-424,UTF-8)" to  specify 
>multibyte encoding.
>
Remote system type is MVS.
ftp> quote site encoding=mbcs
200 SITE command was accepted
ftp> quote site mbdataconn=(IBM-424,UTF-8)
200 SITE command was accepted
ftp> get TEST.TESTPRT(TESTPRT)
200 Port request OK.
504 Multi-byte encoding not supported for RECFM=FB
ftp>
ftp> quit

... putting us right back at the original problem reported
by the OP.

-- gil

>>
>>The Roman characters in the file as transferred with
>>sbdataconn=(IBM-1047,ISO8859-1) appear plausible.
>>
>
>IBM-1047 and ISO8859-1 are both single byte character sets.
>
>Norbert Friemel
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: A z/OS Redbook Corrected - just about!

2012-03-27 Thread Hylton Tom P

They ran out of W's so couldn't use Websphere anymore?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Dick Bond
Sent: Tuesday, March 27, 2012 11:04 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: A z/OS Redbook Corrected - just about!

This could go another route and ask why every IBM product that is "old",
"new" or "purchased via OEM", seems to be given the Tivoli brand name?   ;-)

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

Re: z/OS ftp and Unicode

2012-03-27 Thread Norbert Friemel

On Tue, 27 Mar 2012 13:03:14 -0500, Paul Gilmartin wrote:

>ftp> quote site sbdataconn=(IBM-424,UTF-8)
>200-Some characters cannot be translated between UTF-8 and IBM-424
>200 SITE command was accepted
>ftp> get TEST.TESTPRT(TESTPRT)
>local: TEST.TESTPRT(TESTPRT) remote: TEST.TESTPRT(TESTPRT)
>229 Entering Extended Passive Mode (|||25580|)
>125 Sending data set SPPG.TEST.TESTPRT(TESTPRT) FIXrecfm 80
> 00.00 KiB/s
>557 Data contains codepoints that cannot be translated
>ftp>
> ...
>
>WTF!?  Didn't Shmuel tell us that UTF-8 contains all of Unicode?
>(And all EBCDIC code points are defined in IBM-1047.)  I gotta try
>this on 1.13 and submit a PMR.  Or am I missing something?

UTF-8 is a variable-width encoding (1 to 4 Bytes/"octets" per character), it's 
not a single byte character set. "sbdataconn" specifies single byte encoding. 
Use "site encoding=mbcs" and "site mbdataconn=(IBM-424,UTF-8)" to  specify 
multibyte encoding.

>
>The Roman characters in the file as transferred with
>sbdataconn=(IBM-1047,ISO8859-1) appear plausible.
>

IBM-1047 and ISO8859-1 are both single byte character sets.

Norbert Friemel

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

Re: Malicious Software Protection

2012-03-27 Thread Hal Merritt

Actually, Greg's point number 2 is spot on.  

Upon close inspection, they actually be asking for some change control / 
management approval to protect sensitive load and source libraries. 

Over the years, I've found it helpful to not jump to conclusions when presented 
with such. Rather, press for details, and keep pressing until you get something 
understandable. Often as not, it turns out to be something completely 
different. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Elardus Engelbrecht
Sent: Tuesday, March 27, 2012 11:30 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Malicious Software Protection

Greg Dorner wrote:

>Our auditors are insisting that we install a product that protects against 
>malicious software (viruses, worms, trojans, etc.).

Groan, you can replace/fire those auditors as mentioned earlier in this 
thread, but ... ;-D

You have several choices.

1. Ask them to give reasons, examples and recommended vendors of such software. 

2. Ask them to define malicious software, despite your description above. 
Seriously.

3. For native z/OS, they will have a hard way to get any vendors at all which 
can supply such software. Tell me if you can catch these vendors.

4. Despite point 3, there are 'scanners' which can search z/OS on various areas 
to look for 'holes'. They cost $$$ and is vendor specific. 

5. Get 'penetration teams' or 'white hat hackers'. You have lots of $$$, do 
you? :-)

6. z/OS has very good security measures provided you have your controls in 
place. APF, parmlib settings, RACF, SMF, etc. are examples. See other's replies 
on this fact.

7. Speaking of RACF, there are third party RACF [or other ESM] administration 
and audit tools which could ease your work.

8. Weakest links are usually 'insiders'. They are the greatest threats unless 
I'm mistaken. They are usually after your 'live and sensitive production' data.

9. For z/Linux, USS, etc, there MAY be commercial or open-source antivirus 
software available, AFAIK.
(USS - Unix System Service(s) - for those TLA haters... :-D )

10. Give them IBM's Statement of Integrity. APAR reasons for security are 
hidden and you are usually asked to apply them because of some 'vulnurability' 
which IBM usually declines to divulge.

11. Ask those auditors if they have any tools to do the checks for such tools 
against malicous software THEMSELVES! This will silence them properly!

>z/OS, with proper security controls (and believe me - we have LOTS!) should 
>not have to worry about such things, at least that's what I've always heard.

Of course, but see above.

>Any input on this topic would be GREATLY appreciated!!

As Ted MacNeil insists, the auditors only RECOMMENDS, it is your management who 
can APPLY those recommendations.

HTH!

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

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

Re: Malicious Software Protection

2012-03-27 Thread Joel C. Ewing

Yes, it is true that if you could introduce a trojan into an APF library
you could compromise z/OS, and that this might be possible:

If you don't have RACF or equivalent properly configured to protect all
system data sets;
If you allow update authority to APF libraries or PARMLIB to people
other than those which require it for system-level maintenance;
If you install modules into APF libraries from any sources other than
trusted vendors;
If you add installation hooks deliberately designed to circumvent
security that might be exploited, or tolerate vendor products with such
exposures;
If you don't have some sort of change management, oversight, and
monitoring in place to catch violations of installation security policies.

In a very real sense RACF and system maintenance policies and the
mindset and training of z/OS SysProgs are the anti-virus software on
z/OS and this combination has worked quite well over the decades -- much
more reliably than even the best anti-virus software on MS platforms,
and no periodic database or detection program refresh ever required.

The concept of allowing average-Joe user to be able to download data
from arbitrary sources in arbitrary formats and being able from that to
somehow introduce executable code into the system in ways that will
execute with special privileges so as to introduce a virus or trojan is
an issue that is endemic to Windows platforms but foreign to z/OS.

Thus it makes excellent sense for auditors to examine and question
installation RACF conventions, access to critical system data sets, and
change management procedures. It makes zero sense to ask what is your
z/OS anti-virus software.

JC Ewing

On 03/27/2012 01:49 PM, David Cole wrote:

I'm sorry Tom. I did not intend my remarks to be personal. I deeply
regret that you feel hurt by them. Please don't let my words deter you
from future contributions. Your thoughts generally are more valuable
than most.

I just wanted to emphasize the APF Trojan horse vulnerability. It is
real, it is serious, yet for decades everyone seems to want to pretend
that it does not exist... It mystifies me.

...

www.zassure.com is the closest thing I've seen to an MVS anti-virus
program. After seeing a demo, I would have bought it, or recommended
it to a client. Check it out, you will be surprised, if not shocked.

Thank you for this. I will check it out.

[Regarding SAF] I do take issue with your last sentence. SAF and an
ESM have everything to do with anti-virus protection, provided they
are configured to correctly protect APF-authorized resources.

Perhaps. However, all an APF authorized program has to do is flip a bit
or two in certain RACF control blocks, and voilà! He's suddenly a
supervisory program and, as such, is given a pass on all RACF calls...
Alternatively, a malicious APF program can simply dynamically front-end
certain supervisory programs, and again voilà! (As I'm sure you know,
APF programs can fairly easily defeat all hardware storage protections.)

Yes, SAF is still called even for APF programs, but an APF program can
still subvert those calls.

I've never forgotten this [APF libraries]. That's why my
APF-authorized libraries are severely limited in scope, and audited
for any and all updates.

Enforcing trust is a technical issue. RACF is very good at that.
Deciding who to trust is a management issue. Even at shops that allow
only trusted vendor software into APF authorized libraries is implicitly
trusting the hundreds or even thousands of people involved in the
development of that software.

Again, I go into more detail about this in my prior post:
"https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches
".

Again, please accept my apology, Tom. It was not intended to be
personal. I'm sorry it came out that way.

Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658

At 3/27/2012 02:21 PM, Pinnacle wrote:

Replies like this are why I seldom post to IBM-Main anymore. The fact
that it comes from someone who I respect and consider a friend hurts
all the more. Bottom line is that I work for a living, and I often
don't have time to respond in gory detail to everything posted. My
primary objective here was to stress that the z/OS architecture is
inherently hardened against viruses. The fact that I did not go into
explicit protections for APF-authorized programs appears to have been
my fatal flaw, according to Mr. Cole. Regardless of what comes back,
this will be my last post on the subject. My comments below.

Regards,
Tom Conley

On 3/27/2012 1:06 PM, David Cole wrote:

At 3/27/2012 11:19 AM, Pinnacle wrote:

There is a mainf

Re: Malicious Software Protection

Mike, 

Interesting ...didn't know it existed..I knew about ibm's hod product...
Used it in several shops

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



On Mar 27, 2012, at 3:52 PM, Mike Schwab  wrote:

> Netscape came out with a 3270 compatible version (3.10) then they got
> rid of it (I assume due to pressure from IBM)
> http://jisemu.courts.state.md.us/Help.htm
> I think it came with a list of sites that users had provided.
> 
> On Tue, Mar 27, 2012 at 12:49 PM, Scott Ford  wrote:
>> Lets step through this logically:
>> 
>> TN3270 
>> 
>> 1. Must have RACF/ACF2/TSS  userid/lid/acid
>> 2. Must have a valid password
>> 3. Must have valid IP address
>> 4. Must have valid port
>> 5. Must have Firewall rule for #3 and #4 ...
>> 
>> Other issues:  How many firewalls ?  How is the network architected ?
>> 
>> This is just a favor ..FTP the same
>> 
>> Scott J Ford
>> Software Engineer
>> http://www.identityforge.com
> 
> -- 
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Malicious Software Protection

Netscape came out with a 3270 compatible version (3.10) then they got
rid of it (I assume due to pressure from IBM)
http://jisemu.courts.state.md.us/Help.htm
I think it came with a list of sites that users had provided.

On Tue, Mar 27, 2012 at 12:49 PM, Scott Ford  wrote:
> Lets step through this logically:
>
> TN3270 
>
> 1. Must have RACF/ACF2/TSS  userid/lid/acid
> 2. Must have a valid password
> 3. Must have valid IP address
> 4. Must have valid port
> 5. Must have Firewall rule for #3 and #4 ...
>
> Other issues:  How many firewalls ?  How is the network architected ?
>
> This is just a favor ..FTP the same
>
> Scott J Ford
> Software Engineer
> http://www.identityforge.com

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

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

Re: Malicious Software Protection

2012-03-27 Thread Thomas Kern

I must disagree with your second argument. If your mainframe does not provide 
data to
anyone outside of your control, then okay. But if you deliver data to outsider, 
the public
in particular, I feel you have a duty to make sure that the data you provide 
does not
include a virus that might affect their system even if it cannot affect your 
mainframe. A
mainframe webserver delivering windows viruses (virusi?) to the public does not 
help our
reputations.

Even though we have an anti-virus program running on every workstation in our 
agency, I
still do not trust all of the files these people upload to my mainframe (or 
linux/x86)
server for distribution to outsiders. I want to scan all of these files ONE 
MORE TIME
before making them available. I would prefer to do this on an x86 server than 
spend
mainframe cycles.

Similar precautions should be applied to files received from the outside world. 
No one
should get to them before they get scanned. All failures in the scan need to be 
further
quarantined until a security (anti-virus) expert looks at the files.

/Thomas Kern
/on contract to
/U.S. Dept of Energy
/301-903-2211 (Office)
/301-905-6427 (Mobile)

On 3/27/2012 14:25, R.S. wrote:
> W dniu 2012-03-27 17:06, Greg Dorner pisze:
>> Dear IBM-MAINers,
>>
>> Our auditors are insisting that we install a product that protects against 
>> malicious
>> software (viruses, worms, trojans, etc.).
>>
>> Does anyone know of a product that does this? I heard that McAfee is coming 
>> out with a
>> z/OS product "later this year", but I called them and they had no idea what 
>> I was
>> talking about.
>>
>> z/OS, with proper security controls (and believe me - we have LOTS!) should 
>> not have to
>> worry about such things, at least that's what I've always heard.
>>
>> Any input on this topic would be GREATLY appreciated!!
> 
> This is NOT mainframe problem.
> 
> Indeed, you have problem with uneducated auditors. Maybe stupid ones.
> Your problem is how to prove that requirement is both stupid and impossible 
> to fulfill.
> 
> 
> We can provide you some arguments, like
> - there are no such products
> - there are no viruses, trojans or other malware for z/OS and it have never 
> been last 47
> years. (I said 'z/OS', so the only VM worm does not count)
> - no mainframe installation use such product
> - you have RACF *SECURITY SERVER* (or TS or ACF2)
> 
> 

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

Re: Assembler - convrssion of Epoch (Unix) time to printable

http://en.wikipedia.org/wiki/Unix_time
0 is 1970 Jan 01 00:00:00 GMT or UTC (Starting point)
1 is 1970 Jan 01 00:00:01 GMT or UTC (1 second)
60 is 1970 Jan 01 00:01:00 GMT or UTC (1 minute)
3600 is 1970 Jan 01 01:00:00 GMT or UTC (1 hour)
86400 is 1970 Jan 02 00:00:00 GMT or UTC (1 day)
2678400 is 1970 Feb 01 00:00:00 GMT or UTC (31 days)
31536000 is 1971 Jan 01 00:00:00 GMT or UTC (365 days)
315532809 is 1980 Jan 01 00:00:00 GMT or UTC (i3650 days plus 2 leap
days plus 9 leap seconds http://en.wikipedia.org/wiki/Leap_second )

On Tue, Mar 27, 2012 at 1:28 PM, Charles Mills  wrote:
> So Gil, you are saying that a UNIX time of, for example, 60, represents 1:34
> am on 1/1/1970 -- or represents 0:26 am? (Theoretically -- there were no
> leap seconds before 1970.)
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
> Of Paul Gilmartin
> Sent: Tuesday, March 27, 2012 6:30 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Assembler - convrssion of Epoch (Unix) time to printable
>
> On Tue, 27 Mar 2012 07:47:39 -0500, McKown, John wrote:
>
>> ..., the UNIX epoch is simply a number. The number of seconds since
> 00:00:00 GMT 1 Jan 1970. It would be rather easy to convert to
> -mm-ddThh:mm:ss if it weren't for the "leap seconds". Which may or may
> not be of any interest to you.
>>
> Not really.  In effect, the origin of NTP shifts by one second every time a
> leap second occurs.  It is now 00:00:34 GMT 1 Jan 1970; in a little over 3
> months it will be 00:00:35 GMT 1 Jan 1970.
>
>    http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html
>
>    ... it is inappropriate to require that a time represented as seconds
>    since the Epoch precisely represent the number of seconds between
>    the referenced time and the Epoch.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Malicious Software Protection

2012-03-27 Thread Aled Hughes

I have to agree with Tony and many of the others, especially Radislaw's 
comments about auditors needing to be taught. One has to accept, of course, 
that many of them are MBAs (!) who work for the Big Auditors, but sadly have 
never even seen an IBM mainframe system. I first came across these 'specimens' 
back in the early 80s at a bank, who insited that our mainframes could be 
vulnerable. I tried to explain that without a password etc, they could not be. 
'Blue in the face' came to mind. 

I've just thought of something Greg - I'll hire myself as a 'Virus Guru' to 
come into your company and certify that you cannot be attacked. Should only 
take about six months. $2K a day alright? Would that satisfy them? :-)

All joking aside, it's sad that we have to put up with these uneducated 
'auditors' - we have enough to do! 

ALH

-Original Message-
From: Tony Harminc 
To: IBM-MAIN 
Sent: Tue, Mar 27, 2012 5:49 pm
Subject: Re: Malicious Software Protection

On 27 March 2012 11:06, Greg Dorner  wrote:
> Our auditors are insisting that we install a product that protects against 
alicious software (viruses, worms, trojans, etc.).
But have they asked you about the powerful and dangerous AMASPZAP yet?
hey aren't Real Auditors until they confront you about that.
> Does anyone know of a product that does this? I heard that McAfee is coming 
ut with a z/OS product "later this year", but I called them and they had no 
dea what I was talking about.
One approach is to play stupid the whole way.
Malicious software - what is that? Virus? Worm? Trojan? No, I am not
ware of any such thing. Could you please give an example of what you
re talking about? Ah - you suggest general protection against not yet
dentified threats? In your wide experience of auditing other
ompanies, what product(s) to do this have you found most commonly in
se on z/OS? What is the performance impact of these products? Could
ou direct me to some vendor-independent studies of their
rice/performance? Etc, etc.
Tony H.
--
or IBM-MAIN subscribe / signoff / archive access instructions,
end email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Malicious Software Protection

I see a much bigger issue, knowledge, once we old timers cash it in, like Walt 
was lucky enough to do, then who will 'carry the touch'the newer 'kids' 
don't want the responsibility or know how, just the cash, sorry not trying to 
mean or negative, I am second generation IT

Hopefully, schools like Steve and others will have an influx to train the 
youngsters..

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



On Mar 27, 2012, at 3:23 PM, Scott Ford  wrote:

> All,
> 
> I think we all agree that every system has vulnerabilities, where Windows, 
> Unix,VM, or Z/OS,
> the methods make it difficult for hackers to get into the systems, ,no 
> different than protecting a home from robbers. By using a big dog and a 12 
> gauge ..or electronic security system..many of us 
> firewalls,routers,RACF,acf2, TSS, pass-phrases, encryption to slow down the 
> intruder.
> 
> Sent from my iPad
> Scott Ford
> Senior Systems Engineer
> www.identityforge.com
> 
> 
> 
> On Mar 27, 2012, at 2:49 PM, David Cole  wrote:
> 
>> I'm sorry Tom. I did not intend my remarks to be personal. I deeply regret 
>> that you feel hurt by them. Please don't let my words deter you from future 
>> contributions. Your thoughts generally are more valuable than most.
>> 
>> I just wanted to emphasize the APF Trojan horse vulnerability. It is real, 
>> it is serious, yet for decades everyone seems to want to pretend that it 
>> does not exist... It mystifies me.
>> 
>> 
>> 
>> 
>> 
>> 
>>> www.zassure.com is the closest thing I've seen to an MVS anti-virus 
>>> program.  After seeing a demo, I would have bought it, or recommended it to 
>>> a client.  Check it out, you will be surprised, if not shocked.
>> 
>> Thank you for this. I will check it out.
>> 
>> 
>> 
>> 
>> 
>> 
>>> [Regarding SAF] I do take issue with your last sentence.  SAF and an ESM 
>>> have everything to do with anti-virus protection, provided they are 
>>> configured to correctly protect APF-authorized resources.
>> 
>> Perhaps. However, all an APF authorized program has to do is flip a bit or 
>> two in certain RACF control blocks, and voilà! He's suddenly a supervisory 
>> program and, as such, is given a pass on all RACF calls... Alternatively, a 
>> malicious APF program can simply dynamically front-end certain supervisory 
>> programs, and again voilà! (As I'm sure you know, APF programs can fairly 
>> easily defeat all hardware storage protections.)
>> 
>> Yes, SAF is still called even for APF programs, but an APF program can still 
>> subvert those calls.
>> 
>> 
>> 
>> 
>> 
>> 
>>> I've never forgotten this [APF libraries]. That's why my APF-authorized 
>>> libraries are severely limited in scope, and audited for any and all 
>>> updates.
>> 
>> Enforcing trust is a technical issue. RACF is very good at that. Deciding 
>> who to trust is a management issue. Even at shops that allow only trusted 
>> vendor software into APF authorized libraries is implicitly trusting the 
>> hundreds or even thousands of people involved in the development of that 
>> software.
>> 
>> Again, I go into more detail about this in my prior post: 
>> "https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches
>>  ".
>> 
>> 
>> 
>> 
>> 
>> 
>> Again, please accept my apology, Tom. It was not intended to be personal. 
>> I'm sorry it came out that way.
>> 
>> Dave Cole  REPLY TO: dbc...@colesoft.com
>> ColeSoft Marketing WEB PAGE: http://www.colesoft.com
>> 736 Fox Hollow RoadVOICE:540-456-8536
>> Afton, VA 22920FAX:  540-456-6658
>> 
>> 
>> 
>> 
>> 
>> 
>> At 3/27/2012 02:21 PM, Pinnacle wrote:
>>> Replies like this are why I seldom post to IBM-Main anymore.  The fact that 
>>> it comes from someone who I respect and consider a friend hurts all the 
>>> more.  Bottom line is that I work for a living, and I often don't have time 
>>> to respond in gory detail to everything posted.  My primary objective here 
>>> was to stress that the z/OS architecture is inherently hardened against 
>>> viruses.  The fact that I did not go into explicit protections for 
>>> APF-authorized programs appears to have been my fatal flaw, according to 
>>> Mr. Cole.  Regardless of what comes back, this will be my last post on the 
>>> subject.  My comments below.
>>> 
>>> Regards,
>>> Tom Conley
>>> 
>>> 
>>> 
>>> 
>>> On 3/27/2012 1:06 PM, David Cole wrote:
 At 3/27/2012 11:19 AM, Pinnacle wrote:
> There is a mainframe product that protects against malicious software. 
> It's called SAF, and it interfaces with ESM's like RACF, or ACF2, or 
> TopSecret.
 
 "SAF" is not a product. It stands for "System Access Facility" and it is 
 nothing more than an interface within z/OS into which a security syste

Re: Malicious Software Protection

All,

I think we all agree that every system has vulnerabilities, where Windows, 
Unix,VM, or Z/OS,
the methods make it difficult for hackers to get into the systems, ,no 
different than protecting a home from robbers. By using a big dog and a 12 
gauge ..or electronic security system..many of us firewalls,routers,RACF,acf2, 
TSS, pass-phrases, encryption to slow down the intruder.

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



On Mar 27, 2012, at 2:49 PM, David Cole  wrote:

> I'm sorry Tom. I did not intend my remarks to be personal. I deeply regret 
> that you feel hurt by them. Please don't let my words deter you from future 
> contributions. Your thoughts generally are more valuable than most.
> 
> I just wanted to emphasize the APF Trojan horse vulnerability. It is real, it 
> is serious, yet for decades everyone seems to want to pretend that it does 
> not exist... It mystifies me.
> 
> 
> 
> 
> 
> 
>> www.zassure.com is the closest thing I've seen to an MVS anti-virus program. 
>>  After seeing a demo, I would have bought it, or recommended it to a client. 
>>  Check it out, you will be surprised, if not shocked.
> 
> Thank you for this. I will check it out.
> 
> 
> 
> 
> 
> 
>> [Regarding SAF] I do take issue with your last sentence.  SAF and an ESM 
>> have everything to do with anti-virus protection, provided they are 
>> configured to correctly protect APF-authorized resources.
> 
> Perhaps. However, all an APF authorized program has to do is flip a bit or 
> two in certain RACF control blocks, and voilà! He's suddenly a supervisory 
> program and, as such, is given a pass on all RACF calls... Alternatively, a 
> malicious APF program can simply dynamically front-end certain supervisory 
> programs, and again voilà! (As I'm sure you know, APF programs can fairly 
> easily defeat all hardware storage protections.)
> 
> Yes, SAF is still called even for APF programs, but an APF program can still 
> subvert those calls.
> 
> 
> 
> 
> 
> 
>> I've never forgotten this [APF libraries]. That's why my APF-authorized 
>> libraries are severely limited in scope, and audited for any and all updates.
> 
> Enforcing trust is a technical issue. RACF is very good at that. Deciding who 
> to trust is a management issue. Even at shops that allow only trusted vendor 
> software into APF authorized libraries is implicitly trusting the hundreds or 
> even thousands of people involved in the development of that software.
> 
> Again, I go into more detail about this in my prior post: 
> "https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches
>  ".
> 
> 
> 
> 
> 
> 
> Again, please accept my apology, Tom. It was not intended to be personal. I'm 
> sorry it came out that way.
> 
> Dave Cole  REPLY TO: dbc...@colesoft.com
> ColeSoft Marketing WEB PAGE: http://www.colesoft.com
> 736 Fox Hollow RoadVOICE:540-456-8536
> Afton, VA 22920FAX:  540-456-6658
> 
> 
> 
> 
> 
> 
> At 3/27/2012 02:21 PM, Pinnacle wrote:
>> Replies like this are why I seldom post to IBM-Main anymore.  The fact that 
>> it comes from someone who I respect and consider a friend hurts all the 
>> more.  Bottom line is that I work for a living, and I often don't have time 
>> to respond in gory detail to everything posted.  My primary objective here 
>> was to stress that the z/OS architecture is inherently hardened against 
>> viruses.  The fact that I did not go into explicit protections for 
>> APF-authorized programs appears to have been my fatal flaw, according to Mr. 
>> Cole.  Regardless of what comes back, this will be my last post on the 
>> subject.  My comments below.
>> 
>> Regards,
>> Tom Conley
>> 
>> 
>> 
>> 
>> On 3/27/2012 1:06 PM, David Cole wrote:
>>> At 3/27/2012 11:19 AM, Pinnacle wrote:
 There is a mainframe product that protects against malicious software. 
 It's called SAF, and it interfaces with ESM's like RACF, or ACF2, or 
 TopSecret.
>>> 
>>> "SAF" is not a product. It stands for "System Access Facility" and it is 
>>> nothing more than an interface within z/OS into which a security system 
>>> (such as ACF2, TopSecret and any ryo security system) can plug into to 
>>> receive and respond to security calls. It really has nothing to do with 
>>> anti-virus protection.
>> 
>> SAF is not a product, you're right.  Please forgive my use of the term 
>> "product", I should have said "feature".  I do take issue with your last 
>> sentence.  SAF and an ESM have everything to do with anti-virus protection, 
>> provided they are configured to correctly protect APF-authorized resources.
>> 
 It [z/OS] is the only operating system out there with built-in anti-virus 
 protection. On top of that, the hardware itself actively pro

Re: Malicious Software Protection

2012-03-27 Thread David Cole

I'm sorry Tom. I did not intend my remarks to be
personal. I deeply regret that you feel hurt by
them. Please don't let my words deter you from
future contributions. Your thoughts generally are more valuable than most.

I just wanted to emphasize the APF Trojan horse
vulnerability. It is real, it is serious, yet for
decades everyone seems to want to pretend that it
does not exist... It mystifies me.

www.zassure.com is the closest thing I've seen
to an MVS anti-virus program. After seeing a
demo, I would have bought it, or recommended it
to a client. Check it out, you will be surprised, if not shocked.

Thank you for this. I will check it out.

[Regarding SAF] I do take issue with your last
sentence. SAF and an ESM have everything to do
with anti-virus protection, provided they are
configured to correctly protect APF-authorized resources.

Perhaps. However, all an APF authorized program
has to do is flip a bit or two in certain RACF
control blocks, and voilà! He's suddenly a
supervisory program and, as such, is given a pass
on all RACF calls... Alternatively, a malicious
APF program can simply dynamically front-end
certain supervisory programs, and again voilà!
(As I'm sure you know, APF programs can fairly
easily defeat all hardware storage protections.)

Yes, SAF is still called even for APF programs,
but an APF program can still subvert those calls.

I've never forgotten this [APF libraries].
That's why my APF-authorized libraries are
severely limited in scope, and audited for any and all updates.

Enforcing trust is a technical issue. RACF is
very good at that. Deciding who to trust is a
management issue. Even at shops that allow only
trusted vendor software into APF authorized
libraries is implicitly trusting the hundreds or
even thousands of people involved in the development of that software.

Again, I go into more detail about this in my
prior post:
"https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches
".

Again, please accept my apology, Tom. It was not
intended to be personal. I'm sorry it came out that way.

Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX: 540-456-6658

At 3/27/2012 02:21 PM, Pinnacle wrote:
Replies like this are why I seldom post to
IBM-Main anymore. The fact that it comes from
someone who I respect and consider a friend
hurts all the more. Bottom line is that I work
for a living, and I often don't have time to
respond in gory detail to everything posted. My
primary objective here was to stress that the
z/OS architecture is inherently hardened against
viruses. The fact that I did not go into
explicit protections for APF-authorized programs
appears to have been my fatal flaw, according to
Mr. Cole. Regardless of what comes back, this
will be my last post on the subject. My comments below.

Regards,
Tom Conley

On 3/27/2012 1:06 PM, David Cole wrote:

At 3/27/2012 11:19 AM, Pinnacle wrote:
There is a mainframe product that protects
against malicious software. It's called SAF,
and it interfaces with ESM's like RACF, or ACF2, or TopSecret.

SAF is not a product, you're right. Please
forgive my use of the term "product", I should
have said "feature". I do take issue with your
last sentence. SAF and an ESM have everything
to do with anti-virus protection, provided they
are configured to correctly protect APF-authorized resources.

It [z/OS] is the only operating system out
there with built-in anti-virus protection. On
top of that, the hardware itself actively
protects against damage through storage keys, protected memory, etc.
You have to explain to the auditors that
anti-virus software is not needed on z/OS,
because it's intrinsic to the operating system and the hardware.

I think you seriously misunderstand what a virus is...

Yes, z/OS has exceptional security (and
integrity and reliability) features for
protecting against non-authorized programs. But
I must emphasize... -->NON<--authorized programs!

When it comes to AUTHORIZED programs, z/OS's
integrity (which is what you are talking about
with "storage keys" and such) is very good, but
of course not bulletproof. Worse though, when
it comes to SECURITY, there are some real
problems! Because with the proper knowledge, it
is TRIVIALLY EA

Re: Malicious Software Protection

True. For users which have RACF SPECIAL, a WTOR is written to the z/OS console. 
Of course, in our shop, nobody monitors the z/OS consoles. And the shop is 
totally "dark" on the weekends.

Naturally, I have a very weird way to do something about this. Which I will not 
document or tell to anyone.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Skip Robinson
> Sent: Tuesday, March 27, 2012 12:38 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Malicious Software Protection
> 
> We're all pretty sanguine about our mainframe invulnerability. But we 
> should not overlook how one of our most valuable protections 
> can be turned 
> against us. We all have some limit set for logon attempts. If 
> an invalid 
> password is entered too many times, the userid gets 
> suspended--or referred 
> to the OS console for verification. A malicious rascal (any 
> other kind?) 
> can disable a really important userid in this way. Of course 
> the person 
> has to get into the network first and must know the userid to 
> target, but 
> beyond that no special authority is required. Even console 
> referral would 
> be disruptive to normal production. 
> 
> .
> .
> JO.Skip Robinson

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

Re: Malicious Software Protection

2012-03-27 Thread Ed Finnell

What is it, anonymous is threatening to shut down the Internet this Sat. by 
 doing DOS on all the major DNS nodes.
 
 
In a message dated 3/27/2012 1:32:45 P.M. Central Daylight Time,  
scott_j_f...@yahoo.com writes:

We had  to setup ftps etc, it wasn't easy and very very time consuming. If 
the want in  bad enough, yeah your right they can get in for sure, if I 
understand   your posting.



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

Re: Malicious Software Protection

RS,

You are correct a big part of this is the auditors being 
educated...understanding the installation FULLY and also management ppl who 
chartered them to do the work...

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



On Mar 27, 2012, at 2:25 PM, "R.S."  wrote:

> W dniu 2012-03-27 17:06, Greg Dorner pisze:
>> Dear IBM-MAINers,
>> 
>> Our auditors are insisting that we install a product that protects against 
>> malicious software (viruses, worms, trojans, etc.).
>> 
>> Does anyone know of a product that does this? I heard that McAfee is coming 
>> out with a z/OS product "later this year", but I called them and they had no 
>> idea what I was talking about.
>> 
>> z/OS, with proper security controls (and believe me - we have LOTS!) should 
>> not have to worry about such things, at least that's what I've always heard.
>> 
>> Any input on this topic would be GREATLY appreciated!!
> 
> This is NOT mainframe problem.
> 
> Indeed, you have problem with uneducated auditors. Maybe stupid ones.
> Your problem is how to prove that requirement is both stupid and impossible 
> to fulfill.
> 
> 
> We can provide you some arguments, like
> - there are no such products
> - there are no viruses, trojans or other malware for z/OS and it have never 
> been last 47 years. (I said 'z/OS', so the only VM worm does not count)
> - no mainframe installation use such product
> - you have RACF *SECURITY SERVER* (or TS or ACF2)
> 
> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> --
> Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
> przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by 
> jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste 
> adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej 
> przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, 
> rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie 
> zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, 
> prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale 
> usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub 
> zapisane na dysku.
> 
> This e-mail may contain legally privileged information of the Bank and is 
> intended solely for business use of the addressee. This e-mail may only be 
> received by the addressee and may not be disclosed to any third parties. If 
> you are not the intended addressee of this e-mail or the employee authorised 
> to forward it to the addressee, be advised that any dissemination, copying, 
> distribution or any other similar activity is legally prohibited and may be 
> punishable. If you received this e-mail by mistake please advise the sender 
> immediately by using the reply facility in your e-mail software and delete 
> permanently this e-mail including any copies of it either printed or saved to 
> hard drive. 
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
> +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
> Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
> Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
> Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci 
> wpacony) wynosi 168.410.984 zotych.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Malicious Software Protection

Skip,

I agree but spent a lot of time on Wall Street, I can tell you several of the 
brokerage houses had three plus firewalls between the mainframes and outside 
world. We had to setup ftps etc, it wasn't easy and very very time consuming. 
If the want in bad enough, yeah your right they can get in for sure, if I 
understand  your posting.

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



On Mar 27, 2012, at 2:09 PM, Skip Robinson  wrote:

> The reason I brought up this 'vulnerability' is that we hired a consultant 
> a while back to look for weaknesses. Of course they were able to logon 
> with a vanilla userid that had no special authority. And this is what they 
> did. 
> 
> We all spend a lot of time and mental energy focused on how to protect 
> ourselves from sophisticated attack. We look at APF. We look at SVC 
> screening. We look at access to sensitive libraries. But this particular 
> 'denial of service' can be accomplished by anyone with a valid userid and 
> password. And *only* because we lock up users for invalid password 
> attempts. I'm just sayin'... 
> 
> .
> .
> JO.Skip Robinson
> SCE Infrastructure Technology Services
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> 
> 
> From:   Scott Ford 
> To: IBM-MAIN@bama.ua.edu
> Date:   03/27/2012 10:51 AM
> Subject:Re: Malicious Software Protection
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> Lets step through this logically:
> 
> TN3270 
> 
> 1. Must have RACF/ACF2/TSS  userid/lid/acid
> 2. Must have a valid password
> 3. Must have valid IP address
> 4. Must have valid port
> 5. Must have Firewall rule for #3 and #4 ...
> 
> Other issues:  How many firewalls ?  How is the network architected ?
> 
> This is just a favor ..FTP the same
> 
> Scott J Ford
> Software Engineer
> http://www.identityforge.com
> 
> 
> 
> 
> From: Skip Robinson 
> To: IBM-MAIN@bama.ua.edu 
> Sent: Tuesday, March 27, 2012 1:37 PM
> Subject: Re: Malicious Software Protection
> 
> We're all pretty sanguine about our mainframe invulnerability. But we 
> should not overlook how one of our most valuable protections can be turned 
> 
> against us. We all have some limit set for logon attempts. If an invalid 
> password is entered too many times, the userid gets suspended--or referred 
> 
> to the OS console for verification. A malicious rascal (any other kind?) 
> can disable a really important userid in this way. Of course the person 
> has to get into the network first and must know the userid to target, but 
> beyond that no special authority is required. Even console referral would 
> be disruptive to normal production. 
> 
> .
> .
> JO.Skip Robinson
> SCE Infrastructure Technology Services
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> 
> 
> From:   Steve Comstock 
> To:IBM-MAIN@bama.ua.edu
> Date:   03/27/2012 10:22 AM
> Subject:Re: Malicious Software Protection
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> On 3/27/2012 10:46 AM, Greg Dorner wrote:
>> Thank you, Elardus for your verbosity.
>> 
>> 
>> - you can replace/fire those auditors as mentioned earlier in this 
> thread
>> 
>> - As Ted MacNeil insists, the auditors only RECOMMENDS, it is your
>> management
> who can APPLY those recommendations.
>> 
>> Unfortunately, we have no say with these auditors. They are working on
>> behalf
> of the Feds, and if we don't comply we can lose billions of $$ in federal 
> contracts.
>> 
>> The beauty of this is, someone from my company contacted the person at 
> PWC
> that made this claim that MCAFEE is coming out with a product, and he
> backtracked, saying he may have been thinking of Mac OS. MAC OS???
>> 
>> They just took a big chuck of our company offline for several hours to
> research this phantom.
> 
> Wow. And did they reprimand this doofus in any way? Slap on
> the wrist? Letter in his personnel file?
> 
> More likely he got commended for being concerned about company
> security, even though he had no idea what he was talking about.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

GSE UK - Enterprise Security Working Group Meeting

2012-03-27 Thread Mark Wilson

>
>Email sent on behalf of Jamie Pease
>
>
>Hi Folks, 
>
>I'm pleased to announce that the next meeting of the GSE Enterprise
>Security Working Group will take place on Wednesday 27th June.
>
>Full details including the agenda can be found at
>http://www.racf.gse.org.uk/future.html
>
>If you wish to attend the meeting please send me an email and I will add
>you to the list. 
>
>Regards 
>
>_
>
>Jamie Pease CISA, CISM, CISSP, MBCS CITP
>IT Specialist, System z Security
>IBM Software Group
>
>Mobile: +44-7809-551709 (Mobex 37268263)
>e-mail:   jamie_pe...@uk.ibm.com
>_
>
>Chairman of the GSE (UK) Enterprise Security Working Group
>http://www.racf.gse.org.uk/
>
>
>
>
>
>
>Regards,
>
>_
>Mark Wilson 
>Technical Director
>
>RSM Partners Ltd
>z Specialists, Software & Support
>
>Mobile +44 (0)7768 617006
>
>Offices: The Courtyard, Buntsford Drive,
>Stoke Pound, Bromsgrove B60 3DJ
>Tel: 0870 0501004 Fax: 0870 0501006
>
>Email: ma...@rsmpartners.com
>Web:  www.rsmpartners.com
>
>GSE Information
>Large Systems Working Group Chairman
>www.lsx.gse.org.uk
>
>GSE UK Conference Manager  
>www.gse.org.uk/tyc
>


__

This message was delivered by EPA Hosted Exchange and has been certified 
virus-free.
For more information please visit http://www.epacloud.com/exchange 
__

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

Re: Assembler - convrssion of Epoch (Unix) time to printable

So Gil, you are saying that a UNIX time of, for example, 60, represents 1:34
am on 1/1/1970 -- or represents 0:26 am? (Theoretically -- there were no
leap seconds before 1970.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Tuesday, March 27, 2012 6:30 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Assembler - convrssion of Epoch (Unix) time to printable

On Tue, 27 Mar 2012 07:47:39 -0500, McKown, John wrote:

> ..., the UNIX epoch is simply a number. The number of seconds since
00:00:00 GMT 1 Jan 1970. It would be rather easy to convert to
-mm-ddThh:mm:ss if it weren't for the "leap seconds". Which may or may
not be of any interest to you.
>
Not really.  In effect, the origin of NTP shifts by one second every time a
leap second occurs.  It is now 00:00:34 GMT 1 Jan 1970; in a little over 3
months it will be 00:00:35 GMT 1 Jan 1970.

http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html

... it is inappropriate to require that a time represented as seconds
since the Epoch precisely represent the number of seconds between
the referenced time and the Epoch.

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

Re: Malicious Software Protection

W dniu 2012-03-27 17:06, Greg Dorner pisze:

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects against
malicious software (viruses, worms, trojans, etc.).

Does anyone know of a product that does this? I heard that McAfee is coming out with a
z/OS product "later this year", but I called them and they had no idea what I
was talking about.

z/OS, with proper security controls (and believe me - we have LOTS!) should not
have to worry about such things, at least that's what I've always heard.

Any input on this topic would be GREATLY appreciated!!

This is NOT mainframe problem.

Indeed, you have problem with uneducated auditors. Maybe stupid ones.
Your problem is how to prove that requirement is both stupid and
impossible to fulfill.

- no mainframe installation use such product
- you have RACF *SECURITY SERVER* (or TS or ACF2)

--
Radoslaw Skorupka
Lodz, Poland

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

Re: FRBACKUP Still Not Working...

2012-03-27 Thread George Rodriguez

Hi Lizette,

The fact that the message is repeated over and over again doesn't bother
me. The fact that one of my volumes PPRD46 can't be paired with a copy pool
volume bothers me.

One more thing I'm on z/OS V1R11 not V1R13 and I turn on and off the patch
by sending a command to DFSMShsm, I don't have it my ARCCMD00 member.

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



On Tue, Mar 27, 2012 at 2:13 PM, Lizette Koehler wrote:

> >
> >Since I now know that the problem is NOT hardware related, I've tried
> >everything to figure out what the problem is. I've installed the patch
> that
> >helps in problem determination (PATCH .FRGCB.+9 BITS(.1..)) and what I
> >get follows:
> >
> >ARC1809I VOLUME CP00AA IS NOT A FAST REPLICATION CANDIDATE FOR L0 VOLUME
> >PPRD46, VER=0012, RC=0002
> >
> >and the RC=0002 says:
> >
> >volser1 is already paired with another source volume
> >
> >but when I did the FlashCopy query against the target volume CP00AA it
> says
> >that there's no other relationships on the target volume.
> >
> >ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0
> >
> >   FLASHCPY QUERY DDNAME(FCVOL)
> >ICK00700I DEVICE INFORMATION FOR 81DE IS CURRENTLY AS FOLLOWS:
> >  PHYSICAL DEVICE = 3390
> >  STORAGE CONTROLLER = 2107
> >  STORAGE CONTROL DESCRIPTOR = E8
> >  DEVICE DESCRIPTOR = 0A
> >  ADDITIONAL DEVICE INFORMATION = 483C
> >  TRKS/CYL = 15, # PRIMARY CYLS = 3339
> >ICK04000I DEVICE IS IN SIMPLEX STATE
> >ICK03091I EXISTING VOLUME SERIAL READ = CP00AA
> >
> >FLASHCOPY VOLUME CAPABILITY INFORMATION TABLE
> >  MAXIMUM  MAXIMUM
> > *EXISTING* ALLOWED  RELATIONS
> > *RELATIONS*RELATIONSEXCEEDED CAPABILITY
> > *-*----
> > *0*  50099 NO SRC CAP
> >ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0
> > TGT CAP
> >
> >I even ran it against the source volume:
> >
> >ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0
> >
> >   FLASHCPY QUERY DDNAME(FCVOL)
> >ICK00700I DEVICE INFORMATION FOR 833B IS CURRENTLY AS FOLLOWS:
> >  PHYSICAL DEVICE = 3390
> >  STORAGE CONTROLLER = 2107
> >  STORAGE CONTROL DESCRIPTOR = E8
> >  DEVICE DESCRIPTOR = 0A
> >  ADDITIONAL DEVICE INFORMATION = 483C
> >  TRKS/CYL = 15, # PRIMARY CYLS = 3339
> >ICK04000I DEVICE IS IN SIMPLEX STATE
> >ICK03091I EXISTING VOLUME SERIAL READ = PPRD46
> >
> >FLASHCOPY VOLUME CAPABILITY INFORMATION TABLE
> >  MAXIMUM  MAXIMUM
> > *EXISTING* ALLOWED  RELATIONS
> > *RELATIONS*RELATIONSEXCEEDED CAPABILITY
> > -----
> > *0*  50099 NO SRC CAP
> >ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0
> > TGT CAP
> >
> >Any help is appreciated!
> >*
> >*
>
>
> George,
>
> Have you checked out (I always search the internet for messages you post)
> the REDBOOK  z/OS Version 1 Release 13 Implementation
>
> It has the following section:
>
> 6.21 Fast replication ARC1809I messages
>
> Fast replication backup processing issues excessive ARC1809I messages when
> reporting
> the reason why a target volume cannot be paired to a source volume.
> The ARC1809I RC2 message indicates that a source and target cannot be
> paired because
> the target volume has already been matched with a different source. For a
> single FRBACKUP
> command, the ARC1809I RC2 can be issued many times for each target volume.
>
> In previous releases, a patch command can be used to turn off all ARC1809I
> messages. In
> z/OS V1R13 a new SETSYS command called FASTREPLICATION will replace the
> existing
> patch to enable or disable the redundant ARC1809I messages.
> This enhancement will decrease the number of ARC1809I RC2 messages such
> that the
> message will be issued no more than once per target volume for each
> storage group in the
> copy pool.
>
> If you currently have PATCH .FRGCB.+9 BITS(.1..) in your ARCCMDxx
> parmlib member,
> you should replace the patch with the desired command as follows:
> SETSYS FASTREPLICATION(VOLUMEPAIRMESSAGES(YES|NO))
> YES YES indicates that the ARC1809I RC2 messages should be issued when a
> target
> volume cannot be paired with a source volume.
> NO NO indicates that the ARC1809I RC2 messages should not be issued.
>
>
>
> You might want to see if the ARC1809I is reasonable or not.
>
>
> Lizette
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send ema

Re: Assembler - convrssion of Epoch (Unix) time to printable

Right, probably the slickest solution is to figure out how to set up LE and
call mktime() or gmtime() and then strftime(). See the C library manual for
details. People here can help you with setting up an LE environment and
calling a C routine.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of McKown, John
Sent: Tuesday, March 27, 2012 5:48 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Assembler - convrssion of Epoch (Unix) time to printable

Cheat? I'm a big fan of cheating. I often use LE enabled HLASM just so that
I can use the subroutines from the C language to do "fancy" printing by
using sprintf() calls. Of course, you could also cheat by converting the C
epoch to a Lilian date (simple addition) and using the LE subroutine CEEDATE
to convert it to printable form. But, then, the UNIX epoch is simply a
number. The number of seconds since 00:00:00 GMT 1 Jan 1970. It would be
rather easy to convert to -mm-ddThh:mm:ss if it weren't for the "leap
seconds". Which may or may not be of any interest to you.

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

Re: Malicious Software Protection

2012-03-27 Thread Pinnacle

Replies like this are why I seldom post to IBM-Main anymore.  The fact 
that it comes from someone who I respect and consider a friend hurts all 
the more.  Bottom line is that I work for a living, and I often don't 
have time to respond in gory detail to everything posted.  My primary 
objective here was to stress that the z/OS architecture is inherently 
hardened against viruses.  The fact that I did not go into explicit 
protections for APF-authorized programs appears to have been my fatal 
flaw, according to Mr. Cole.  Regardless of what comes back, this will 
be my last post on the subject.  My comments below.


Regards,
Tom Conley

On 3/27/2012 1:06 PM, David Cole wrote:

At 3/27/2012 11:19 AM, Pinnacle wrote:
There is a mainframe product that protects against malicious 
software. It's called SAF, and it interfaces with ESM's like RACF, or 
ACF2, or TopSecret.


"SAF" is not a product. It stands for "System Access Facility" and it 
is nothing more than an interface within z/OS into which a security 
system (such as ACF2, TopSecret and any ryo security system) can plug 
into to receive and respond to security calls. It really has nothing 
to do with anti-virus protection.




SAF is not a product, you're right.  Please forgive my use of the term 
"product", I should have said "feature".  I do take issue with your last 
sentence.  SAF and an ESM have everything to do with anti-virus 
protection, provided they are configured to correctly protect 
APF-authorized resources.


It [z/OS] is the only operating system out there with built-in 
anti-virus protection. On top of that, the hardware itself actively 
protects against damage through storage keys, protected memory, etc.
You have to explain to the auditors that anti-virus software is not 
needed on z/OS, because it's intrinsic to the operating system and 
the hardware.


I think you seriously misunderstand what a virus is...

Yes, z/OS has exceptional security (and integrity and reliability) 
features for protecting against non-authorized programs. But I must 
emphasize... -->NON<--authorized programs!


When it comes to AUTHORIZED programs, z/OS's integrity (which is what 
you are talking about with "storage keys" and such) is very good, but 
of course not bulletproof. Worse though, when it comes to SECURITY, 
there are some real problems! Because with the proper knowledge, it is 
TRIVIALLY EASY FOR AN AUTHORIZED PROGRAM TO SUBVERT SECURITY COMPLETELY!


This is what mainframers constantly forget regarding security. For 
authorized programs there is no security. All that is necessary for a 
malicious program to do is to Trojan-horse its way (with the AC(1) 
attribute) into an authorized library, and you're done for!


I've never forgotten this.  That's why my APF-authorized libraries are 
severely limited in scope, and audited for any and all updates.




As far as I know there is no serious anti-virus program for 
mainframes. I believe strongly that there needs to be one, but I don't 
know of one. And at this stage of the mainframe culture, I would be 
seriously suspicious of the efficacy of any program that claimed to be 
anti-virus. I don't think that a serious mainframe anti-virus program 
can exist unless and until IBM itself makes a commitment to support an 
effort to make the mainframe anti-virus proof.





www.zassure.com is the closest thing I've seen to an MVS anti-virus 
program.  After seeing a demo, I would have bought it, or recommended it 
to a client.  Check it out, you will be surprised, if not shocked.


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

Re: Leaving IBM

I don't usually respond to these things -- but you have been a big help over
the years. Thank you. You will be missed. Best wishes to you also.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Walt Farrell
Sent: Monday, March 26, 2012 6:53 AM
To: IBM-MAIN@bama.ua.edu
Subject: Leaving IBM

I mentioned this over on RACF-L the other day, so for some of you this will
be old news. 

I've been an IBMer for 28 years and have had a lot of fun with RACF and MVS,

and I've had a lot of fun interacting with you folks on RACF-L and IBM-MAIN.

But the time has come for me to retire and have fun with other things. I've
enjoyed the discussions here, and working with many of you to plan
enhancements or resolve problems.  I'm sure I'll still read both lists for
awhile, and probably even participate from a personal email address. 

But after Wednesday morning I will no longer be an active IBM employee and
I'll speak about z/OS and RACF even less officially than than I do now.

It's been a great 28 years, but my family and other activities are calling
to me more and more strongly, and it's time to spend more time with them.

Best wishes to you all,
Walt

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

Re: Assembler - convrssion of Epoch (Unix) time to printable

Leap seconds pretty much have to be of interest to you or you will be off by
twenty seconds plus, probably too much to ignore. But they are not a big
deal (spoken as one who recently had to solve this problem). They are
available (assuming they have been input, and if not, then obviously all
bets are off) in a CVT extension. They are stored in hardware clock units
(of course we store a two-digit integral number of seconds as a 64-bit
fraction!) but converting hardware clock units to seconds is not a big deal.
(Shift right twelve and divide by a million as I recall.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Tuesday, March 27, 2012 6:30 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Assembler - convrssion of Epoch (Unix) time to printable

On Tue, 27 Mar 2012 07:47:39 -0500, McKown, John wrote:

> ..., the UNIX epoch is simply a number. The number of seconds since
00:00:00 GMT 1 Jan 1970. It would be rather easy to convert to
-mm-ddThh:mm:ss if it weren't for the "leap seconds". Which may or may
not be of any interest to you.
>

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

Re: Malicious Software Protection

On Tue, 27 Mar 2012 11:09:23 -0700, Skip Robinson wrote:

>The reason I brought up this 'vulnerability' is that we hired a consultant
>a while back to look for weaknesses. Of course they were able to logon
>with a vanilla userid that had no special authority. And this is what they
>did.
>
>We all spend a lot of time and mental energy focused on how to protect
>ourselves from sophisticated attack. We look at APF. We look at SVC
>screening. We look at access to sensitive libraries. But this particular
>'denial of service' can be accomplished by anyone with a valid userid and
>password. And *only* because we lock up users for invalid password
>attempts. I'm just sayin'...
> 
Would you and the auditors feel better if users logged on without
typing passwords, via SSH with certificates stored on their desktops?

Does SSH/SSL lock accounts on detected intrusion?

There is an SSL flavor of tn3270, isn't there?  And that would
encrypt even LAN traffic.

-- gil

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

Re: FRBACKUP Still Not Working...

2012-03-27 Thread Lizette Koehler

>
>Since I now know that the problem is NOT hardware related, I've tried
>everything to figure out what the problem is. I've installed the patch that
>helps in problem determination (PATCH .FRGCB.+9 BITS(.1..)) and what I
>get follows:
>
>ARC1809I VOLUME CP00AA IS NOT A FAST REPLICATION CANDIDATE FOR L0 VOLUME
>PPRD46, VER=0012, RC=0002
>
>and the RC=0002 says:
>
>volser1 is already paired with another source volume
>
>but when I did the FlashCopy query against the target volume CP00AA it says
>that there's no other relationships on the target volume.
>
>ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0
>
>   FLASHCPY QUERY DDNAME(FCVOL)
>ICK00700I DEVICE INFORMATION FOR 81DE IS CURRENTLY AS FOLLOWS:
>  PHYSICAL DEVICE = 3390
>  STORAGE CONTROLLER = 2107
>  STORAGE CONTROL DESCRIPTOR = E8
>  DEVICE DESCRIPTOR = 0A
>  ADDITIONAL DEVICE INFORMATION = 483C
>  TRKS/CYL = 15, # PRIMARY CYLS = 3339
>ICK04000I DEVICE IS IN SIMPLEX STATE
>ICK03091I EXISTING VOLUME SERIAL READ = CP00AA
>
>FLASHCOPY VOLUME CAPABILITY INFORMATION TABLE
>  MAXIMUM  MAXIMUM
> *EXISTING* ALLOWED  RELATIONS
> *RELATIONS*RELATIONSEXCEEDED CAPABILITY
> *-*----
> *0*  50099 NO SRC CAP
>ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0
> TGT CAP
>
>I even ran it against the source volume:
>
>ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0
>
>   FLASHCPY QUERY DDNAME(FCVOL)
>ICK00700I DEVICE INFORMATION FOR 833B IS CURRENTLY AS FOLLOWS:
>  PHYSICAL DEVICE = 3390
>  STORAGE CONTROLLER = 2107
>  STORAGE CONTROL DESCRIPTOR = E8
>  DEVICE DESCRIPTOR = 0A
>  ADDITIONAL DEVICE INFORMATION = 483C
>  TRKS/CYL = 15, # PRIMARY CYLS = 3339
>ICK04000I DEVICE IS IN SIMPLEX STATE
>ICK03091I EXISTING VOLUME SERIAL READ = PPRD46
>
>FLASHCOPY VOLUME CAPABILITY INFORMATION TABLE
>  MAXIMUM  MAXIMUM
> *EXISTING* ALLOWED  RELATIONS
> *RELATIONS*RELATIONSEXCEEDED CAPABILITY
> -----
> *0*  50099 NO SRC CAP
>ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0
> TGT CAP
>
>Any help is appreciated!
>*
>*


George,

Have you checked out (I always search the internet for messages you post) the 
REDBOOK  z/OS Version 1 Release 13 Implementation

It has the following section:

6.21 Fast replication ARC1809I messages

Fast replication backup processing issues excessive ARC1809I messages when 
reporting
the reason why a target volume cannot be paired to a source volume.
The ARC1809I RC2 message indicates that a source and target cannot be paired 
because
the target volume has already been matched with a different source. For a 
single FRBACKUP
command, the ARC1809I RC2 can be issued many times for each target volume.

In previous releases, a patch command can be used to turn off all ARC1809I 
messages. In
z/OS V1R13 a new SETSYS command called FASTREPLICATION will replace the existing
patch to enable or disable the redundant ARC1809I messages.
This enhancement will decrease the number of ARC1809I RC2 messages such that the
message will be issued no more than once per target volume for each storage 
group in the
copy pool.

If you currently have PATCH .FRGCB.+9 BITS(.1..) in your ARCCMDxx parmlib 
member,
you should replace the patch with the desired command as follows:
SETSYS FASTREPLICATION(VOLUMEPAIRMESSAGES(YES|NO))
YES YES indicates that the ARC1809I RC2 messages should be issued when a target
volume cannot be paired with a source volume.
NO NO indicates that the ARC1809I RC2 messages should not be issued.



You might want to see if the ARC1809I is reasonable or not.


Lizette

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

Re: Malicious Software Protection

2012-03-27 Thread Skip Robinson

The reason I brought up this 'vulnerability' is that we hired a consultant 
a while back to look for weaknesses. Of course they were able to logon 
with a vanilla userid that had no special authority. And this is what they 
did. 

We all spend a lot of time and mental energy focused on how to protect 
ourselves from sophisticated attack. We look at APF. We look at SVC 
screening. We look at access to sensitive libraries. But this particular 
'denial of service' can be accomplished by anyone with a valid userid and 
password. And *only* because we lock up users for invalid password 
attempts. I'm just sayin'... 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

From:   Scott Ford 
To: IBM-MAIN@bama.ua.edu
Date:   03/27/2012 10:51 AM
Subject:Re: Malicious Software Protection
Sent by:IBM Mainframe Discussion List 

Lets step through this logically:

TN3270 

1. Must have RACF/ACF2/TSS  userid/lid/acid
2. Must have a valid password
3. Must have valid IP address
4. Must have valid port
5. Must have Firewall rule for #3 and #4 ...

Other issues:  How many firewalls ?  How is the network architected ?

This is just a favor ..FTP the same

Scott J Ford
Software Engineer
http://www.identityforge.com

 From: Skip Robinson 
To: IBM-MAIN@bama.ua.edu 
Sent: Tuesday, March 27, 2012 1:37 PM
Subject: Re: Malicious Software Protection

We're all pretty sanguine about our mainframe invulnerability. But we 
should not overlook how one of our most valuable protections can be turned 

against us. We all have some limit set for logon attempts. If an invalid 
password is entered too many times, the userid gets suspended--or referred 

to the OS console for verification. A malicious rascal (any other kind?) 
can disable a really important userid in this way. Of course the person 
has to get into the network first and must know the userid to target, but 
beyond that no special authority is required. Even console referral would 
be disruptive to normal production. 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

From:   Steve Comstock 
To:IBM-MAIN@bama.ua.edu
Date:   03/27/2012 10:22 AM
Subject:Re: Malicious Software Protection
Sent by:IBM Mainframe Discussion List 

On 3/27/2012 10:46 AM, Greg Dorner wrote:
> Thank you, Elardus for your verbosity.
>
>
> - you can replace/fire those auditors as mentioned earlier in this 
thread
>
> - As Ted MacNeil insists, the auditors only RECOMMENDS, it is your
> management
who can APPLY those recommendations.
>
> Unfortunately, we have no say with these auditors. They are working on
> behalf
of the Feds, and if we don't comply we can lose billions of $$ in federal 
contracts.
>
> The beauty of this is, someone from my company contacted the person at 
PWC
that made this claim that MCAFEE is coming out with a product, and he
backtracked, saying he may have been thinking of Mac OS. MAC OS???
>
> They just took a big chuck of our company offline for several hours to
research this phantom.

Wow. And did they reprimand this doofus in any way? Slap on
the wrist? Letter in his personnel file?

More likely he got commended for being concerned about company
security, even though he had no idea what he was talking about.

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

Re: z/OS ftp and Unicode

On Tue, 27 Mar 2012 11:25:43 +0200, גדי בן 
אבי   wrote:

>The file http://gadib.tripod.com/images/ibm-424.xmit is a xmitted PDS 
>containing one member.
>The text is in IBM-424.
>The text in the line below new code is in Hebrew. IT should start with x'41'.
>
Thanks.  After some munging, I get:

220-FTPD1 IBM FTP CS V1R12 at mvs, 17:42:18 on 2012-03-27.
...
Remote system type is MVS.
ftp> 
ftp> 
ftp> quote site sbdataconn=(IBM-424,UTF-8)
200-Some characters cannot be translated between UTF-8 and IBM-424
200 SITE command was accepted
ftp> get TEST.TESTPRT(TESTPRT)
local: TEST.TESTPRT(TESTPRT) remote: TEST.TESTPRT(TESTPRT)
229 Entering Extended Passive Mode (|||25580|)
125 Sending data set SPPG.TEST.TESTPRT(TESTPRT) FIXrecfm 80
 00.00 KiB/s 
557 Data contains codepoints that cannot be translated
ftp> 
ftp> 
ftp> quote site sbdataconn=(IBM-1047,UTF-8)
200-Some characters cannot be translated between UTF-8 and IBM-1047
200 SITE command was accepted
ftp> get TEST.TESTPRT(TESTPRT) test2
local: test2 remote: TEST.TESTPRT(TESTPRT)
229 Entering Extended Passive Mode (|||25582|)
125 Sending data set SPPG.TEST.TESTPRT(TESTPRT) FIXrecfm 80
 00.00 KiB/s 
557 Data contains codepoints that cannot be translated
ftp> 
ftp> quote site sbdataconn=(IBM-1047,ISO8859-1)
200 SITE command was accepted
ftp> get TEST.TESTPRT(TESTPRT) test3
local: test3 remote: TEST.TESTPRT(TESTPRT)
229 Entering Extended Passive Mode (|||25584|)
125 Sending data set SPPG.TEST.TESTPRT(TESTPRT) FIXrecfm 80
   756   18.75 KiB/s 
250 Transfer completed successfully.
756 bytes received in 00:00 (7.21 KiB/s)
ftp> 
ftp> quit

WTF!?  Didn't Shmuel tell us that UTF-8 contains all of Unicode?
(And all EBCDIC code points are defined in IBM-1047.)  I gotta try
this on 1.13 and submit a PMR.  Or am I missing something?

The Roman characters in the file as transferred with
sbdataconn=(IBM-1047,ISO8859-1) appear plausible.

Perhaps I should resubscribe to IBMTCP-L.

-- gil

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

Re: Malicious Software Protection

Sorry should be flavor

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



On Mar 27, 2012, at 1:49 PM, Scott Ford  wrote:

> Lets step through this logically:
>  
> TN3270 
>  
> 1. Must have RACF/ACF2/TSS  userid/lid/acid
> 2. Must have a valid password
> 3. Must have valid IP address
> 4. Must have valid port
> 5. Must have Firewall rule for #3 and #4 ...
>  
> Other issues:  How many firewalls ?  How is the network architected ?
>  
> This is just a favor ..FTP the same
> 
> Scott J Ford
> Software Engineer
> http://www.identityforge.com
>  
> 
> 
> 
> From: Skip Robinson 
> To: IBM-MAIN@bama.ua.edu 
> Sent: Tuesday, March 27, 2012 1:37 PM
> Subject: Re: Malicious Software Protection
> 
> We're all pretty sanguine about our mainframe invulnerability. But we 
> should not overlook how one of our most valuable protections can be turned 
> against us. We all have some limit set for logon attempts. If an invalid 
> password is entered too many times, the userid gets suspended--or referred 
> to the OS console for verification. A malicious rascal (any other kind?) 
> can disable a really important userid in this way. Of course the person 
> has to get into the network first and must know the userid to target, but 
> beyond that no special authority is required. Even console referral would 
> be disruptive to normal production. 
> 
> .
> .
> JO.Skip Robinson
> SCE Infrastructure Technology Services
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> 
> 
> From:   Steve Comstock 
> To:IBM-MAIN@bama.ua.edu
> Date:   03/27/2012 10:22 AM
> Subject:Re: Malicious Software Protection
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> On 3/27/2012 10:46 AM, Greg Dorner wrote:
>> Thank you, Elardus for your verbosity.
>> 
>> 
>> - you can replace/fire those auditors as mentioned earlier in this 
> thread
>> 
>> - As Ted MacNeil insists, the auditors only RECOMMENDS, it is your
>> management
> who can APPLY those recommendations.
>> 
>> Unfortunately, we have no say with these auditors. They are working on
>> behalf
> of the Feds, and if we don't comply we can lose billions of $$ in federal 
> contracts.
>> 
>> The beauty of this is, someone from my company contacted the person at 
> PWC
> that made this claim that MCAFEE is coming out with a product, and he
> backtracked, saying he may have been thinking of Mac OS. MAC OS???
>> 
>> They just took a big chuck of our company offline for several hours to
> research this phantom.
> 
> Wow. And did they reprimand this doofus in any way? Slap on
> the wrist? Letter in his personnel file?
> 
> More likely he got commended for being concerned about company
> security, even though he had no idea what he was talking about.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Malicious Software Protection

Lets step through this logically:

TN3270 

1. Must have RACF/ACF2/TSS  userid/lid/acid
2. Must have a valid password
3. Must have valid IP address
4. Must have valid port
5. Must have Firewall rule for #3 and #4 ...

Other issues:  How many firewalls ?  How is the network architected ?

This is just a favor ..FTP the same

Scott J Ford
Software Engineer
http://www.identityforge.com

 From: Skip Robinson 
To: IBM-MAIN@bama.ua.edu 
Sent: Tuesday, March 27, 2012 1:37 PM
Subject: Re: Malicious Software Protection

We're all pretty sanguine about our mainframe invulnerability. But we 
should not overlook how one of our most valuable protections can be turned 
against us. We all have some limit set for logon attempts. If an invalid 
password is entered too many times, the userid gets suspended--or referred 
to the OS console for verification. A malicious rascal (any other kind?) 
can disable a really important userid in this way. Of course the person 
has to get into the network first and must know the userid to target, but 
beyond that no special authority is required. Even console referral would 
be disruptive to normal production. 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

From:   Steve Comstock 
To:    IBM-MAIN@bama.ua.edu
Date:   03/27/2012 10:22 AM
Subject:        Re: Malicious Software Protection
Sent by:        IBM Mainframe Discussion List 

On 3/27/2012 10:46 AM, Greg Dorner wrote:
> Thank you, Elardus for your verbosity.
>
>
> - you can replace/fire those auditors as mentioned earlier in this 
thread
>
> - As Ted MacNeil insists, the auditors only RECOMMENDS, it is your
> management
who can APPLY those recommendations.
>
> Unfortunately, we have no say with these auditors. They are working on
> behalf
of the Feds, and if we don't comply we can lose billions of $$ in federal 
contracts.
>
> The beauty of this is, someone from my company contacted the person at 
PWC
that made this claim that MCAFEE is coming out with a product, and he
backtracked, saying he may have been thinking of Mac OS. MAC OS???
>
> They just took a big chuck of our company offline for several hours to
research this phantom.

Wow. And did they reprimand this doofus in any way? Slap on
the wrist? Letter in his personnel file?

More likely he got commended for being concerned about company
security, even though he had no idea what he was talking about.

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

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

Re: Malicious Software Protection

2012-03-27 Thread Skip Robinson

We're all pretty sanguine about our mainframe invulnerability. But we 
should not overlook how one of our most valuable protections can be turned 
against us. We all have some limit set for logon attempts. If an invalid 
password is entered too many times, the userid gets suspended--or referred 
to the OS console for verification. A malicious rascal (any other kind?) 
can disable a really important userid in this way. Of course the person 
has to get into the network first and must know the userid to target, but 
beyond that no special authority is required. Even console referral would 
be disruptive to normal production. 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

From:   Steve Comstock 
To: IBM-MAIN@bama.ua.edu
Date:   03/27/2012 10:22 AM
Subject:Re: Malicious Software Protection
Sent by:IBM Mainframe Discussion List 

On 3/27/2012 10:46 AM, Greg Dorner wrote:
> Thank you, Elardus for your verbosity.
>
>
> - you can replace/fire those auditors as mentioned earlier in this 
thread
>
> - As Ted MacNeil insists, the auditors only RECOMMENDS, it is your
> management
who can APPLY those recommendations.
>
> Unfortunately, we have no say with these auditors. They are working on
> behalf
of the Feds, and if we don't comply we can lose billions of $$ in federal 
contracts.
>
> The beauty of this is, someone from my company contacted the person at 
PWC
that made this claim that MCAFEE is coming out with a product, and he
backtracked, saying he may have been thinking of Mac OS. MAC OS???
>
> They just took a big chuck of our company offline for several hours to
research this phantom.

Wow. And did they reprimand this doofus in any way? Slap on
the wrist? Letter in his personnel file?

More likely he got commended for being concerned about company
security, even though he had no idea what he was talking about.

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

Re: Malicious Software Protection

2012-03-27 Thread Lloyd Fuller

And, if someone builds an anti-virus program for z/OS, please tell me before 
you 
announce it publicly.  I know some out-source companies I would like to buy 
stock in because MIPS are going way up.

Lloyd

- Original Message 
From: David Cole 
To: IBM-MAIN@bama.ua.edu
Sent: Tue, March 27, 2012 1:01:34 PM
Subject: Re: Malicious Software Protection

At 3/27/2012 11:19 AM, Pinnacle wrote:
> There is a mainframe product that protects against malicious software. It's 
>called SAF, and it interfaces with ESM's like RACF, or ACF2, or TopSecret.

"SAF" is not a product. It stands for "System Access Facility" and it is 
nothing 
more than an interface within z/OS into which a security system (such as ACF2, 
TopSecret and any ryo security system) can plug into to receive and respond to 
security calls. It really has nothing to do with anti-virus protection. For 
more 
information, see 
"http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsecurity/zsecc_030.htm
 "

> It [z/OS] is the only operating system out there with built-in anti-virus 
>protection. On top of that, the hardware itself actively protects against 
>damage 
>through storage keys, protected memory, etc.
> You have to explain to the auditors that anti-virus software is not needed on 
>z/OS, because it's intrinsic to the operating system and the hardware.

I think you seriously misunderstand what a virus is...

Yes, z/OS has exceptional security (and integrity and reliability) features for 
protecting against non-authorized programs. But I must emphasize... 
-->NON<--authorized programs!

When it comes to AUTHORIZED programs, z/OS's integrity (which is what you are 
talking about with "storage keys" and such) is very good, but of course not 
bulletproof. Worse though, when it comes to SECURITY, there are some real 
problems! Because with the proper knowledge, it is TRIVIALLY EASY FOR AN 
AUTHORIZED PROGRAM TO SUBVERT SECURITY COMPLETELY!

This is what mainframers constantly forget regarding security. For authorized 
programs there is no security. All that is necessary for a malicious program to 
do is to Trojan-horse its way (with the AC(1) attribute) into an authorized 
library, and you're done for!

This is something I've brought up on this listserv from time to time before. In 
particular, for more information, please read a prior post of mine at 
"https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches
 ".

And please... stop confusing security with integrity. They are not the same. 
The 
"hardware protections" that so many people mention are not security 
protections, 
they are integrity protections. They help to keep careless programs from 
accidentally breaking things. When it comes to authorized programs, these 
"hardware protections" offer no protection at all!

As far as I know there is no serious anti-virus program for mainframes. I 
believe strongly that there needs to be one, but I don't know of one. And at 
this stage of the mainframe culture, I would be seriously suspicious of the 
efficacy of any program that claimed to be anti-virus. I don't think that a 
serious mainframe anti-virus program can exist unless and until IBM itself 
makes 
a commitment to support an effort to make the mainframe anti-virus proof.

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

FRBACKUP Still Not Working...

2012-03-27 Thread George Rodriguez

Since I now know that the problem is NOT hardware related, I've tried
everything to figure out what the problem is. I've installed the patch that
helps in problem determination (PATCH .FRGCB.+9 BITS(.1..)) and what I
get follows:

ARC1809I VOLUME CP00AA IS NOT A FAST REPLICATION CANDIDATE FOR L0 VOLUME
PPRD46, VER=0012, RC=0002

and the RC=0002 says:

volser1 is already paired with another source volume

but when I did the FlashCopy query against the target volume CP00AA it says
that there's no other relationships on the target volume.

ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0

   FLASHCPY QUERY DDNAME(FCVOL)
ICK00700I DEVICE INFORMATION FOR 81DE IS CURRENTLY AS FOLLOWS:
  PHYSICAL DEVICE = 3390
  STORAGE CONTROLLER = 2107
  STORAGE CONTROL DESCRIPTOR = E8
  DEVICE DESCRIPTOR = 0A
  ADDITIONAL DEVICE INFORMATION = 483C
  TRKS/CYL = 15, # PRIMARY CYLS = 3339
ICK04000I DEVICE IS IN SIMPLEX STATE
ICK03091I EXISTING VOLUME SERIAL READ = CP00AA

FLASHCOPY VOLUME CAPABILITY INFORMATION TABLE
  MAXIMUM  MAXIMUM
 *EXISTING* ALLOWED  RELATIONS
 *RELATIONS*RELATIONSEXCEEDED CAPABILITY
 *-*----
 *0*  50099 NO SRC CAP
ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0
 TGT CAP

I even ran it against the source volume:

ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0

   FLASHCPY QUERY DDNAME(FCVOL)
ICK00700I DEVICE INFORMATION FOR 833B IS CURRENTLY AS FOLLOWS:
  PHYSICAL DEVICE = 3390
  STORAGE CONTROLLER = 2107
  STORAGE CONTROL DESCRIPTOR = E8
  DEVICE DESCRIPTOR = 0A
  ADDITIONAL DEVICE INFORMATION = 483C
  TRKS/CYL = 15, # PRIMARY CYLS = 3339
ICK04000I DEVICE IS IN SIMPLEX STATE
ICK03091I EXISTING VOLUME SERIAL READ = PPRD46

FLASHCOPY VOLUME CAPABILITY INFORMATION TABLE
  MAXIMUM  MAXIMUM
 *EXISTING* ALLOWED  RELATIONS
 *RELATIONS*RELATIONSEXCEEDED CAPABILITY
 -----
 *0*  50099 NO SRC CAP
ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0
 TGT CAP

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

Home of Florida's first LEED Gold Certified School

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

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

Re: LE enclave calls another LE enclave

2012-03-27 Thread Binyamin Dissen

Ran across that at a client. I believe that the PL/I manuals document that an
LE enabled program cannot call a PL/I MAIN.

On Tue, 27 Mar 2012 18:16:06 +0200 Bernd Oppolzer 
wrote:

:>Hello all,
:>
:>we have a problem that is not easy to describe. Let me try it.
:>
:>We are building a test supporting system, which allows to do tests of 
:>software
:>components. The system consists of the following modules or parts:
:>
:>A - driver, written in ASSEMBLER. The driver builds a LE enclave, so 
:>that it
:>can call C subfunctions and the test objects, which are (normally) PL/1 
:>routines
:>
:>B - driver supporting routine, written in C. This routine provides 
:>services OPEN,
:>WRITE and CLOSE. It is called by the driver. On OPEN, it fetches a 
:>testcase list
:>from the testcase database and builds a linked list in memory (in the LE 
:>heap).
:>It also opens a log file for writing. On WRITE, it writes some protocol data
:>on the log file. On CLOSE, it closes the log file.
:>
:>C - driver exit, written in ASSEMBLER. It is called at the beginning of 
:>the test object
:>(at the entry point) by means of TRAP2 interrupts. It has access to the 
:>testcase list
:>element that B took from the testcase database for the current testcase. 
:>It then calls
:>D, passing the address of the testcase list element. D reads the 
:>testcase data,
:>builds a parameter list for the testcase, and returns a parameter list. 
:>Then the
:>driver exits resumes the test object at the position of the entry point 
:>(this way
:>the test data is passed to the test object).
:>
:>D - is a C routine which reads the data from the testcase data base and 
:>builds the
:>parameter list for the test object - because this is much easier to do 
:>in C than in
:>ASSEMBLER.
:>
:>Now the problem:
:>
:>all works well, if the test object is a PL/1 subroutine and not a main 
:>program. Then
:>the LE enclave built by A is used by B, passed to the test object, and 
:>used by D as well.
:>There is no problem passing the LE environment through the TRAP2 interrupt.
:>
:>But:
:>
:>we also want to be able to test PL/1 main programs this way. The PL/1 
:>main programs
:>are called by the driver the same way as the modules are called, but 
:>because they are
:>started at CEESTART, a second LE enclave below the first enclave is 
:>built. Then C and
:>D run below the second enclave. This is no problem so far, because there 
:>is no need
:>to share ressources between the two enclaves; the only information 
:>exchange is through
:>the testcase list element which belongs to the heap of the first 
:>enclave, and this is no problem,
:>in our opinion.
:>
:>But:
:>
:>when we return from the test object and we try to execute the WRITE call 
:>to B in the
:>first enclave, it fails in the prologue of B.
:>
:>We first thought that reg 12 had not be restored correctly, but this is 
:>not the case.
:>Reg 12 is the same as before the call of the PL/1 main, points to the 
:>original CEECAA.
:>Also, the save area (including NAB etc, the words behind offsets 72) are 
:>unchanged.
:>But still, we get abends 0C4 etc. in the prologue of B. But only in the 
:>PL/1 main case,
:>if there is a second enclave, not in the other case.
:>
:>We fixed this problem by doing the WRITE and CLOSE calls not in the same 
:>(first)
:>enclave as the OPEN call, but instead we did all the subsequent calls by 
:>an intermediate
:>PL/1 main, that is: after the PL/1 test object main destroyed somehow 
:>our first enclave,
:>we didn't use it any more, but instead constructed new enclaves for 
:>every subsequent
:>call at the same level. But this doesn't look very sound to me.
:>
:>My question is: has somebody out there an idea, what has happened here 
:>and what
:>might be a solution to our problem? Is it possible to have one LE 
:>enclave call another
:>and on return from the second still have the first one usable? What are 
:>we getting wrong?
:>
:>Kind regards
:>
:>Bernd
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Malicious Software Protection

2012-03-27 Thread Steve Comstock


On 3/27/2012 10:46 AM, Greg Dorner wrote:

Thank you, Elardus for your verbosity.


- you can replace/fire those auditors as mentioned earlier in this thread

- As Ted MacNeil insists, the auditors only RECOMMENDS, it is your
management

who can APPLY those recommendations.


Unfortunately, we have no say with these auditors. They are working on
behalf

of the Feds, and if we don't comply we can lose billions of $$ in federal 
contracts.


The beauty of this is, someone from my company contacted the person at PWC

that made this claim that MCAFEE is coming out with a product, and he
backtracked, saying he may have been thinking of Mac OS. MAC OS???


They just took a big chuck of our company offline for several hours to

research this phantom.

Wow. And did they reprimand this doofus in any way? Slap on
the wrist? Letter in his personnel file?

More likely he got commended for being concerned about company
security, even though he had no idea what he was talking about.




Thank you all for your input!



--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

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

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

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

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

Re: Malicious Software Protection

2012-03-27 Thread retired mainframer

Since you have one of the security products installed and heavily
configured, why not identify that as your protection tool.  Maybe even
demonstrate that controls prevent unauthorized updates to system and APF
datasets and the IPL text.  Given z/OS's statement of integrity, if the
malicious software cannot execute privileged it can't do any real damage.

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
:>: Behalf Of Greg Dorner
:>: Sent: Tuesday, March 27, 2012 8:07 AM
:>: To: IBM-MAIN@bama.ua.edu
:>: Subject: Malicious Software Protection
:>:
:>: Dear IBM-MAINers,
:>:
:>: Our auditors are insisting that we install a product that protects
:>: against malicious software (viruses, worms, trojans, etc.).
:>:
:>: Does anyone know of a product that does this? I heard that McAfee is
:>: coming out with a z/OS product "later this year", but I called them and
:>: they had no idea what I was talking about.
:>:
:>: z/OS, with proper security controls (and believe me - we have LOTS!)
:>: should not have to worry about such things, at least that's what I've
:>: always heard.
:>:
:>: Any input on this topic would be GREATLY appreciated!!
:>:
:>: Thanks,
:>: Greg Dorner, WPS Insurance Corp.
:>:
:>: --
:>: For IBM-MAIN subscribe / signoff / archive access instructions,
:>: send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Malicious Software Protection

2012-03-27 Thread David Cole

At 3/27/2012 11:19 AM, Pinnacle wrote:
There is a mainframe product that protects against malicious
software. It's called SAF, and it interfaces with ESM's like RACF,
or ACF2, or TopSecret.

"SAF" is not a product. It stands for "System Access Facility" and it
is nothing more than an interface within z/OS into which a security
system (such as ACF2, TopSecret and any ryo security system) can plug
into to receive and respond to security calls. It really has nothing
to do with anti-virus protection. For more information, see
"http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsecurity/zsecc_030.htm
"

It [z/OS] is the only operating system out there with built-in
anti-virus protection. On top of that, the hardware itself actively
protects against damage through storage keys, protected memory, etc.
You have to explain to the auditors that anti-virus software is not
needed on z/OS, because it's intrinsic to the operating system and
the hardware.

I think you seriously misunderstand what a virus is...

Yes, z/OS has exceptional security (and integrity and reliability)
features for protecting against non-authorized programs. But I must
emphasize... -->NON<--authorized programs!

When it comes to AUTHORIZED programs, z/OS's integrity (which is what
you are talking about with "storage keys" and such) is very good, but
of course not bulletproof. Worse though, when it comes to SECURITY,
there are some real problems! Because with the proper knowledge, it
is TRIVIALLY EASY FOR AN AUTHORIZED PROGRAM TO SUBVERT SECURITY COMPLETELY!

This is what mainframers constantly forget regarding security. For
authorized programs there is no security. All that is necessary for a
malicious program to do is to Trojan-horse its way (with the AC(1)
attribute) into an authorized library, and you're done for!

This is something I've brought up on this listserv from time to time
before. In particular, for more information, please read a prior post
of mine at
"https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches
".

And please... stop confusing security with integrity. They are not
the same. The "hardware protections" that so many people mention are
not security protections, they are integrity protections. They help
to keep careless programs from accidentally breaking things. When it
comes to authorized programs, these "hardware protections" offer no
protection at all!

As far as I know there is no serious anti-virus program for
mainframes. I believe strongly that there needs to be one, but I
don't know of one. And at this stage of the mainframe culture, I
would be seriously suspicious of the efficacy of any program that
claimed to be anti-virus. I don't think that a serious mainframe
anti-virus program can exist unless and until IBM itself makes a
commitment to support an effort to make the mainframe anti-virus proof.

Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX: 540-456-6658

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

SMPTLIB receive issue

2012-03-27 Thread Tim Brown

Cant seem to receive new functions, error IKJ56228I DATA SET IBM.HABIA10.F1 NOT 
IN CATALOG OR CATALOG CAN NOT BE ACCESSED



IBM is a valid prefix, it's a result of the RFDSNPFX in the function source



My global opt is coded with DSPREFIX of 'SMPE" and SMPTLIB is set to



DSPREFIX ===> CPAC11

 (Data set prefix name, max 26 chars)

UNIT ===> 3390 Unit type

VOLUME   ===> Z11INS   __   __   __   __





++FUNCTION(HABIA10) FESN(0500045) REWORK(2011128)

  DESC(IBM InfoSphere Classic Federation Server for z/OS)

  RFDSNPFX(IBM) /* TIME=16:02:34 DATE= 5/08/11 */ FILES(9)



Thanks,



Tim Brown
Systems Specialist - Project Leader
Central Hudson Gas & Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbr...@cenhud.com <>
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255




This message contains confidential information and is only for the intended 
recipient. If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, please notify the sender immediately by replying to this note and 
deleting all copies and attachments.






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

Re: RES: z/OS 1.11 DFSORT ICE046A

2012-03-27 Thread Frank Yaeger

Ituriel do Nascimento Neto at IBM Mainframe Discussion List
 wrote on 03/27/2012 08:13:45 AM:
> If we SORT datasets in dasd, then IGNWKDD is perfect.
> But what happens when SORTIN is a TAPE dataset and tape management
software
> is not RMM ?
>
> What is the best approach, is it necessary to specify USEWKDD ?

Other tape management products (e.g. CA-1) can supply an ICETPEX exit that
will pass the filesize to DFSORT (similar to what RMM does).

Are you saying that your tape management product does NOT supply an ICETPEX
exit?

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

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

Re: Malicious Software Protection

Greg,

Gil's points were excellent also as well as the other folks talking about 
RACF..etc...


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



On Mar 27, 2012, at 12:46 PM, Greg Dorner  wrote:

> Thank you, Elardus for your verbosity. 
> 
> 
> - you can replace/fire those auditors as mentioned earlier in this thread
> 
> - As Ted MacNeil insists, the auditors only RECOMMENDS, it is your management 
> who can APPLY those recommendations.
> 
> Unfortunately, we have no say with these auditors. They are working on behalf 
> of the Feds, and if we don't comply we can lose billions of $$ in federal 
> contracts. 
> 
> The beauty of this is, someone from my company contacted the person at PWC 
> that made this claim that MCAFEE is coming out with a product, and he 
> backtracked, saying he may have been thinking of Mac OS. MAC OS??? 
> 
> They just took a big chuck of our company offline for several hours to 
> research this phantom.
> 
> Thank you all for your input! 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Malicious Software Protection

2012-03-27 Thread Tony Harminc

On 27 March 2012 11:06, Greg Dorner  wrote:

> Our auditors are insisting that we install a product that protects against 
> malicious software (viruses, worms, trojans, etc.).

But have they asked you about the powerful and dangerous AMASPZAP yet?
They aren't Real Auditors until they confront you about that.

> Does anyone know of a product that does this? I heard that McAfee is coming 
> out with a z/OS product "later this year", but I called them and they had no 
> idea what I was talking about.

One approach is to play stupid the whole way.

Malicious software - what is that? Virus? Worm? Trojan? No, I am not
aware of any such thing. Could you please give an example of what you
are talking about? Ah - you suggest general protection against not yet
identified threats? In your wide experience of auditing other
companies, what product(s) to do this have you found most commonly in
use on z/OS? What is the performance impact of these products? Could
you direct me to some vendor-independent studies of their
price/performance? Etc, etc.

Tony H.

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

Re: Malicious Software Protection

2012-03-27 Thread Greg Dorner

Thank you, Elardus for your verbosity. 


- you can replace/fire those auditors as mentioned earlier in this thread

- As Ted MacNeil insists, the auditors only RECOMMENDS, it is your management 
who can APPLY those recommendations.

Unfortunately, we have no say with these auditors. They are working on behalf 
of the Feds, and if we don't comply we can lose billions of $$ in federal 
contracts. 

The beauty of this is, someone from my company contacted the person at PWC that 
made this claim that MCAFEE is coming out with a product, and he backtracked, 
saying he may have been thinking of Mac OS. MAC OS??? 

They just took a big chuck of our company offline for several hours to research 
this phantom.

Thank you all for your input! 

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

Re: Malicious Software Protection

2012-03-27 Thread Greg Dorner

No,. I'm not serious. But the auditors at PWC are.  I'm practicing my 
belly-laugh for when they actually want to discuss the issue. You are all 
telling me what I already knew, but I just wanted to get the feedback so it 
isn't just my understanding of it. 

Thanks everyone, for all the good quotes, quips, and entertainment!

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

Re: Malicious Software Protection

2012-03-27 Thread Elardus Engelbrecht

Greg Dorner wrote:

>Our auditors are insisting that we install a product that protects against 
>malicious software (viruses, worms, trojans, etc.).

Groan, you can replace/fire those auditors as mentioned earlier in this 
thread, but ... ;-D

You have several choices.

1. Ask them to give reasons, examples and recommended vendors of such software. 

2. Ask them to define malicious software, despite your description above. 
Seriously.

3. For native z/OS, they will have a hard way to get any vendors at all which 
can supply such software. Tell me if you can catch these vendors.

4. Despite point 3, there are 'scanners' which can search z/OS on various areas 
to look for 'holes'. They cost $$$ and is vendor specific. 

5. Get 'penetration teams' or 'white hat hackers'. You have lots of $$$, do 
you? :-)

6. z/OS has very good security measures provided you have your controls in 
place. APF, parmlib settings, RACF, SMF, etc. are examples. See other's replies 
on this fact.

7. Speaking of RACF, there are third party RACF [or other ESM] administration 
and audit tools which could ease your work.

8. Weakest links are usually 'insiders'. They are the greatest threats unless 
I'm mistaken. They are usually after your 'live and sensitive production' data.

9. For z/Linux, USS, etc, there MAY be commercial or open-source antivirus 
software available, AFAIK.
(USS - Unix System Service(s) - for those TLA haters... :-D )

10. Give them IBM's Statement of Integrity. APAR reasons for security are 
hidden and you are usually asked to apply them because of some 'vulnurability' 
which IBM usually declines to divulge.

11. Ask those auditors if they have any tools to do the checks for such tools 
against malicous software THEMSELVES! This will silence them properly!

>z/OS, with proper security controls (and believe me - we have LOTS!) should 
>not have to worry about such things, at least that's what I've always heard.

Of course, but see above.

>Any input on this topic would be GREATLY appreciated!!

As Ted MacNeil insists, the auditors only RECOMMENDS, it is your management who 
can APPLY those recommendations.

HTH!

Groete / Greetings
Elardus Engelbrecht

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

Re: Malicious Software Protection

2012-03-27 Thread Anne & Lynn Wheeler

scott_j_f...@yahoo.com (Scott Ford) writes:
> You can't be serious...never never heard of anyone developing a virus
> for mainframes, I understand the fear, but firewalls, network apps do
> rat in front of the mainframe

this discussion group, mailing list originated on BITNET ... recent
discussion (with wiki references)
http://www.garlic.com/~lynn/2012e.html#19 Inventor of e-mail honored by 
Smithsonian

really long winded recent post in linkedin MainframeZone group
http://www.garlic.com/~lynn/2012d.html#49 Do you know where all your sensitive 
data is located?

mentions the "xmas" exec nov1987 ... reference from vmshare archive
http://vm.marist.edu/~vmshare/browse?fn=CHRISTMA&ft=PROB

was almost exactly a year before the morris worm on the internet.

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

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

LE enclave calls another LE enclave

2012-03-27 Thread Bernd Oppolzer


Hello all,

we have a problem that is not easy to describe. Let me try it.

We are building a test supporting system, which allows to do tests of 
software

components. The system consists of the following modules or parts:

A - driver, written in ASSEMBLER. The driver builds a LE enclave, so 
that it
can call C subfunctions and the test objects, which are (normally) PL/1 
routines


B - driver supporting routine, written in C. This routine provides 
services OPEN,
WRITE and CLOSE. It is called by the driver. On OPEN, it fetches a 
testcase list
from the testcase database and builds a linked list in memory (in the LE 
heap).

It also opens a log file for writing. On WRITE, it writes some protocol data
on the log file. On CLOSE, it closes the log file.

C - driver exit, written in ASSEMBLER. It is called at the beginning of 
the test object
(at the entry point) by means of TRAP2 interrupts. It has access to the 
testcase list
element that B took from the testcase database for the current testcase. 
It then calls
D, passing the address of the testcase list element. D reads the 
testcase data,
builds a parameter list for the testcase, and returns a parameter list. 
Then the
driver exits resumes the test object at the position of the entry point 
(this way

the test data is passed to the test object).

D - is a C routine which reads the data from the testcase data base and 
builds the
parameter list for the test object - because this is much easier to do 
in C than in

ASSEMBLER.

Now the problem:

all works well, if the test object is a PL/1 subroutine and not a main 
program. Then
the LE enclave built by A is used by B, passed to the test object, and 
used by D as well.

There is no problem passing the LE environment through the TRAP2 interrupt.

But:

we also want to be able to test PL/1 main programs this way. The PL/1 
main programs
are called by the driver the same way as the modules are called, but 
because they are
started at CEESTART, a second LE enclave below the first enclave is 
built. Then C and
D run below the second enclave. This is no problem so far, because there 
is no need
to share ressources between the two enclaves; the only information 
exchange is through
the testcase list element which belongs to the heap of the first 
enclave, and this is no problem,

in our opinion.

But:

when we return from the test object and we try to execute the WRITE call 
to B in the

first enclave, it fails in the prologue of B.

We first thought that reg 12 had not be restored correctly, but this is 
not the case.
Reg 12 is the same as before the call of the PL/1 main, points to the 
original CEECAA.
Also, the save area (including NAB etc, the words behind offsets 72) are 
unchanged.
But still, we get abends 0C4 etc. in the prologue of B. But only in the 
PL/1 main case,

if there is a second enclave, not in the other case.

We fixed this problem by doing the WRITE and CLOSE calls not in the same 
(first)
enclave as the OPEN call, but instead we did all the subsequent calls by 
an intermediate
PL/1 main, that is: after the PL/1 test object main destroyed somehow 
our first enclave,
we didn't use it any more, but instead constructed new enclaves for 
every subsequent

call at the same level. But this doesn't look very sound to me.

My question is: has somebody out there an idea, what has happened here 
and what
might be a solution to our problem? Is it possible to have one LE 
enclave call another
and on return from the second still have the first one usable? What are 
we getting wrong?


Kind regards

Bernd

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

Re: Malicious Software Protection

On Tue, 27 Mar 2012 11:15:52 -0400, Gross, Randall [GCG-PFS] wrote:

>Ask your auditor to recommend one for the mainframe ;-)
> 
That's likely not the auditor's job.  But if he knows of none, it is
his prerogative to assign a failing grade.

However, what body certifies the available commercial AV
products for PCs?  Would RACF pass that certification?  Would
someone have to pay for it?

How about penetration tests?  Install a known virus in files
on both PC and z.  Run PC virus scanners.  They'll report it.
Is there anything that will scan (all!) z/OS data sets and
report the virus?  That z/OS itself is not infected may be of
no import; the criterion may be that the latent presence of
an agent infectious to other systems must not be tolerated.
In this spirit, ClamAV for Linux scans Linux mail folders and
reports (eliminates?) malware that is harmless to Linux
but infectious to Windows.

It's a shame that the insecurities of Windows impel such
mickeymouse on better OSes.

-- gil

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

Re: Malicious Software Protection

Sorry should be 'do that in front of the mainframe'

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



On Mar 27, 2012, at 12:07 PM, Scott Ford  wrote:

> You can't be serious...never never heard of anyone developing a virus for 
> mainframes, I understand the fear, but firewalls, network apps do rat in 
> front of the mainframe
> 
> Sent from my iPad
> Scott Ford
> Senior Systems Engineer
> www.identityforge.com
> 
> 
> 
> On Mar 27, 2012, at 11:06 AM, Greg Dorner  wrote:
> 
>> Dear IBM-MAINers,
>> 
>> Our auditors are insisting that we install a product that protects against 
>> malicious software (viruses, worms, trojans, etc.).
>> 
>> Does anyone know of a product that does this? I heard that McAfee is coming 
>> out with a z/OS product "later this year", but I called them and they had no 
>> idea what I was talking about.
>> 
>> z/OS, with proper security controls (and believe me - we have LOTS!) should 
>> not have to worry about such things, at least that's what I've always heard.
>> 
>> Any input on this topic would be GREATLY appreciated!!
>> 
>> Thanks, 
>> Greg Dorner, WPS Insurance Corp.
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Malicious Software Protection

You can't be serious...never never heard of anyone developing a virus for 
mainframes, I understand the fear, but firewalls, network apps do rat in front 
of the mainframe

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



On Mar 27, 2012, at 11:06 AM, Greg Dorner  wrote:

> Dear IBM-MAINers,
> 
> Our auditors are insisting that we install a product that protects against 
> malicious software (viruses, worms, trojans, etc.).
> 
> Does anyone know of a product that does this? I heard that McAfee is coming 
> out with a z/OS product "later this year", but I called them and they had no 
> idea what I was talking about.
> 
> z/OS, with proper security controls (and believe me - we have LOTS!) should 
> not have to worry about such things, at least that's what I've always heard.
> 
> Any input on this topic would be GREATLY appreciated!!
> 
> Thanks, 
> Greg Dorner, WPS Insurance Corp.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Malicious Software Protection

2012-03-27 Thread Rob Schramm

VAT Security.  If you need to test/scan for MVS integrity.


Rob Schramm
Senior Systems Consultant
Imperium Group



On Tue, Mar 27, 2012 at 11:26 AM, Sam Siegel  wrote:
> On Tue, Mar 27, 2012 at 8:15 AM, Gross, Randall [GCG-PFS] <
> randy.gr...@primerica.com> wrote:
>
>> Ask your auditor to recommend one for the mainframe ;-)
>>
>
>
> Maybe a recommendation for at least competing products so you are not
> trapped by a single vendor choice. ;-)
>
>
>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
>> Behalf Of Greg Dorner
>> Sent: Tuesday, March 27, 2012 11:07 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Malicious Software Protection
>>
>> Dear IBM-MAINers,
>>
>> Our auditors are insisting that we install a product that protects
>> against malicious software (viruses, worms, trojans, etc.).
>>
>> Does anyone know of a product that does this? I heard that McAfee is
>> coming out with a z/OS product "later this year", but I called them and
>> they had no idea what I was talking about.
>>
>> z/OS, with proper security controls (and believe me - we have LOTS!)
>> should not have to worry about such things, at least that's what I've
>> always heard.
>>
>> Any input on this topic would be GREATLY appreciated!!
>>
>> Thanks,
>> Greg Dorner, WPS Insurance Corp.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send
>> email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Grace Hopper Stories!! (was RE: Pre-Friday fun: Halon dumps and POK Resets)

They have the 12 inch ruler with mm on the other side, flip side sould
be scaled with nano seconds speed of light, and speed of sound
http://en.wikipedia.org/wiki/Speed_of_sound is 340 m/s so .34m oer
340mm is 0.001 Mach-second (13.38 inches)

But speed of sound depends on medium.  And second depends on human
based time keeping.  Just like in the movie Contact, what would
someone from another planet recognize as a base unit of measurement?

How about a ruler based on Hydrogen?  http://en.wikipedia.org/wiki/Hydrogen
A scale based upon a 10^9 multiple of a hydrogen wavelength
(unfortunately there are several).

It also lists a Covalent radius 31±5 pm (31 picometers = 3.1 × 10-11
meters) (3.1 cm = 1 million Hydrogen covalent bonds)

On Tue, Mar 27, 2012 at 9:06 AM, John Gilmore
 wrote:
> I like zMan's idea for a two-sided--nanosecond and millimeter--ruler;
> his notion that the availability of the second, millimeter side would
> make justifying its cost easy is a really inspired piece of nonsense.
>
> I wish I'd thought of it.
>
> John Gilmore, Ashland, MA 01721 - USA
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: A z/OS Redbook Corrected - just about!

2012-03-27 Thread Anne & Lynn Wheeler

mike.a.sch...@gmail.com (Mike Schwab) writes:
> Since they have AIX on Power, how about zIX or MIX.  One concern I
> have is an operating system name without z/OS implies a completely
> independent operating system, not a subsystem of z/OS.

re:
http://www.garlic.com/~lynn/2012e.html#13 A z/OS Redbook Corrected - just about!

besides the OSF and POSIX support on MVS folklore

recent tale of origin of "AIX"
http://www.garlic.com/~lynn/2012e.html#2

was done for IBM by the company that had done port of AT&T unix to
ibm/pc as "PC/IX" ... i.e. ROMP was originally going to be the followon
to the Displaywriter ... but when that was canceled, it was redirected
to the unix workstation market (as PC/RT with AIX). RS/6000 and Power
were then followon to PC/RT.

the above also mentioned that the people that had done the initial
development for what becomes SUN workstation, had come to IBM about
producing the product. There was meeting in Palo Alto that included
several organizations around the company ... afterwards several
organizations all claimed that they were doing something better ..  and
IBM declined to come out with SUN workstation.

Palo Alto had been working on port of Berkeley's unix work-alike (BSD)
to mainframe ... but later get redirected to port it to the PC/RT
... coming out as "AOS" (as an alternative to AIX).

I had done internal advanced technology conference spring of 1982
... one of the first since the mid-70s ... when there was lots of
corporate retrenching after the failure of Future System effort .. some
past posts
http://www.garlic.com/~lynn/submain.html#futuresys

Presentations included BSD implementation on vm/370, TSS/370 UNIX PRPQ
for AT&T, and CMS running under MVS ... old post regarding the adtech
conference
http://www.garlic.com/~lynn/96.html#4a

Palo Alto was also working with UCLA and its unix work-alike (Locus)
... and ported it to both mainframe and ps2 ... which was released as
AIX/370 and AIX/386.

Another unix work-alike was MACH done at CMU ... a derivative can still
be found as the Apple operating system.

recent tale of mainframe "C language" 
http://www.garlic.com/~lynn/2012d.html#64 Layer 8: NASA unplugs last mainframe

There joint project between IBM and AT&T for unix on the mainframe
... purely for AT&T internal use ... it involved doing a stripped down
TSS/370 (residual limited availability follow-on to TSS/360) kernel with
unix higher levels layered on top.

Part of the TSS/370 strategy was to provide an alternative to Amdahl's
"UTS" (unix) & Amdahl processors for large number of AT&T installations.

As an aside, person responsible for UTS (code named "GOLD" during
development for Au or Amdahl Unix) had done port of unix to ibm
mainframe at school. When he was graduating, some of us attempted
unsuccesfully to get IBM to make him an offer.

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

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

Re: Malicious Software Protection

2012-03-27 Thread Sam Siegel

On Tue, Mar 27, 2012 at 8:15 AM, Gross, Randall [GCG-PFS] <
randy.gr...@primerica.com> wrote:

> Ask your auditor to recommend one for the mainframe ;-)
>


Maybe a recommendation for at least competing products so you are not
trapped by a single vendor choice. ;-)



>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Greg Dorner
> Sent: Tuesday, March 27, 2012 11:07 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Malicious Software Protection
>
> Dear IBM-MAINers,
>
> Our auditors are insisting that we install a product that protects
> against malicious software (viruses, worms, trojans, etc.).
>
> Does anyone know of a product that does this? I heard that McAfee is
> coming out with a z/OS product "later this year", but I called them and
> they had no idea what I was talking about.
>
> z/OS, with proper security controls (and believe me - we have LOTS!)
> should not have to worry about such things, at least that's what I've
> always heard.
>
> Any input on this topic would be GREATLY appreciated!!
>
> Thanks,
> Greg Dorner, WPS Insurance Corp.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/OS 1.11 DFSORT ICE046A

Do you have tape management software? If so, which one? CA-1 implements the 
ICETPEX exit and accurately reflects estimated record counts to DFSORT. We have 
used this for __years__ with no problems. If you have some other tape 
management software, ask the vendor.

If you don't have any tape management software at all, you'll need to "fake up" 
your own ICETPEX exit code and somehow give a fairly accurate record count to 
DFSORT.

If this is not possible, then __somebody__ need to be responsible to estimate 
the correct number and size of the SORTWKnn DD statements. There is no magic. 
Just hard work.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

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® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of ITURIEL DO NASCIMENTO NETO
> Sent: Tuesday, March 27, 2012 10:14 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: RES: z/OS 1.11 DFSORT ICE046A
> 
> Mr Yaeger,
> 
> If we SORT datasets in dasd, then IGNWKDD is perfect.
> But what happens when SORTIN is a TAPE dataset and tape 
> management software
> is not RMM ?
> 
> What is the best approach, is it necessary to specify USEWKDD ?
> 
> Atenciosamente / Regards / Saludos
> 
> Ituriel do Nascimento Neto
> BANCO BRADESCO S.A.
> 4254 / DPCD Engenharia de Software
> Sistemas Operacionais Mainframes
> Tel: +55 11 3684-2177 R: 42177 3-1402
> Fax: +55 11 4197-2814
> 
> 
> -Mensagem original-
> De: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] Em nome de Frank Yaeger
> Enviada em: segunda-feira, 26 de março de 2012 14:30
> Para: IBM-MAIN@bama.ua.edu
> Assunto: Re: z/OS 1.11 DFSORT ICE046A
> 
> Jerry Bergman on IBM Mainframe Discussion List 
>  wrote
> on 03/26/2012 09:49:24 AM:
> > We recently upgraded from 1.9 to 1.11. It went well, but now several
> > of our production jobs are dying with ICE406A - Sort Capacity
> > Exceeded.  The JCL has 3 sortwork DDs with an allocation of CYL(1,1)
> > or (2,1). Quite frankly I'm surprised they ever worked. When I tell
> > the application folks they need to follow the recommendation from
> > the doc for ICE046A, namely increase their sortwork size, their
> > response is that I need to set some parameter so they don't have to
> > change their JCL and if I ask someone will surely know what that
> > parameter is and tell me. So I am asking.
> 
> >I need to set some parameter so they don't have to change their JCL
> 
> Consider setting the DFSORT installation option 
> DYNAUTO=IGNWKDD (via an
> ICEPRMxx member).
> This would tell DFSORT to deallocate any SORTWKdd DD data sets and use
> dynamically
> allocated work data sets instead, which we recommend.
> 
> For more details, see the DFSORT books at:
> 
> http://www.ibm.com/support/docview.wss?rs=114&uid=isg3T780
> 
> Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
> Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, 
> Migration
> 
>  => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> AVISO LEGAL ...Esta mensagem é destinada exclusivamente 
> para a(s) pessoa(s) a quem é dirigida, podendo conter 
> informação confidencial e/ou legalmente privilegiada. Se você 
> não for destinatário desta mensagem, desde já fica notificado 
> de abster-se a divulgar, copiar, distribuir, examinar ou, de 
> qualquer forma, utilizar a informação contida nesta mensagem, 
> por ser ilegal. Caso você tenha recebido esta mensagem por 
> engano, pedimos que nos retorne este E-Mail, promovendo, 
> desde logo, a eliminação do seu conteúdo em sua base de 
> dados, registros ou sistema de controle. Fica desprovida de 
> eficácia e validade a mensagem que contiver vínculos 
> obrigacionais, expedida por quem não detenha poderes de 
> representação. 
> LEGAL ADVICE...This message is exclusively destined for 
> the people to whom it is directed, and it can bear private 
> and/or legally exceptional information. If you are not 
> addressee of this message, since now you are advised to not 
> release, copy, distribute, check or, otherwise, use the 
> information contained in this message, because it is illegal. 
> If you rec

Re: Malicious Software Protection

2012-03-27 Thread Staller, Allan

Get some new auditors!


z/OS, with proper security controls (and believe me - we have LOTS!)
should not have to worry about such things, at least that's what I've
always heard.

Any input on this topic would be GREATLY appreciated!!


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

Re: Malicious Software Protection

2012-03-27 Thread Pinnacle


On 3/27/2012 11:09 AM, Greg Dorner wrote:

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects against 
malicious software (viruses, worms, trojans, etc.).

Does anyone know of a product that does this? I heard that McAfee is coming out with a 
z/OS product "later this year", but I called them and they had no idea what I 
was talking about.

z/OS, with proper security controls (and believe me - we have LOTS!) should not 
have to worry about such things, at least that's what I've always heard.

Any input on this topic would be GREATLY appreciated!!

Thanks,
Greg Dorner, WPS Insurance Corp.

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


There is a mainframe product that protects against malicious software.  
It's called SAF, and it interfaces with ESM's like RACF, or ACF2, or 
TopSecret.  It's the only operating system out there with built-in 
anti-virus protection.  On top of that, the hardware itself actively 
protects against damage through storage keys, protected memory, etc.  
You have to explain to the auditors that anti-virus software is not 
needed on z/OS, because it's intrinsic to the operating system and the 
hardware.


Regards,
Tom Conley

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

Re: Malicious Software Protection

2012-03-27 Thread Gross, Randall [GCG-PFS]

Ask your auditor to recommend one for the mainframe ;-) 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Greg Dorner
Sent: Tuesday, March 27, 2012 11:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Malicious Software Protection

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects
against malicious software (viruses, worms, trojans, etc.).

Does anyone know of a product that does this? I heard that McAfee is
coming out with a z/OS product "later this year", but I called them and
they had no idea what I was talking about.

z/OS, with proper security controls (and believe me - we have LOTS!)
should not have to worry about such things, at least that's what I've
always heard.

Any input on this topic would be GREATLY appreciated!!

Thanks, 
Greg Dorner, WPS Insurance Corp.

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

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

RES: z/OS 1.11 DFSORT ICE046A

2012-03-27 Thread ITURIEL DO NASCIMENTO NETO

Mr Yaeger,

If we SORT datasets in dasd, then IGNWKDD is perfect.
But what happens when SORTIN is a TAPE dataset and tape management software
is not RMM ?

What is the best approach, is it necessary to specify USEWKDD ?

Atenciosamente / Regards / Saludos

Ituriel do Nascimento Neto
BANCO BRADESCO S.A.
4254 / DPCD Engenharia de Software
Sistemas Operacionais Mainframes
Tel: +55 11 3684-2177 R: 42177 3-1402
Fax: +55 11 4197-2814


-Mensagem original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] Em nome de 
Frank Yaeger
Enviada em: segunda-feira, 26 de março de 2012 14:30
Para: IBM-MAIN@bama.ua.edu
Assunto: Re: z/OS 1.11 DFSORT ICE046A

Jerry Bergman on IBM Mainframe Discussion List  wrote
on 03/26/2012 09:49:24 AM:
> We recently upgraded from 1.9 to 1.11. It went well, but now several
> of our production jobs are dying with ICE406A - Sort Capacity
> Exceeded.  The JCL has 3 sortwork DDs with an allocation of CYL(1,1)
> or (2,1). Quite frankly I'm surprised they ever worked. When I tell
> the application folks they need to follow the recommendation from
> the doc for ICE046A, namely increase their sortwork size, their
> response is that I need to set some parameter so they don't have to
> change their JCL and if I ask someone will surely know what that
> parameter is and tell me. So I am asking.

>I need to set some parameter so they don't have to change their JCL

Consider setting the DFSORT installation option DYNAUTO=IGNWKDD (via an
ICEPRMxx member).
This would tell DFSORT to deallocate any SORTWKdd DD data sets and use
dynamically
allocated work data sets instead, which we recommend.

For more details, see the DFSORT books at:

http://www.ibm.com/support/docview.wss?rs=114&uid=isg3T780

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

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

AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) 
a quem é dirigida, podendo conter informação confidencial e/ou legalmente 
privilegiada. Se você não for destinatário desta mensagem, desde já fica 
notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de 
qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. 
Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este 
E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de 
dados, registros ou sistema de controle. Fica desprovida de eficácia e validade 
a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha 
poderes de representação. 
LEGAL ADVICE...This message is exclusively destined for the people to whom 
it is directed, and it can bear private and/or legally exceptional information. 
If you are not addressee of this message, since now you are advised to not 
release, copy, distribute, check or, otherwise, use the information contained 
in this message, because it is illegal. If you received this message by 
mistake, we ask you to return this email, making possible, as soon as possible, 
the elimination of its contents of your database, registrations or controls 
system. The message that bears any mandatory links, issued by someone who has 
no representation powers, shall be null or void.

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

Re: Pre-Friday fun: Halon dumps and POK Resets

2012-03-27 Thread Phil Smith

Scott Ford wrote:
>Had a Hasp RJE like that John, everytime it rained there were strange 
>creatures on the phone lines...of course the standard phone company reply was 
>classic, no problems here and the problems always disappeared.

I'm certainly no apologist for Big Phone, but have to relate a contra-story in 
the spirit of fairness:

In the mid-80s I lived in Waterloo, Ontario. Working late at night over my 
speedy 2400bps dialup, I'd get bad characters occasionally, but always the 
*same* characters (curly braces, forget which direction). I called Bell Canada, 
and they not only took it seriously and investigated, but got back to me to 
tell me that it was automated line testing, and that they'd turned it off for 
my line.

Of course that person was probably RIFfed soon after...

...phsiii

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

Malicious Software Protection

2012-03-27 Thread Greg Dorner

Dear IBM-MAINers,

Our auditors are insisting that we install a product that protects against 
malicious software (viruses, worms, trojans, etc.).

Does anyone know of a product that does this? I heard that McAfee is coming out 
with a z/OS product "later this year", but I called them and they had no idea 
what I was talking about.

z/OS, with proper security controls (and believe me - we have LOTS!) should not 
have to worry about such things, at least that's what I've always heard.

Any input on this topic would be GREATLY appreciated!!

Thanks, 
Greg Dorner, WPS Insurance Corp.

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

Re: A z/OS Redbook Corrected - just about!

2012-03-27 Thread Dick Bond

This could go another route and ask why every IBM product that is "old",
"new" or "purchased via OEM", seems to be given the Tivoli brand name?   ;-)

On Tue, Mar 27, 2012 at 6:09 AM, Scott Ford  wrote:

> After seeing this thread it's very apparent to me, IMHO, that someone at
> IBM missed the boat on the acronyms. Maybe an accident ? zUSS would have
> been better IMHO than calling Unix System Services , USS ...fwiw
>
> Sent from my iPad
> Scott Ford
> Senior Systems Engineer
> www.identityforge.com
>
>
>
> On Mar 27, 2012, at 8:21 AM, "McKown, John" 
> wrote:
>
> > Many, especially around here, would go with a different expansion of the
> first three characters. And it's not "Point Of Sale". They don't like the
> POSIX / UNIX (since it is X/Open branded) portion of z/OS at all.
> >
> > --
> > John McKown
> > Systems Engineer IV
> > IT
> >
> > Administrative Services Group
> >
> > HealthMarkets(r)
> >
> > 9151 Boulevard 26 * N. Richland Hills * TX 76010
> > (817) 255-3225 phone *
> > john.mck...@healthmarkets.com * www.HealthMarkets.com
> >
> > Confidentiality Notice: This e-mail message may contain confidential or
> proprietary information. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message. HealthMarkets(r) is the brand name for products underwritten and
> issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake
> Life Insurance Company(r), Mid-West National Life Insurance Company of
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
> >
> >
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List
> >> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of J R
> >> Sent: Monday, March 26, 2012 9:34 PM
> >> To: IBM-MAIN@bama.ua.edu
> >> Subject: Re: A z/OS Redbook Corrected - just about!
> >>
> >> I agree, why not zUnix?  Or z/Unix?
> >>
> >> However, since Lynn Wheeler has reminded us that z/OS Unix is
> >> (to some degree) POSIX compliant/compatible, why not adopt a
> >> catchy contraction of "POSIX"?
> >>
> >> I'd like to suggest z/POX, which also connotes the blight it
> >> has become on z/OS.  ;-)  ...
> >>> Date: Mon, 26 Mar 2012 10:16:32 -0700
> >>> From: dickbond...@gmail.com
> >>> Subject: Re: A z/OS Redbook Corrected - just about!
> >>> To: IBM-MAIN@bama.ua.edu
> >>>
> >>> I agree with Chris Mason.   IBM should have never started
> >> called it USS -
> >>> how about a simple definitive abbreviation, like "zUnix".
> >> IBM adores
> >>> putting a "z" in front of everything (for some clueless
> >> reason) so why
> >>> should their version of Unix be any different?
> >>>
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >>
> >>
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Grace Hopper Stories!! (was RE: Pre-Friday fun: Halon dumps and POK Resets)

On Tue, 27 Mar 2012 09:06:30 -0500, John Gilmore wrote:

>I like zMan's idea for a two-sided--nanosecond and millimeter--ruler;
>his notion that the availability of the second, millimeter side would
>make justifying its cost easy is a really inspired piece of nonsense.
>
>I wish I'd thought of it.
> 
Earlier in this thread someone said 11 inches.  Elsewhere, I've seen
9 inches or 8 inches.  It depends largely on the speed of light in the
insulation of the wire, which is not well controlled.  Precise rulers are
calibrated at a specific temperature; the nanosecond ruler needs to
be calibrated for a specific propagation medium.

-- gil

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

Re: XEDIT change in 6.2 ?

On Tue, 27 Mar 2012 06:55:42 -0700, Phil Smith wrote:

>Tony Thigpen wrote:
>>I have used that method also. But, it has the same problem. Anytime you use 
>>xedit with either (noprof or with a special, single purpose profile, the 
>>routines are most likely now broken. It's not something that can be fixed by 
>>a simple 'just change your profile xedit file'. It's also not something that 
>>could be addressed by using a system wide profile xedit that calls a userid() 
>>xedit.
>
>But my point was that in a macro, you have control over the case; if you stack 
>stuff, you're making assumptions about case translation. I wouldn't write:
>
>'command change /this/that/*'
>
>in a macro if I meant to change THIS to THAT; your technique allows/encourages 
>such sloppiness if you're assuming CASE U, because stuff will get uppercased 
>when it falls out of the stack. Yes, the subcommand above will do the same in 
>CASE U, but it seems clearer to me that it's wrong.
>
>Maybe this is just me...
> 
What are you following up to?  You've posted two replies in
this (slightly OT) thread, and I see no antecedents.

But, yes.  I advocate a principle of minimal munging.
Long ago, I tweaked my PROFILE XEDIT so I could
open a binary file, make a one-character change (perhaps
in hex) and save it with no collateral damage:  No case
changes elsewhere in the record; no tabs expanded;
no sequence numbers modified.  These should be
the defaults for minimum astonishment factor.

-- gil

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

Re: Grace Hopper Stories!! (was RE: Pre-Friday fun: Halon dumps and POK Resets)

2012-03-27 Thread John Gilmore

I like zMan's idea for a two-sided--nanosecond and millimeter--ruler;
his notion that the availability of the second, millimeter side would
make justifying its cost easy is a really inspired piece of nonsense.

I wish I'd thought of it.

John Gilmore, Ashland, MA 01721 - USA

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

Re: XEDIT change in 6.2 ?

2012-03-27 Thread Phil Smith

Tony Thigpen wrote:
>I have used that method also. But, it has the same problem. Anytime you use 
>xedit with either (noprof or with a special, single purpose profile, the 
>routines are most likely now broken. It's not something that can be fixed by a 
>simple 'just change your profile xedit file'. It's also not something that 
>could be addressed by using a system wide profile xedit that calls a userid() 
>xedit.

But my point was that in a macro, you have control over the case; if you stack 
stuff, you're making assumptions about case translation. I wouldn't write:

'command change /this/that/*'

in a macro if I meant to change THIS to THAT; your technique allows/encourages 
such sloppiness if you're assuming CASE U, because stuff will get uppercased 
when it falls out of the stack. Yes, the subcommand above will do the same in 
CASE U, but it seems clearer to me that it's wrong.

Maybe this is just me...
--
.phsiii

Phil Smith III
p...@voltage.com
Voltage Security, Inc.
www.voltage.com

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

Re: Grace Hopper Stories!! (was RE: Pre-Friday fun: Halon dumps and POK Resets)

2012-03-27 Thread zMan

On Mon, Mar 26, 2012 at 6:23 PM, Tony Harminc  wrote:

> On 23 March 2012 11:53, Sevetson, Phil  wrote:
> > How many people here have been to one of her lectures?  Where she used
> to hold up 11-inch bits of wire, explaining that "This is a nanosecond" and
> sometimes carried around a coil of wire that was a light-microsecond long?
>
> I am surprised that a nanosecond ruler has not shown up as a standard
> scientific novelty. There are various examples of them on the net, but
> they are hand crafted by physics teachers and professors. What we need
> is a cheap plastic ruler 1 ns long, with no inches or cm or other
> clutter. Played straight, so to speak, as though we really used such a
> ruler as an everyday tool. It would just barely be feasible to have ps
> divisions, though the unaided eye could not use them to measure
> things. But 100 and 10 ps divisions would be quite usable.
>

That would be fun. Alternatively, have one side be inches (or mm/cm) and
the other ns ... then it would actually be useful and folks could justify
the cost.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: Assembler - convrssion of Epoch (Unix) time to printable

On Tue, 27 Mar 2012 07:47:39 -0500, McKown, John wrote:

> ..., the UNIX epoch is simply a number. The number of seconds since 00:00:00 
> GMT 1 Jan 1970. It would be rather easy to convert to -mm-ddThh:mm:ss if 
> it weren't for the "leap seconds". Which may or may not be of any interest to 
> you.
>
Not really.  In effect, the origin of NTP shifts by one second every time
a leap second occurs.  It is now 00:00:34 GMT 1 Jan 1970; in a little
over 3 months it will be 00:00:35 GMT 1 Jan 1970.

http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html

... it is inappropriate to require that a time represented as seconds
since the Epoch precisely represent the number of seconds between
the referenced time and the Epoch.



-- gil

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

Re: A z/OS Redbook Corrected - just about!

After seeing this thread it's very apparent to me, IMHO, that someone at IBM 
missed the boat on the acronyms. Maybe an accident ? zUSS would have been 
better IMHO than calling Unix System Services , USS ...fwiw

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



On Mar 27, 2012, at 8:21 AM, "McKown, John"  
wrote:

> Many, especially around here, would go with a different expansion of the 
> first three characters. And it's not "Point Of Sale". They don't like the 
> POSIX / UNIX (since it is X/Open branded) portion of z/OS at all.
> 
> --
> John McKown 
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets(r)
> 
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone * 
> john.mck...@healthmarkets.com * www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain confidential or 
> proprietary information. If you are not the intended recipient, please 
> contact the sender by reply e-mail and destroy all copies of the original 
> message. HealthMarkets(r) is the brand name for products underwritten and 
> issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake 
> Life Insurance Company(r), Mid-West National Life Insurance Company of 
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
> 
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List 
>> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of J R
>> Sent: Monday, March 26, 2012 9:34 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: A z/OS Redbook Corrected - just about!
>> 
>> I agree, why not zUnix?  Or z/Unix?  
>> 
>> However, since Lynn Wheeler has reminded us that z/OS Unix is 
>> (to some degree) POSIX compliant/compatible, why not adopt a 
>> catchy contraction of "POSIX"?  
>> 
>> I'd like to suggest z/POX, which also connotes the blight it 
>> has become on z/OS.  ;-)  ...
>>> Date: Mon, 26 Mar 2012 10:16:32 -0700
>>> From: dickbond...@gmail.com
>>> Subject: Re: A z/OS Redbook Corrected - just about!
>>> To: IBM-MAIN@bama.ua.edu
>>> 
>>> I agree with Chris Mason.   IBM should have never started 
>> called it USS -
>>> how about a simple definitive abbreviation, like "zUnix".  
>> IBM adores
>>> putting a "z" in front of everything (for some clueless 
>> reason) so why
>>> should their version of Unix be any different?
>>> 
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>> 
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Pre-Friday fun: Halon dumps and POK Resets

Man,

Had a Hasp RJE like that John, everytime it rained there were strange creatures 
on the phone lines...of course the standard phone company reply was classic, no 
problems here and the problems always disappeared.

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



On Mar 27, 2012, at 8:17 AM, "McKown, John"  
wrote:

> I had that at my first job. I learned early to hate the telephone company. 
> And "concentrator" office in Garland, TX. I would call them about no 
> connectivity to TCIC (Texas Crime Information Center, or something like 
> that). I was told "nobody else is experiencing problems!". I would then call 
> another shop at the other end of town. They would be down too.
> 
> Had one remote police office with 3767s and a 3275(?). Every time it rained, 
> they'd be down. Rain would stop and dry out, they'd come back up. Telephone 
> company said I was lying.
> 
> --
> John McKown 
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets(r)
> 
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone * 
> john.mck...@healthmarkets.com * www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain confidential or 
> proprietary information. If you are not the intended recipient, please 
> contact the sender by reply e-mail and destroy all copies of the original 
> message. HealthMarkets(r) is the brand name for products underwritten and 
> issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake 
> Life Insurance Company(r), Mid-West National Life Insurance Company of 
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
> 
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List 
>> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.)
>> Sent: Monday, March 26, 2012 1:28 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: Pre-Friday fun: Halon dumps and POK Resets
>> 
>> In <7282054772622349.wa.steve.doverccbcc@bama.ua.edu>, on
>> 03/26/2012
>>   at 08:19 AM, Steve Dover  said:
>> 
>>> ATT said everything was great on the line,
>> 
>> Reminds me of the old diagnostic technique:
>> 
>> 1. Clean all of the contacts/.
>> 
>> 2. Test the link.
>> 
>> 3. Tell the customer that you couldn't find a problem so
>>it must be on his end.
>> 
>> -- 
>> Shmuel (Seymour J.) Metz, SysProg and JOAT
>> ISO position; see  
>> We don't care. We don't have to care, we're Congress.
>> (S877: The Shut up and Eat Your spam act of 2003)
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>> 
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Assembler - convrssion of Epoch (Unix) time to printable

Cheat? I'm a big fan of cheating. I often use LE enabled HLASM just so that I 
can use the subroutines from the C language to do "fancy" printing by using 
sprintf() calls. Of course, you could also cheat by converting the C epoch to a 
Lilian date (simple addition) and using the LE subroutine CEEDATE to convert it 
to printable form. But, then, the UNIX epoch is simply a number. The number of 
seconds since 00:00:00 GMT 1 Jan 1970. It would be rather easy to convert to 
-mm-ddThh:mm:ss if it weren't for the "leap seconds". Which may or may not 
be of any interest to you.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Arye Shemer
> Sent: Tuesday, March 27, 2012 4:19 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Assembler - convrssion of Epoch (Unix) time to printable
> 
> Hello distinguished forummers,
> I need help in finding a method of converssion Epoch (Unix) time to
> printable format in an Assembler program,
> Any clue how to achieve this ?
> 
> Thank you,
> 
> Arye Shemer.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

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

Re: Pre-Friday fun: Halon dumps and POK Resets

2012-03-27 Thread Shane Ginnane

On Tue, 27 Mar 2012 07:17:21 -0500, McKown, John wrote:

>Every time it rained, they'd be down. Rain would stop and dry out, they'd come 
>back up. Telephone company said I was lying.

Sounds like my ADSL link - and man, have we had some rain in the last year or 
two ...

Shane ...

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

Re: A z/OS Redbook Corrected - just about!

Many, especially around here, would go with a different expansion of the first 
three characters. And it's not "Point Of Sale". They don't like the POSIX / 
UNIX (since it is X/Open branded) portion of z/OS at all.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of J R
> Sent: Monday, March 26, 2012 9:34 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: A z/OS Redbook Corrected - just about!
> 
> I agree, why not zUnix?  Or z/Unix?  
> 
> However, since Lynn Wheeler has reminded us that z/OS Unix is 
> (to some degree) POSIX compliant/compatible, why not adopt a 
> catchy contraction of "POSIX"?  
> 
> I'd like to suggest z/POX, which also connotes the blight it 
> has become on z/OS.  ;-)  ...
>  > Date: Mon, 26 Mar 2012 10:16:32 -0700
> > From: dickbond...@gmail.com
> > Subject: Re: A z/OS Redbook Corrected - just about!
> > To: IBM-MAIN@bama.ua.edu
> > 
> > I agree with Chris Mason.   IBM should have never started 
> called it USS -
> > how about a simple definitive abbreviation, like "zUnix".  
> IBM adores
> > putting a "z" in front of everything (for some clueless 
> reason) so why
> > should their version of Unix be any different?
> > 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

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

Re: Leaving IBM

2012-03-27 Thread Steve Dover

Walt, enjoy your time with family, friends and pleasant pursuits.  You have 
always been the calm amidst the chaos and your wisdom and assistance was 
plentiful and helpful.  Thanks for all you have done for all of us.

On Mon, 26 Mar 2012 08:52:45 -0500, Walt Farrell  wrote:

>I mentioned this over on RACF-L the other day, so for some of you this will be 
>old news.
>
>I've been an IBMer for 28 years and have had a lot of fun with RACF and MVS,
>and I've had a lot of fun interacting with you folks on RACF-L and IBM-MAIN.
>
>But the time has come for me to retire and have fun with other things. I've
>enjoyed the discussions here, and working with many of you to plan
>enhancements or resolve problems.  I'm sure I'll still read both lists for
>awhile, and probably even participate from a personal email address.
>
>But after Wednesday morning I will no longer be an active IBM employee and
>I'll speak about z/OS and RACF even less officially than than I do now.
>
>It's been a great 28 years, but my family and other activities are calling
>to me more and more strongly, and it's time to spend more time with them.
>
>Best wishes to you all,
>Walt
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Pre-Friday fun: Halon dumps and POK Resets

I had that at my first job. I learned early to hate the telephone company. And 
"concentrator" office in Garland, TX. I would call them about no connectivity 
to TCIC (Texas Crime Information Center, or something like that). I was told 
"nobody else is experiencing problems!". I would then call another shop at the 
other end of town. They would be down too.

Had one remote police office with 3767s and a 3275(?). Every time it rained, 
they'd be down. Rain would stop and dry out, they'd come back up. Telephone 
company said I was lying.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

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

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

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Monday, March 26, 2012 1:28 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Pre-Friday fun: Halon dumps and POK Resets
> 
> In <7282054772622349.wa.steve.doverccbcc@bama.ua.edu>, on
> 03/26/2012
>at 08:19 AM, Steve Dover  said:
> 
> >ATT said everything was great on the line,
> 
> Reminds me of the old diagnostic technique:
> 
>  1. Clean all of the contacts/.
> 
>  2. Test the link.
> 
>  3. Tell the customer that you couldn't find a problem so
> it must be on his end.
>  
> -- 
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see  
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

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

Re: A z/OS Redbook Corrected - just about!