Re: Managing system logger data

[Ed Gould]

On Jan 31, 2008, at 6:58 PM, Skip Robinson wrote:

---SNIP---
Here's the problem. IFASMFDL does most of what IFASMFDP does (and  
more),
but what it *doesn't* do is clear out the dumped SMF data. In other  
words,
after archiving the contents of a log stream to a flat file, the  
now dumped

records are still sitting just where they were. A subsequent run of
IFASMFDL appears to pick up the same records all over again. The  
output

file just gets bigger and bigger each time the dump is run.

For those of you who use system logger for operlog or logrec, how  
do you

clean up log streams so that you get one and only copy of all the data
produced?

.


Skip:

Not sure this is a solution but it might be worth a try. Sort the SMF  
records each time and specify in sort to drop duplicate records.

That was you should get only 1 record and the other 1 will be dropped.

Ed

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

Re: Job ad for z/OS systems programmer trainee

[Ed Gould]

On Jan 31, 2008, at 2:13 PM, Gary Green wrote:

Well, all us write in our resumes that we "look for a challenge".   
From that

position profile, I can't think of anything more challenging.  :)



Would you really take that type of a job... out in the middle of a  
desert and LA is a good 90 miles away. Yes there is a community  
(albeit all government type people) Secrecy is all around you and  
probably your next door neighbor is spying on you. Its like living in  
the back hills of the south.


You certainly would not be allowed to join in on here you would miss  
the toothless biting humor of Ron H and the 1 (or 2) word answers  
from Schmuel  all you would be able to do is stare out on the desert  
at night. And the high point would be if someone runs a red light.


Ed

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

Re: identify sas usage by component

[Ed Gould]

On Jan 31, 2008, at 11:02 AM, Gary Green wrote:

I have not followed this thread so forgive if this was covered  
earlier...


Speaking off the top of my head (yeah, I know, I know...)

I need to leave aside the fact that any change to an OEM's SMF record
requires tweaking of any vendor record specific downstream  
processing.  If
all this processing is done in-house, that's no big deal.  A slight  
tweak to
Barry's MXG record definitions, could handle that.  If the data is  
sent to
the vendor, that is easy as well.  Just coble something together to  
reverse

the changes.

...

How about looking into writing an SMF Dump Program exit where you  
would
modify the OEM SMF records on the fly and use your own record-type/ 
sub-type
numbering scheme.  As the records pass through your exit, you would  
modify
the appropriate records before they are written to the SMF dump  
tape/disk

file.

1. If the vendor's SMF record uses a header with the SMFxSTY (subtype)
field, dump a few thousand of their records to see if they actually  
use the
STY field or is the value constant.  If constant, it's possibly  
ripe for you
to use.  For this type of record, change the record type and  
subtype to your
liking. XX for the record type and yy for sub-type for vendor yy,  
and zz for

vendor zz and so on.

2. If the vendor's SMF record does not use a header with the SMFxSTY
(subtype) field (most likely), you have two options.
A. You could reformat the record header to make it support subtypes.
Allocate a buffer to rebuild the record, copy the existing original  
18 byte
header and actual Vendor SMF record data to the appropriate area in  
the
buffer and change the record type then insert the subtype in the  
SSY field
to represent that specific vendor.  Of course, if the vendor's  
record uses
triplet fields, they would need to be modified as well.  I would  
review the
documentation from the vendor for this information.  As for the SSI  
field, I

would ignore it since it was never there in the first place.

B. You could use the SMFxFLG field.  I look at records all the time  
and "I"
do not recall ever seeing a vendor actually using this field; of  
course
YMMV.  That said, I dumped a  million SMF records between 128-255  
they all
contain the same value; 1E in my case.  You could use this field  
for your
vendor specific sub-type value and then change the record type.  Of  
course,
this will only provide you a 16:1 reduction in used records types  
but that's

better than nothing. ;)

..

Now, if one were to entertain this idea, the big question is, if  
multiple
vendors use the same SMF record type, how does one distinguish one  
vendor's
record from the others that are using the same record type.   
Generally,
there is almost always some type of eye-catcher in the record that  
would

give it away.

A simple branch table/array to identify the records to process.  In  
that

table/array you could have an offset to the eye-catcher location to
interrogate and another pointer to an array of values to compare  
against,

any one of which would be a hit.

JMTC...


Sure that is possible if you *OWN* the programs in question but our  
issue at the time was OEM code (usually in COBOL) and you can't  
change the code. If you do you own it. Then there is the issue of  
maintaining the code with (about) 3 updates a year. Our staff was not  
equipped to handle that type of change. Yes we were understaffed but  
who isn't? At the time we had one individual handling the SMF  
products and he really worked his butt off doing so. Add to that we  
were on the bleeding edge of IBM PTF's it was all we could handle  
plus the installation of OEM software plus we had quite a few  
experimental (more like early ship) equipment (DASD & TAPE) and few  
other items like we were FCS on some IBM controllers that we were  
dying to get our hands on as we were busting our seams trying to keep  
the number of UCB's below the magic number and and and... in other  
words we had our hands full.


I am sure there are ways but since we didn't own the code and the  
vendors were not sympathetic about us touching their code.  I won't  
go into the vendor arm twisting that was done and it was tried just a  
dead end. One vendor told us that they would charge us 25K a hear and  
an hourly rate if we really needed it. Even if we could have gotten  
the same deal (unlikely) from the other 3 that would have raised the  
cost to probably over 100K a year.


Ed

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

Re: OT 1TB Drive and 37 hours

[Brian Westerman]

I have two of them and neither took over 3 hours to format.  I noticed that
they had accepted the auto update of Vista, which was pretty dumb of them in
the first place, and that appears to be what caused their problem.  I
replaced 2 WD 500GB drives with these, and while I thought they were very
quiet, I am very pleased at the fact that it's now just about silent.  They
also appear to run about 10 degrees F cooler.

Brian

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

Re: Data Erasure Products

[Anne & Lynn Wheeler]

[EMAIL PROTECTED] (Stephen Mednick) writes:
> it's not a case of how valuable the data is, more importantly it's to
> do with what the security classification is that has been assigned to
> the data. Depending on the data's security classification dictates the
> media overwriting/sanitisation method that is it be deployed in
> accordance with government requirements.

security classification is simplification ... like role-based access
qcontrol is simplification for permissions. ... recent post on dealing
with permissions
http://www.garlic.com/~lynn/2008b.html#26 folklore indeed

the issue normally reduces to what is the threat model? security
classification tends to be associated with threat model where divulging
the information is not desirable ... and classification level attempts
to make the measures to prevent information divulging proportional to
the damange that might happen if the information is divulged (and/or the
effort that an attacker will go to in order to get the data). For
magnetic media this might be something like overwritting a specific
number of times with (different) random data ... nist standard:
http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf

An example of how this gets simplified is example of consumer financial
information stored at a merchant. The "damage" gets translated into
security proportional to risk ... and the risk is what is the value of
the information to the merchant ... old post on the subject:
http://www.garlic.com/~lynn/2001h.html#61 Security Proportional To Risk

The problem is that the real threat model and therefor risk, is that the
value of the information to the consumer (and to any attacking crook) is
possibly one hundred times larger than the value of the information to
the merchant. The merchant is required to keep transaction logs (and the
associated account numbers) for some period as part of mandated business
processes.

The information value (to the merchant) is some part of the merchant's
profit margin on the transaction ... for hypothetical example for some
number of product transactions, this could be $10,000. The value of the
information to the crook, is related to the credit limits associated
with the individual accounts. This could conceivable be $10,000,000
(totally unrelated to the value of the information to the merchant,
i.e. some portion of the profit on the purchased products). Since the
value to the crook can be 100 to 1000 times larger, the attacking crooks
can afford to outspend the defending merchants by possibly one hundred
times.

in the mid-90s, the x9a10 financial standard working group had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments. Part of this was looking in
detail at end-to-end vulnerabilities and threat models ...  as part of
coming up with x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959

part of the x9.59 financial standard was eliminating the usefulness of
the account transaction log information (at merchants) to attacking
crooks  i.e. it didn't involve trying to prevent attacking crooks
from getting at the information ... it just made the information useless
to crooks for performing fraudulent financial transactions.

A different example was we also got involved in co-authoring the
financial industry x9.99 privacy standard. As part of that we had to
look at both GLBA and HIPAA (financial transactions can used for medical
procedures which may be listed).

One of the issues in HIPAA is that there is a real requirement to make
some amount of medical procedure information available. At a result,
HIPAA allows for information to be available if it can't be associated
with an individual (aka "deidentified").

deidentified
 Under the HIPAA Privacy Rule, data are deidentified if either (1) an
 experienced expert determines that the risk that certain information
 could be used to identify an individual is 'very small' and documents
 and justifies the determination, or (2) the data do not include any of
 the following eighteen identifiers

... snip ...

As part of working on x9.99, we put together a privacy merged taxonomy
and glossary ... see:
http://www.garlic.com/~lynn/privacy.htm

for other details see notes at
http://www.garlic.com/~lynn/index.html#glosnote

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

Re: Data Erasure Products

[Stephen Mednick]

> Stephan:
> 
> It comes down purely (IMO) how valuable the data is. If its 
> nuclear bomb data (or the like) then I would suggest that 
> cost is not an issue.

Ed,

it's not a case of how valuable the data is, more importantly it's to do with
what the security classification is that has been assigned to the data. 
Depending
on the data's security classification dictates the media 
overwriting/sanitisation
method that is it be deployed in accordance with government requirements.

You'll find that these days most organisations are required to have a designated
IT Security Advisor whose job it is to keep abreast of compliance regulations 
and
requirements and ensure that they are being applied across the organisation and
that corporate governance is being properly maintained. For heaven's sake, lets
not bring the lawyers into this!!!

I think this thread is developing the symptoms of drifting OT so let's try and
hold it here.

Stephen Mednick
Computer Supervisory Services
Sydney, Australia

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

Re: Managing system logger data

[R.J. Crook]

Skip,

We're still at 1.7, so I can't speak to SMF data yet.

Operlog we just set up with a 5 day RETPD in the logstream def'n. After
that, Logger manages the datasets and makes them disappear. Copying to DASD
for archiving is still done from the Syslog, and happens the way it always
has. Syslog and Operlog are independant.

For Logrec, IFCEREP1 has a LASTRUN parm. This marks the logstream data at
the place that it last read up to,  so that next time it's run it knows to
start from there.

Richard Crook
zOS Technical Specialist,
IBM Global Technology Services

(64 4) 576-9795
[EMAIL PROTECTED]


   
 Skip Robinson 
   To 
 Sent by: IBM  IBM-MAIN@BAMA.UA.EDU
 Mainframe  cc 
 Discussion List   
 <[EMAIL PROTECTED] Subject 
 .EDU> Managing system logger data 
   
   
 01/02/2008 01:58  
 PM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 <[EMAIL PROTECTED] 
   .EDU>   
   
   




After a decade of parallel sysplexing, I feel like a rookie with log
streams. Up to now we've used system logger only for CICS and RRS. No
operlog, no logrec. So we've never had to deal with the question of how to
handle real data that needs to be kept (archived), massaged, and cleaned
up.

I'm now playing with the new SMF log stream available in z/OS 1.9. Not many
folks have done this yet, but I think the problems are similar to other
data-type log streams. Capturing the SMF data in a CF structure is easy.
Logger writes the data out to data sets of the form 'hlq.IFASMF.xxx' where
you choose the qualifier and tell the system what the name is. There is a
new dump utility called IFASMFDL.

Here's the problem. IFASMFDL does most of what IFASMFDP does (and more),
but what it *doesn't* do is clear out the dumped SMF data. In other words,
after archiving the contents of a log stream to a flat file, the now dumped
records are still sitting just where they were. A subsequent run of
IFASMFDL appears to pick up the same records all over again. The output
file just gets bigger and bigger each time the dump is run.

For those of you who use system logger for operlog or logrec, how do you
clean up log streams so that you get one and only copy of all the data
produced?

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]

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



The contents of this e-mail are confidential. If you have received this 
communication by mistake, please advise the sender immediately and delete the 
message and any attachments. Nothing in this email designates an information 
system for the purposes of Section 11(a) of the New Zealand Electronic 
Transactions Act 2002. Westpac New Zealand Limited.

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

Re: Data Erasure Products

[Ed Gould]

On Jan 31, 2008, at 5:15 PM, SUBSCRIBE IBM-MAIN Niall wrote:

---SNIP---
Unless there is some weird legislative standard which says that  
encryption is
fine for transmission of data over open IP networks, but is not  
fine for

resundant data held on permanent storage.


OK.. but what encryption? and how many bytes of key are mandatory? 1  
byte, 64 bytes or ?
I do not pretend to know the answer, but for me if its really secure  
it doesn't go over an IP network I don't care how many bytes are in  
the encryption key.
The IP (INTERNET) network was never meant to be a secure way of  
transferring data. *MAYBE* if its a private one and there are  
appropriate safe guards but *NOT* the Internet.


I heard of a place in Switzerland that used a new kind of encryption  
that is anybody even copied(looked) at the data the the receiver was  
notified and the data was effectively vaporized. I believe the Swiss  
believe in security and when they go to this extreme just to transmit  
vote type data you can believe its secure.


Ed






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

Re: Data Erasure Products

[Ed Gould]

On Jan 31, 2008, at 3:31 PM, Stephen Mednick wrote:


--SNIP
The downside of physically destroying the media as against using a  
certified
erase solution to remove the contents is that the obsolete storage  
media can
never be acquired on a lease-basis given that the box is not going  
to be able to
be returned intact when the lease would have expired. For storage  
subsystems that
have been purchased, there's no way that any residual value that  
the box might

contain can be realised.

Using a secure storage santisation or overwriting methodology, once  
the data has
been removed, it's then possible to put out requests to second hand  
equipment
dealers to submit an offer to acquire the box and remove it and at  
least get some

dollars back.



Stephan:

It comes down purely (IMO) how valuable the data is. If its nuclear  
bomb data (or the like) then I would suggest that cost is not an issue.
If its secure type data (ie HIPAA(sp?) or payroll or bank files) it  
is different . Each one probably has its own requirements. I am not a  
lawyer (and don't profess to be one). I would suggest that if there  
is any question get a lawyer to sign off on it or/in addition to the  
government agency that has jurisdiction in the area.


Ed

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

Managing system logger data

[Skip Robinson]

After a decade of parallel sysplexing, I feel like a rookie with log
streams. Up to now we've used system logger only for CICS and RRS. No
operlog, no logrec. So we've never had to deal with the question of how to
handle real data that needs to be kept (archived), massaged, and cleaned
up.

I'm now playing with the new SMF log stream available in z/OS 1.9. Not many
folks have done this yet, but I think the problems are similar to other
data-type log streams. Capturing the SMF data in a CF structure is easy.
Logger writes the data out to data sets of the form 'hlq.IFASMF.xxx' where
you choose the qualifier and tell the system what the name is. There is a
new dump utility called IFASMFDL.

Here's the problem. IFASMFDL does most of what IFASMFDP does (and more),
but what it *doesn't* do is clear out the dumped SMF data. In other words,
after archiving the contents of a log stream to a flat file, the now dumped
records are still sitting just where they were. A subsequent run of
IFASMFDL appears to pick up the same records all over again. The output
file just gets bigger and bigger each time the dump is run.

For those of you who use system logger for operlog or logrec, how do you
clean up log streams so that you get one and only copy of all the data
produced?

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]

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

Re: Data Erasure Products

[Ed Gould]

On Jan 31, 2008, at 2:29 PM, George Fogg wrote:


I have worked at several top secret installations in the past and I  
was told
that they take the old DASD and drop them in a acid bath then cut  
them up.

Never saw it happened so not totally sure it was done or not.
George Fogg




George,

Well it would put an end to any thought of recovery that is for sure.  
Of course there was a TV episode about an acid bath  and they did  
figure out the persons identity after it but that is TV for you.
I wish I had a chance to ask an (now) ex-IBMer about this as it is an  
interesting issue. I am sure that security means different things to  
different people/companies.
I would think the government has some sort of guidelines in this area  
as to how erase the data. What gets interesting on the "new" type of  
DASD is that the platters are not used for "permanent" DASD to me it  
is like a virtual dasd volume (much like the 3850). The security  
"erasure" would be a lot different in those types of equipment as  
data is never actually deleted just pointers are "evaporated". I  
would hope the manufacturer would have a really good erase program  
(procedure).



Ed

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

Re: Migration from Mainframe to othre platforms - the othe bell?

[John S. Giltner, Jr.]

Opps, posted to the news group by accident.

I will try and find the link, or you may find it when you do the Google,
but there has been an update.

The original migration to the mainframe was using IFL's on their
existing IBM mainframes.  After 1 year they had something like 700
virtual images, 200+/- production and the rest TEST and QA systems.

They figured that they were going to save so much money from NOT having
to upgrade their two data centers, reducing their environmental costs,
reducing their software licensing fees, and reducing networking
equipment costs, that they purchased 2 z9's just for the purpose of
running Linux on zSeries.  I can't remember exactly how many images they
had on the z9's, but I think it was over 1,000.

Kelman, Tom wrote:

Are you interested in just z/OS stories or in stories about mainframe
Linux also?  One big story back in 2006 was the one about Nationwide
Insurance moving the processing from 400 servers to 2 IBM z900 Linux
systems.  At the time they estimate the savings to by $15 million over 3
years.  Here is one article on it or you can Google "nationwide linux"
to get some more.

http://www.linux.com/feature/59984



Tom Kelman
Commerce Bank of Kansas City
(816) 760-7632

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mautalen Juan Guillermo
Sent: Thursday, January 31, 2008 7:58 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Migration from Mainframe to othre platforms - the othe bell?





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

Re: Metal C

[Edward Jaffe]

Tony Harminc wrote:

Then it seems that METAL inhibits use of the ARCH option, so METAL C must
generate code at the ARCH(CURRENT) level, which means it can (and does) use
LARL and the like from the long displacement facility. Well, no, actually it
accepts ARCH(5), which says is the default and generates code at the
z900/z800 level, but it still generates LARL, which I don't believe is
architected at that level.
  


LARL was added to the ESA/390 instruction set implemented on the very 
first machines supporting z/Architecture.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Young mainframers' group gains momentum

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.


Young mainframers' group gains momentum
http://www.networkworld.com/news/2008/013108-young-mainframers-group-gains.html
Young mainframers' group gains momentum
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9060499

from above:

ZNextGen, an organization aimed at young mainframe programmers, has
gained significant momentum since it was created roughly two years ago
through IBM and its user group, Share, according to its leaders.

... snip ...

SHARE zNextGen
http://www.znextgen.org/

from above:

zNextGen, a user-driven community for new and emerging System z
professionals that has the resources to help expediate your professional
development skills.

... snip ...

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

Re: Data Erasure Products

[SUBSCRIBE IBM-MAIN Niall]

There are several data protection standards applying over here in Europe, but 
I would guess that I could at least  defend myself to SOX auditors if I chose 
to use encryption in the scenarios I described. Alas, your mileage may vary in 
all of these things.  

My interest in the subject is at the theoretical one, which would hold that an 
adequate standard of encryption should allow you to leave data wherever it 
lies and not to worry about it so long as the finder doesn't have the key.

Thanks for the replies!

Niall

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

Re: Data Erasure Products

[Stephen Mednick]

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of SUBSCRIBE IBM-MAIN Niall
> Sent: Friday, 1 February 2008 10:16 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Data Erasure Products
> 
< SNIP >
> But none of these anecdotes answer my question: would you 
> feel happy after, for instance, a DR test, to know that the 
> DASD you used contained only encrypted data and that the 
> VTOC's had been overwritten? More importantly, would this 
> ensure compliance with the standards required?
> 
> I ask because ther seems to be a couple of contradictory 
> issues involved: in some jurisdictions a standard of 
> encryption is considered to be a requirement when sending 
> data offsite, be it over the wires or in some other portable 
> format. In other words, the authorities accept that once it 
> has been encrypted and adeqaute care is taken over key 
> exchange, then you have fulfilled the requiremnts to protect 
> your data. Yet deleted data seems to require another standard 
> - or does it?
> 
> In the same vein, if you are decommisioning DASD, or removing 
> yourself from a hot-site, would encrypting your data be 
> adequate both to satisy compliancy requirements and to make 
> you feel comfortable yourelves? I assume the re-init at the 
> least of the volumes afterwards, of course. Even the entries 
> of a VTOC could be valuable.
> 
< SNIP >

Your idea would appear to have some merit but I am not aware of any facility to
be able to encrypt data in-place (I may be wrong) and from my knowledge, it's
usually the case that the data is to be read through an encryption facility,
apply an encryption key and then write out the encrypted data.

Therefore, I can't see how you could conceivably encrypt existing data in-place.
If using a software encryption tool, there is usually a high price to pay in
terms of CPU cycles to undertake the encryption process and to try and encrypt 
an
entire volume could prove fairly costly, time-wise at the completion of a DR
exercise. 

Compare the time to encrypt in the manner you are suggesting to a software
product that is quoted as being able to erase 3 Terrabytes of data in less than 
2
hours.

By the way, the folks on this list would probably appreciate it if you could 
sign
your posts.

Stephen Mednick
Marketing & Support Manager
Computer Supervisory Services
Tel: +61 (2) 9665 1104
Fax: +61 (2) 9665 7382

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

Metal C

[Tony Harminc]

I was looking forward to this, but now that I've found a little time to play
with it, I am a little puzzled.

There are options METAL and GENASM, and the doc says that METAL forces
GENASM, but when I try GENASM without METAL, I get 
CCN0458(S) Option GENASM is invalid because option METAL is not specified.

[Talk about a good error message - the "explanation" for CCN0458 says:
Explanation: The option &1 is only valid when used in conjunction with &2.
In the message text: &1 and &2 are both option names.
User Response: Compile with &2 or remove &1.]

So what is GENASM for if it can't be specified by itself?

Then it seems that METAL inhibits use of the ARCH option, so METAL C must
generate code at the ARCH(CURRENT) level, which means it can (and does) use
LARL and the like from the long displacement facility. Well, no, actually it
accepts ARCH(5), which says is the default and generates code at the
z900/z800 level, but it still generates LARL, which I don't believe is
architected at that level.

Anyway - there are plenty of other things to ask about, but I'm not sure
where the right place is. I don't think there's a System z C/C++ list...

Are other people actively using Metal C? I'd be interested in your experiences.

Tony H.

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

Re: Data Erasure Products

[Ted MacNEIL]

>Unless there is some weird legislative standard which says that encryption is 
>fine for transmission of data over open IP networks, but is not fine for 
resundant data held on permanent storage. 

I'm interpreting this from a Canadian perspective, but after working for a 
company headquartered in the US, I don't believe there are any legislative 
standards.

SOX, et al, say you have to protect your data.
They don't say how, since they are not IT professionals.

It's up to your:
SME's
Compliance officers
And, auditors -- external and internal.

-
Too busy driving to stop for gas!

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

Re: DFHSM ARC0184I error

[Art]

Rick & Dave,

I can not locate the tape to know what the dataset or for that matter if its 
really a alternate tape a migrated tape.. etc. In my search I have two other 
tapes that are prefixed with H** and took care of those but can not find the 
others..

If you know of anything else that I can try and/or look for. Please let me 
know. Thank you in Advance

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

Re: Migration from Mainframe to othre platforms - the othe bell?

[Ted MacNEIL]

>It was true back in the 90's that the mainframe was more expensive for most 
>customers.

I actually disagree with that.
Back then, PCs and *NIX platforms were a lot more expensive.
If you looked at cost per seat, and cost for support personell, the M/F was 
still cheaper.

The whole TCO argument has always been political.
In the PC/NIX world manpower is rarely counted.
It in on the M/F.

Also, BSOD resolution by the end-user is never counted, nor any of the extra 
work the user and the help desk does is never counted.

Rarely does a business (CICS) user under z/OS have to call for technical 
problems.
Under the others, most are technical.
And, the windows solution? Re-Image.

-
Too busy driving to stop for gas!

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

Re: Data Erasure Products

[SUBSCRIBE IBM-MAIN Niall]

I've heard from my Amdahl days that the decommissioned machines had to be 
destroyed rather than returned for their parts value - and that the destruction 
was pretty definitive.

But none of these anecdotes answer my question: would you feel happy after, 
for instance, a DR test, to know that the DASD you used contained only 
encrypted data and that the VTOC's had been overwritten? More importantly, 
would this ensure compliance with the standards required?

I ask because ther seems to be a couple of contradictory issues involved: in 
some jurisdictions a standard of encryption is considered to be a requirement 
when sending data offsite, be it over the wires or in some other portable 
format. In other words, the authorities accept that once it has been 
encrypted and adeqaute care is taken over key exchange, then you have 
fulfilled the requiremnts to protect your data. Yet deleted data seems to 
require another standard - or does it?

In the same vein, if you are decommisioning DASD, or removing yourself from a 
hot-site, would encrypting your data be adequate both to satisy compliancy 
requirements and to make you feel comfortable yourelves? I assume the re-init 
at the least of the volumes afterwards, of course. Even the entries of a VTOC 
could be valuable.

I'd be interested to se what the Innovation Data Processing people would 
have to say on this as they provide both encryption and erase products. One 
of them - short of huge performance factors which wouldn't really be an issue 
when decommisioning DASD- would appear to be redundant.

Unless there is some weird legislative standard which says that encryption is 
fine for transmission of data over open IP networks, but is not fine for 
resundant data held on permanent storage. 

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

Re: Migration from Mainframe to othre platforms - the othe bell?

[Dan Gillis]

I'd suggest that you do a seach on "mainframe TCO" on Google to get
some more information on this topic. I spend a lot of time at IBM
educating customers on what the true cost of ownership is for various
technology platforms they choose. It was true back in the 90's that
the mainframe was more expensive for most customers. Not true today
where the mainframe can be competitive or cheaper than other
platforms, of course depending on your own specific situation and
software.

Since I do this, I can probably also find a coworker of mine to run a
TCO study for your site. I can be reached directly at
[EMAIL PROTECTED]

Dan

On Jan 31, 2008 1:53 PM, Eric Bielefeld <[EMAIL PROTECTED]> wrote:
> I think I've mentioned this here before, but I used to work at P&H Mining 
> Equipment in Milwaukee.  They had a mainframe running SAP/R2, and several 
> other applications.  It was an MP3000-H50.  In the mid 90's, they bought Joy 
> Mining in Pennsylvania.  Joy converted their old 3081 to an Lpar on our 
> machine in Milwaukee back in 1996.  A few years later, Joy decided they 
> didn't want to go through a Y2K conversion, and still have all old software.  
> They converted everything to SAP/R3, and got off our mainframe in early 1999.
>
> When SAP said that if we ran P&H on the same equipment that Joy was using, 
> they would not charge us for new SAP licenses.  This eliminated a huge cost, 
> and P&H decided to convert to SAP/R3 and run it in Pennsylvania.  The project 
> took just under 2 years when it finally got started till they turned the 
> mainframe off.  There was some pain at first, but the conversion as a whole 
> went very well.  According to management, they saved a bundle of money not 
> having to pay for 2 datacenters, no z/OS software and hardware, etc.  Eleven 
> people, including myself and my boss were eliminated, although one retired, 
> and a couple found jobs within the company.  One of those people got a job at 
> higher pay as a forklift operator!
>
> You can get off the mainframe and save money!  Having a company with a 
> datacenter already set up and running was a big help though.  I'm sure that 
> had that not been the case, it would have taken at least a year or so more 
> time to convert.
>
> Eric
>
>  Michael Saraco <[EMAIL PROTECTED]> wrote:
> >
> > In the end I have never heard of any shop getting off of the mainframe and
> > saving money. I don't know maybe there is savings after one or two hundred
> > years.
> >
> --
> Eric Bielefeld
> Systems Programmer
> Aviva USA
> Des Moines, Iowa
> 515-645-5153
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
READ CAREFULLY. By reading this email, you agree, on behalf of your
employer, to release me from all obligations and waivers arising from
any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I
have entered into with your employer, its partners, licensors, agents
and assigns, in perpetuity, without prejudice to my ongoing rights and
privileges. You further represent that you have the authority to
release me from any BOGUS AGREEMENTS on behalf of your employer.

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

Re: VLF - What's in your VLF

[George Fogg]

> What are the entries in your VLF that give your system a big performance
> boost?
>
Class names CSVLLA, IKJEXEC, IGGCAS, and for RACF, IRRGTS, IRRACEE, IRRGMAP,
IRRUMAP and IRRSMAP.
George Fogg

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

VLF - What's in your VLF

[John Norgauer]

What are the entries in your VLF that give your system a big performance
boost?

John Norgauer
University of California Davis Medical Center
2315 Stockton Blvd
ASB 1300
Sacramento, Ca 95817
916-734-0536

 SYSTEMS PROGRAMMING..  Guilty, until proven innocent !! "JN  2004

"Hardware eventually breaks - Software eventually works"  anon


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

Re: BPXAS RC=255

[Skip Robinson]

What a coincidence. We IPLed a sandbox system this morning and saw a
similar problem with SSHD. It appeared to us that OMVS had not yet fully
initialized. Automation complained about SSHD, and several minutes later it
was (re)started manually with no problem. The original return code 255 may
just be a simple-minded representation of the -1 that Unix is famous for.

Our case plus the FTPD case has made us rethink the trigger for
OMVS-dependent tasks. For whatever reason, we have historically triggered
some of these tasks on TCP/IP initialization. But IP seems to come up
earlier than it used to--this was a 1.9 system. We're now looking at
triggering on this message:

BPXI004I OMVS INITIALIZATION COMPLETE

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]


   
 John Hooper   
 <[EMAIL PROTECTED] 
 .COM>  To 
 Sent by: IBM  IBM-MAIN@BAMA.UA.EDU
 Mainframe  cc 
 Discussion List   
 <[EMAIL PROTECTED] Subject 
 .EDU> BPXAS RC=255
   
   
 01/31/2008 07:27  
 AM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 <[EMAIL PROTECTED] 
   .EDU>   
   
   




We had an occurrence where BPXAS on behalf of FTPD ended with a return
code of 255.  There were no error messages in SYSLOG or the log for BPXAS.

There were no software records in Logrec.  It appears that it stopped as it

normally does but had this return code.  Nothing appears to have failed.  I

know very little about this process - it just works.  Our AO product caught
the
return code and, of course, they want an explanation.  Has anyone else seen

this return code or know where they are documented.  I have looked on
IBMLINK, Google, and IBM-Main.  Help!!

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

Re: Migration from Mainframe to othre platforms - the othe bell?

[tony babonas]

Hey, that's great news!  I used to run a forklift... 




-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Eric Bielefeld
Sent: Thursday, January 31, 2008 3:54 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Migration from Mainframe to othre platforms - the othe bell?

SNIP 

  One of those people got a job at higher pay as a forklift operator!  







You can get off the mainframe and save money!  Having a company with a
datacenter already set up and running was a big help though.  I'm sure that
had that not been the case, it would have taken at least a year or so more
time to convert.

Eric

 Michael Saraco <[EMAIL PROTECTED]> wrote: 
> 
> In the end I have never heard of any shop getting off of the mainframe and

> saving money. I don't know maybe there is savings after one or two hundred

> years. 
> 
--
Eric Bielefeld
Systems Programmer
Aviva USA
Des Moines, Iowa
515-645-5153

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

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.17/1253 - Release Date: 1/31/2008
9:09 AM
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.17/1253 - Release Date: 1/31/2008
9:09 AM
 

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

Re: Migration from Mainframe to othre platforms - the othe bell?

[Eric Bielefeld]

I think I've mentioned this here before, but I used to work at P&H Mining 
Equipment in Milwaukee.  They had a mainframe running SAP/R2, and several other 
applications.  It was an MP3000-H50.  In the mid 90's, they bought Joy Mining 
in Pennsylvania.  Joy converted their old 3081 to an Lpar on our machine in 
Milwaukee back in 1996.  A few years later, Joy decided they didn't want to go 
through a Y2K conversion, and still have all old software.  They converted 
everything to SAP/R3, and got off our mainframe in early 1999.  

When SAP said that if we ran P&H on the same equipment that Joy was using, they 
would not charge us for new SAP licenses.  This eliminated a huge cost, and P&H 
decided to convert to SAP/R3 and run it in Pennsylvania.  The project took just 
under 2 years when it finally got started till they turned the mainframe off.  
There was some pain at first, but the conversion as a whole went very well.  
According to management, they saved a bundle of money not having to pay for 2 
datacenters, no z/OS software and hardware, etc.  Eleven people, including 
myself and my boss were eliminated, although one retired, and a couple found 
jobs within the company.  One of those people got a job at higher pay as a 
forklift operator!  

You can get off the mainframe and save money!  Having a company with a 
datacenter already set up and running was a big help though.  I'm sure that had 
that not been the case, it would have taken at least a year or so more time to 
convert.

Eric

 Michael Saraco <[EMAIL PROTECTED]> wrote: 
> 
> In the end I have never heard of any shop getting off of the mainframe and 
> saving money. I don't know maybe there is savings after one or two hundred 
> years. 
> 
--
Eric Bielefeld
Systems Programmer
Aviva USA
Des Moines, Iowa
515-645-5153

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

Re: Data Erasure Products

[Stephen Mednick]

 

> -Original Message-
> > Ed
> I have worked at several top secret installations in the past 
> and I was told that they take the old DASD and drop them in a 
> acid bath then cut them up.
> Never saw it happened so not totally sure it was done or not.
> George Fogg
> 

Physical destruction of DASD such as that described by George is probably the
"purest" form of data destruction. However, if my understanding of the various
compliance requirements is correct, it would need to be witnessed by someone 
from
the owning organisation in order to provide formal verification.

The downside of physically destroying the media as against using a certified
erase solution to remove the contents is that the obsolete storage media can
never be acquired on a lease-basis given that the box is not going to be able to
be returned intact when the lease would have expired. For storage subsystems 
that
have been purchased, there's no way that any residual value that the box might
contain can be realised.

Using a secure storage santisation or overwriting methodology, once the data has
been removed, it's then possible to put out requests to second hand equipment
dealers to submit an offer to acquire the box and remove it and at least get 
some
dollars back.

Stephen Mednick
Computer Supervisory Services
Sydney, Australia

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

Re: COBOL OUTDD(SYSOUT)

[Farley, Peter x23353]

I stand corrected.  OUTDD and MSGFILE are not related at all, and indeed
there seems to be no prohibition nor error in specifying different OUTDD
ddnames for different COBOL programs in the same enclave.  I just tested
a simple main program and subprogram with different OUTDD values at
compile time and unique DISPLAY statements, and both DD's were properly
written to, and the LE MSGFILE output (via
PARM='/RPTOPTS(ON),MSGFILE(CEEMSG)') went to a third DD, with no affect
on the COBOL OUTDD's at all.

Ya learn somthin' new every day...  Ain't it grand?

Thanks.

Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Bill Klein
> Sent: Thursday, January 31, 2008 3:44 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Fw: COBOL OUTDD(SYSOUT)
> 
> I see nothing at:
> 
>
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG32/2.4.
39
> 
> that says that you can't have different OUTDD values for different
> programs
> within a single load module (or dynamic call sequence).  If you want
the
> specific DD to be "in" the program, add a
> 
>   Process Outdd(whatever)
> 
> before your identification division of each program that you want to
use
> "myfile".
This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.

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

Re: New Opcodes

[Tom Schmidt]

On Fri, 25 Jan 2008 13:12:22 -0800, Keith E. Moe wrote:
>Second, there was one mnemonic that caught my eye.  I do not know what 
it does, but it's probably one that none of us will forget:  PTF.
 
 
Are you certain that it wasn't PTFF (which was already described in the 
current Principles of Operations -05 pub)?  If so there's no NDA worries.  
  
 
I'm still waiting for MVCOS to finally make it out into the PoO... it was 
"leaked" 
pretty thoroughly a few SHAREs ago in several IBM sessions but didn't make it 
into either of the last 2 PoOs.  (I don't care about what issues caused it to 
be 
late, I just want it to be born after all this time.)  
 
-- 
Tom Schmidt 
 

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

Fw: COBOL OUTDD(SYSOUT)

[Bill Klein]

I see nothing at:
 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG32/2.4.39 

that says that you can't have different OUTDD values for different programs
within a single load module (or dynamic call sequence).  If you want the
specific DD to be "in" the program, add a

  Process Outdd(whatever)

before your identification division of each program that you want to use
"myfile".


"Farley, Peter x23353" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Radoslaw,
> 
> In your JCL PARM specify the LE runtime option MSGFILE(yourdd), for COBOL
like this:
> 
> //STEP01 EXEC PGM=yourcobolprogram,PARM='yourpgmparms/MSGFILE(NEWOUTDD)'
> //NEWOUTDD DD SYSOUT=*
> 
> I don't believe there is a way for different COBOL programs in the same LE
enclave to use different OUTDD/MSGFILE names.  I also don't believe that the
name can be dynamically changed, but I could be mistaken about that.  You'd
need to check the available LE callable functions to see if there are any to
do that (LE Language Reference and/or Programming Guide).
> 
> HTH
> 
> Peter
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> > Behalf Of R.S.
> > Sent: Thursday, January 31, 2008 11:39 AM
> > To: IBM-MAIN@BAMA.UA.EDU
> > Subject: COBOL OUTDD(SYSOUT)
> > 
> > The compiler option default is OUTDD(SYSOUT).
> > 
> > Q1: Is there corresponding runtime option?
> > Q2: Can I specify other ddname for the above in COBOL program ?
> > 
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> > 
> > 
> > --
> > BRE Bank SA
> > ul. Senatorska 18
> > 00-950 Warszawa
> > www.brebank.pl
> > 

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

Re: Data Erasure Products

[Stephen Mednick]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Pat Mihalec
> Sent: Friday, 1 February 2008 7:04 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Data Erasure Products
> 
> I have used FDR Erase. It is easy to install and use. We last 
> used it after a DR test.
> Not too expensive.
> 
> Pat Mihalec
> Rush University Medical Center
> Senior System Programmer
> (312) 942-8386
> [EMAIL PROTECTED]
> 

Just to let people know, Innovation Data Processing's FDRERASE/OPEN has just now
acquired formal CCEVS accreditation with a conformance claim of EAL2 Augmented
with ALC_FLR.2 .

The details of the validation can be viewed at the following link:

http://niap-ccevs.org/cc-scheme/st/index.cfm/vid/10232

For those who are interested, the CCEVS accreditation details for the existing
FDRERASE for z/OS can be viewed at the following link:

http://niap-ccevs.org/cc-scheme/st/index.cfm/vid/10064

Stephen Mednick
Computer Supervisory Services
Sydney, Australia

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

Re: Data Erasure Products

[Gary Green]

My uncle did design work on satellites and all his top secret work took
place in a vault.  When it came time to replace/erase his personal disk
drives, all of them were physically crushed into a cube as I recall.


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of George Fogg
Sent: Thursday, January 31, 2008 3:29 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Data Erasure Products

> On Jan 31, 2008, at 3:48 AM, SUBSCRIBE IBM-MAIN Niall wrote:
>
>> How about encrypting the volume in its entirety before deletion?
>>
>> I've been through the DR/deletion exercise a few times, and used an 
>> in-house utility to overwrite the disk. If available, however, would 
>> encryption not be a possible solution in that even if a shadow of the 
>> data were left, it should at least be in a format that is not 
>> readable?
>>
>> I ask because some sites may already have invested in an encryption 
>> tool, and it might be an imaginative use of an existing asset.
>>
> I vaguely remember a story here I cannot remember where I heard it (it 
> may be an urban legend).
> *SUPPOSEDLY* the CIA (NSA??) was able to read a disk even after data 
> has been written on it, even after 10 or 11 times.
>
> I have heard this but where? I do *NOT* know if this is true or not.
>
> Ed
I have worked at several top secret installations in the past and I was told
that they take the old DASD and drop them in a acid bath then cut them up.
Never saw it happened so not totally sure it was done or not.
George Fogg

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

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

Re: Data Erasure Products

[George Fogg]

> On Jan 31, 2008, at 3:48 AM, SUBSCRIBE IBM-MAIN Niall wrote:
>
>> How about encrypting the volume in its entirety before deletion?
>>
>> I've been through the DR/deletion exercise a few times, and used an
>> in-house
>> utility to overwrite the disk. If available, however, would
>> encryption not
>> be a possible solution in that even if a shadow of the data were
>> left, it
>> should at least be in a format that is not readable?
>>
>> I ask because some sites may already have invested in an encryption
>> tool,
>> and it might be an imaginative use of an existing asset.
>>
> I vaguely remember a story here I cannot remember where I heard it
> (it may be an urban legend).
> *SUPPOSEDLY* the CIA (NSA??) was able to read a disk even after data
> has been written on it, even after 10 or 11 times.
>
> I have heard this but where? I do *NOT* know if this is true or not.
>
> Ed
I have worked at several top secret installations in the past and I was told
that they take the old DASD and drop them in a acid bath then cut them up.
Never saw it happened so not totally sure it was done or not.
George Fogg

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

Re: Job ad for z/OS systems programmer trainee

[Gary Green]

Well, all us write in our resumes that we "look for a challenge".  From that
position profile, I can't think of anything more challenging.  :)

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Ed Gould
Sent: Thursday, January 31, 2008 3:07 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Job ad for z/OS systems programmer trainee

Mark,

a *LONG*  time ago early 1990's I interviewed for a job out in California
that was well to say the least different. This was a systems programmer job
that was at a data center that worked with top secret data. You were
expected to debug vendor code yet not talk with the vendor. I asked for
details and they basically said you were expected to find the bug and fix it
yourself without calling the vendor (even IBM). I practically ran from the
job.

Ed

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

Re: Job ad for z/OS systems programmer trainee

[Ed Gould]

On Jan 31, 2008, at 7:45 AM, Mark H. Young wrote:


---SNIP-
NO, I meant "level 2 support" like IBM and OTHER vendors (OEM) have  
THEIR
level 2 support (which is usually the developers, or AT LEAST some  
coders).
Vendors' help desk is level one support, who you call in to or who  
read your

problem ticket for the first time, and then you go to LEVEL 2.

Regards,
Mark



Mark,

a *LONG*  time ago early 1990's I interviewed for a job out in  
California that was well to say the least different. This was a  
systems programmer job that was at a data center that worked with top  
secret data. You were expected to debug vendor code yet not talk with  
the vendor. I asked for details and they basically said you were  
expected to find the bug and fix it yourself without calling the  
vendor (even IBM). I practically ran from the job.


Ed

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

Re: Data Erasure Products

[Pat Mihalec]

I have used FDR Erase. It is easy to install and use. We last used it 
after a DR test.
Not too expensive.

Pat Mihalec
Rush University Medical Center
Senior System Programmer
(312) 942-8386
[EMAIL PROTECTED]

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

Re: Data Erasure Products

[Ed Gould]

On Jan 31, 2008, at 3:48 AM, SUBSCRIBE IBM-MAIN Niall wrote:


How about encrypting the volume in its entirety before deletion?

I've been through the DR/deletion exercise a few times, and used an  
in-house
utility to overwrite the disk. If available, however, would  
encryption not
be a possible solution in that even if a shadow of the data were  
left, it

should at least be in a format that is not readable?

I ask because some sites may already have invested in an encryption  
tool,

and it might be an imaginative use of an existing asset.

I vaguely remember a story here I cannot remember where I heard it  
(it may be an urban legend).
*SUPPOSEDLY* the CIA (NSA??) was able to read a disk even after data  
has been written on it, even after 10 or 11 times.


I have heard this but where? I do *NOT* know if this is true or not.

Ed

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

Re: Shark to EMC

[Ted MacNEIL]

>Now you can download the new MFNetDisk with the support of MIDAW.

Maybe, I'm too picky.
But, all I've seen from this poster is stuff about the product.

-
Too busy driving to stop for gas!

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

Common Criteria security (was: DB2 queries without using MF.)

[Wayne Driscoll]

Ron, 
I also am an MF bigot, but also realize that we live in a wide world,
and that far too many people who should know better sometimes have a
tendency to view the IT world as z/OS vs Windows, when in reality there
are a lot of UNIX servers that are approaching in many ways, and
surpassing in others, the mainframe.  As for security, since z/OS with
RACF has had EAL 3+ since 1.6 and (as Walt Farrell pointed out) has had
EAL 4+ since 1.7, I would assume that CA is working on this, but I have
no knowledge either way.  Also, I do not know if IBM has submitted any
version of RACF for z/VM for certification.  Also, one must keep in mind
that just because the base operating system and security system has been
certified as EAL 4+ (or whatever), it doesn't mean that it isn't
possible (or even difficult) to configure the system in a very unsecure
fashion.

Wayne Driscoll
Product Developer
JME Software LLC
NOTE:  All opinions are strictly my own.




-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ron Hawkins
Sent: Thursday, January 31, 2008 12:29 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DB2 queries without using MF.

Wayne,

Thanks for correcting me. I am a MF bigot, but I am also a realist. Do
you
know if z/OS with RACF is the only server/software combination that has
these certification? One quick Google gave me this at the top of the
page:

http://www-03.ibm.com/industries/government/doc/content/news/pressreleas
e/10
12559109.html

and this later on

http://www.sun.com/smi/Press/sunflash/2005-10/sunflash.20051026.4.xml

If we follow some of the arguments in this thread, if SUN get EAK4
before
IBM we should jump over to Solaris as quickly as we can.

My real point is that z/OS is not necessarily streets ahead in security
anymore. To use this as an argument to maintain the mainframe may
backfire
when Solaris, AIX or HP-UX leapfrog z/OS, which I'm sure they do on
occasions.


Ron




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Wayne Driscoll
> Sent: Thursday, January 31, 2008 7:30 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: [IBM-MAIN] DB2 queries without using MF.
> 
> Ron,
> With regard to "AFAIK it's been a long time since RACF had any sort of
> special security
> rating, and even then you had to disconnect the network", Since z/OS
> 1.6
> RACF has had CAPP EAL 3+ certification, and LSP EAL 3+ certification.
> Your above comment relates to the old DOD B1 rating that RACF, with a
> specific set of hardware devices and software service levels, and
> multi-level security (MLS, ie labeling, levels and categories) active,
> received in the early 90's.  The old "Orange Book" ratings are
> outdated,
> and have been replaced by the EAL Common Criteria.  For more info,
see:
> http://www-03.ibm.com/systems/z/security/ccs_certification.html
> 
> Wayne Driscoll
> Product Developer
> JME Software LLC
> NOTE:  All opinions are strictly my own.
> 
> 
> 

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

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

Re: Migration from Mainframe to othre platforms - the othe bell?

[Howard Brazee]

Training employees works when the expectation by both employers and
employees is for career employees.   Both sides need to favor the long
term over the short term.


Training a workplace works when expectation by both tax-payers and
tax-beneficiaries is long term.   When politicians and voters are more
concerned with the near term, big deficits are preferred over
preparing the next generation.

It's not just mainframe users that are concerned only with now.

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

Re: Shark to EMC

[shai hess]

HI,

Now you can download the new MFNetDisk with the support of MIDAW.

Some of the people assume that this product is a toy, OK but it can do all
the important tasks of EMC, HDS and IBM disk and also some tasks of backup
(in the PC), DR in no time, mirroring to any real disk (EMC, HDS and IBM),
3390 emulations, replace of OEM real disk with another OEM without downtime
or performance degradation, incremental track backup (track no file!),
Sharing 3390 disks among MF and MF emulation, sharing 3390 from any distance
without any hardware, PC API do read MVS file from PC Server from any PC
without any MVS involvement and more.

The bitmap file MPCLOG RECFM is changed from RECFM=U to RECFM=F. Action is
required. More information in the FIXINFO file in my site.

Thanks,

Shai


On 1/31/08, shai hess <[EMAIL PROTECTED]> wrote:
>
>
> HI,
>
> Yes, there are many ways to move data from one disk to another.
>
> Easer and a free way are to use MFNetDisk ability to copy disks to other
> disks without any cost and without any hardware and without any downtime for
> the source disks.
>
> The status of MFNetDisk is that the IBM MIDAW is under testing, and we
> prepare the product to production.
>
> Some of the MVS MFNetDisk parameters will be changed (SYNCDEV will be
> ASYNCMRR, and FstSync will be SYNCMRR). Better MFNetDisk MVS traces, Better
> documentation and better and faster code. Now it is the time to try the
> product. This is not anymore a beta product.
>
>
> Thanks,
> Shai
>  On 1/30/08, Ron Hawkins <[EMAIL PROTECTED]> wrote:
> >
> > Tom,
> >
> > You can virtualise both boxes behind HDS USP-VM and mirror from Shark to
> > EMC
> > using TrueCopy or HUR.
> >
> > Ron
> >
> > >
> > > I would think that the only way to mirror in a multi-vendor
> > environment
> > > would be XRC.  The reason is because all the replication goes through
> > > the
> > > system mover and thus is at a higher level than the bare metal.
> > >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
>
>

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

Re: Timeout to server printer software after IP change

[Johnston, Robert E]

Thanks to everyone who replied on and off list. We've been looking at all the
suggestions. Now it looks like we may have a resolution.

One of our server guys has been working with McKesson on the problem.
Yesterday they found a 4 gig log file on the server that bothered them. They
renamed the log file and made a new one. We stayed in communication all night
with the server and everyone's reports were ready this morning. I'll still be
keeping my fingers crossed for a few days.

Quite a coincidence that we start having this problem the night we converted
to 1.7 with IBM TCPIP, huh?

Thanks again to a great bunch of folks...
Robert

Confidentiality Notice: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and may contain confidential and 
privileged information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.

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

Re: Migration from Mainframe to othre platforms - the othe bell?

[Michael Saraco]

I have seen several shops get or try to get off the mainframe. The biggest 
reason the upper management gives for trying to get off the mainframe is 
no one coming out of college knows anything about the mainframe. When I 
was hired as a SYSPROG I had never seen a mainframe the company gave some 
test and asked if I wanted to learn the mainframe and I said yes. I was 
trained by older SYSPROGs. I am sure that is how most SYSPROGs got trained 
by their mentors. 
I have never seen a mainframe to whatever platform happen in budget or in 
the time frame that was sold to them. I have seen companies chunk millions 
at trying to get off of the mainframe when they could train the staff and 
exploit the mainframe for all of uses for decades. 
The 4 shops I know off personally that did or tried to get off the 
mainframe were all drive by upper management lack of understanding of the 
mainframe or a sales rep that came in told them they could get off the 
mainframe in 6 months and save them millions of dollars. What happened was 
what they said the cost would be multiply it by 20 to get close and if 
that does not drive the company into bankruptcy the added cost for all the 
floor space for all the servers, office space for all the additional staff 
to manage the server farms, and lets not forget all the extra cost of the 
software for every server and and every engine turned on on the server 
will unless they have a endless money pot.

In the end I have never heard of any shop getting off of the mainframe and 
saving money. I don't know maybe there is savings after one or two hundred 
years. 



From:
"Kelman, Tom" <[EMAIL PROTECTED]>
To:
IBM-MAIN@BAMA.UA.EDU
Date:
01/31/2008 12:16 PM
Subject:
Re: Migration from Mainframe to othre platforms - the othe bell?



Are you interested in just z/OS stories or in stories about mainframe
Linux also?  One big story back in 2006 was the one about Nationwide
Insurance moving the processing from 400 servers to 2 IBM z900 Linux
systems.  At the time they estimate the savings to by $15 million over 3
years.  Here is one article on it or you can Google "nationwide linux"
to get some more.

http://www.linux.com/feature/59984



Tom Kelman
Commerce Bank of Kansas City
(816) 760-7632
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Mautalen Juan Guillermo
> Sent: Thursday, January 31, 2008 7:58 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Migration from Mainframe to othre platforms - the othe bell?
> 
> Hi,
> 
> I am full of reports, sent to Management, about completely succesfull
> conversions from the "old and expensive" "IBM Mainframe to other
> platforms. And, as you may know, the most important argument is that
the
> Mainframe is very expensive and the same level of processing, with the
> same degree of thrust, can be achieved in other platforms with much
less
> money. Of course, i dont beleive this, or at least i dont think things
> to be so simple. So, i want to collect some information to support the
> Mainframe side.
> 
> Are there somewhere on the web, as a counterpart of all the marketing
> flood about getting rid of the Mainframe, stories, reports or analysis
> of :
> 
> - Conversions (or Consolidations) from other platforms into
Mainframes.
> - Stories of unsuccessful migrations from Mainframe to other
platforms.
> - Serious and independant cost analysis between different solutions.
> - Serious and independant studies comparing the security level of the
> different platforms.
> 
> 
> Thanks in advance for your help,
> 
> 
> Juan G. Mautalen
> 
> 
> 
> El contenido del presente mensaje y sus anexos es privado,
confidencial y
> de exclusivo uso para el titular de la direccion de correo electronico
a
> quien esta dirigido. Puede contener informacion privilegiada o
amparada
> por el secreto profesional o por disposiciones legales y/o
reglamentarias
> vigentes. Cualquier modificacion, retransmision, diseminacion o
> divulgacion de su informacion se encuentra expresamente prohibida y su
uso
> inadecuado puede derivar en responsabilidad civil para el usuario o
> configurar los delitos previstos en los articulos 153 a 157 del Codigo
> Penal. Si no fuere uno de los destinatarios consignados o lo hubiere
> recibido por error, Ud. NO ESTA AUTORIZADO a utilizar total o
> parcialmente, copiar, enviar, revelar, imprimir, divulgar de manera
alguna
> el contenido del presente mensaje o el de sus adjuntos. En
consecuencia,
> tenga a bien comunicarselo inmediatamente al emisor y ELIMINARLO.
> ANSES no aceptara responsabilidad alguna por errores u omisiones
> emergentes del presente mensaje o sus adjuntos, ni garantiza la
seguridad,
> exactitud u oportunidad de lo transmitido por este medio debido a que
el
> mismo puede ser objeto de intercepcion, modificacion, retraso,
perdida, o
> bien de contener virus informaticos u otras anomalias.
> Asimismo, las opiniones expresadas en este mensaje son propias del
> remitente y no representan la 

Re: DB2 queries without using MF.

[Ron Hawkins]

Wayne,

Thanks for correcting me. I am a MF bigot, but I am also a realist. Do you
know if z/OS with RACF is the only server/software combination that has
these certification? One quick Google gave me this at the top of the page:

http://www-03.ibm.com/industries/government/doc/content/news/pressrelease/10
12559109.html

and this later on

http://www.sun.com/smi/Press/sunflash/2005-10/sunflash.20051026.4.xml

If we follow some of the arguments in this thread, if SUN get EAK4 before
IBM we should jump over to Solaris as quickly as we can.

My real point is that z/OS is not necessarily streets ahead in security
anymore. To use this as an argument to maintain the mainframe may backfire
when Solaris, AIX or HP-UX leapfrog z/OS, which I'm sure they do on
occasions.


Ron




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Wayne Driscoll
> Sent: Thursday, January 31, 2008 7:30 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: [IBM-MAIN] DB2 queries without using MF.
> 
> Ron,
> With regard to "AFAIK it's been a long time since RACF had any sort of
> special security
> rating, and even then you had to disconnect the network", Since z/OS
> 1.6
> RACF has had CAPP EAL 3+ certification, and LSP EAL 3+ certification.
> Your above comment relates to the old DOD B1 rating that RACF, with a
> specific set of hardware devices and software service levels, and
> multi-level security (MLS, ie labeling, levels and categories) active,
> received in the early 90's.  The old "Orange Book" ratings are
> outdated,
> and have been replaced by the EAL Common Criteria.  For more info, see:
> http://www-03.ibm.com/systems/z/security/ccs_certification.html
> 
> Wayne Driscoll
> Product Developer
> JME Software LLC
> NOTE:  All opinions are strictly my own.
> 
> 
> 

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

Re: TSO/REXX Does Not FREE Storage?

[Paul Gilmartin]

On Thu, 31 Jan 2008 13:30:12 +0100, Barbara Nitz <[EMAIL PROTECTED]> wrote:

>Not having seen the original post (did it only go to the newsfeed?),
>
... I see it in the archives.

>this sounds suspiciously like a problem that was reported in the
>early nineties and that took more than 2 or 3 years. Unfortunately
>for the life of me, I don't remember if it was fixed back then or
>if both the customer and I gave up frustrated after several years.
>
This feels like a case of dueling APARs.  An attempt to fix this
may have had as a side efect the problem I reported in OA17169:

INCORRECT STEM VARIABLE ASSIGNMENT AFTER REXX DROP FUNCTION

Due to the complexity of the fix and limited impact of the error
this APAR is being closed as a suggestion. This suggestion has
been accepted and will be considered for inclusion in a future
release or product.
.
The fix for this SUG APAR was shipped in the base for z/OS V1R9.

... and around we go again.

-- gil

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

Re: Shark to EMC

[Ron Hawkins]

Radoslaw,

I'm interpreting the original reference to mirroring to mean continuous
replication, and not a migration exercise. In this context PAS and TDMF are
solutions up to the Virtual Storage restrictions they have. For 100 volumes
they will probably be OK, but for 2000 volumes you will have some
challenges.

XRC is an option, but you need an active mainframe, Software licenses and
MIPS for the SDM at the remote site. This is not cost effective if the 2nd
site is a cold site.

To do replication at the storage level, Jasbir is faced with buying a new
DS8K from IBM or a DMX4 from EMC, along with all the disk drives and
software. Or he can use kit from resellers.

He has a third option where he can buy a two diskless controllers from HDS
and mirror between ESS and EMC that way. When the time comes to replace the
EMC or ESS then he will not have to buy from the big three. Once virtualized
the EMC DASD can be migrated to a brand new DS6K, a Clariion or a HP EVA
without dropping MVS. 

Virtualization can improve TCO over time because the backing storage becomes
a commodity and MVS users get a greater choice of storage vendor and type of
storage. Is it a same day return? Maybe not. But based on a 5 year TCO
covering your refresh cycle and lease/purchase choices it can be a better
mousetrap.

Ron




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of R.S.
> Sent: Thursday, January 31, 2008 8:54 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: [IBM-MAIN] Shark to EMC
> 
> Ron,
> First I wanted to say I like HDS solutions, including storage
> virtualization. I just wanted to complement your message, not to
> criticize you or HDS solutions. However you said the good news and I
> added the bad ones. 
> 
> Regarding PPRC, etc. - yes it is paid feature, usually with
> capacity-based price. However virtualization does not relieve it while
> simply adds additional cost.
> 
> Regarding SPOF in USP - I said about single point of disaster-like
> outage. Let's assume I have some ESS-A in location A and ESS-B in
> location B. I can virtualize it through USP in location A. I would need
> another USP in location B to be disaster-proof.
> 
> Regarding to original question - in fact we don't know what are the
> real
> need and - last but not least - constraints. I mean budget and
> acceptable outages.
> I know a method for one-time migration, which is cheap (FREE), and -
> depending on data type - does not require longer outage than for re-IPL
> + few minutes. It has definitely nothing to do with USP virtualization
> which is good for absolutely different needs (and it is good!).
> 
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 

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

Re: Migration from Mainframe to othre platforms - the othe bell?

[Kelman, Tom]

Are you interested in just z/OS stories or in stories about mainframe
Linux also?  One big story back in 2006 was the one about Nationwide
Insurance moving the processing from 400 servers to 2 IBM z900 Linux
systems.  At the time they estimate the savings to by $15 million over 3
years.  Here is one article on it or you can Google "nationwide linux"
to get some more.

http://www.linux.com/feature/59984



Tom Kelman
Commerce Bank of Kansas City
(816) 760-7632
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Mautalen Juan Guillermo
> Sent: Thursday, January 31, 2008 7:58 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Migration from Mainframe to othre platforms - the othe bell?
> 
> Hi,
> 
> I am full of reports, sent to Management, about completely succesfull
> conversions from the "old and expensive" "IBM Mainframe to other
> platforms. And, as you may know, the most important argument is that
the
> Mainframe is very expensive and the same level of processing, with the
> same degree of thrust, can be achieved in other platforms with much
less
> money. Of course, i dont beleive this, or at least i dont think things
> to be so simple. So, i want to collect some information to support the
> Mainframe side.
> 
> Are there somewhere on the web, as a counterpart of all the marketing
> flood about getting rid of the Mainframe, stories, reports or analysis
> of :
> 
> - Conversions (or Consolidations) from other platforms into
Mainframes.
> - Stories of unsuccessful migrations from Mainframe to other
platforms.
> - Serious and independant cost analysis between different solutions.
> - Serious and independant studies comparing the security level of the
> different platforms.
> 
> 
> Thanks in advance for your help,
> 
> 
> Juan G. Mautalen
> 
> 
> 
> El contenido del presente mensaje y sus anexos es privado,
confidencial y
> de exclusivo uso para el titular de la direccion de correo electronico
a
> quien esta dirigido. Puede contener informacion privilegiada o
amparada
> por el secreto profesional o por disposiciones legales y/o
reglamentarias
> vigentes. Cualquier modificacion, retransmision, diseminacion o
> divulgacion de su informacion se encuentra expresamente prohibida y su
uso
> inadecuado puede derivar en responsabilidad civil para el usuario o
> configurar los delitos previstos en los articulos 153 a 157 del Codigo
> Penal. Si no fuere uno de los destinatarios consignados o lo hubiere
> recibido por error, Ud. NO ESTA AUTORIZADO a utilizar total o
> parcialmente, copiar, enviar, revelar, imprimir, divulgar de manera
alguna
> el contenido del presente mensaje o el de sus adjuntos. En
consecuencia,
> tenga a bien comunicarselo inmediatamente al emisor y ELIMINARLO.
> ANSES no aceptara responsabilidad alguna por errores u omisiones
> emergentes del presente mensaje o sus adjuntos, ni garantiza la
seguridad,
> exactitud u oportunidad de lo transmitido por este medio debido a que
el
> mismo puede ser objeto de intercepcion, modificacion, retraso,
perdida, o
> bien de contener virus informaticos u otras anomalias.
> Asimismo, las opiniones expresadas en este mensaje son propias del
> remitente y no representan la opinion o politicas de ANSES y/o de
ningun
> empleado y/o funcionario de la organizacion. Por ende, ANSES no
asumira -
> en ningun caso- responsabilidad alguna frente al destinatario y/o
terceros
> en virtud de dichas comunicaciones y ademas, no sera responsable
frente a
> los usuarios por la correspondencia o los mensajes de correo
electronico
> enviados por terceros u otras personas distintas a ANSES, ya sea que
estos
> hubieren o no solicitado el envio de tales mensajes.
> ANSES se reserva el derecho de bloquear el acceso o remover en forma
> parcial o total todo mensaje y sus adjuntos que a su criterio pudiere
> resultar abusivo, difamatorio, obsceno, fraudulento, artificioso,
> enganoso,  ofensivo o violatorio a los terminos de la presente.
> PD:Tildes omitidas intencionalmente.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html




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

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is stri

Re: DFHSM ARC0184I error

[Adams, Rick]

Art,
   If these are alternate tapes this is a normal message.

ThanksRick

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Art
Sent: Thursday, January 31, 2008 11:08 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: DFHSM ARC0184I error

All, 

I issue this command:

LIST TTOC SELECT(hsm.volume)

I received several of these messages:

 ARC0184I ERROR WHEN READING THE DFSMSHSM CONTROL DATA SET X 
RECORD FOR H1, RC=0004
 
and not figured out on how to resolve. Has anyone gotten these messages 
and can recommend on how to resolve.

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

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

NPDA (was: How to suppress some informational VTAM messages ?)

[Patrick O'Keefe]

On Thu, 31 Jan 2008 10:31:33 -0500, Scott Ford 
<[EMAIL PROTECTED]> wrote:

>...  I think if my memory serves me correctly that
>NPDA was designed for usage with IBM modemsright ?
>...

One very small part of NPDA dealt with running tests on IBM modems.

The basic function of NPDA is/was to display hardware-generated
event data for devices in an SNA network.  The format of the the 
event data went through several interations.  I've forgotten more
than I ever knew about the first 2 - RECMS and RECFMS.  ("Record
Management Statistics" and "REcord Formatted Management
Statistics" maybe?)   There are still some hooks in MVS that convert
logrec OBR records to one of those.

The 3rd type of event record - still actively used - is definied as
part of the SNA architecture - SNA Management Services major
vector x'' - ALERT which is delivered in the SNA Request Unit
NMVT - Network Management Vector Transport.

The Alert vector has thousands of architected code points  for
description
possible causes
recommended corrective action
etc.  
in predefined subvectors that hardware and software use to 
describe exceptional conditions or resolutions from such conditions.

You can think of this as the SNA equivalent of SNMP.
Except the is no pretense that it is "simple".
And it's not limited to SNA devces.  MVS's DB2 generate these alerts.
So do some IBM printer abd DASD subsystems.
And there is a set of user code points and the NetView GENALERT
commands that lets you build your own for any situation you want.

Oh.  This was supposed to be about NPDA.  NPDA displays this data.

Pat O'Keefe



 

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

TWS HOST not reflecting FTA down

[Van Dalsen, Herbie]

Hi all,

Tivoli is great, but then again, sometime...

I have searched the web, but came up with nothing for this one...

We have z/890 Host and several Sun Solaris 10 FTA's

Last night we had a problem where the jobs were failing with OSUF, which
is understandable because the symphony file is not available because the
link is down, however on the Host's TSO interface this was not reflected
until after I had the OPS run a job to re-send the symphony to the
FTA's.

Has anyone had this problem before? I have seen a lot of the abends that
we got on the web with related PQn's but not for the release we
have. We have an idea why the link broke, but not why the HOST was not
reflecting the change in status.

Any Ideas will help.

Regards

Herbie
Elavon Financial Services Limited
Registered in Ireland: Number 418442
Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, 
Co. Dublin, Ireland
Directors: Robert Abele (USA), John Collins,  Terrance Dolan (USA),  Pamela 
Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson
Elavon Financial Services Limited, trading as Elavon, is regulated by the 
Financial Regulator

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

Re: AMATERSE available (was: TSO TRANSMIT ...)

[Robert Wright]

Mark Pace wrote:

It was a surprise to me when I went looking for it on my freshly installed
z/OS 1.9 system and it was not there.



Check SYS1.MIGLIB.  You should find AMATERSE there with its TRSMAIN 
alias.  MIGLIB is forced into the linklist, so you have access to it 
without a need for a STEPLIB.


Bob Wright - MVS Service Aids

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

DFHSM ARC0184I error

[Art]

All, 

I issue this command:

LIST TTOC SELECT(hsm.volume)

I received several of these messages:

 ARC0184I ERROR WHEN READING THE DFSMSHSM CONTROL DATA SET X 
RECORD FOR H1, RC=0004
 
and not figured out on how to resolve. Has anyone gotten these messages 
and can recommend on how to resolve.

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

Re: AMATERSE available (was: TSO TRANSMIT ...)

[Bob Shannon]

>It was a surprise to me when I went looking for it on my freshly installed 
>>z/OS 1.9 system and it was not there.

Look in SYS1.MIGLIB. It's on our 1.9 system and it was on the ESP beta's long 
before GA.

Bob Shannon
Rocket Software

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

Re: identify sas usage by component

[Gary Green]

I have not followed this thread so forgive if this was covered earlier...

Speaking off the top of my head (yeah, I know, I know...)

I need to leave aside the fact that any change to an OEM's SMF record
requires tweaking of any vendor record specific downstream processing.  If
all this processing is done in-house, that's no big deal.  A slight tweak to
Barry's MXG record definitions, could handle that.  If the data is sent to
the vendor, that is easy as well.  Just coble something together to reverse
the changes.

...

How about looking into writing an SMF Dump Program exit where you would
modify the OEM SMF records on the fly and use your own record-type/sub-type
numbering scheme.  As the records pass through your exit, you would modify
the appropriate records before they are written to the SMF dump tape/disk
file.

1. If the vendor's SMF record uses a header with the SMFxSTY (subtype)
field, dump a few thousand of their records to see if they actually use the
STY field or is the value constant.  If constant, it's possibly ripe for you
to use.  For this type of record, change the record type and subtype to your
liking. XX for the record type and yy for sub-type for vendor yy, and zz for
vendor zz and so on.

2. If the vendor's SMF record does not use a header with the SMFxSTY
(subtype) field (most likely), you have two options.
A. You could reformat the record header to make it support subtypes.
Allocate a buffer to rebuild the record, copy the existing original 18 byte
header and actual Vendor SMF record data to the appropriate area in the
buffer and change the record type then insert the subtype in the SSY field
to represent that specific vendor.  Of course, if the vendor's record uses
triplet fields, they would need to be modified as well.  I would review the
documentation from the vendor for this information.  As for the SSI field, I
would ignore it since it was never there in the first place.

B. You could use the SMFxFLG field.  I look at records all the time and "I"
do not recall ever seeing a vendor actually using this field; of course
YMMV.  That said, I dumped a  million SMF records between 128-255 they all
contain the same value; 1E in my case.  You could use this field for your
vendor specific sub-type value and then change the record type.  Of course,
this will only provide you a 16:1 reduction in used records types but that's
better than nothing. ;)

..

Now, if one were to entertain this idea, the big question is, if multiple
vendors use the same SMF record type, how does one distinguish one vendor's
record from the others that are using the same record type.  Generally,
there is almost always some type of eye-catcher in the record that would
give it away.

A simple branch table/array to identify the records to process.  In that
table/array you could have an offset to the eye-catcher location to
interrogate and another pointer to an array of values to compare against,
any one of which would be a hit.

JMTC...


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Ed Gould
Sent: Thursday, January 31, 2008 1:11 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: identify sas uage by component

Bruce,

Excellent point but what we found out that two many OEM programs had to be
altered to do this. The only way we could do it was to split all the user
SMF records off to another file (deleting them from the cumulative file.
Then we ran into auditing issues and were reluctant to buck heads with the
auditors. We asked the three vendors how to handle the situation they all
came back with different opinions. One was to time consuming to implement as
each time we got programs from them (about 3 times a year) we had to insert
logic to essentially delete the smf records in question. The logic entailed
changing 30 COBOL programs. In one case the other vendors were a little
cleaner and they were somewhat happy to have the records deleted before it
got to them but they both produced error messages that type XX were missing
and the accounting people weren't happy . Another vendor's code was set to
abend if they didn't get the records they were expecting. We could not win.
I suppose if its a home based system it might be easier but again depending
on what you are doing with them.  
All but one of the OEM vendor products supplied source  so yes we could
change it *BUT* the vendors would *NOT* support it. We thought we had tried
different options and none of them made everybody happy we were in a catch
22. We tried for an exemption and they would not hear of it. The one vendor
want to have the record layouts of every vendor that cut SMF records. That
was sort of OK but the lead time was at least 1 year. It got so bad between
the vendors and internal politics and legal (auditors) we thought of
creating two master tapes but that was a nightmare as the number of tapes
was depleting our tape library with just one set  if we had asked for more
we would have been told no in no u

Re: AMATERSE available (was: TSO TRANSMIT ...)

[Mark Pace]

On Jan 31, 2008 10:57 AM, John Eells <[EMAIL PROTECTED]> wrote:

> Paul Gilmartin wrote:
> > On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote:
> >> See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on
> z/OS
> >> R7 and up.  That's all supported releases since R6 is out of service
> and
> >> AMATERSE is included in z/OS R9.  The PTFs closed 4 November 2007.
>  They
> >> are:
> >>
> >> UA36927 - z/OS R7
> >> UA36928 - z/OS R8
> >>
> > If you say so.  But the IBM Enhanced Customer Data Repository Service
> > page at:
> >
> > http://www-05.ibm.com/de/support/ecurep/mvs_create.html
> >
> > appears to be unaware of this.  I'll try to contact them.
> 
>
> I followed the link on the page you posted to the "program and
> instructions,: and found this at that link
> (http://techsupport.services.ibm.com/390/trsmain.html):
>
> "TRSMAIN Utility
> "In z/OS Release 1.9 the TRSMAIN program has been added to the BCP
> element of z/OS, and it has been redesigned to support large format
> sequential data sets. This program has also been rewritten to follow IBM
> programming conventions. The new utility is called AMATERSE.
> AMATERSE is available on z/OS Releases 7 and 8 via PTFs UA36927 and
> UA36928 for APAR OA19194."
>
> Do you see something different?
>
> --
> John Eells
> z/OS Technical Marketing
> IBM Poughkeepsie
> [EMAIL PROTECTED]
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

It was a surprise to me when I went looking for it on my freshly installed
z/OS 1.9 system and it was not there.

-- 
Mark Pace
Mainline Information Systems

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

Re: Shark to EMC

[R.S.]

Ron,
First I wanted to say I like HDS solutions, including storage 
virtualization. I just wanted to complement your message, not to 
criticize you or HDS solutions. However you said the good news and I 
added the bad ones. 


Regarding PPRC, etc. - yes it is paid feature, usually with 
capacity-based price. However virtualization does not relieve it while 
simply adds additional cost.


Regarding SPOF in USP - I said about single point of disaster-like 
outage. Let's assume I have some ESS-A in location A and ESS-B in 
location B. I can virtualize it through USP in location A. I would need 
another USP in location B to be disaster-proof.


Regarding to original question - in fact we don't know what are the real 
need and - last but not least - constraints. I mean budget and 
acceptable outages.
I know a method for one-time migration, which is cheap (FREE), and - 
depending on data type - does not require longer outage than for re-IPL 
+ few minutes. It has definitely nothing to do with USP virtualization 
which is good for absolutely different needs (and it is good!).


Regards
--
Radoslaw Skorupka
Lodz, Poland


Ron Hawkins wrote:

Radoslaw,

I think it's been two years and one generation of storage since you looked
at the pricing. I don't do sales so I don't know if it is still as ugly as
you make out. There are plenty of customers using it. 


Are you telling me that XRC is free? Or PPRC, SRDF, Flashcopy and Timefinder
are free? Aren't these products licensed based on the capacity they manage.
The virtualized DASD will use HUR, TrueCopy and Shasdowimage just like they
were internal disks. Why should software managing external storage be free? 


And I did say USP-VM. I think you only looked at USP and not the diskless
NSC-55, which is the -1 gen of the USP-VM. 


The ESS does not need any new hardware to be virtualized. The channels have
to be reloaded as Fibre Channel microcode instead of FICON. If you have
ESCON then you have to replace with FCP/FICON. An EMC with FICON or ESCON
channels must have them replaced with Fibre Channel. Both boxes must be
reformatted as Open System LUNs before they are virtualized. 


Please describe the single point of failure in a HDS USP-V. I'm ready to
listen. 


I agree you get a single pane of glass management, and less moving parts. I
thought this was one of the aims of risk reduction. Are you trying to tell
me that if you spread your Production MVS across 10 boxes you have less
risk? Tell me what happens to when you power off the one with the SYSRES,
Common or the master catalog? MVS single points of failure trump any "eggs
in one basket" syndrome.

Yes I work for HDS. No I don't think virtualization is for everyone. I do
think it is a solution for the original question, and possibly a better TCO
solution than XRC.




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

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci 
opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 
r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 
z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

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

Re: COBOL OUTDD(SYSOUT)

[Farley, Peter x23353]

Radoslaw,

In your JCL PARM specify the LE runtime option MSGFILE(yourdd), for COBOL like 
this:

//STEP01 EXEC PGM=yourcobolprogram,PARM='yourpgmparms/MSGFILE(NEWOUTDD)'
//NEWOUTDD DD SYSOUT=*

I don't believe there is a way for different COBOL programs in the same LE 
enclave to use different OUTDD/MSGFILE names.  I also don't believe that the 
name can be dynamically changed, but I could be mistaken about that.  You'd 
need to check the available LE callable functions to see if there are any to do 
that (LE Language Reference and/or Programming Guide).

HTH

Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of R.S.
> Sent: Thursday, January 31, 2008 11:39 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: COBOL OUTDD(SYSOUT)
> 
> The compiler option default is OUTDD(SYSOUT).
> 
> Q1: Is there corresponding runtime option?
> Q2: Can I specify other ddname for the above in COBOL program ?
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> --
> BRE Bank SA
> ul. Senatorska 18
> 00-950 Warszawa
> www.brebank.pl
> 
> Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego,
> nr rejestru przedsiębiorców KRS 025237
> NIP: 526-021-50-88
> Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w
> całości opłacony) wynosi 118.064.140 zł. W związku z realizacją
> warunkowego podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ
> z dnia 21.05.2003 r., kapitał zakładowy BRE Banku SA może ulec
> podwyższeniu do kwoty 118.760.528 zł. Akcje w podwyższonym kapitale
> zakładowym będą w całości opłacone.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.

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

COBOL OUTDD(SYSOUT)

[R.S.]

The compiler option default is OUTDD(SYSOUT).

Q1: Is there corresponding runtime option?
Q2: Can I specify other ddname for the above in COBOL program ?

--
Radoslaw Skorupka
Lodz, Poland


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

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

NIP: 526-021-50-88
Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w całości 
opłacony) wynosi 118.064.140 zł. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ z dnia 21.05.2003 
r., kapitał zakładowy BRE Banku SA może ulec podwyższeniu do kwoty 118.760.528 
zł. Akcje w podwyższonym kapitale zakładowym będą w całości opłacone.

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

Re: Data Erasure Products

[Ron Hawkins]

Why not have the applications encrypt sensitive data before they write it.
Seems to me that this is the logical place to protect data. DASD shredding
would become an academic argument...

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of SUBSCRIBE IBM-MAIN Niall
> Sent: Thursday, January 31, 2008 1:48 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: [IBM-MAIN] Data Erasure Products
> 
> How about encrypting the volume in its entirety before deletion?
> 
> I've been through the DR/deletion exercise a few times, and used an in-
> house
> utility to overwrite the disk. If available, however, would encryption
> not
> be a possible solution in that even if a shadow of the data were left,
> it
> should at least be in a format that is not readable?
> 
> I ask because some sites may already have invested in an encryption
> tool,
> and it might be an imaginative use of an existing asset.
> 

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

Re: Shark to EMC

[Ron Hawkins]

Radoslaw,

I think it's been two years and one generation of storage since you looked
at the pricing. I don't do sales so I don't know if it is still as ugly as
you make out. There are plenty of customers using it. 

Are you telling me that XRC is free? Or PPRC, SRDF, Flashcopy and Timefinder
are free? Aren't these products licensed based on the capacity they manage.
The virtualized DASD will use HUR, TrueCopy and Shasdowimage just like they
were internal disks. Why should software managing external storage be free? 

And I did say USP-VM. I think you only looked at USP and not the diskless
NSC-55, which is the -1 gen of the USP-VM. 

The ESS does not need any new hardware to be virtualized. The channels have
to be reloaded as Fibre Channel microcode instead of FICON. If you have
ESCON then you have to replace with FCP/FICON. An EMC with FICON or ESCON
channels must have them replaced with Fibre Channel. Both boxes must be
reformatted as Open System LUNs before they are virtualized. 

Please describe the single point of failure in a HDS USP-V. I'm ready to
listen. 

I agree you get a single pane of glass management, and less moving parts. I
thought this was one of the aims of risk reduction. Are you trying to tell
me that if you spread your Production MVS across 10 boxes you have less
risk? Tell me what happens to when you power off the one with the SYSRES,
Common or the master catalog? MVS single points of failure trump any "eggs
in one basket" syndrome.

Yes I work for HDS. No I don't think virtualization is for everyone. I do
think it is a solution for the original question, and possibly a better TCO
solution than XRC.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of R.S.
> Sent: Wednesday, January 30, 2008 11:31 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: [IBM-MAIN] Shark to EMC
> 
> Ron Hawkins wrote:
> > Tom,
> >
> > You can virtualise both boxes behind HDS USP-VM and mirror from Shark
> to EMC
> > using TrueCopy or HUR.
> 
> ...and you get single point of ...control.  But seriously - single
> point of disaster-like-failure.
> ...and you pay $s for HDS hardware and software - the software's price
> depends on TB of Shark and EMC.
> ...and you may need to buy some hardware/software features to you Shark
> and EMC since AFAIK (correct me if I'm wrong), the array behind the USP
> has to be Fibre Channel connected and FBA emulated.
> 
> 
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 

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

Re: AMATERSE available (was: TSO TRANSMIT ...)

[Mark Zelden]

On Thu, 31 Jan 2008 10:00:18 -0600, Chase, John <[EMAIL PROTECTED]> wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of Robert Wright
>>
>> Paul Gilmartin wrote:
>> > On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote:
>> >> See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on
>
>> >> z/OS
>> >> R7 and up.  That's all supported releases since R6 is out of
>service
>> >> and AMATERSE is included in z/OS R9.  The PTFs closed 4 November
>> >> 2007.  They
>> >> are:
>> >>
>> >> UA36927 - z/OS R7
>> >> UA36928 - z/OS R8
>> >>
>> > If you say so.  But the IBM Enhanced Customer Data
>> Repository Service
>> > page at:
>> >
>> > http://www-05.ibm.com/de/support/ecurep/mvs_create.html
>> >
>> > appears to be unaware of this.  I'll try to contact them.
>>
>> The PTFs closed in July, 2007, so we're just reaching the
>> point in time where most customers would have AMATERSE
>> installed since those PTFs didn't qualify as emergency
>> service.  If you have TRSMAIN from the source described on
>> that page, the data stream is compatible with AMATERSE.
>
>Any plans to assign an RSU sourceid to them?  I'm reasonably sure we're
>not the only shop that "routinely" applies only RSUs, HIPERs and
>PEFIXes.
>

It should get there soon.  It has to go though CST and should wait until 
quarterly RSU since it isn't HIPER or resolving a PE.   It was on PUT0710 
so that probably means it won't hit RSU until RSU0803.   

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

Re: AMATERSE available

[John Eells]

Chase, John wrote:


Any plans to assign an RSU sourceid to them?  I'm reasonably sure we're
not the only shop that "routinely" applies only RSUs, HIPERs and
PEFIXes.



http://www-03.ibm.com/support/techdocs/atsmastr.nsf/PubAllNum/Flash10106


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]

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

Re: Dumb idea - pandering to the "other systems" people?

[Van Dalsen, Herbie]

This takes me back a few years...

I worked for a building society, that was eaten alive by RBS, and when I
joined I was told by the person who I was going to report to for the
next few years... that there are 2 Systems Prod, and 'the
LPAR'(referring to the development LPAR, of course for some time I tried
to convince them that both were LPAR's, but alas... He was a helpdesk
person that became a NT admin, and had a good relationship with the
outgoing Sysprog(upwards in the company)... In the end there were still
2 systems... Prod and 'the LPAR'

I suppose it all depends it you see someone is going to continue on a
steady mainframe path, then you help him to understand the terms end
things the right way, but if not... by the time he is mid-level
management, things like that does not matter in any case, except if
Windows becomes the preferred platform for new work-loads just because
he is not comfortable with the System-z, or is it Z6 from now onwards...

Herbie


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of SUBSCRIBE IBM-MAIN Niall
Sent: 31 Januarie 2008 10:03
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Dumb idea - pandering to the "other systems" people?

My one concern would be to the future. If you were to leave, would a
replacement sysprog have to relearn a new vocabulary because there is a
different vocabulary in place? And since the people there don't know the
Z/OS equivalents, is there a risk that the gap between what they say and
what the new guy interprets could cause a major outage?

For my money, the company should stump up for enough basic training to
allow
Z/OS discussions to be held in the appropriate language and using the
appropriate terms.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Elavon Financial Services Limited
Registered in Ireland: Number 418442
Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, 
Co. Dublin, Ireland
Directors: Robert Abele (USA), John Collins,  Terrance Dolan (USA),  Pamela 
Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson
Elavon Financial Services Limited, trading as Elavon, is regulated by the 
Financial Regulator

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

Re: DB2 queries without using MF.

[Wayne Driscoll]

Walt,
In regards to the EAL4+, that was what I remembered, but I was going by
the contents of
http://www-03.ibm.com/servers/eserver/zseries/zos/racf/whatsnew.html
because I wanted a reference page from IBM.  You may want to try and get
this page updated.

Wayne Driscoll
Product Developer
JME Software LLC
NOTE:  All opinions are strictly my own.




-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Walt Farrell
Sent: Thursday, January 31, 2008 10:01 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DB2 queries without using MF.

On Thu, 31 Jan 2008 10:30:11 -0500, Wayne Driscoll
<[EMAIL PROTECTED]> wrote:

>Since z/OS 1.6
>RACF has had CAPP EAL 3+ certification, and LSP EAL 3+ certification.
>

Thanks for mentioning that, Wayne.  Just a couple of points:

(1) It's z/OS (when using RACF) that has the Common Criteria
certification,
not RACF by itself..

(2) Since z/OS R7 we've had an evaluation at EAL4+ complying with the
CAPP
and LSPP protection profiles.

-- 
  Walt Farrell, CISSP
  IBM STSM, z/OS Security Design

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

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

Re: DB2 queries without using MF.

[Walt Farrell]

On Thu, 31 Jan 2008 10:30:11 -0500, Wayne Driscoll
<[EMAIL PROTECTED]> wrote:

>Since z/OS 1.6
>RACF has had CAPP EAL 3+ certification, and LSP EAL 3+ certification.
>

Thanks for mentioning that, Wayne.  Just a couple of points:

(1) It's z/OS (when using RACF) that has the Common Criteria certification,
not RACF by itself..

(2) Since z/OS R7 we've had an evaluation at EAL4+ complying with the CAPP
and LSPP protection profiles.

-- 
  Walt Farrell, CISSP
  IBM STSM, z/OS Security Design

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

Re: AMATERSE available (was: TSO TRANSMIT ...)

[Chris Hoelscher]

I dont want AMATERSE ... I want PROFESSIONALS


Paul Gilmartin wrote:
> On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote:
>> See APAR OA19194, which makes AMATERSE, alias TRSMAIN,

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain CONFIDENTIAL material.  If you receive this 
material/information in error, please contact the sender and delete or destroy 
the material/information.

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

Re: AMATERSE available (was: TSO TRANSMIT ...)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Robert Wright
> 
> Paul Gilmartin wrote:
> > On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote:
> >> See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on

> >> z/OS
> >> R7 and up.  That's all supported releases since R6 is out of
service 
> >> and AMATERSE is included in z/OS R9.  The PTFs closed 4 November 
> >> 2007.  They
> >> are:
> >>
> >> UA36927 - z/OS R7
> >> UA36928 - z/OS R8
> >>
> > If you say so.  But the IBM Enhanced Customer Data 
> Repository Service 
> > page at:
> > 
> > http://www-05.ibm.com/de/support/ecurep/mvs_create.html
> > 
> > appears to be unaware of this.  I'll try to contact them.
> 
> The PTFs closed in July, 2007, so we're just reaching the 
> point in time where most customers would have AMATERSE 
> installed since those PTFs didn't qualify as emergency 
> service.  If you have TRSMAIN from the source described on 
> that page, the data stream is compatible with AMATERSE.

Any plans to assign an RSU sourceid to them?  I'm reasonably sure we're
not the only shop that "routinely" applies only RSUs, HIPERs and
PEFIXes.

   -jc-

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

Re: How to suppress some informational VTAM messages ?

[Barrett, Dennis]

ISTMSFLD ??


>
>
>>I'm looking for the best way to suppress some informational VTAM 
>>messages
in syslog.  Is there anybody want to share this to me ?
>>
>--


Dennis Barrett
Systems Programmer
Laclede Gas Co.
720 Olive Street, room 1103
St. Louis, Mo.  63101
(314) 342-0695
[EMAIL PROTECTED]

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

Re: AMATERSE available (was: TSO TRANSMIT ...)

[John Eells]

Paul Gilmartin wrote:

On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote:

See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS
R7 and up.  That's all supported releases since R6 is out of service and
AMATERSE is included in z/OS R9.  The PTFs closed 4 November 2007.  They
are:

UA36927 - z/OS R7
UA36928 - z/OS R8


If you say so.  But the IBM Enhanced Customer Data Repository Service
page at:

http://www-05.ibm.com/de/support/ecurep/mvs_create.html

appears to be unaware of this.  I'll try to contact them.



I followed the link on the page you posted to the "program and 
instructions,: and found this at that link 
(http://techsupport.services.ibm.com/390/trsmain.html):


"TRSMAIN Utility
"In z/OS Release 1.9 the TRSMAIN program has been added to the BCP 
element of z/OS, and it has been redesigned to support large format 
sequential data sets. This program has also been rewritten to follow IBM 
programming conventions. The new utility is called AMATERSE.
AMATERSE is available on z/OS Releases 7 and 8 via PTFs UA36927 and 
UA36928 for APAR OA19194."


Do you see something different?

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]

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

Re: Job ad for z/OS systems programmer trainee

[Don Leahy]

On Jan 31, 2008 8:45 AM, Mark H. Young <[EMAIL PROTECTED]> wrote:
> On Wed, 30 Jan 2008 14:06:23 -0500, Don Leahy <[EMAIL PROTECTED]>
> wrote:
>
> >On Jan 30, 2008 11:51 AM, Mark H. Young <[EMAIL PROTECTED]>
> wrote:
> >> I've read ALL the responses on this topic.  In reading the job posting, the
> >> first thing that struck me was the VERY FIRST line:
> >>
> >> The purpose of the Z/OS Operating System Programmer trainee position is
> >> providing second level support on various Z/OS mainframe products &
> utilities.
> >>
> >> "second level support" ?   As in IBM or other OEM Level 2 support?!
> >>
>
> >Probably they mean "level 2 support" as the first level after the
> >'Help Desk'.  That's a long way from calling IBM or other vendor for
> >help.  But someone with a good (even if non-sysprog) programming
> >background should be able to handle it.
>
> NO, I meant "level 2 support" like IBM and OTHER vendors (OEM) have THEIR
> level 2 support (which is usually the developers, or AT LEAST some coders).
> Vendors' help desk is level one support, who you call in to or who read your
> problem ticket for the first time, and then you go to LEVEL 2.
>
> Regards,
> Mark
>
The position is for a bank, not a vendor.  So, the use of the term
"Level 2" is different.

My point was the job ad calls for someone with the capability of
providing "Level 2" support to the bank's user community, which is a
very different skill set from a vendor's "Level 2" support.

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

Re: AMATERSE available (was: TSO TRANSMIT ...)

[Robert Wright]

Paul Gilmartin wrote:

On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote:

See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS
R7 and up.  That's all supported releases since R6 is out of service and
AMATERSE is included in z/OS R9.  The PTFs closed 4 November 2007.  They
are:

UA36927 - z/OS R7
UA36928 - z/OS R8


If you say so.  But the IBM Enhanced Customer Data Repository Service
page at:

http://www-05.ibm.com/de/support/ecurep/mvs_create.html

appears to be unaware of this.  I'll try to contact them.


The PTFs closed in July, 2007, so we're just reaching the point in time 
where most customers would have AMATERSE installed since those PTFs 
didn't qualify as emergency service.  If you have TRSMAIN from the 
source described on that page, the data stream is compatible with AMATERSE.


Bob Wright - MVS Service Aids

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

Re: z890 2086-160 w/ 2 IFLs on eBay - Update

[Heloisa]

Here is the e-bay details with pictures and configuration

http://cgi.ebay.com/IBM-e-SERVER-zSERIES-890-2086-A04-MAINFRAME-
COMPUTER_W0QQitemZ260202032717QQihZ016QQcategoryZ64030QQssPageNa
meZWDVWQQrdZ1QQcmdZViewItem

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

More VTS Questions

[Daniel McLaughlin]

I've come across a TLMS report which gives me the information needed to 
build my export list. I'm looking at the manuals but haven't come across what 
happens if the same volser shows up twice in the list...I know that the 
EXPORT process will sort things according to the out code..but not what it 
does with dupes. Not a huge deal, we can program around it but if there is no 
need to write extra code for this, why do it?
Thanks in advance.

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

Re: DB2 queries without using MF.

[Wayne Driscoll]

Ron,
With regard to "AFAIK it's been a long time since RACF had any sort of
special security
rating, and even then you had to disconnect the network", Since z/OS 1.6
RACF has had CAPP EAL 3+ certification, and LSP EAL 3+ certification.
Your above comment relates to the old DOD B1 rating that RACF, with a
specific set of hardware devices and software service levels, and
multi-level security (MLS, ie labeling, levels and categories) active,
received in the early 90's.  The old "Orange Book" ratings are outdated,
and have been replaced by the EAL Common Criteria.  For more info, see:
http://www-03.ibm.com/systems/z/security/ccs_certification.html

Wayne Driscoll
Product Developer
JME Software LLC
NOTE:  All opinions are strictly my own.




-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ron Hawkins
Sent: Thursday, January 31, 2008 1:31 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DB2 queries without using MF.

Lars,

Then we better write off z/OS NFS right now... 

If Shai can provide a call to RACF via the host side client, then what
is
the big deal!

And if you take a look around there are plenty of publicly listed
companies
around the world that fully comply with SOX or BASEL II, but have never
owned or plan to own a MF.

AFAIK it's been a long time since RACF had any sort of special security
rating, and even then you had to disconnect the network

Ron



> 
> A product such as yours is thus unlikely to be allowed into the
> data center of a large (publicly traded) company or a company in
> the Health Care industry.
> 

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

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

AMATERSE available (was: TSO TRANSMIT ...)

[Paul Gilmartin]

On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote:
>
>See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS
>R7 and up.  That's all supported releases since R6 is out of service and
>AMATERSE is included in z/OS R9.  The PTFs closed 4 November 2007.  They
>are:
>
>UA36927 - z/OS R7
>UA36928 - z/OS R8
>
If you say so.  But the IBM Enhanced Customer Data Repository Service
page at:

http://www-05.ibm.com/de/support/ecurep/mvs_create.html

appears to be unaware of this.  I'll try to contact them.

Thanks,
gil

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

Re: SPAM: How to suppress some informational VTAM messages ?

[Scott Ford]

Ed and Pat,

I was a VTAM old timer for a long time with 3745's , etc. I used Netview's
NLDM more than NPDA. I think if my memory serves me correctly that
NPDA was designed for usage with IBM modemsright ?


Regards,
Scott
IDF

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Ed Gould
Sent: Thursday, January 31, 2008 2:00 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: SPAM: How to suppress some informational VTAM messages ?

On Jan 30, 2008, at 10:41 PM, Patrick O'Keefe wrote:
>
>> ... I never figured out how to make sense out of NPDA ...
> (Sorry about taking that quote out of order.)
>
> That isn't exactly the fault of the product (and doesn't relate to
> automation anyway).   I was able to figure it out well enough that
> I've been generating my own alerts for years.  As we've moved away
> from SNA networks there are many fewer devices and programs
> issuing their own alerts, but NPDA on a "focal point" NetView is a
> great central place to collect program-generated alerts notifying you
> of situations needing attention.
>
> Pat O'Keefe
>

Pat:

Getting back to my point NPDA was a PITA to just get a handle on what  
was going on. Every time I want to see some error it wasn't there.  
Heck half the time I had trouble finding the *** LU. I will be  
the first to admit I never attended a class on the thing but every  
time I would picked up a manual and go through the process I could  
not find what I was looking for. Plus as far as I could figure out  
there was no way to purge the database so I ended up putting it in  
NETVIEW at start up to delete and define the database. The splits got  
so bad and the pack busies got really bad (almost as much as the JES2  
checkpoint) It just wasn't worth the effort to figure out how to fix  
it. It was easier just to bring down Netview and delete/define the  
data bases.

For what it was designed for its probably OK but I would not  
recommend it (in reality AFAIK there is no other package out there)  
so its sort of mandatory you buy it. The network help desk could not  
even begin to figure it out. The only way I could get real  
information was to run TAF to trace items. BTW 95 percent of the time  
when I opened a 37xx (NCP) IBM always asked for a ACFTAP trace not  
what was in NPDA.

The other 5 percent were extremely minor issues and I had the ACFTAF  
trace printed and ready to fax by the time they called back. They  
could could have accessed NPDA so from my perspective NPDA was  
essentially a waste of time.

I thought I made it clear that I was not comparing netview to opsmvs.

Ed


Ed
  
   

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

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

BPXAS RC=255

[John Hooper]

We had an occurrence where BPXAS on behalf of FTPD ended with a return 
code of 255.  There were no error messages in SYSLOG or the log for BPXAS.  
There were no software records in Logrec.  It appears that it stopped as it 
normally does but had this return code.  Nothing appears to have failed.  I 
know very little about this process - it just works.  Our AO product caught the 
return code and, of course, they want an explanation.  Has anyone else seen 
this return code or know where they are documented.  I have looked on 
IBMLINK, Google, and IBM-Main.  Help!!

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

Re: TSO/REXX Does Not FREE Storage?

[Robert Wright]

Joe Denison wrote:
I'm having an issue with REXX EXECs (interpreted, not compiled) that seem to 
*not* free storage after they terminate.  Is this a known issue?  Has anyone 
else experienced this?  


It would be helpful if you could go at least one step beyond what you 
reported here to determine whether the growth that you're seeing is in a 
particular subpool.  Subpool 78 is intentionally shared by all TSO tasks 
to permit storage that should persist across command and other task 
terminations to do so, and authorized programs have the ability to 
attribute storage ownership to the job step TCB for similar reasons. 
The identity of the subpool would cut the list of potential culprits 
down significantly although it would hardly point at just one.


Bob Wright - MVS Service Aids

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

Re: Problems with SNA Consoles in Z/OS V1R8

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 01/28/2008
   at 06:24 PM, Timothy Sipples <[EMAIL PROTECTED]> said:

>Lots of products have already implemented that RFC,

What RFC? As of last month it was still just an Internet draft, as far as
I could tell.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Migration from Mainframe to othre platforms - the othe bell?

[Staller, Allan]

Try the following links:

IBM saves $250 million consolidating Linux servers on to mainframes
http://www.networkworld.com/community/node/17998

An article to counterbalance all of those "we're moving off of the
mainframe" stories we see posted here.

http://blog.coleo.com/wp-content/uploads/2007/05/share_session_9230.pdf


It's a  large working document.   For the Business people, go
to page 24 and on.

z/VM strikes again:-)




I am full of reports, sent to Management, about completely succesfull
conversions from the "old and expensive" "IBM Mainframe to other
platforms. And, as you may know, the most important argument is that the
Mainframe is very expensive and the same level of processing, with the
same degree of thrust, can be achieved in other platforms with much less
money. Of course, i dont beleive this, or at least i dont think things
to be so simple. So, i want to collect some information to support the
Mainframe side.

Are there somewhere on the web, as a counterpart of all the marketing
flood about getting rid of the Mainframe, stories, reports or analysis
of :

- Conversions (or Consolidations) from other platforms into Mainframes.
- Stories of unsuccessful migrations from Mainframe to other platforms.
- Serious and independant cost analysis between different solutions.
- Serious and independant studies comparing the security level of the
different platforms.


Thanks in advance for your help,


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

Migration from Mainframe to othre platforms - the othe bell?

[Mautalen Juan Guillermo]

Hi,

I am full of reports, sent to Management, about completely succesfull
conversions from the "old and expensive" "IBM Mainframe to other
platforms. And, as you may know, the most important argument is that the
Mainframe is very expensive and the same level of processing, with the
same degree of thrust, can be achieved in other platforms with much less
money. Of course, i dont beleive this, or at least i dont think things
to be so simple. So, i want to collect some information to support the
Mainframe side.

Are there somewhere on the web, as a counterpart of all the marketing
flood about getting rid of the Mainframe, stories, reports or analysis
of :

- Conversions (or Consolidations) from other platforms into Mainframes.
- Stories of unsuccessful migrations from Mainframe to other platforms.
- Serious and independant cost analysis between different solutions.
- Serious and independant studies comparing the security level of the
different platforms.


Thanks in advance for your help,


Juan G. Mautalen



El contenido del presente mensaje y sus anexos es privado, confidencial y de 
exclusivo uso para el titular de la direccion de correo electronico a quien 
esta dirigido. Puede contener informacion privilegiada o amparada por el 
secreto profesional o por disposiciones legales y/o reglamentarias vigentes. 
Cualquier modificacion, retransmision, diseminacion o divulgacion de su 
informacion se encuentra expresamente prohibida y su uso inadecuado puede 
derivar en responsabilidad civil para el usuario o configurar los delitos 
previstos en los articulos 153 a 157 del Codigo Penal. Si no fuere uno de los 
destinatarios consignados o lo hubiere recibido por error, Ud. NO ESTA 
AUTORIZADO a utilizar total o parcialmente, copiar, enviar, revelar, imprimir, 
divulgar de manera alguna el contenido del presente mensaje o el de sus 
adjuntos. En consecuencia, tenga a bien comunicarselo inmediatamente al emisor 
y ELIMINARLO. 
ANSES no aceptara responsabilidad alguna por errores u omisiones emergentes del 
presente mensaje o sus adjuntos, ni garantiza la seguridad, exactitud u 
oportunidad de lo transmitido por este medio debido a que el mismo puede ser 
objeto de intercepcion, modificacion, retraso, perdida, o bien de contener 
virus informaticos u otras anomalias.
Asimismo, las opiniones expresadas en este mensaje son propias del remitente y 
no representan la opinion o politicas de ANSES y/o de ningun empleado y/o 
funcionario de la organizacion. Por ende, ANSES no asumira -en ningun caso- 
responsabilidad alguna frente al destinatario y/o terceros en virtud de dichas 
comunicaciones y ademas, no sera responsable frente a los usuarios por la 
correspondencia o los mensajes de correo electronico enviados por terceros u 
otras personas distintas a ANSES, ya sea que estos hubieren o no solicitado el 
envio de tales mensajes.
ANSES se reserva el derecho de bloquear el acceso o remover en forma parcial o 
total todo mensaje y sus adjuntos que a su criterio pudiere resultar abusivo, 
difamatorio, obsceno, fraudulento, artificioso, enganoso,  ofensivo o 
violatorio a los terminos de la presente.
PD:Tildes omitidas intencionalmente.


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

Re: Job ad for z/OS systems programmer trainee

[Mark H. Young]

On Wed, 30 Jan 2008 14:06:23 -0500, Don Leahy <[EMAIL PROTECTED]> 
wrote:

>On Jan 30, 2008 11:51 AM, Mark H. Young <[EMAIL PROTECTED]> 
wrote:
>> I've read ALL the responses on this topic.  In reading the job posting, the 
>> first thing that struck me was the VERY FIRST line:
>>
>> The purpose of the Z/OS Operating System Programmer trainee position is
>> providing second level support on various Z/OS mainframe products & 
utilities.
>>
>> "second level support" ?   As in IBM or other OEM Level 2 support?!
>>

>Probably they mean "level 2 support" as the first level after the
>'Help Desk'.  That's a long way from calling IBM or other vendor for
>help.  But someone with a good (even if non-sysprog) programming
>background should be able to handle it.

NO, I meant "level 2 support" like IBM and OTHER vendors (OEM) have THEIR 
level 2 support (which is usually the developers, or AT LEAST some coders).
Vendors' help desk is level one support, who you call in to or who read your 
problem ticket for the first time, and then you go to LEVEL 2.

Regards,
Mark

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

Re: TSO/REXX Does Not FREE Storage?

[Barbara Nitz]

Not having seen the original post (did it only go to the newsfeed?), this 
sounds suspiciously like a problem that was reported in the early nineties and 
that took more than 2 or 3 years. Unfortunately for the life of me, I don't 
remember if it was fixed back then or if both the customer and I gave up 
frustrated after several years. But yes, in the case I remember storage was 
left until the address space terminated 878-10. That customer had provided me 
back then with a demo program showing the effect. Whenever it was executed, one 
more page was left in the address space. That was clearly visible when I dumped 
my own TSO user after every run. I think the storage was then gotten under the 
job step tcb and hence not subject to task termination.
Regards, Barbara Nitz


-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

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

Re: TSO/REXX Does Not FREE Storage?

[Walt Farrell]

On Wed, 30 Jan 2008 22:50:08 -0600, Joe Denison <[EMAIL PROTECTED]> wrote:

>I'm having an issue with REXX EXECs (interpreted, not compiled) that seem to
>*not* free storage after they terminate.  Is this a known issue?  Has anyone
>else experienced this?
>
>(my apologies for the long post -- but wanted to provide some details to
>reduce some questions that may be asked)
>
>A simple example to demonstrate the issue:
>
>/* REXX EXEC */
>DO i=1 to 10
>bb.i=COPIES("P",1000)
>END
>EXIT
>
>While running this, the "used" storage increases as each of the stem variables
>gets populated with a string of 1000 "P" characters.  But when the REXX
>program terminates, the storage (GETMAIN'd) during this process does not get
>freed. 

Can you provide more details of how you're running that exec?  If run via
the exec command then the normal task termination should clean up all the
storage.

-- 
  Walt

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

Re: Dumb idea - pandering to the "other systems" people?

[SUBSCRIBE IBM-MAIN Niall]

My one concern would be to the future. If you were to leave, would a
replacement sysprog have to relearn a new vocabulary because there is a
different vocabulary in place? And since the people there don't know the
Z/OS equivalents, is there a risk that the gap between what they say and
what the new guy interprets could cause a major outage?

For my money, the company should stump up for enough basic training to allow
Z/OS discussions to be held in the appropriate language and using the
appropriate terms.

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

Re: Data Erasure Products

[SUBSCRIBE IBM-MAIN Niall]

How about encrypting the volume in its entirety before deletion?

I've been through the DR/deletion exercise a few times, and used an in-house
utility to overwrite the disk. If available, however, would encryption not
be a possible solution in that even if a shadow of the data were left, it
should at least be in a format that is not readable?

I ask because some sites may already have invested in an encryption tool,
and it might be an imaginative use of an existing asset.

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

Re: Shark to EMC

[shai hess]

HI,

Yes, there are many ways to move data from one disk to another.

Easer and a free way are to use MFNetDisk ability to copy disks to other
disks without any cost and without any hardware and without any downtime for
the source disks.

The status of MFNetDisk is that the IBM MIDAW is under testing, and we
prepare the product to production.

Some of the MVS MFNetDisk parameters will be changed (SYNCDEV will be
ASYNCMRR, and FstSync will be SYNCMRR). Better MFNetDisk MVS traces, Better
documentation and better and faster code. Now it is the time to try the
product. This is not anymore a beta product.


Thanks,
Shai
On 1/30/08, Ron Hawkins <[EMAIL PROTECTED]> wrote:
>
> Tom,
>
> You can virtualise both boxes behind HDS USP-VM and mirror from Shark to
> EMC
> using TrueCopy or HUR.
>
> Ron
>
> >
> > I would think that the only way to mirror in a multi-vendor environment
> > would be XRC.  The reason is because all the replication goes through
> > the
> > system mover and thus is at a higher level than the bare metal.
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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