test

2010-02-25 Thread Scott T. Harder
test post.  sorry for the bother.

thanks!

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

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


Job Posting?

2010-02-26 Thread Scott T. Harder
Hi All,

 

Does IBM-MAIN still have a job posting section?  If so, can someone refresh
my memory as to how to get there?  Thanks!

 

All the best,

 

Scott T. Harder

Mainframe Services, Inc.

Naples, FL

 


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


Re: What's with IBMLINK now??

2010-02-26 Thread Scott T. Harder
Wow!  Many times, I've heard of people not being able to get a site to load
properly with IE, but when they used Firefox all was well.  I've never heard
the story told this way around; where Firefox had problems, but IE was all
good.  Chalk one up for MS, I guess.  

All the best,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of John Kelly
Sent: Friday, February 26, 2010 11:29 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What's with IBMLINK now??


www-304bluecoat.ibm.com uses an invalid security certificate.


Here's my response form IBM FeedBack about it. I find that it goes away 
after a while but happens mostly with Firefox. When I get it, I go to IE 
and get in OK. I had an offline line email from someone else who's had the 
problem and they accepted the site and apparently got in.

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


Re: IBM Plans to Discontinue REDBOOK Series

2010-03-06 Thread Scott T. Harder
Incredibly BAD idea.  It cannot be understated what a BAD idea this is.
Somehow, I doubt we'll see a single opinion in favor on this list (or the
others, for that matter).

All I have to say is that they better re-write some of the "less than
optimal" manuals that are out there on important subjects and pieces of
hardware or software.  I know they are there; I just can't think of any off
the top of my head right now and don't have time to look it up.  I seem to
remember that there are numerous manuals where diligent research results in
dead ends... only to find out that the information you were looking for is
under some other much more obscure section title or a different manual
altogether.

What I always *loved* about Redbooks is the way they pulled everything
together and presented the information in an order that actually makes
sense.

All the best,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of esst...@juno.com
Sent: Saturday, March 06, 2010 1:22 PM
To: IBM-MAIN@bama.ua.edu
Subject: IBM Plans to Discontinue REDBOOK Series

IBM REDBOOKS have been a rich source of information for Years.
I have always directed new bees to the ABCs of MVS (all 12 Volumes) 
as a starting point.

Without identifying individuals I have it on good authority that IBM
intended to stop developing the "REDBOOK" Series of publications. 
My contact at IBM, stated that other IBMers displayed there resentment to
dis-continuing the IBM REDBOOKS series.

REDBOOKs do not only affect the Mainframe, they affect all other 
distributed platforms.

Apparently the Bean Counters at IBM only understand numbers.
How does one put a $ Value on Intellectual Capital ?

The Discontinuance of the REDBOOK Series  has been postponed to 2011.
2010 will be the last Year for any New IBM REDBOOKS.

This is a bad decision on IBMs part.


You Comments



Diet Help
Cheap Diet Help Tips. Click here.
http://thirdpartyoffers.juno.com/TGL2141/c?cp=322ZpkcD1O_69jHFqK2GQQAAJ1DMCv
I8C_EKS4yGKHO7DleMAAYAAADNAAAYQAA=

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

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


Re: IBM Plans to Discontinue REDBOOK Series

2010-03-08 Thread Scott T. Harder
Thanks, Bob, for the correction.  Sorry about that (doh!).

I agree and was going to add to my original reply an "if this is true..."
caveat, but for some reason I just went with it.  It did seem unlikely that
IBM would do this, but stranger things have happened.  I'm *very* happy that
it was just a rumor.

All the best,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Bob Woodside
Sent: Saturday, March 06, 2010 9:22 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IBM Plans to Discontinue REDBOOK Series

On Saturday 06 March 2010, Scott T. Harder wrote:
> Incredibly BAD idea.  It cannot be understated what a BAD idea this
> is.

s/understated/overstated/

There. Fixed that for you.

I'm with Ted, in that I'll withhold any further comment until we 
see an authoritative word from someone within IBM; but if true it bodes 
no good for anyone.


Cheers,
Bob

-- 
Bob Woodside
Woodsway Consulting, Inc.
http://www.woodsway.com

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

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


Re: ISPF Preprocessed Panels

2010-03-13 Thread Scott T. Harder


It seems that the consensus is *not* to compile the panels - that there are
other means by which performance can be increased without the added
headaches of processes/procedures associated with such action, and I guess
that I would agree; everything being "same old-same old".  But, what about
situations where the application is ISPF-intensive (for lack of a better
term), where - for example - there are tons of AB items (therefore, most
likely a lot of commands), let's say a huge tutorial, a lot of processing on
the panel side of things, ya know?  Where the programs do only what they
need to do and ISPF is handling the rest; and newer features are used, such
as panel REXX, etc., etc. (am I making sense?... don't really know, but I'll
stick with it).

Would it then make sense to pre-process the panels???

Just thinking out loud, which usually gets me into trouble.  ;-)

All the best,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Ed Gould
Sent: Saturday, March 13, 2010 10:53 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ISPF Preprocessed Panels

I looked at that years ago. The issue I kept coming up with was to remember
to re process the panels after maintenance.
It might be semi acceptable on a small shop but when you have various people
applying maintenance is could cause headaches.
To me it just wasn't worth the exposure. I certainly can understand the look
at. I would suggest as a painless easyway for essentially buyback with
little or no effort is to put the applicable ISPF libraries into LPALIB or
lpalist (probably the second is easiest).
We did that from DAY 1 and we never went back. We had a "hotshot"
performance guy in and he suggested it and was surprised that we had already
done it. 

Ed





--

>Hello everybody:   I would like to request  people's opinions on taking the
trouble of preprocessing ISPF panels.  We have been preprocessing ISPF and
SDSF panels for a long time now (at least the portion of those that are
preprocessable) and I never personally noticed any performance gain from
preprocessing.  That is, the non-ISPF and non-SDSF panels which we don't
preprocess don't seem to load perceptibly slower that ISPF/SDSF ones.
>Also, all those preprocessed libraries at the top of the ISPPLIB
concatenation:  don't they make the search longer for any panel load?   Thus
offsetting any performance gain from preprocessing?Thanks, Nur Allen,
Systems Pgmmer Analyst, County of Santa Clara
>

---
I've never noticed any performance difference, even on a fairly small 
machine (z/800 0A1)

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




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

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


XMIT Manager

2010-03-17 Thread Scott T. Harder
Hi All,

 

Is there a version of XMIT Manager that will run on Windows 7??

 

I have v3 and it has not worked (won't install) since I went to Vista.  Now
I'm on Win7 and, of course, have the same problem.

 

Thanks!

 

Scott T. Harder

Mainframe Services, Inc.

Naples, FL

 


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


Re: XMIT Manager

2010-03-17 Thread Scott T. Harder
Tried that on the setup.exe file, but still get this in a pop-up when I try
to run it:

"The version of this file is not compatible with the version of Windows you
are running.  Check your computer's system information to see whether you
need an x86 (32-bit) or x64 (64-bit) version of the program, then contact
the software publisher."

Just for grins, I also tried checking "run as Administrator" on setup.exe
Properties under Compatibility, but got the same thing.

I am running Windows-7 64-bit, but other 32 bit software installs fine into
"Program Files (x86)".

Thanks for the suggestion, though.  I knew it was there, but hadn't thought
of it.  Very much appreciated.

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Hal Merritt
> Sent: Wednesday, March 17, 2010 4:47 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: XMIT Manager
> 
> Have you tried the 'compatibility' option of Windows? Right click on the
> program, choose properties, then choose compatibility.
> 
> HTH
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Scott T. Harder
> Sent: Wednesday, March 17, 2010 3:40 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: XMIT Manager
> 
> Hi All,
> 
> 
> 
> Is there a version of XMIT Manager that will run on Windows 7??
> 
> 
> 
> I have v3 and it has not worked (won't install) since I went to Vista.
> Now
> I'm on Win7 and, of course, have the same problem.
> 
> 
> 
> Thanks!
> 
> 
> 
> Scott T. Harder
> 
> Mainframe Services, Inc.
> 
> Naples, FL
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> NOTICE: This electronic mail message and any files transmitted with it are
> intended
> exclusively for the individual or entity to which it is addressed. The
> message,
> together with any attachment, may contain confidential and/or privileged
> information.
> Any unauthorized review, use, printing, saving, copying, disclosure or
> distribution
> is strictly prohibited. If you have received this message in error, please
> immediately advise the sender by reply email and delete all copies.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: RC=4093 from TSO ALLOC in compiled REXX

2010-03-21 Thread Scott T. Harder
Could it have something to do with Prefix processing; where it's successful
when run in foreground because a Prefix is added to the filename, but not in
background because without the Prefix, you end up with an invalid dsn???

Just a guess.

All the best,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Staffan Tylen
> Sent: Sunday, March 21, 2010 11:11 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: RC=4093 from TSO ALLOC in compiled REXX
> 
> I'm staring myself blind on a silly problem that I've created for myself.
> Here is a very advanced REXX program:
> 
> /* rexx */
> address TSO
> "ALLOC F(FILE1) NEW TRACKS SPACE(1) RECFM(F B) LRECL(80) REUSE"
> exit RC
> 
> If I execute it using the TSO EXEC command it gives RC=0 as expected,but
> if
> I compile the program and run it from the load library, it gives RC=4093!
> What's the secret?
> 
> Staffan
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: XMIT Manager

2010-03-21 Thread Scott T. Harder
This did the trick.  Thanks, Chuck!

Allthe best,
Scott


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Chuck Arney
> Sent: Wednesday, March 17, 2010 5:29 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: XMIT Manager
> 
> Under Win7 you can setup and run a WinXP Virtual Machine.  A free XP
> system image is available for download from Microsoft to run under Win7.
> You should be able to install and run old software in the XP VM.  I've
> had to do that with a number of packages.  It's a bit slow starting up
> the VM but runs fine after that.
> 
> Chuck Arney
> illustro Systems International, LLC
> http://www.illustro.com
> Internet-enable your applications with z/Ware V2
> Voice: 214-800-8900 X#5562
> --
> This e-mail is private and may be confidential and is for the intended
> recipient only. If misdirected, please notify us by telephone and
> confirm that it has been deleted from your system and any copies
> destroyed. If you are not the intended recipient you are strictly
> prohibited from using, printing, copying, distributing or disseminating
> this e-mail or any information contained in it.
> 
> We use reasonable measures to virus scan all E-mails leaving illustro
> but no warranty is given that this E-mail and any attachments are virus
> free. You should ensure you have adequate measures in place for your own
> virus checking.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Scott T. Harder
> Sent: Wednesday, March 17, 2010 4:04 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: XMIT Manager
> 
> Tried that on the setup.exe file, but still get this in a pop-up when I
> try
> to run it:
> 
> "The version of this file is not compatible with the version of Windows
> you
> are running.  Check your computer's system information to see whether
> you
> need an x86 (32-bit) or x64 (64-bit) version of the program, then
> contact
> the software publisher."
> 
> Just for grins, I also tried checking "run as Administrator" on
> setup.exe
> Properties under Compatibility, but got the same thing.
> 
> I am running Windows-7 64-bit, but other 32 bit software installs fine
> into
> "Program Files (x86)".
> 
> Thanks for the suggestion, though.  I knew it was there, but hadn't
> thought
> of it.  Very much appreciated.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: Portable? XMIT Manager

2010-03-22 Thread Scott T. Harder
Yeah, (and the "t" word does do my heart good) but we don't have to IML a
controller once-a-week, or less, anymore in order to keep the darn thing
functioning, so I guess that's a good thing.

Thin client?  VMWare?  Too many areas where so-called "new technologies"
have taken the landscape by storm.  As always, Marketing rules; and it has
been painfully clear that those that have labored, created, and invented in
the past are left to obscurity until some historian with a brain in their
head writes an article to the contrary.

To the historians (with a brain in there head)!  

;-)  

Scott T. Harder
Mainframe Services, Inc.
Naples, Inc.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Paul Gilmartin
> Sent: Monday, March 22, 2010 6:39 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Portable? XMIT Manager
> 
> On Thu, 18 Mar 2010 12:39:42 -0500, Hal Merritt wrote:
> 
> >USB stick based solutions are a good thing for the weary warrior just
> trying to do a job in spite of the 'services' of the PC folks. However,
> such solutions have been drawing attention from both the auditors and
> miscreants as an attack vector.
> >
> Sic transit PuTTY?  XMing?  Knoppix?  et. al.
> 
> Doesn't the same apply to optical disks?
> 
> Perhaps every programmer should be given a thin client with
> no floppy, optical, nor USB.
> 
> Hmmm.  My thin client has 4 USB ports.
> 
> "thin client"?  I remember when they were called "terminals".
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: Any tools for managing z/OS system software products inventory?

2010-03-23 Thread Scott T. Harder
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Ted MacNEIL
> Sent: Tuesday, March 23, 2010 10:03 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Any tools for managing z/OS system software products
> inventory?
> 
> >In either case there are DOCUMENTS. The documents are not retired, fired,
> died.
> 
> But, they are lost, incomplete, or misunderstood.
> 
> >We're not talikng about group of PFCSK and bunch of PCs for gaming, we're
> talking about professional team.
> >Mainframe specialists!
> 
> Who, unfortunately, are only human.
> Sh*t happens!

I have to agree with Ted on this whole issue; all extremely good points that
he makes.  It is a hopeful assumption that there are complete groups of
"mainframe specialists" in every group within Tech Services (or whatever
it's called at your shop... data center system and program product support
is what we're basically talking about, right?).  

These days, I would guess (as I don't know for sure, unfortunately) that
staffing is at a close to all-time low in many shops.  Just keeping up with
day-to-day requirements probably has people completely tied up.

I can see that there is most likely a real need for a product like this in
today's world.  And... one that will not only tell you what products are
there, but if they are being used, by who/what, and how often.

And... what about products that may not be executing, but are still there in
a proclib somewhere... the maintenance still being paid, etc.??  As Ted
said, it takes a view from multiple angles to see the entire field in this
case.  




Scott T. Harder
Mainframe Services, Inc.
Naples, FL

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


Re: Encryption software?

2010-03-23 Thread Scott T. Harder
I'm not trying to be a jerk here, but does this mean that all someone needs
is your product and knowledge of the id used, in order to generate the
key(s) to decrypt data encrypted with that id???

I am probably missing something here, but it sounds like there is something
intrinsically wrong with that premise.

All the best,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Phil Smith III
> Sent: Tuesday, March 23, 2010 12:01 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Encryption software?
> 
> Hal Merritt wrote:
> >I am beginning to think that the silence of major players is meaningful.
> 
> >I can report one horror story: pay close attention to your key manangment
> process. The whole process to include entry, change, and propagation to a
> recovery site. That whole sand box looks to be very fragile by design.
> And, without keys, the data is unrecoverable.
> 
> >I'm really worried that there are a lot of worthless backups out there
> that won't be discovered until it is way too late.
> 
> Indeed. "Encryption is easy, key management is hard". That's why the
> Voltage solutions all use keynames (identities) defined *by the user*
> (they look like email addresses, and actually are for Voltage SecureMail,
> but need not be for Voltage SecureData). Keys are generated based on a
> Master Secret and that identity *on the fly*. Thus keys need not be backed
> up, and key servers replicated with the same Master Secret will generate
> the same key for the same identity.
> 
> Our customers love this flexibility: no constant key server backups, easy
> failover and geographic replication, and applications can share keys by
> using the same identity, without having to pass keys themselves around.
> 
> ...phsiii
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: Mainframe Executive article on the death of tape

2010-03-24 Thread Scott T. Harder
I have to chime in to the contrary.  I seem to remember many data check
errors on 3480 cart media.  Am I the only one?

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Fletcher, Kevin
> Sent: Wednesday, March 24, 2010 6:54 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Mainframe Executive article on the death of tape
> 
> 
> I haven't seen a bona-fide tape I/O error since my shop installed 3480
> drives, lo these many years ago. What's this guy smoking? Whatever it
> is, I'm sure it's illegal! :-)
> 
> Rick
> 
> 
> 
> I have to agree with the list, the last error on a tape (MF) was a
> duplex tape where the physical tape was dropped and the case cracked. No
> big deal since it was a duplex tape. On the other hand, tapes on the
> open systems side do have some failures. The failures are not even close
> to what the article specified though. If he is smoking something, he
> should at least share with the list :-).
> 
> 
> Thanks,
> 
> Kevin Fletcher (317) 817-3545
> Transition Coordinator
> z/OS, DB2, AS400 support
> Conseco, LLC
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: Encryption software?

2010-03-24 Thread Scott T. Harder
Phil, 

Thanks very much for the detailed explanation.  Impressive.  

My interest is based on my involvement, not too long ago, with a commercial
z/OS crypto product where I had been looking at creating a key server to be
stored on z/OS (for all the usual and (I feel) proper reasons... RAS, etc.),
providing the kind of unique and value-add management features such that you
have described with your product; but also wanted to stay inside the lines
with our crayon when it came to compatibility with existing key management
methodologies (ICSF); and use those for all that is the best of the breed
(no need to re-invent the wheel, right?).  This, for both symmetric and
asymmetric keys, as well.  Not a simple project and mine never got off the
ground (won't go into it); but I admire someone (an entire team, I'm sure)
that was able to take this on and have some level of success.   
  

All the best,

Scott T. harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Phil Smith III
> Sent: Tuesday, March 23, 2010 11:50 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Encryption software?
> 
> Scott T. Harder wrote:
> >I'm not trying to be a jerk here, but does this mean that all someone
> needs
> >is your product and knowledge of the id used, in order to generate the
> >key(s) to decrypt data encrypted with that id???
> 
> >I am probably missing something here, but it sounds like there is
> something
> >intrinsically wrong with that premise.
> 
> You aren't being a jerk, you're asking a great question, because I failed
> to explain how key access is controlled. Any key server has some sort of
> authentication: ours ships with several (password-based, user/password,
> LDAP, Active Directory, etc.), and is built so it's trivial to add more --
> based on phase of the moon or stock prices or whatever you can program. So
> no, knowing the identity used doesn't help a cracker break into Voltage
> SecureData, any more than knowing the key name helps with any other key
> management system.
> 
> Knowing the identity and even the key generation algorithm wouldn't help
> you create keys on your own, either. Remember, there's root key material
> configured in the key server (as is something similar in all key servers,
> whether it's explicit or just entropy). This root key material is what
> needs to be backed up with Voltage SecureData: when you instantiate a key
> server, you create a one-time backup (or hopefully several copies of it!)
> and put THAT in your safe. Then you can ALWAYS recreate a key server and
> your keys, by firing up a hot/warm/cold spare and restoring that
> configuration. Hey presto, it can serve the keys you need.
> 
> With most key servers you have to back up keys constantly -- which means
> those key backups are now a target. They also generate the key names with
> the keys, so the data flow is all from the key server to the application.
> And now there are TWO critical, dynamic pieces of data to back up: the key
> AND the key name. If you lose either, your data is gone. Most key servers
> pre-generate groups of keys, so they can do a backup before the keys are
> needed -- but the key name must still be matched to the data (and they
> better generate ENOUGH keys for a day's requirements, eh?). If the data
> store is DB2 or equivalent, that's not too bad: you add a column
> containing the key name used to encrypt a given row, and in a DR scenario,
> you restore your encrypted database and your key database and life goes
> on. It's a bit harder with most other datastores, as you have to store the
> key name somewhere. (Oh, and you DID take as much care backing up the key
> database as you do the data, right? And yo!
>  u protected the key database somehow, presumably NOT storing it with the
> data backups? So you have two sets of daily data that must be kept
> separate: key and data backups. Hmm.)
> 
> With Voltage SecureData, your daily backups are just as they were before
> encryption: data. Your key server-related backups (the configuration) are
> infrequent, and are thus easy to manage. These configurations (we call
> them "districts") are small and easy to back up, and the key server can
> support an essentially unlimited number of them (presumably limited only
> by disk space).
> 
> To (perhaps) anticipate your follow-on question, the next nightmare of
> encryption is rolling keys. Rolling keys means changing keys periodically
> as required by many regulations (PCI et al). You can roll keys within a
> district, so most customers do not tend to have many separate districts,
> just generations of keys within a distri

Re: Mainframe Executive article on the death of tape

2010-03-24 Thread Scott T. Harder
Thanks, John.  I wasn't sure of the circumstances; just a somewhat clear
memory of DCK's on 3480's.  Everyone else was so clear to the contrary that
I just had to do a sanity check.  It's good to know that I'm still somewhat
sane.

My best to you, John.  Good to hear from you

;-)

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of John Kington
> Sent: Wednesday, March 24, 2010 8:07 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Mainframe Executive article on the death of tape
> 
> Scott,
> 
> >I have to chime in to the contrary.  I seem to remember many data check
> >errors on 3480 cart media.  Am I the only one?
> 
> Spencer hit it on the head. The only significant problem with 3480 tapes
> was due to faulty media produced by BASF.
> 
> Regards,
> John
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: Mainframe Executive article on the death of tape

2010-03-24 Thread Scott T. Harder
> one of the datacenters we looked at was in a large downtown skyscraper
> ... and the claim was that the datacenter earned more profit in 24hr
> period than the annual rent on the whole bldg plus the annual salaries
> of everybody that worked in the bldg.

Hence, the annual 3%-4% raises for those in the trenches?

I kid.

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

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


Re: Crazy idea for a "desktop integration with z/OS" project?

2010-03-25 Thread Scott T. Harder
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of clementcla...@ozemail.com.au
> Sent: Thursday, March 25, 2010 4:33 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Crazy idea for a "desktop integration with z/OS" project?
> 
> Charles Mills wrote:
> > I think Chris has hit the nail on the head with regard to the viability
> of
> > this idea as a product of some sort. (As a personal project -- that's a
> > different matter.)
> >
> > Most "mainframers" (however that term might be defined) are familiar
> with
> > TSO and ISPF. There would be a learning curve to use this new product.

Some; but not much, if designed properly.  I think we "mainframers"
understand how to use a well designed GUI and, in fact, have had to tech
ourselves how to use more than our share of poorly designed GUI's.  ;-)

I think that one major issue, however, is the sheer enormity of the project
we speak of.  I agree that a new z/OS user interface is a waste if it ends
up leaving ISPF hanging around for whatever function that was not or could
not have been included.  I also think that a new user interface for z/OS is
absolutely needed if z/OS is really going to take root with the kids who IBM
is trying desperately to convert via their Academic Initiative (which I
fully support, btw).

There will, obviously, be some overlap but it needs to be kept to a minimum.
Bring it on, IBM.

All the best,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL



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


Re: Mainframe Executive article on the death of tape

2010-03-25 Thread Scott T. Harder
Hi Shmuel,

Rightly categorized as incredibly vague and not to the point of the original
post.  My apologies to all.  ;-)

All I know is that many of the replies to the OP were in the "no errors at
all... what are you talking about?" camp, and my memory as an MCO in a
growth shop from 1987-1994 (about... until I finally made it to Technical
Services and Storage Management for 10 months, before moving to system
automation support until my resignation from this large telco in mid-1997)
was that we did, indeed, receive DCK errors on 3480 media more times than I
would like to have seen happen.  Of course, some errors were due to hardware
problems, but we definitely had our share of true data check (media) errors.
Subsequent posts indicate the cause to be some sort of manufacturing issue
with BASF tapes (that I *know* we used); as well as Imation tapes (that I
*know* we used).  So, I can only attribute our particular issues at the time
to those problems (not knowing any better, really).

My memory is not wonderful, but I do remember these occurrences.  I really
just wanted to convey my experience, which seemed to be so contrary to what
most other posters to the thread were saying.

All the best,
Scott

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Shmuel Metz (Seymour J.)
> Sent: Thursday, March 25, 2010 5:21 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Mainframe Executive article on the death of tape
> 
> In , on 03/24/2010
>at 07:07 AM, "Scott T. Harder"  said:
> 
> >I have to chime in to the contrary.  I seem to remember many data check
> >errors on 3480 cart media.
> 
> How many is "many"? Even with defective tapes I've never seen 2 digit
> failure rates on CDC's,  IBM's, RCA's or STK's mainframe tape drives.
> 
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: Mainframe Executive article on the death of tape

2010-03-26 Thread Scott T. Harder
Right... This is why I said that I did not do a good job of staying on point
as far as the original post.  Those numbers in the failure rates reported
were *multitudes* higher than anything I have ever seen or heard of.  Again,
I only chimed in because of the subsequent posts that made it sound like DCK
errors went away with the advent of the 3480.

All the best,
Scott

Scott T. Harder
Mainframe Services, Inc.
Naples, FL



> Hi Scott, seeing as that your experience is different than 1% failure
> rate reported most posters, I am interested in an estimate of what kinds
> of error rates you saw. Were you seeing the 15-50% referenced in the
> article? Or rather just something in excess of the 1% being reported?
> 
> I definitely saw many media errors, but in the scheme of the tens of
> thousands of tapes being passed, it was certainly below 1%. Of course
> that didn't help much when you took a tape error in the middle of a
> hundred reel file, and had to explain to the programmer once again the
> importance of making their two day jobs restartable.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: How to recatalog to a different master catalog?

2010-03-26 Thread Scott T. Harder
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Steve Dover
> Sent: Friday, March 26, 2010 8:11 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: How to recatalog to a different master catalog?
> 
> John, I agree that naming standards and such should be durable.  BUT, when
> you come into a shop that has had more system programmers than Carter has
> little pills (I figure everyone here is old enough to remember that,
> including me), 

I always thought it was "liver pills", whatever those might be.  I never
"got it".  It was something my father always said (and does to this day).  I
get him back with "tricky Dick" references, myself.  Once bought him a
shower head that was The head/face of Richard Nixon where the water came out
through his wide open mouth.  One of the funniest things I've ever seen to
this day.  ;-)



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


Re: Mainframe emulator part of a conspira cy • The Register

2010-03-26 Thread Scott T. Harder
I really enjoyed reading this article, but in the end it left me flat again; 
with no hope of a viable solution to the problem.  I had no idea that this 
issue went back so far in history, which also added to my dismay about the 
whole thing.  

I don't know about you all, but those FLEX-ES boxes were a ton of fun to work 
on (and the P/390... never worked on a Multiprise, but those looked fun too).  
Why can't we have that again??  I'd be running z/OS and actively doing 
development for the platform *right now* if I had that capability.  As it is, 
it seems to me that IBM does nothing but hurt themselves and the platform in 
general with their current stance (sorry for the quite obvious statement).

Also sorry that I can't afford Dallas on my own.  What am I to do but to learn 
C#?????

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of McKown, John
> Sent: Friday, March 26, 2010 9:24 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: IBM: Mainframe emulator part of a conspira cy • The Register
> 
> http://www.theregister.co.uk/2010/03/26/ibm_turbohercules_response/
> 
> 
> 
> Comment Let's start with the obvious: there was never a poor bald geek's
> chance with a supermodel that IBM was ever going to willingly license its
> z/OS and related systems software so it could run on the commercialized
> version of the open source Hercules mainframe hardware emulator for x64
> iron.
> 
> So the launch of the
> TurboHercules<http://www.theregister.co.uk/2009/09/25/turbohercules_goes_c
> ommercial/> commercial version of the mainframe hardware emulator in
> September 2009 was always going to end up living or dying based on what
> some court somewhere would say.
> 
> 
> 
> 
> 
> John McKown
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets®
> 
> 9151 Boulevard 26 • N. Richland Hills • TX 76010
> (817) 255-3225 phone • (817)-961-6183 cell
> john.mck...@healthmarkets.com • www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain confidential or
> proprietary information. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message. HealthMarkets® is the brand name for products underwritten and
> issued by the insurance subsidiaries of HealthMarkets, Inc. –The
> Chesapeake Life Insurance Company®, Mid-West National Life Insurance
> Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

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


Re: Mainframe emulator part of a conspira cy • The Register

2010-03-26 Thread Scott T. Harder
Scott T. Harder
Mainframe Services, Inc.
Naples, FL
 


> The Dallas system is less expensive than a P390 (or Flex-ES) was. 

Yeah... That's the other thing (or, another in a long line of things) that 
doesn't make sense to me about this.  They (IBM) seem to be throwing the baby 
out with the bath water with regards to the awesome deal they give on the 
Dallas thing.  It *must* be costing them a ton of money, no?  I just 
incorporated myself recently and so my stated experience with FLEX and the P390 
was with a company that I worked for before that *could* afford them.

> The zPDT is the logical successor to the P390, but frankly it too will be > 
> more expensive than using the Dallas system.

Right.  Is this to become GA in the US?  32- and 64-bit versions?



All the best,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

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


Re: Mainframe emulator part of a conspira cy • The Register

2010-03-26 Thread Scott T. Harder
Excuse the reply to my own post, but just wanted to make this addendum...

> I'd be running z/OS and actively doing development for the platform *right > 
> now* if I had that capability.

Or, if not actually working on a specific product of my own, I'd be able to 
test solutions (and/or behaviors) related to issues/problems raised on this 
list, and others like it that are z/OS oriented.  At least I'd be able to 
contribute in a meaningful, albeit small, way to the health and welfare of the 
platform in general.  Without a system to run, I'm completely reliant on 
memory; which is spotty at best. 

All the best,
Scott

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -----Original Message-
> From: Scott T. Harder [mailto:scott.har...@embarqmail.com]
> Sent: Friday, March 26, 2010 10:14 AM
> To: 'IBM Mainframe Discussion List'
> Subject: RE: Mainframe emulator part of a conspira cy • The Register
> 
> I really enjoyed reading this article, but in the end it left me flat
> again; with no hope of a viable solution to the problem.  I had no idea
> that this issue went back so far in history, which also added to my dismay
> about the whole thing.
> 
> I don't know about you all, but those FLEX-ES boxes were a ton of fun to
> work on (and the P/390... never worked on a Multiprise, but those looked
> fun too).  Why can't we have that again??As it is, it seems to me that 
> IBM does nothing but hurt
> themselves and the platform in general with their current stance (sorry
> for the quite obvious statement).
> 
> Also sorry that I can't afford Dallas on my own.  What am I to do but to
> learn C#?
> 
> Scott T. Harder
> Mainframe Services, Inc.
> Naples, FL
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> > Behalf Of McKown, John
> > Sent: Friday, March 26, 2010 9:24 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: IBM: Mainframe emulator part of a conspira cy • The Register
> >
> > http://www.theregister.co.uk/2010/03/26/ibm_turbohercules_response/
> >
> > 
> >
> > Comment Let's start with the obvious: there was never a poor bald geek's
> > chance with a supermodel that IBM was ever going to willingly license
> its
> > z/OS and related systems software so it could run on the commercialized
> > version of the open source Hercules mainframe hardware emulator for x64
> > iron.
> >
,> > So the launch of the
> >
> TurboHercules<http://www.theregister.co.uk/2009/09/25/turbohercules_goes_c
> > ommercial/> commercial version of the mainframe hardware emulator in
> > September 2009 was always going to end up living or dying based on what
> > some court somewhere would say.
> >
> > 
> >
> >
> >
> > John McKown
> > Systems Engineer IV
> > IT
> >
> > Administrative Services Group
> >
> > HealthMarkets®
> >
> > 9151 Boulevard 26 • N. Richland Hills • TX 76010
> > (817) 255-3225 phone • (817)-961-6183 cell
> > john.mck...@healthmarkets.com • www.HealthMarkets.com
> >
> > Confidentiality Notice: This e-mail message may contain confidential or
> > proprietary information. If you are not the intended recipient, please
> > contact the sender by reply e-mail and destroy all copies of the
> original
> > message. HealthMarkets® is the brand name for products underwritten and
> > issued by the insurance subsidiaries of HealthMarkets, Inc. –The
> > Chesapeake Life Insurance Company®, Mid-West National Life Insurance
> > Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

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


Re: Mainframe emulator part of a conspira cy • The Register

2010-03-26 Thread Scott T. Harder
My personal problem is that I have - for some stupid reason - avoided *NIX like 
the plague.  It just seemed like going backwards to me when I *did* try to 
learn it pre-GUI.  I just figured, "why go back to a DOS-like or native 
TSO-like system

But, I no longer have that excuse and - you are right, John - this (open 
source) is probably the best way for me to go at this point; unless a suitable 
mainframe shop presents itself soon.  Now... what to rename my corporation 
to???  ;-)

All the best,
Scott

Scott T. Harder
Mainframe Services, Inc.
Naples, FL  

> C#?? Yuck! Install Linux/Intel. Learn lots of languages: C/C++, Objective-
> C, Perl, Python, PHP, Ruby, Erlang, Java, Clojure, Scala, Groovy, C#
> (Mono's csharp), Io, Lua, Bash (shell scripting), Lisp (many variants),
> Haskell (2 different versions), Curry, Gambas (BASIC), Ada, Forth, Scheme
> (LISP-like), OOREXX, Regina (REXX), R (statistics), Slang, TCL/Tk, even
> more.
> 
> I need an SQL database: SQLite, MySQL, PostgreSQL, Derby
> 
> I need an editor: vi/vim/gvim, emacs, kate, nedit, eric, ...
> 
> I need an IDE: Eclipse, NetBeans, Kdevelop, Anjuta, Qt Creator, ...
> 
> I need source management: CVS, Subversion, git.
> 
> I need an office package: Koffice, OpenOffice (MS Office file read/write),
> many XML editors and document editors.
> 
> I need Visio work: Kivio, Dia .
> 
> I need virtual machine capability: KVM, Xen, VirtualBox OSE, dosbox, ...
> 
> I need ... application which is only available under Windows: Install
> Windows in a VM. But first try Wine or Crossover Linux (costs money, but
> inexpensive) to run the Windows apps under Linux.
> 
> Gee, what does all this cost ABSOLUTE FREE FOR THE DOWNLOAD. You
> supply the PC.
> 
> --
> John McKown
> Systems Engineer IV
> IT
> 
> Administrative Services Group
u/archives/ibm-main.html

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


Re: Mainframe emulator part of a conspir a cy â â¬Â¢ The Register

2010-03-26 Thread Scott T. Harder
> POSIX shell is _not_ DOS-like nor native TSO-like.

I should have said command-driven, as that is what I was trying to get at;
right or wrong.  Also around the same time, I had been introduced to ROSCOE
after being a TSO (ISPF/PDF) person my "whole life" (from 1984).  So, I was
all about menus, macros, skeletons, REXX, and Clist.  Absolutely could not
see the forest through the trees at that point.  
 

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


Re: Mainframe Executive article on the death of tape

2010-03-29 Thread Scott T. Harder
> Will SSDs ever "completely" replace hard disks? We'll see.



I'm missing a whole lot of experience with regards to the changes with SSD
in the data center over the last 10+ years.  Perhaps someone can fill me in
a bit?  I remember a SSD unit in a data center I worked in around 1990-92
(not sure, really.  We still had a 3084 in production, so that should frame
it somewhat).  They had very performance-critical data sets on it...
important system software checkpoint data sets, etc.  It worked fine, until
issues with the UPS caused extended power outages; and that happened quite a
bit.  What has changed in SSD (longer  battery life?) or UPS systems
(something to make them more reliable?) that would ever get us to the point
of hard disks going away?  If there is even the smallest chance of the
batteries crapping out on the SSD's, it would be way too risky, no?

Thanks!

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

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


Re: Regarding Loadmodule transfer..

2010-03-29 Thread Scott T. Harder
Use the TSO TRANSMIT (XMIT) command, such as this one below, putting the
loadmod into a FB/80 format:

XMIT X.X DA(/) OUTDA('FB.80.PDS')

This assumes you previously copied the loadmod to a PDS all by itself and
that you are issuing this from option 3.4 against the PDS where you copied
the loadmod to.

Then, do a BINARY download (IND$FILE or FTP... your choice) from the
mainframe to your PC/network.  You can then attach to an email or send to
somewhere else via FTP.  That is, unless you sent it directly to the
intended place from the mainframe.

Once on the desired mainframe on the other end, use the TSO RECEIVE command
to unload.  I always Issued:

TSO RECEIVE INDA(/) 

... FROM 3.4 and then responded to the prompt for parameters with:

DA('TARGET.DSN')

If your default data set attributes are not right, always pre-allocate.
That goes for both sides.

If u need more detail step-by-step, contact me offline - or I'm sure someone
else will provide it on the list.

HTH,
Scott

Scott T. Harder
Mainframe Services, Inc.
Naples, FL
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of SUBSCRIBE IBM-MAIN Joe H. Smith
> Sent: Monday, March 29, 2010 11:44 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Regarding Loadmodule transfer..
> 
> How to transfer load modules from mainframe to pc...please can any body
> explan me...
> 
> Thanks,
> N.Suresh
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: Mainframe Executive article on the death of tape

2010-03-29 Thread Scott T. Harder
Ed,

Agreed...

I think we would all be appalled and scared crap-less (to put it nicely) if
we all really knew the true state of BCP's at many companies.  There should
be more customer involvement in DR; built into the contracts.  IOW, review
of required test results, etc., if the customer so chooses; at a minimum, so
that they can tell that a test was done!  Rigid accountability to those that
make the company viable is the only way towards improvement here.

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Ed Gould
> Sent: Tuesday, March 30, 2010 12:21 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Mainframe Executive article on the death of tape
> 
> 
> From: Ted MacNEIL 
> To: IBM-MAIN@bama.ua.edu
> Sent: Mon, March 29, 2010 8:35:23 PM
> Subject: Re: Mainframe Executive article on the death of tape
> 
> >I thinkk you'll find a significant, though maybe not large, number of
> shops running straight from the grid today. For those shops, the cost of
> an outage may be lower than the cost of power conditioning and/or UPS
> equipment.
> 
> Wow!
> I haven't worked at a shop without conditioning and UPS since the early
> 1980's.
> 
> And, GTA power was pretty noisy back then.
> So, nobody ran raw, that I know of.
> 
> 
> Ted:
> 
> But there are more than a few out there that do not. I shudder at such
> places. Some places have 24 X 7 X 7 requirements and they still do not
> have it.
> I was at one place and their DR scenario was to go offsite to an obsolete
> system that was 10 years old when it was started. They sit there at board
> meetings and with a straight face say they have DR working perfectly.
> Chuckle chuckle The system they want to IPL won't because they refuse to
> believe you cannot just IPL any old version of MVS.
> 
> Ed
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 

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


Re: You know you've been doing too much MVS when...

2010-03-31 Thread Scott T. Harder
Ouch, again.  You guys are tough on a man!

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Scott Rowe
> Sent: Tuesday, March 30, 2010 10:27 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: You know you've been doing too much MVS when...
> 
> Would that imply a manager that actually does productive work, or just one
> that is functional? ;-)
> 
> >>> "Jousma, David"  3/30/2010 10:08 AM >>>
> Ouch.  I prefer working manager



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

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


Re: Mainframe Executive article on the death of tape

2010-03-31 Thread Scott T. Harder
Thanks, Rick.  I was beginning to think that my post didn't hit the list,
and I had figured it to raise more than a few hairs on the backs of heads.
;-)

Anyway...  Yes!  I think (don't know at all, for sure, so this is just my
opinion) that too many shops back up data and that's it.  Without repeated
testing, backups are worth squat.  Not to mention all the other required
facilities, such as telephony, internet connectivity, etc., etc., etc.

All the best,
Scott

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Rick Fochtman
> Sent: Tuesday, March 30, 2010 10:04 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Mainframe Executive article on the death of tape
> 
> ---
> I think we would all be appalled and scared crap-less (to put it nicely)
> if we all really knew the true state of BCP's at many companies. There
> should be more customer involvement in DR; built into the contracts.
> IOW, review of required test results, etc., if the customer so chooses;
> at a minimum, so that they can tell that a test was done! Rigid
> accountability to those that make the company viable is the only way
> towards improvement here.
> 
> Complete agreement, Scott. But far too many "IT Executives" are
> interested only in the "bottom line". DR planning and testing are an
> insurance policy that is all too often viewed as an unnecessary expense.
> 
> During the "Chicago Flood" of 1992, we discovered a number of holes in
> our disaster recovery procedures, but our provider was able to supply
> the necessary expertise and equipment to plug those holes. Consequently,
> we were able to recover our (admittedly small) shop in just over 5
> hours, at least to the point where our basic business functions could
> proceed. Then we hit issues like how to distribute printed reports, and
> how to print them in a timely fashion. That's when we learned about
> channel extension, power supply and distribution at alternate sites. All
> in all, a very powerful learning experience.
> 
> Another shop that I know of never did get running at the DR site; quite
> a few heads were rolled after that little fiasco, and they were
> high-level heads! :-)
> 
> Rick
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: Hercules Emulator on window vista

2010-04-05 Thread Scott T. Harder
Speaking of which...

What is the highest version of MVS that one can legally run under Hercules
without a license?  And, where can one obtain that version of MVS for that
purpose?

Thanks!

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Brian Westerman
> Sent: Monday, April 05, 2010 4:45 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Hercules Emulator on window vista
> 
> It's fully supported on all versions of windows from XP on up to Windows 7
> (32 and 64-bit) as well as on a MAC.
> 
> As the previous post stated, the best place for information is on one of
> the
> several hercules based lists.  If you are authorized to run z/OS, then you
> will want one of the Hercules-390 based lists, otherwise for 370 based
> Hercules, you want the Hercules-370 lists or the Hercules Turnkey list for
> the all-in-one MVS 3.8 and Hercules combination all in one integrated
> package.
> 
> Brian
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: Console's behavior when no paths available

2010-04-10 Thread Scott T. Harder
I thought console buffer shortages were not supposed to happen anymore...
period??


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Barbara Nitz
> Sent: Wednesday, April 07, 2010 2:38 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Console's behaviour when no paths available
> 
> Last night (well, way into this morning) we had a severe WTO buffer
> shortage
> that nobody saw. Here's why:
> 
> *IOS071I 0500,**,CONSOLE, START PENDING 378
> *IOS002A 0500,NO PATHS AVAILABLE
>  IOS2002I 0500 NO PATHS AVAILABLE 381
>  STATUS FOR PATH(S) ED
>SUBCHANNEL PATH AVAILABLE, BUT DEVICE NOT OPERATIONAL (C0)
>NO FURTHER INFORMATION AVAILABLE OR UNKNOWN CONDITION (FF)
> 
> 3.5 hours later:
> 
> *IEA405E WTO BUFFER SHORTAGE - 80% FULL
> IEE889I 01.04.41 CONSOLE DISPLAY 111
> MSG: CURR=2401 LIM=3000 RPLY:CURR=18   LIM=99   SYS=  PFK=00
>  xx 46  COND=A  AUTH=MASTER   NBUF=2390
>   0500  AREA=Z,AMFORM=T,S,J
>     DEL=RD   RTME=1/4RNUM=15   SEG=14CON=N
> K S,DEL=R,L=xx
> IEE151I DELETE REQUEST INCONSISTENT-NO DISPLAY ON SCREEN
> COMMAND ISSUED IS K E,D,L=xx
> 
> Severe WTO buffer shortage a short while later. No other IOS messages or
> CNZ messages (no cnz messages before the buffer shortage) until the
> console
> was varied online again *hours* later (while still in severe wto
> shortage):
> V 500,ONLINE
> IEE302I 0500 ONLINE
> LOGOFF - ISSUED BY IEECVFTG
> IEA406I WTO BUFFER SHORTAGE RELIEVED
> 
> At the time of the IOS002A another system in another sysplex but on the
> same box got this:
> *IOS050I CHANNEL DETECTED ERROR ON 0500,**,**,**04
>  CNZ4200I CONSOLE zz HAS FAILED. REASON=IOERR
> 
> Now my question (mainly to IBM - will probably be faster than going
> through a
> tedious ETR): Why the heck isn't the console address space notified that
> no
> paths are available? Why is the console address space still issuing
> messages to
> that console? Why isn't console notified that the console 500 is not
> availabe
> anymore?
> 
> Nobody was able to even *see* the shortage messages since nothing got
> displayed on that console anymore
> 
> And if this is broken as designed, will I have to code an mpf exit that
> makes
> sure all buffer shortage messages will be sent to all consoles in the
> sysplex?
> Operators will be extremely happy about that (since many don't even know
> where to see which system issued the message- reading a formatted syslog
> message appears to be a dying/lost art).
> 
> Regards, Barbara Nitz
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: (slightly OT) CA is laying off 1,000 workers and expects to take a $50m h...

2010-04-10 Thread Scott T. Harder
Amen to that.  True words.  It ain't real nice weather "out here" right now.
I'm not from CA, but brave the same elements.

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Chris Craddock
> Sent: Friday, April 09, 2010 4:52 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: (slightly OT) CA is laying off 1,000 workers and expects to
> take a $50m h...
> 
> On Fri, Apr 9, 2010 at 9:19 AM, Ed Finnell  wrote:
> 
> >
> > In a message dated 4/9/2010 9:14:34 A.M. Central Daylight Time,
> > maryanne4...@gmail.com writes:
> >
> > Um, it wasn't Ed Gould, it was zman.
> >
> 
> 
> True and regardless of who posted the original story it is at best
> insensitive to take any pleasure in seeing 1000 people lose their jobs.
> FWIW
> the overwhelming majority of people I worked with at CA are great and
> today's CA is not the big bad CA of old. But no matter what you might
> think
> of the company they work for, those are real people with families and
> responsibilities. Now they are going to be facing a really tough time. A
> little empathy would be a much more civilized response.
> 
> 
> --
> This email might be from the
> artist formerly known as CC
> (or not) You be the judge.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: CONNECT:Direct performance problem

2009-05-02 Thread Scott T. Harder
Wow, Pat.  Is there anything you can do to try to create an environment such
as is with the long x-missions?  I hate to be trite, but it sounds like you
have too many things going on and you need to take them one at a time.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Patrick O'Keefe
Sent: Saturday, May 02, 2009 5:15 PM
To: IBM-MAIN@bama.ua.edu
Subject: CONNECT:Direct performance problem

We have recently run into a very odd performance problem with Sterling
Commerce's CONNECT:Direct (aka NDM).  We've opened a problem
ticket on this but I'd like to see if any other users C:D users have seen
anything similar.

Some time over the last 2 or 3 weeks we've seen a very large increase
in the transmission times for some very large sequential datasets.
Transmissions that used to take 20 minutes are now taking over 3 hours.
This does not appear to be related to cycle availability at either end.

For a while this problem was consistently related to our C:D on our
production LPARs; the same transmission from a "development" LPAR
ran at the old fast rate.   Someone noticed that our we have
checkpointing enabled by default on the prod C:Ds but not on the
dev C:Ds so we turned it on on one of the dev C:Ds.  Sure enough,
the transmission rate took a nose dive.  Unfortunately, turning
checkpointing back off did not make the performance go back up.  :-(

Nothing changed in CONNECT:Direct in the past 3 weeks, but we did
put some MVS (z/OS 1.8) maintenance on.  (I don't know what maint.)

To make things more puzzling, we have not had any obvious problem
with our usual production transmissions.  (This kind of increase
SHOULD have been noticeable even if SLAs were still met.)

Effected datasets are involved in an upcoming event that has gone
through a number of trial runs with approximately the same amount
of data, and with people carefully noting transmission times.  This
increase has had a lot of unfavorable attention.

Is anyone familiar with this kind of CONNECT:Direct behavior?

Pat O'Keefe

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


Click here to find the perfect picture with our powerful photo search features.
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYR2bmNv2yLHrYX7n70UbdTRtb31UTSNJM0Ug8STAld0iyWuqH61aA/

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


Re: Pricing of Software Licenses

2009-05-05 Thread Scott T. Harder
IMVHO... the software vendors (most of them) have not embraced SCP for the
simple reason that they can get more of your money the old fashioned way.
That's all I have to say on this subject.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Hal Merritt
Sent: Tuesday, May 05, 2009 6:41 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Pricing of Software Licenses

The applicability of sub capacity pricing is a pretty complex issue. Usually
software is priced in MIP or MSU ranges so you'd have to figure out what
your break points are. For example, we have a license for a product that
goes up to 110 MSU. If we use more than that, then we move to the next tier.

The larger strategy is to buy a much bigger box than you need and then grow
into it. Meanwhile your software costs grow along with your workload not
with a big bang for the new box.

Conversely, if your shop is shrinking, your software costs also shrink.

All assuming, of course, that your OEM software venders will agree to the
reduced prices.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Jacky Bright
Sent: Friday, May 01, 2009 9:15 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Pricing of Software Licenses

Yes. We do have sub-capacity pricing, but to generate SCRT report we need
Type 70 records for which either CMF or RMF Required.  So its necessary to
have RMF or CMF.

Now that this topic has come up its worth discussing pricing of softwares. I
have a question here. If your utilisation is consistently more that 80-85%
of overall CPC capacity then is it worth going for sub-capacity pricing ? I
have not done any research on this but came to know from one sales guy that
I sub-capacity pricing is 10% more than PSLC charges.

Does anyone have any idea about this ?

JAcky




NOTICE: This electronic mail message and any files transmitted with it are
intended
exclusively for the individual or entity to which it is addressed. The
message,
together with any attachment, may contain confidential and/or privileged
information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

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


Click here to find the perfect picture with our powerful photo search features.
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYR2bmF68OwiCW3rOiKJmsh11eVfj7xHJ7ZCykb9zKDD5wKOTIYNtG/

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


Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

2009-05-05 Thread Scott T. Harder
Sorry, guys.  In my world, Application Programmers have no business having
access to Storage Management utilities like DSS.  Period.  That needs to
remain a centralized function.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Thompson, Steve
Sent: Tuesday, May 05, 2009 6:52 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

Having done a few VSE to MVS migrations, let me speak to this at a
conceptual level.

What kind of security risk is it for someone to duplicate a volume with
sensitive data on it? This can be done with FLASHCOPY or physical volume
backup (DSS).

Granted, in a VSE shop, programmers get much more freedom than they do
under MVS.

And just like in the VSE shop, you can access NON-VSAM files as long as
you know the VOLSER where the data is. So a CLIP and a VARY ONLINE and
the data is available.

However, if the senior level programmers have access to flashcopy, how
would you know that a volume had not just been clobbered before you got
it backed up? Two people using the same "phantom" volume, and the last
one to write wins. How would you ensure that the production backups and
the programmers are using different volumes for the flashcopy?

UNLIKE VSE, MVS does not have the catalogs owning the volumes where
their VSAM files are. So "catalog backup" doesn't work for MVS as it
does for VSE. And DSS logical backups come close, but there are some
gaps that can cause serious heartburn during DR testing.

Again, not even using the MVS SMS capabilities, MVS manages files for
you, while under VSE, without some third-party product, you (the data
manager) must assign EXTENTS on volumes. Very different mind-set and
function between MVS and VSE (and granted, my VSE knowledge is rather
dated, I really haven't touch VSE for a while, and not even looked at
z/VSE).

DSS also allows you to take that logical backup and then rename for
restore. How do you secure this, so that production data (perhaps
subject to HIPPA) doesn't get out in the wild (as it were)?

You will want to make sure that the security "keys" in your security
system are set appropriately. Which brings up a new set of concepts.
What Security system did you have for VSE? If you didn't have one, MVS
does things at the data set name level. So it might not matter what the
volser is, DSN=A.B.C obtained via the CATALOG system, or via VOLSER will
be checked.

Many concepts to understand that are very different in their
implementations between the two environments.

Regards,
Steve Thompson




That is the question I am trying to have answered.  What harm might be
done
in giving programmers access to DSS COPY flashcopy?  Going by the name
of
the resource and the comments on
http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.i
bm.zos.r9.e0zh300/dssracf.htm
it would appear that this resource pertains only to DSS COPY and not to
Flashcopy in general.  Therefore I would think that giving programmers
rights to it would not unexpectedly give us rights to something else.
Does
anyone disagree with this?

To answer someone else's question about something having "changed" if we
could do this before but can no longer, this is not the case.  We are a
new
z/OS shop (in process converting from VSE), and I had just never tried
this
function before.

Thanks!
Frank



-- Opinions expressed by this poster may not reflect poster's employer's
views or policies. --

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


Keep clean no matter where you are with a portable shower. Click here!
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYUV4MoOpluAzyqiv3TthIPudJkgWCtCuXlV252QuCinpP8036JHvK/

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


Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

2009-05-05 Thread Scott T. Harder
Well... I don't know about that (sysprogs).  Probably - yes - from a pure
security standpoint - but I was retiring a string of DASD one time and I
screwed up the TMC (CA,'s) and it was a sysprog that saved my bacon.  I
suggested the only way out of the deal, but without his authority it would
not have been possible.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Ted MacNEIL
Sent: Tuesday, May 05, 2009 7:39 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

>Sorry, guys.  In my world, Application Programmers have no business having
access to Storage Management utilities like DSS.  Period.  That needs to
remain a centralized function.


ABSOLUTELY!
Even sysprogs should not have access.
Only those who are storage admins!

Would you give RACF special to non-security types?

Somebody pointed out that if you gave somebody OPERATIONS to an ID, they
could do some damage.
Well, don't give them the attribute!

Doctor, it hurts when I do this.

Well, stop doing that!

-
Too busy driving to stop for gas!

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


Put your loved ones in good hands with quality senior assisted living. Click 
now!
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYWs6wKmg86SaEesgnY9HAjKwhtk0jWNSkd1onKuGDWcnG4VLG0KNS/

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


Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

2009-05-06 Thread Scott T. Harder
I can see where IF you have ALL the appropriate security profiles set up
properly, then I suppose I see your point.  For me, though, I would rather
cut off access completely.  I would ask "Why do they need it?"  If your SMS
constructs and ACS routines, and your backups, are all set up properly, why
do they need to be moving data around or backing it up with DSS???

I think my mom *did* say that once or twice, btw.  ;-)

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of R.S.
Sent: Wednesday, May 06, 2009 4:28 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

Scott T. Harder pisze:
> Sorry, guys.  In my world, Application Programmers have no business having
> access to Storage Management utilities like DSS.  Period.  That needs to
> remain a centralized function.

Why?
Because mama said that?
Poor justification.

In my shop appliccation prgrammers have access to any tool they want,
UNLESS it is dangerous, i.e. bypasses regular security checking.
That's why DSS is available to everyone, but STGADMIN.ADR.STGADMIN.** is
not.

--
Radoslaw Skorupka
Lodz, Poland


--
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.2009 r. kapita zakadowy BRE Banku SA (w
caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj
warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z
dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r.,
moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym
kapitale zakadowym BRE Banku SA bd w caoci opacone.

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


Click to get free auto insurance quotes from top companies.
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYVuaBWv7AWYURlb9WSMu72CGqSBxVgXhvzxo95aAj9ZRRnhV5d7eI/

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


Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

2009-05-06 Thread Scott T. Harder
Radoslaw,

I meant "you" in the general sense.  Your points are well taken, but I would
still have a hard time distributing DSS.  Just some nagging feeling in the
back of my head tells me that, eventually, something "not good" would come
of that.  Can't come up with any examples and I could be very wrong (sure
wouldn't be the first time!).  But, I can't shake that feeling.  I guess
we'll just have to agree to disagree.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of R.S.
Sent: Wednesday, May 06, 2009 10:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

Scott T. Harder pisze:
> I can see where IF you have ALL the appropriate security profiles set up
> properly, then I suppose I see your point.

Yes, I do have all the appropriate profiles set up. It's really easy.
More: it's enough not to create any of them. As I said previously, all
"powerful" functions are disabled by defualt (require explicit
authorization).

IMHO it is very (yes VERY) bad approach - to disable the tool because
someone does not know how to protect it or "just by default".


> For me, though, I would rather
> cut off access completely.  I would ask "Why do they need it?"  If your
SMS
> constructs and ACS routines, and your backups, are all set up properly,
why
> do they need to be moving data around or backing it up with DSS???

It's enough for me to know they *could* want it. However the tool allows
i.e. to copy HLQ1.DEV.** to HLQ2.TEST.** with many other options. Of
course the programmer has ALTER to both dataset profiles. In your shop
he has to do it one-by-one dataset, in my shop he codes single JCL step.

BTW: there is a list of IBM-supplied programs which should be restricted
by default. This is very short list: IEHINITT, IRRDPI00, ICHDSM00 (it's
information-only tool, it doesn't change anything).

Hammer for everyone! We should protect fingers, not hammers. 

Regards
--
Radoslaw Skorupka
Lodz, Poland


--
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.2009 r. kapita zakadowy BRE Banku SA (w
caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj
warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z
dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r.,
moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym
kapitale zakadowym BRE Banku SA bd w caoci opacone.

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


Get the best Criminal Lawyer. Click Here
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYbd6xqMCWsduaF7zR56Al7s7VQGTKKpfJpsppgT26rHn45VL1Xcru/

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


Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

2009-05-06 Thread Scott T. Harder
I *knew* I had read that (Mark's last point) somewhere.  Yeah That's the
ticket!

(One of my favorite SNL references.  Right behind the "Bass-O-Matic".

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Stephen Mednick
Sent: Wednesday, May 06, 2009 4:11 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]



> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott T. Harder
> Sent: Thursday, 7 May 2009 2:19 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]
>
> Radoslaw,
>
> I meant "you" in the general sense.  Your points are well
> taken, but I would still have a hard time distributing DSS.
> Just some nagging feeling in the back of my head tells me
> that, eventually, something "not good" would come of that.
> Can't come up with any examples and I could be very wrong
> (sure wouldn't be the first time!).  But, I can't shake that
> feeling.  I guess we'll just have to agree to disagree.
>
> All the best,
> Scott T. Harder
>

Scott, your response just underscores exactly the attitude Mark Zelden was
referring to in his posting for this thread especially his last point!

Stephen Mednick
Computer Supervisory Services
Sydney, Australia


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


Click for the latest fitness products and trends. 
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYWlS5qFUAAABtjAq668oYp5lU2de6JXduQoXC6concX3JQ3zLwFu4/

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


Unsubscribe Command

2009-05-06 Thread Scott T. Harder
Hi All,

At the moment, I am subscribed to IBM-MAIN with two personal email
addresses.  How can I UNSUBSCRIBE (or, I guess it’s now SIGNOFF) from just
one of these email addresses?  I have the REFCARD, but SIGNOFF doesn’t look
to do the job from what I can see.  Thanks!

All the best,
Scott T. Harder



Click now to find great remedies for hangovers!
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYX6cPu0faKh05GWzPkm4evfgujEIPrYCz3fv7oBRwy7uDXjWlKps0/

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


Test

2009-05-06 Thread Scott T. Harder
Test post.  Sorry.
 
All the best,
Scott T. Harder
 


Keep the bad stuff out and the good stuff in with a new hot tub cover. Click 
now!
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYTmpJ3dEIZJcAWi5qoBY1pPxZycEnpQNgMpjBwai6BIDH8nAErk9C/

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


Re: Test

2009-05-06 Thread Scott T. Harder
I just noticed that Netzero (it must be... or what?) is appending ads to the
bottom of my emails.  I don't appreciate it.  When I look at my Sent folder
the "hot tub" crap is not there!  Any shoves in the direction where I can
stop this is much appreciated.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Scott T. Harder
Sent: Wednesday, May 06, 2009 5:50 PM
To: IBM-MAIN@bama.ua.edu
Subject: Test

Test post.  Sorry.

All the best,
Scott T. Harder



Keep the bad stuff out and the good stuff in with a new hot tub cover. Click
now!
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYTmpJ3dEIZJcAWi5qoBY1pP
xZycEnpQNgMpjBwai6BIDH8nAErk9C/

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

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


Re: Test

2009-05-06 Thread Scott T. Harder
Yup.  Thanks!

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Lionel B Dyck
Sent: Wednesday, May 06, 2009 6:04 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Test

Switch e-mail providers

Try gmail - its free and works fine

Lionel B. Dyck, Consultant/Specialist

?Never attribute to malice what can be caused by miscommunication.?

NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail,
you are prohibited from sharing, copying, or otherwise using or disclosing
its contents. If you have received this e-mail in error, please notify the
sender immediately by reply e-mail and permanently delete this e-mail and
any attachments without reading, forwarding or saving them. Thank you.



From:
"Scott T. Harder" 
To:
IBM-MAIN@bama.ua.edu
Date:
05/06/2009 02:57 PM
Subject:
Re: Test
Sent by:
IBM Mainframe Discussion List 



I just noticed that Netzero (it must be... or what?) is appending ads to
the
bottom of my emails.  I don't appreciate it.  When I look at my Sent
folder
the "hot tub" crap is not there!  Any shoves in the direction where I can
stop this is much appreciated.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Scott T. Harder
Sent: Wednesday, May 06, 2009 5:50 PM
To: IBM-MAIN@bama.ua.edu
Subject: Test

Test post.  Sorry.

All the best,
Scott T. Harder



Keep the bad stuff out and the good stuff in with a new hot tub cover.
Click
now!
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYTmpJ3dEIZJcAWi5qoBY1pP

xZycEnpQNgMpjBwai6BIDH8nAErk9C/

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

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


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


Click here for expert wrinkle removal with Botox cosmetic solutions!
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYZldhdtfUXN0PdQ7fs8Yz7CbWCtWLVlV1FnzTNmTO7dP1Qbnu6KH2/

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


test

2009-05-06 Thread Scott T. Harder
 
 
All the best,
Scott T. Harder
 


Deter possible thieves with a reliable new car alarm! Click now!
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYaurqiNB5FZba1VBMSdB7JOaEHjlRrD66mymnHtvmnoENj5vN6At6/

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


Re: Mainframe articles

2009-05-11 Thread Scott T. Harder
Very cool.  Funny, though... I remember first logging onto TSO on what
I thought was a 3082 (although I didn't know what even DASD was at the
time).  Then, when I finally got my hands on a mainframe in MCO, it
was a 3084.  This slideshow shows a 3083, which I don't have any
recollection of.  Looks like a 3084, from what I can remember, though.

All the best,
Scott

On 5/11/09, Howard Brazee  wrote:
> A nice slide show on the history of IBM mainframes:
>
> http://www.eweek.com/c/a/IT-Infrastructure/The-IBM-Mainframe-50-Years-of
> -Big-Iron-Innovation-583073/?kc=EWKNLEDP05112009A
>
> http://www.eweek.com/c/a/IT-Infrastructure/50-Years-of-IBM-Mainframe-Mil
> estones-136541/?kc=EWKNLEDP05112009C
>
>
>
>
>
>
>
>
>
> Why the mainframe will never die
>
> http://www.eweek.com/c/a/IT-Infrastructure/IBM-Why-the-Mainframe-Will-Ne
> ver-Die-Part-I-164505/?kc=EWKNLEDP05112009B
>
>
>
>
>
>
>
> http://www.eweek.com/c/a/IT-Infrastructure/CA-Sees-Strong-Future-for-Mai
> nframes-234697/?kc=EWKNLEDP05112009D
>
>
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>


-- 
All the best,
Scott T. Harder

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


Re: Mainframe articles

2009-05-11 Thread Scott T. Harder
Maybe it was a 3080 when I first logged on to TSO???  Sorry... a bit foggy.

On 5/11/09, Scott T. Harder  wrote:
> Very cool.  Funny, though... I remember first logging onto TSO on what
> I thought was a 3082 (although I didn't know what even DASD was at the
> time).  Then, when I finally got my hands on a mainframe in MCO, it
> was a 3084.  This slideshow shows a 3083, which I don't have any
> recollection of.  Looks like a 3084, from what I can remember, though.
>
> All the best,
> Scott
>
> On 5/11/09, Howard Brazee  wrote:
>> A nice slide show on the history of IBM mainframes:
>>
>> http://www.eweek.com/c/a/IT-Infrastructure/The-IBM-Mainframe-50-Years-of
>> -Big-Iron-Innovation-583073/?kc=EWKNLEDP05112009A
>>
>> http://www.eweek.com/c/a/IT-Infrastructure/50-Years-of-IBM-Mainframe-Mil
>> estones-136541/?kc=EWKNLEDP05112009C
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Why the mainframe will never die
>>
>> http://www.eweek.com/c/a/IT-Infrastructure/IBM-Why-the-Mainframe-Will-Ne
>> ver-Die-Part-I-164505/?kc=EWKNLEDP05112009B
>>
>>
>>
>>
>>
>>
>>
>> http://www.eweek.com/c/a/IT-Infrastructure/CA-Sees-Strong-Future-for-Mai
>> nframes-234697/?kc=EWKNLEDP05112009D
>>
>>
>>
>>
>>
>>
>>
>>
>> ----------
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>>
>
>
> --
> All the best,
> Scott T. Harder
>


-- 
All the best,
Scott T. Harder

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


Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

2009-05-12 Thread Scott T. Harder
Joes (and Radoslaw),

You both have moved me more towards the center, certainly, of this
issue.  Excellent points.  I just was brought up in a centralized
environment, where CONTROL and MANAGED storage were the words of the
day.  How do you coordinate recovery well when there are multiple
groups, both in and outside the data center, responsible for
recovering everything?  Obviously, it can be done, but much harder
IMO.

Products such as ABARS (ok... I know) and other 3rd party DR backup
products can group application data set backups together - on a point
in time - and allow for proper recovery.  That, of course, takes money
though and I can see where your model would make sense and work.

All the best,
Scott T. Harder

On 5/12/09, Joel C Ewing  wrote:
> Obviously some shops must be radically different.  In a full SMS shop,
> applications programmers of course have no business doing volume-level
> or volume-specific operations, and to prevent override of RACF access
> restrictions ADRDSSU ADMIN authority must be tightly restricted to those
> authorized to perform DASDAdmin functions; but for us to deny
> applications access to DFDSS for dataset level backup/restore functions
> on their own application datasets would be counterproductive.
>
> We find that SMS configuration and conventions can reasonably be used to
> handle a few backups, but are completely inadequate for many others
> where the only kinds of backups that make sense are driven by
> application-level events, with sets of related datasets that must be
> handled as a consistent group, and/or with archival retention
> requirements that don't fit within the rather simplistic SMS management
> capabilities.
>
> As a SysProg it is part of my responsibility to see that we can recover
> the data center as a whole to a point-in-time in the event of a data
> center failure.  But, I do not have the time, the inclination, or the
> responsibility to determine what additional backups many different
> individual application areas may need in order to recover from
> mini-disasters caused by application program failures, to reprocess old
> data because of changed end-user requirements, or to meet data archival
> requirements imposed by management or law specific to that application area.
>
> Given that there are of necessity backups that must be designed by and
> maintained by non-SysProg, applications people who are the ones in the
> best position to understand their archival requirements, to deny them
> ADRDSSU, effectively limiting them to sequential file backups and
> awkward and inefficient file stacking on tape backups, makes little sense.
>JC Ewing
>
> Obviously
> Scott T. Harder wrote:
>> I can see where IF you have ALL the appropriate security profiles set up
>> properly, then I suppose I see your point.  For me, though, I would rather
>> cut off access completely.  I would ask "Why do they need it?"  If your
>> SMS
>> constructs and ACS routines, and your backups, are all set up properly,
>> why
>> do they need to be moving data around or backing it up with DSS???
>>
>> I think my mom *did* say that once or twice, btw.  ;-)
>>
>> All the best,
>> Scott T. Harder
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
>> Of R.S.
>> Sent: Wednesday, May 06, 2009 4:28 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]
>>
>> Scott T. Harder pisze:
>>> Sorry, guys.  In my world, Application Programmers have no business
>>> having
>>> access to Storage Management utilities like DSS.  Period.  That needs to
>>> remain a centralized function.
>>
>> Why?
>> Because mama said that?
>> Poor justification.
>>
>> In my shop appliccation prgrammers have access to any tool they want,
>> UNLESS it is dangerous, i.e. bypasses regular security checking.
>> That's why DSS is available to everyone, but STGADMIN.ADR.STGADMIN.** is
>> not.
>>
>> --
>> Radoslaw Skorupka
>> Lodz, Poland
> ...
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>


-- 
All the best,
Scott T. Harder

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


Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

2009-05-12 Thread Scott T. Harder
I did not see this hit the list, so if it did, I apologize for the dup...

Joel (and Radislaw)  sp?

You have both moved me far more towards the center of this issue.
Excellent points, both.  It's just that I was "brought up" in a
CENTRALIZED/MANAGED environment and that is hard to shake.  How do you
coordinate recovery from multiple groups, both in and outside the data
center.  Obviously, it can be done, but much harder IMO.

There are products such as ABARS (ok... I know) and other 3rd party
products that wrap up application backups on a point in time; then
allow for recovery TO that point in time.  Of course, that costs
money, so I can see where you model, Joel, works and makes sense.

All the best,
Scott T. Harder

On 5/12/09, O'Brien, David W. (NIH/CIT) [C]  wrote:
> For that you need an add-on product like Mainstar's ABARs Manager. At least
> that's what it was called a few years ago.
>
> Dave O'Brien
> NIH Contractor
> 
> From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Joel
> C Ewing [jcew...@acm.org]
> Sent: Tuesday, May 12, 2009 5:22 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]
>
> O'Brien, David W. [C] , NIH/CIT wrote:
>> Why not use HSM ABAR Backups which include migrated datasets?
>
> Try figuring out how to recall a single dataset from an ABARS backup and
> it becomes clear ABARS is really designed with recovery in mind, not
> with providing easy access to archives of specific datasets.
>JC Ewing
>>
>> Dave O'Brien
>> NIH Contractor
>> 
>> From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of
>> Mark Jacobs [mark.jac...@custserv.com]
>> Sent: Tuesday, May 12, 2009 11:37 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]
>>
>> R.S. wrote:
>>> Roach, Dennis (N-GHG) pisze:
>>>> As a sysprog, I agree.
>>>> For the applprog, verify what happens when a data set is on ML1 or ML2
>>>> and a masked include is used. DSS used to skip these and still have a
>>>> zero return code. This caused the application source to be left off of
>>>> their DR tapes.
>>> This is well-know and documented behavior. We shouldn't assume, that
>>> applprog is less intelligent than sysprog.
>>> And this "gotcha" is no justification to for denying ADRDSSU at all.
>>> Applprogs (everyone) can make mistake without ADRDSSU as well.
>>> Applprogs are probably  allowed to use many tools which they don't
>>> know well.
>>>
>>
>> Jobstep 1 - HRECALL with wait option
>> Jobstep 2 - DFDSS processing.
>>
>> It's not rocket science.
>
> A simpler and more fool-proof method:
> Instead of a separate step, hang an unreferenced DD statement on the
> actual DFDSS step for all datasets that "must" be dumped and which have
> any possibility of being migrated.  Step allocation will cause all
> DD-referenced datasets to be recalled before step execution proceeds,
> and there is no possibility of migration occurring before the dump
> (which could happen if a separate recall step occurs just before DFHSM
> interval migration, since the dataset is not opened to reset the
> last-referenced date).  If a dataset is migrated because it has not been
> referenced as recently as the others in the backup step, it might also
> make sense to question if it is appropriate for that dataset to be in
> the same backup collection.
>JC Ewing
>>
>> --
>> Mark Jacobs
>> Time Customer Service
>> Tampa, FL
>> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>


-- 
All the best,
Scott T. Harder

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


Re: USERCAT Error (Out of Space)

2009-05-16 Thread Scott T. Harder
Also, because I like the product...   CIM (Catalog Information
Manager), from ASPG, Inc. (last I knew) is also a very good catalog
mgmt tool.  Very extensive ISPF interface; tons of online help, etc.
The developers are also *very* willing to provide desired
features/functions, as requested.

All the best,
Scott T. Harder

On 5/15/09, O'Brien, David W. (NIH/CIT) [C]  wrote:
> Catalog Recovery Plus from Mainstar.com will allow you to increase the size
> of your catalog, re-organize it with optimum CI sizes and move it if
> necessary to another volume, non-disruptively.
> In theory this can be done with multiple LPARs accessing the catalog. In
> practice I've done this type of catalog work during quiet times on Sunday.
>
> I suspect there are other products, CRP is just the one with which I'm most
> familiar.
>
> Dave O'Brien
> NIH Contractor
> 
> From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of
> George Rodriguez [rodrigu...@palmbeach.k12.fl.us]
> Sent: Friday, May 15, 2009 9:23 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: USERCAT Error (Out of Space)
>
> I've got this out of space problem in one of our user catalogs. Since
> this particular catalog is used by a bunch of STC, I was thinking of
> expanding the catalog this Sunday in a window. Here's my question...Is
> it possible to REORG the catalog to reclaim "dead space"? I've deleted
> about 600 entries but that only bought me about 4 hours until it got
> full again.
>
>
>
> George Rodriguez
>
> Specialist, Systems Programmer
>
> Network & Technical Services
>
> (561) 357-7652 (office)
>
> (561) 707-3496 (mobil)
>
> School District of Palm Beach County
>
> 3348 Forest Hill Blvd.
>
> Room B-332
>
> West Palm Beach, FL. 33406-5869
>
> Rated "A" by the Florida Department of Education 2005, 2006, 2007 & 2008
>
>
>
> - Under Florida law, e-mail
> addresses are public records. If you do not want your e-mail
> address released in response to a public records request, do not
> send electronic mail to this entity. Instead, contact this office
> by phone or in writing.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> ----------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>


-- 
All the best,
Scott T. Harder

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


Re: TSO/E Exits

2009-05-16 Thread Scott T. Harder
Jeepers creepers...  I think most of the responses to Bin are a bit
excessive, here.  He merely posed a valid inquiry.  The best part of
this list is when someone questions "why?", eliciting the best from
the best minds.  I would suggest we slow this "flame train" down a
bit.

All the best,
Scott T. Harder

On 5/14/09, Ted MacNEIL  wrote:
>>Silly me. I can't think of a reason why IBM would survey this except to
>> remove
> them (except for IKJEFLD which is no longer needed IMHO).
>
> (Sorry, hit the send key too fast).
>
> He said:
>>>(No worries, we don't plan to get rid of any!)
>
> So, are you calling him a liar?
>
> You are wayy off base, here!
> -
> Too busy driving to stop for gas!
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>


-- 
All the best,
Scott T. Harder

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


Re: z/Journal Does it Again

2009-05-16 Thread Scott T. Harder
I rather think that "they" (client/server model... "we're getting rid
of the mainframe") tried that in the 90's.

On 5/14/09, Phil Smith III  wrote:
> Eric Bielefeld wrote:
>>I just received another z/Journal email sponsored by Microsoft urging us to
>> get off the mainframe and going to .NET.  They refer you to the following
>> web site:
>
>> http://www.microsoft.com/windowsserver/mainframe/whoknew/default.aspx
>
>>I would think that would be counter productive.  I'm sure that Microsoft
>> pays z/Journal big bucks to advertise, but if every mainframe user
>> followed MS advertising, there wouldn't be a need for the z/Journal.
>
>
> Here's an excerpt from Bob Thomas's publisher's letter in the May/June issue
> of Mainframe Executive, which is directly relevant:
>
> "This May/June 2009 issue of Mainframe Executive marks our eighth issue
> published. Although the target audience for both Mainframe Executive and
> z/Journal is users of IBM mainframe computer systems, I think it's important
> to remind readers that both magazines are totally independent publications.
> [He means not owned by IBM, not "independent of each other"]
>
> "As our readers have no doubt already noticed, the vast majority of
> articles, white papers, and ads in both magazines are clearly pro-mainframe.
> And while we are upfront about our mainframe bias, we do recognize that the
> mainframe isn't the optimum solution in all situations. So, we also will
> feature articles, white papers, and ads dealing with mainframe alternatives
> as a service to our readers. Because the readers we serve mostly reside
> within large public and private organizations of all types, we feel it's our
> duty to objectively deliver information for all types of mainframe-centric
> computing considerations that occur within an enterprise and aid in
> achieving business objectives."
> -30-
>
> And of course he's right -- mainframe fan that I am, I'm not going to argue
> that it's *always* the right answer. Pretty well every shop has
> Microsoft/Intel stuff, so it's a reasonable assumption that companies are
> already aware that there are alternatives. It's also a reasonable assumption
> that they're smart enough to evaluate what's actually best for their
> business, despite our (and I include myself!) bleating about "management by
> magazine".
>
> On the other hand, blind, fan-boy mainframe idolatry is just childish:
> ignoring the competition and hoping it will go away doesn't work. We tried
> that in the 90s, remember?
> --
> ...phsiii
>
> Phil Smith III
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>


-- 
All the best,
Scott T. Harder

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


Re: DSLIST VSAM support for Info line command

2009-05-19 Thread Scott T. Harder
I want to say that it was a late version of OS/390.  v2.9??  v2.10??
But, I don't know for sure.

All the best,
Scott T. Harder

On 5/18/09, David Speake  wrote:
> Does anyone know when the I - Info line command on DSLIST started supporting
> VSAM. I have been using ISPF Workplace for nine years (as well as Option
> 3.4) and had never tried the Info line command in the DSLIST. I had always
> gone back to the primary Workplace panel and used Q OR 3.2 and used V which
> both give me
> 'VSAM Utilities' with 'List Catalog Information' as option 3 instead of
> directly into the latter panel.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>


-- 
All the best,
Scott T. Harder

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


Re: ups batteries draining, can't switch to generators

2009-05-23 Thread Scott T. Harder
Hi All,

I have a couple of points to make on this topic:

1)  For all the well documented (and well taken) information about the
importance of shutting down a system orderly and cleanly, I find it
hard to remember when - in my experience - the system ever had
problems coming back up after a hard crash (I worked in OPS for 10+
yrs.).  Maybe back in the 308x days, but 3090+ ??  The hardware was
pretty resilient, as I remember.  I'm not saying that I recommend
anything other than a clean shutdown, but

2)  Kelly's post harken's me back to an old pet peev and that is;
Operations *used* to have good, knowledgable people who could make
decisions without calling 5 people to tell them what to do!  I saw,
firsthand, the dumbing down of OPS and it disturbed me greatly.  I had
mgmt come into Operations where I worked that *never* wanted to be at
fault... that was truly their #1 priority.  They achieved this through
never making a darn decision on their own... never sticking their neck
out no matter what the situation.  I remember one time where I
restarted the master catalog to resolve a problem; as called for by
the manual (ok... I think I could have gotten away with a lesser
evil), but my point is that my mgmt thought I was nuts (and just
lucky).  Maybe so, but as long as we put zombies who won't take action
based on knowledge and experience (and who are - most importantly -
empowered to do so), then more money must be spent on hardware,
systems and automation that will take the place of that.

Just my thoughts...

All the best,
Scott T. Harder

> Kelly Bert Manning wrote:
>> Please don't laugh.
>>
>> I work with applications on a non-sysplex and non-xrf, supported, z/OS
>> where there have been 3 cases of UPS batteries draining flat,
>> followed by uncontrolled server crashes, in the past 17 years.
>>
>> They all happened in October and November, gale season (Cue background
>> music with the "Gales of November" line by Gordon Lightfoot)
>>
>> After the first one the data center operator said that they would consider
>> giving operators authority to shut down OS/390 if they were unable to
>> make immediate contact with the "Duty Manager" after discovering that
>> UPS batteries were draining during a power failure and that generator
>> power was not available or failed after starting.
>>
>> Four weeks later a carbon copy crash occurred, inspriring a promise that
>> operators would start draining CICS and IMS message queues and stopping
>> and rolling back BMPs and DB2 online jobs, while there was still power
>> in batteries.
>>
>> Roll forward to this decade, power off during gale season, generators
>> start, but one fails and goes offline, followed by other mayhem in the
>> power hardware. Back on batteries for 22 minutes, until they drain and
>> the z server crashes. Current operator says "what promise to shut
>> everything down cleanly before the batteries drain?".
>>
>> Is 22 minutes an unreasonable time figure for purging IMS messaqe
>> queues, bringing down CICS regions, draining initiators, and abending
>> and rolling back online IMS and DB2 jobs to the last checkpoint, swapping
>> logs, writing and dismounting log backups and turning off power before
>> sudden power loss starts to play mayhem with disk and other hardware?
>>
>> Oh did I mention, the 2 CPU single processor was only about 30% busy at
>> the
>> time, the Sunday weekly low CPU use period.
>>
>> We had a different sort of power outage after the first of the 2 crashes
>> last decade. Somebody working for one of the potential bidders used
>> a metal tape measure in an attempt to measure clearance around the
>> power cable entrance to the building. The resulting demonstration of
>> how much power moves through the space around a high voltage cable
>> destroyed several 3380 clone drives, in addition to crashing all
>> the OS/390 processors. I earned my DBA pay that day.
>>
>> Bottom line, what should happen when UPS batteries start to drain and
>> there is no prospect of reliable, high quality, utility power being
>> restored quickly? Leave it up and roll the dice about losing work
>> in progress and log data (head crashes and cache controller microcode
>> bugs) or shut it down cleanly?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>


-- 
All the best,
Scott T. Harder

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


Re: ups batteries draining, can't switch to generators

2009-05-23 Thread Scott T. Harder
Sorry should have said "restarted the CATALOG address space".

On 5/23/09, Scott T. Harder  wrote:
> Hi All,
>
> I have a couple of points to make on this topic:
>
> 1)  For all the well documented (and well taken) information about the
> importance of shutting down a system orderly and cleanly, I find it
> hard to remember when - in my experience - the system ever had
> problems coming back up after a hard crash (I worked in OPS for 10+
> yrs.).  Maybe back in the 308x days, but 3090+ ??  The hardware was
> pretty resilient, as I remember.  I'm not saying that I recommend
> anything other than a clean shutdown, but
>
> 2)  Kelly's post harken's me back to an old pet peev and that is;
> Operations *used* to have good, knowledgable people who could make
> decisions without calling 5 people to tell them what to do!  I saw,
> firsthand, the dumbing down of OPS and it disturbed me greatly.  I had
> mgmt come into Operations where I worked that *never* wanted to be at
> fault... that was truly their #1 priority.  They achieved this through
> never making a darn decision on their own... never sticking their neck
> out no matter what the situation.  I remember one time where I
> restarted the master catalog to resolve a problem; as called for by
> the manual (ok... I think I could have gotten away with a lesser
> evil), but my point is that my mgmt thought I was nuts (and just
> lucky).  Maybe so, but as long as we put zombies who won't take action
> based on knowledge and experience (and who are - most importantly -
> empowered to do so), then more money must be spent on hardware,
> systems and automation that will take the place of that.
>
> Just my thoughts...
>
> All the best,
> Scott T. Harder
>
>> Kelly Bert Manning wrote:
>>> Please don't laugh.
>>>
>>> I work with applications on a non-sysplex and non-xrf, supported, z/OS
>>> where there have been 3 cases of UPS batteries draining flat,
>>> followed by uncontrolled server crashes, in the past 17 years.
>>>
>>> They all happened in October and November, gale season (Cue background
>>> music with the "Gales of November" line by Gordon Lightfoot)
>>>
>>> After the first one the data center operator said that they would
>>> consider
>>> giving operators authority to shut down OS/390 if they were unable to
>>> make immediate contact with the "Duty Manager" after discovering that
>>> UPS batteries were draining during a power failure and that generator
>>> power was not available or failed after starting.
>>>
>>> Four weeks later a carbon copy crash occurred, inspriring a promise that
>>> operators would start draining CICS and IMS message queues and stopping
>>> and rolling back BMPs and DB2 online jobs, while there was still power
>>> in batteries.
>>>
>>> Roll forward to this decade, power off during gale season, generators
>>> start, but one fails and goes offline, followed by other mayhem in the
>>> power hardware. Back on batteries for 22 minutes, until they drain and
>>> the z server crashes. Current operator says "what promise to shut
>>> everything down cleanly before the batteries drain?".
>>>
>>> Is 22 minutes an unreasonable time figure for purging IMS messaqe
>>> queues, bringing down CICS regions, draining initiators, and abending
>>> and rolling back online IMS and DB2 jobs to the last checkpoint,
>>> swapping
>>> logs, writing and dismounting log backups and turning off power before
>>> sudden power loss starts to play mayhem with disk and other hardware?
>>>
>>> Oh did I mention, the 2 CPU single processor was only about 30% busy at
>>> the
>>> time, the Sunday weekly low CPU use period.
>>>
>>> We had a different sort of power outage after the first of the 2 crashes
>>> last decade. Somebody working for one of the potential bidders used
>>> a metal tape measure in an attempt to measure clearance around the
>>> power cable entrance to the building. The resulting demonstration of
>>> how much power moves through the space around a high voltage cable
>>> destroyed several 3380 clone drives, in addition to crashing all
>>> the OS/390 processors. I earned my DBA pay that day.
>>>
>>> Bottom line, what should happen when UPS batteries start to drain and
>>> there is no prospect of reliable, high quality, utility power being
>>> restored quickly? Leave it up and roll the dice about losing work
>>> in progress and log data (head cra

Re: ups batteries draining, can't switch to generators

2009-05-23 Thread Scott T. Harder
On 5/23/09, Ted MacNEIL  wrote:
> When I started in this business, working as an operator was almost a
> requirement before becoming a SYSPROG.

Absolutely.

>
> BTDT. GTTS.

;-)

>
> But, my management (at the time) still gave them the call of if/which
> changes would be implemented.
> And, which changes to back out.

Yup.  Warrented, I think, though.

> And, when I complained, they just said I didn't understand, having never
> been in the trenches.

Wrong.

> I said, I have the scars to prove it.
> Remember when you could do a $PQ and blow everything away (before $PQ,ALL
> was introduced and $PQ was an error).
> I did that, once.

What about just a $P?  One day, everything came to a screaching halt
and nobody could figure it out.  Turned out, a Print Room Op had
indadvertently entered $P and the whole system drained.  ;-)

>
>
>>They achieved this through never making a darn decision on their own...
>> never sticking their neck out no matter what the situation.
>
> I've worked for many financial and government organisations.
> That is the prevalent attitude in many departments, not just Computer Ops.
> The problem becomes, eventually a decision will be made, due to the erosion
> of the situation, and you can only postpone for so long.

Too much time wasted.  People on the front lines need to be empowered
to make decisions and they need to be well-paid, knowledgable
professionals.

>
> By the way, I think you have the wrong third letter in 'darn'.

You bet!  ;-)

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


-- 
All the best,
Scott T. Harder

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


Re: Book on Poughkeepsie

2009-05-26 Thread Scott T. Harder
Punch cards were pre-me, but I do remember when someone told me why we
code JCL in 80 column data sets (or members).  It's just an online
punch card, of sorts, right?  I remember thinking that was so cool, so
I hope it is true.  ;-)

Never heard of 96-column cards, though.  Just some ignorance on my
part with that one.

-- 
All the best,
Scott T. Harder


On 5/26/09, jack.hamil...@kp.org  wrote:
> I remember 80-column punch cards.  I don't remember the model of the
> keypunch machine, but I do remember that it was large, heavy, and
> unforgiving.
>
>
>
> --
> Jack Hamilton
> Management Information & Analysis - Analytic Information Services
> Kaiser Foundation Health Plan, Inc.
> 1950 Franklin Street, Oakland, California 94612
> +1 510 987-1556 (KP tieline 8-427-1556)
>
> NOTE:  This email document and attachments are covered by CA Evidence Code
> §1157 and CA Health and Safety Code §1370.
>
> NOTICE TO RECIPIENT:  If you are not the intended recipient of this
> e-mail, you are prohibited from sharing, copying, or otherwise using or
> disclosing its contents.  If you have received this e-mail in error,
> please notify the sender immediately by reply e-mail and permanently
> delete this e-mail and any attachments without reading, forwarding or
> saving them.  Thank you.
>
>
>
>
> Rick Fochtman 
> Sent by: IBM Mainframe Discussion List 
> 05/26/2009 09:18 AM
> Please respond to
> IBM Mainframe Discussion List 
>
>
> To
> IBM-MAIN@bama.ua.edu
> cc
>
> Subject
> Re: [IBM-MAIN] Book on Poughkeepsie
>
>
>
>
>
> --
> A while back I posted something on punched cards here and got a private
> email "what does punched cards have to do the the mainframe?" so I'm
> half expecting a "what does Poughkeepsie NY have to do with the
> mainframe?".
> --
> Consider, if you will, the sweet innocence of childhood. ;-) How many of
> us remember the days of punched cards, either 80-column or 96-column? Or
> the 1442 "Multifunction Card Machine", also known as "Mother Fletcher's
> Card Mulcher"? Or the venerable 2540? or the 2501 Optical Card Reader?
> Or the 3505/3525?
>
> --
> Rick
> --
> Remember that if you?re not the lead dog, the view never changes.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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


Re: Book on Poughkeepsie

2009-05-26 Thread Scott T. Harder
VBG.  Too funny.  I've heard many stories about card decks being
dropped every which-way, but what did you have to do when that
happened?  Were they numbered or denoted in some way where you could
put the deck back together?  Must have been, but what a job; like
trying to find a mis-filed tape.  ;-)   And, I would think that
everything else came to a halt while the deck was re-ordered.

-- 
All the best,
Scott T. Harder


On 5/27/09, Patrick O'Keefe  wrote:
> On Tue, 26 May 2009 23:37:49 -0400, Scott T. Harder
>  wrote:
>
>>...
>>Never heard of 96-column cards, though.  Just some ignorance on my
>>part with that one.
>>...
>
> The "96-column" card was really 3 tiers of 32 columns.  6 bits per logical
> column.It was small (3-1/4 inch wide by 2-5/8 inch high) with small
> round holes.)   It was used on the S/3.  I'm not sure it was used by
> anything else.
>
> The small card size had both advantages and disadvantages.   Large
> decks were light so people tended to pick up decks that were too large.
> If you tried picking up a deck that was much longer that the card's width
> you were left holding the first and last card with the rest of the deck
> sprayed across the room.
>
> Pat O'Keefe

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


Re: Book on Poughkeepsie

2009-05-27 Thread Scott T. Harder
Now, see???...  THAT is a great piece of information!  I *hate*
those damn numbers always having to do NUM OFF and many times
having (or just wanting) to clear the numbers off the end (just
because it seems cleaner to me (i'm a bit anal that way).  But,
now I know the origin and that changes everything.

Thanks, Dave!

-- 
All the best,
Scott T. Harder

On 5/27/09, Gibney, Dave  wrote:
> And now you know the origin of sequence numbers in columns 73-80.
> Card reader/sorter/punch/printer machines predate these fancy new
> computers :)
>I never saw them (I started at a remote reader/printer  attached to a
> 370), but I'm told we did have the machines that you rewired a circuit
> board to change the program.
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>> Behalf Of Scott T. Harder
>> Sent: Tuesday, May 26, 2009 9:27 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: Book on Poughkeepsie
>>
>> VBG.  Too funny.  I've heard many stories about card decks being
>> dropped every which-way, but what did you have to do when that
>> happened?  Were they numbered or denoted in some way where you could
>> put the deck back together?  Must have been, but what a job; like
>> trying to find a mis-filed tape.  ;-)   And, I would think that
>> everything else came to a halt while the deck was re-ordered.
>>
>> --
>> All the best,
>> Scott T. Harder
>>
>>
>> On 5/27/09, Patrick O'Keefe  wrote:
>> > On Tue, 26 May 2009 23:37:49 -0400, Scott T. Harder
>> >  wrote:
>> >
>> >>...
>> >>Never heard of 96-column cards, though.  Just some ignorance on my
>> >>part with that one.
>> >>...
>> >
>> > The "96-column" card was really 3 tiers of 32 columns.  6 bits per
>> logical
>> > column.It was small (3-1/4 inch wide by 2-5/8 inch high) with
> small
>> > round holes.)   It was used on the S/3.  I'm not sure it was used by
>> > anything else.
>> >
>> > The small card size had both advantages and disadvantages.   Large
>> > decks were light so people tended to pick up decks that were too
> large.
>> > If you tried picking up a deck that was much longer that the card's
>> width
>> > you were left holding the first and last card with the rest of the
> deck
>> > sprayed across the room.
>> >
>> > Pat O'Keefe
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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


Re: Book on Poughkeepsie

2009-05-27 Thread Scott T. Harder
It's interesting to me that I am seeing a couple of references to the
80's (albeit early 80's) in some of these posts related to punched
cards.   I started in 1984 at AT&T in Orlando (in I/O Distribution)
and saw nary a punched card.  I guess it depends on where you were.

-- 
All the best,
Scott T. Harder


On 5/27/09, Ted MacNEIL  wrote:
>>As for sorting dropped cards: in the mid-80s, I worked at UofWaterloo.
>>We had one full professor who refused to get off of cards.
>
> I think I know who that was.
>
> On a related note, at one Insurance Company I worked at, we had one of the
> most prestigious pension plans in North America.
> It was maintained by a file clerk, who would type updates on a keypunch, and
> submit that and the master file as two card decks.
> Every week, she (and it was a she in 1981)



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


Re: Book on Poughkeepsie

2009-05-27 Thread Scott T. Harder
Yeah... understood.  So much changed so fast; and continues to do so.

On 5/27/09, Ted MacNEIL  wrote:
>>It's interesting to me that I am seeing a couple of references to the 80's
>> (albeit early 80's) in some of these posts related to punched cards.
>>I started in 1984 at AT&T in Orlando (in I/O Distribution) and saw nary a
>> punched card.
>>I guess it depends on where you were.
>
> Three years can make a big difference in IT (remember Moore's Law).
>
> In 1981, we were still using punched cards (albeit one app).
> In 1984, we weren't using any.
> I helped cart the old equipment out the door in 1983.
>
> In 1981, we had a 5 MIPS machine (AMD 470/V8).
> In i984, we had a 10+MIPS machine (IBM 3081D).
>
> In 1981, we had 30GB of 3330 DASD.
> In 1984, we had 75GB of 3350 DASD.
> In both cases, we thought we were a huge shop.
>
> The first DASD acquisition I was responsible for, in 1984, it was for 300GB.
> The last one was for 14TB. (And, in a previous incarnation [one job before],
> 32TB).
>
> I am interviewing for a job where I will be resonsible for managing 4.5PB
> (PetaBytes), and expecting to grow to 10 within a year to 18 months.
>
> The point being, it changes rather quickly.
>
> -
> Too busy driving to stop for gas!
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>


-- 
All the best,
Scott T. Harder

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


Re: DFHSM question concerning Duplex copies

2009-05-29 Thread Scott T. Harder
Wow...sounds like Dual Copy, but for tape.

-- 
All the best,
Scott T. Harder


On 5/28/09, O'Brien, David W. (NIH/CIT) [C]  wrote:
> Thanks Allan, I finally found the section you were quoting and after reading
> concede your point.
> I've learned something so the day is not a total loss.
>
> Dave O'Brien
> NIH Contractor
> 
> From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of
> Staller, Allan [allan.stal...@kbm1.com]
> Sent: Thursday, May 28, 2009 4:38 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DFHSM question concerning Duplex copies
>
> I have not been actively duplexing in a while, but in my past life,
> assuming no other problems with the tape, if one or the other tapes of
> the primary/duplex pair hit end-of-volume, this would cause a new pair
> to start.
>
> From the z/OS 1.9 DFSMShsm Users Guide SC35-0421-07 Topic 3.4.2.1.1
>
> When the original tape reaches its percent-full capacity, DFSMShsm must
> flush all the data to both tapes before performing a FEOV.
>
> If natural EOV is reached on either tape, DFSMShsm marks the tapes as
> FULL and restarts processing of the current data set from its beginning
> on two new tapes.
>
> IOW, the shorter tape wins.
>
> HTH,
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of O'Brien, David W. (NIH/CIT) [C]
> Sent: Thursday, May 28, 2009 2:21 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DFHSM question concerning Duplex copies
>
> From the HSM Guide:
> The alternate tape must have the same tape geometry as the original. For
> example, if the original tape is a 3590-1 tape, the alternate must be
>
> also.
>
>
> The question is: Is the tape geometry of the 9840A and 9840D the same?
>
> Allan, is your Duplex parameter defined as follows:
> SETSYS DUPLEX(MIGRATION(Y ERRALT(MARKFULL)))
>
> That would explain your following comment:
> Whichever tape is
> shorter will cause the initial primary/duplex pair to be marked full and
> a new pair created.
>
> In my environment any problem with the duplex tape results in the
> function (Migrate, Backup or Recycle) continuing and an HSM internal
> Tapecopy task for each unduplex'd tape.
>
> Dave O'Brien
> NIH Contractor
> 
> From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of
> Staller, Allan [allan.stal...@kbm1.com]
> Sent: Thursday, May 28, 2009 3:03 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: DFHSM question concerning Duplex copies
>
> This is actually the standard way duplexing works. Data is written
> simultaneously to both the primary and duplex copy. Whichever tape is
> shorter will cause the initial primary/duplex pair to be marked full and
> a new pair created.
>
> Reading between the lines, it sounds like your management want's to use
> (e.g.) 1 primary (long) and 2 duplex (short) to make up a primary/duplex
> pair. This cannot be done. A 1 for 1 relationship between primary and
> duplex volumes is mandatory.
>
> IIRC, the primary/duplex pair must be the same device type as well. As
> stated above, the "shorter" tape controls.
>
> HTH,
>
> 
> Is there a way to fool HSM into using only part of a tape for ML2 and
> Backup so that a shorter tape could be used for duplexing?
>
> We currently use 9840A drives for both local and remote (Duplex) ML2 and
> Backup tapes.
> Management would like to transfer the local HSM workload to an SL8500
> with 9840D tape drives.
> Both the 9840As and 9840Ds are gen'd as emulated 3490s.
>
> We currently use the following Tapeutilization parameters:
>
> SETSYS -
>   TAPEUTILIZATION(UNITTYPE(L9840) PERCENTFULL(2200))   -
>   TAPESPANSIZE(1000)
> SETSYS -
>   TAPEUTILIZATION(UNITTYPE(R9840) PERCENTFULL(2200))   -
>   TAPESPANSIZE(1000)
>
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to 

Re: Book on Poughkeepsie

2009-05-29 Thread Scott T. Harder
Complely off topic, but I can't resist

The refrence to toll collection harkens me back to the NY State
Thruway (a sort of Poughkeepsie relationship there, so maybe not so
off topic).  I was born and raised in Saugerties, NY, which is just
north of Poughkeepsie; triangular to Kingston and Woodstock.  My whole
family hails from Woodstock (parents, grandparents, etc.).  I learned
how to play golf at the Woodstock CC; great memories.  Oh well...

I remember having to take a "punched card" when I got on the Thruway
and then handing it into the attendent at the exit where I got off.
Don't know if that is still the same deal, but ...
-- 
All the best,
Scott T. Harder


On 5/28/09, Anne & Lynn Wheeler  wrote:
> The following message is a courtesy copy of an article
> that has been posted to bit.listserv.ibm-main,alt.folklore.computers as
> well.
>
>
> TrailingEdgeTechnologies  writes:
>> Another use for the 1mm-hole form factor for cards would have been a
>> step between the original 80-column and 51-column cards used for
>> toll collection and the current mag stripe cards.
>
> for a little topic drift ... wiki mag-stripe page
> http://en.wikipedia.org/wiki/Magnetic_stripe
>
> "invented by IBM under a contract with the US government for a security
> system"
> http://en.wikipedia.org/wiki/Forrest_Parry
>
> magstripe standards then managed out of the IBM Los Gatos lab from 1966
> to 1975.
>
> IBM los gatos also 3624 (& 3514) ATM (cash) machine:
> http://en.wikipedia.org/wiki/IBM_3624
>
> ... transaction records printed by 3624 was on approx. 3in sq card
> similar to card stock.
>
> earlier post in thread mentioning 3614/3624
> http://www.garlic.com/~lynn/2009h.html#44 Book on Poughkeepsie
>
> --
> 40+yrs virtualization experience (since Jan68), online at home since Mar1970
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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


Re: SMP/E packaging of maintence / products (was: FMID descriptions)

2009-05-29 Thread Scott T. Harder
Wasn't IBM going to, at one point, wrap something around SMP/E so that
it essentially ran "under the covers" and the user had a *much*
simpler interface (so to speak)??

-- 
All the best,
Scott T. Harder


On 5/29/09, Paul Gilmartin  wrote:
> On Fri, 29 May 2009 16:00:47 -0700, Howard Rifkind wrote:
>>
>>I also find this a pain in the a__.  Is it still IBM's purpose to 'Make
>> this more difficult so we will understand it'  You took something that
>> worked real well and messed it up.
>>
> Err...  How did the earlier "something" work "real well" for
> Internet delivery?  PTFs, perhaps, but not FUNCTIONs with
> Relative Files.
>
>>How about two procedures, one for the z/OS-z/VM and one for HFS/OMVS/UNIX
>> fixes???
>>
> Yukk!  You would have the z/OS customer deal with two procedures,
> since z/OS sooner or later involves HFS/OMVS/UNIX fixes?  That's
> two PITAs.
>
> However, since everything going into SMP/E, even for the
> HFS/OMVS/UNIX fixes funnels through SMPPTFIN or RELFILEs,
> both of which are Classic data sets, a single procedure could
> work for both.
>
> Likewise, the current procedure works for both.  There's
> little cause to change it.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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


Re: ETR is down (hilarious resolution)

2010-05-03 Thread Scott T. Harder
Yup...  Have to admit:  It is not a very good system that puts the onus on
the customer to massage and alter the data in a problem record, such that it
meets the limited capabilities of the receiving system.

Reporting a problem shouldn't be a problem in and of itself.  In a perfect
world, it should be a no-brainer full of ease.  IBMLink is certainly not the
only weak link in the chain, here, as we all know very well.  Name a
company; it ain't an easy thing to do.  But, those with the resources of the
larger companies have far fewer excuses, AFAIC.

Just my $0.02,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Bob goolsby
> Sent: Thursday, April 29, 2010 10:33 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: ETR is down (hilarious resolution)
> 
> Tom --
> 
> Let me get this right -- They want you to sanitize your text so Their
> "system" will let you send then a Trouble Ticket?  Their "system"
> can't handle 'special characters'?
> 
> So, what do they do with someone whose Locale isn't ISO 8859-1?  Let
> us say 850 (LATIN-1 with Euro-symbol) or 863 (French Canadian)?  I
> really want to see them tell a Francophone Quebeker that they have to
> submit the ETR in English
> 
> 
> B
> 
> On Thu, Apr 29, 2010 at 7:13 AM, Pinnacle 
> wrote:
> > - Original Message - From: "Pinnacle"
> 
> > Newsgroups: bit.listserv.ibm-main
> > Sent: Thursday, April 29, 2010 9:50 AM
> > Subject: ETR is down
> >
> >
> >> FYI,
> >>
> >> Getting "internal error occurred" trying to submit an ETR.
> >>
> >> Regards,
> >> Tom Conley
> >>
> >
> > Called IBMLink support in Bangalore, and found out my problem.  Before I
> > even finished saying, "internal error has occurred, I was told to
> "remove
> > all special characters" from the ETR, "remove excess blank lines", and
> > "shorten long sentences".  I had copied in a panel, and the underscores
> at
> > the top of the panel below the menu were all changed to cent signs.  I
> > deleted all the cent signs, and viola!  My ETR submitted.
> >
> > I did mention to the Level 1 person that an error message telling me to
> > "remove all special characters" would have been more helpful than
> "internal
> > error has occurred".
> >
> > I love IBMLink.
> >
> > Regards,
> > Tom Conley
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> 
> 
> 
> --
> 
> Bob Goolsby
> bob.gool...@gmail.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


MVS to z/OS Experience Looking for Work

2010-05-03 Thread Scott T. Harder
I know this is most likely a no-no, but I am going to go for it:

I am seeking anything from Computer Operator to System Administrator to
program product support; with a preference of something in System
Automation, in a large IBM mainframe installation running z/OS.  I will
consider relocating *anywhere* in the good ol' USA.  I am currently in
Naples, FL and hate the idea of leaving, but will do it.  Of course,
telecommuting is an even better idea!  I would be more than willing to spend
time at a location for whatever period required, initially; prior to the
beginning of a telecommuting situation.

If anyone knows of any potential openings at companies where I could send my
resume, please let me know offline and I will be eternally grateful.

Thanks for your time,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

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

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


Re: Problem with AbendAid 11.2.2

2010-05-03 Thread Scott T. Harder
I think pretty much everyone on this list has a story to be told that would
reveal wounds which are still open to this day.  I know what mine is.

Let it go.  Let it go.  You're in good company.  ;-)

Scott T. Harder
Mainframe Services, Inc.
Naples, FL


 
> For myself, I caused an uneeded re-IPL because of an overlooked ICHRDSNT
> and other modules... it still hurts after many moons... ;-D
> 
> Groete / Greetings
> Elardus Engelbrecht

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


Re: Catalog re-location

2010-05-04 Thread Scott T. Harder
Wow.  I don't think I could bring myself to put all of my catalogs on the
same device - RAID DASD or no RAID DASD.  

I worked in Storage Management only for a year back in the mid-90's, so
PAV's are something I'm not familiar with.  Going by the name only (and some
very quick lookup via Google); are they some sort of constant/permanent Dual
Copy situation?  Automatic failover?

BTW... in searching for "PAV + IBM" on Google, I ran across this link that
you may already be familiar with, but I was not.  Very cool stuff that I
just thought I would share.  The "Vintage Views" links to the right of this
page I thought were fascinating.  Some marketing blurb about the IBM Stretch
computer bragged about the fact that it "only" took up 2000 sq. feet of
floor space.  I felt that, among all the other techno-babble, was probably
the most telling.

http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV2085.html

All the best,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Darth Keller
> Sent: Tuesday, May 04, 2010 8:46 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Catalog re-location
> 
> Single point of Failure  -   Other than John's saying he's moving to
> Hitachi Mod 9's, he really didn't describe his storage.  It would probably
> be safe to assume (& watch me get burned on this one) he's got RAID DASD -
> in which case he does have some protection.   In my case, in the last 10
> years I've had zero DASD failures, but I've 5+ catalog failures which I've
> had to recover from.   So if he's going to be worried about a failure, I'd
> say his time would probably be better spent looking at his catalog backup
> & recovery procedures  (insert plug here for DINO Software's TREX).
> 
> With that said, I'm with Bob in that I'm 'old school' enough that I'd
> spread my catalogs across at least a few volumes.  For one thing, I want
> plenty of room for catalogs to take 2ndary extents.  Not much worse that
> getting called at o-dark in the morning because some application failed
> because a catalog can't take a 2ndary.
> 
> John - are you running with PAV's?  Even though catalogs can be cached in
> memory in CAS and using ECS, eventually catalogs are going to need to be
> updated meaning writes to DASD - if you don't have PAV's and you've got
> all your catalogs on one volume, you've got limited access to your
> catalogs.  Something to consider - some of my catalogs are very busy
> during certain times of the day and one volume would be an issue for me
> without PAV's.
> 
> ddk
> 
> This e-mail message and all attachments transmitted with it may
> contain legally privileged and/or confidential information intended
> solely for the use of the addressee(s). If the reader of this
> message is not the intended recipient, you are hereby notified that
> any reading, dissemination, distribution, copying, forwarding or
> other use of this message or its attachments is strictly
> prohibited. If you have received this message in error, please
> notify the sender immediately and delete this message and all
> copies and backups thereof. Thank you.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: XMIT MANAGER

2010-05-08 Thread Scott T. Harder
Right... it was my question/OP about running XMIT Manager on Win7 (64 bit).
What I did (at the instruction of another kind list member) was to set up
Windows XP Mode in MS Virtual PC.  I installed the 32 bit version of XMIT
Manager there and it worked gr8.  The version of Windows that you are
running on the host determines whether you have MS Virtual PC available
without additional fees, I believe.

All the best,

Scott T. Harder
Mainframe Services, Inc.
Naples, FL

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Hal Merritt
> Sent: Thursday, May 06, 2010 9:58 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: XMIT MANAGER
> 
> Part of the discussion a short time ago on this topic included a
> suggestion to adjust the proprieties on Windows so that it will run the
> program in compatibility mode. There was no response if that worked or
> another solution was found.
> 
> HTH and good luck
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of David Cartwright
> Sent: Thursday, May 06, 2010 4:50 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: XMIT MANAGER
> 
> Slightly OT I'm afraid, but does anyone know if there is a 64 bit version
> of Xmit
> Manager?  I no longer have a 32 bit Windows available (talk about dead
> media!).
> The home website seems to have gone and it won't install from an old
> (months)
> download. I want to look inside file 172 to find the stuff I did on cache
> management which seems to be a hot topic at the moment.
> Any ideas?
> 
> TIA
> DC
> 
> 
> NOTICE: This electronic mail message and any files transmitted with it are
> intended
> exclusively for the individual or entity to which it is addressed. The
> message,
> together with any attachment, may contain confidential and/or privileged
> information.
> Any unauthorized review, use, printing, saving, copying, disclosure or
> distribution
> is strictly prohibited. If you have received this message in error, please
> immediately advise the sender by reply email and delete all copies.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Crypto-DASD?

2009-02-10 Thread Scott T. Harder
Just curious if anyone has heard anything about new DASD coming out any
time soon (or not so soon) that will have encryption built in, where
anything written to a volume on a unit supporting this would
automatically get encrypted; and decrypted when read, of course.

 

Thanks!

Scott

 

Scott T. Harder

Tech Support & Product Development

ASPG, Inc.

Ph:   239-649-1548 / Ext. 203

Fax:  239-649-6391

General Support Email:  aspgt...@aspg.com

 


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


Re: Crypto-DASD?

2009-02-10 Thread Scott T. Harder
Hi Eric,

I think the main reason would be to comply with govt. regulations that
say "thow must encrypteth data at rest that contains personal/private
information".  Credit card numbers, medical records... the usual stuff.


Now it won't help B2B exchange; only situations where a company is
required to encrypt data where it lives.  It will automatically be
encrypted and decrypted; I imagine via a symmetric key stored in the
hardware.  It could be good, also, for DR situations where data is
mirrored to DASD at the DR site.  Not sure why there, because nobody
seems worried about data mirrored to offsite disk, where they are very
worried about tape during transport.  But, again, if the requirement is
that the data at rest be encrypted, then that requirement - I would
think - would extend to DR sites, as well.

I asked the original question only because I had heard that crypto-DASD
was coming next (after the tape hardware encryption, which is obviously
already in the field).  I haven't been able to find any information on
the crypto-DASD topic, so I just thought I'd see what the list had
heard.  Just fishing.

Thanks!
Scott   

Scott T. Harder
Tech Support & Product Development
ASPG, Inc.
Ph:   239-649-1548 / Ext. 203
Fax:  239-649-6391
General Support Email:  aspgt...@aspg.com


-Original Message-
From: eric-ibmm...@wi.rr.com [mailto:eric-ibmm...@wi.rr.com] 
Sent: Tuesday, February 10, 2009 12:58 PM
To: IBM Mainframe Discussion List
Cc: Scott T. Harder
Subject: Re: Crypto-DASD?

I haven't heard anything about this new dasd, but I have a question.
Why would you want everything encrypted?  If you have a dasd box in your
datacenter, what is the reason to encrypt all your data?  I can see that
maybe for mirroring where the data gets sent long distances over
communication lines, but why would the average datacenter need this?

Eric

--
Eric Bielefeld
Systems Programmer
Washington University
St Louis, Missouri
314-935-3418

 "Scott T. Harder"  wrote: 
> Just curious if anyone has heard anything about new DASD coming out
any
> time soon (or not so soon) that will have encryption built in, where
> anything written to a volume on a unit supporting this would
> automatically get encrypted; and decrypted when read, of course.
> 
>  
> 
> Thanks!
> 
> Scott
> 
>  
> 
> Scott T. Harder
> 
> Tech Support & Product Development
> 
> ASPG, Inc.
> 
> Ph:   239-649-1548 / Ext. 203
> 
> Fax:  239-649-6391
> 
> General Support Email:  aspgt...@aspg.com
> 
>  
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: Crypto-DASD?

2009-02-10 Thread Scott T. Harder
"I asked the original question only because I had heard that crypto-DASD
was coming next (after the tape hardware encryption, which is obviously
already in the field).  I haven't been able to find any information on
the crypto-DASD topic, so I just thought I'd see what the list had
heard.  Just fishing."

Of course, if you are under any kind of NDA or CDA, I don't want to hear
from you.  ;-)

Thanks!
Scott   

Scott T. Harder
Tech Support & Product Development
ASPG, Inc.
Ph:   239-649-1548 / Ext. 203
Fax:  239-649-6391
General Support Email:  aspgt...@aspg.com


-Original Message-
From: eric-ibmm...@wi.rr.com [mailto:eric-ibmm...@wi.rr.com] 
Sent: Tuesday, February 10, 2009 12:58 PM
To: IBM Mainframe Discussion List
Cc: Scott T. Harder
Subject: Re: Crypto-DASD?

I haven't heard anything about this new dasd, but I have a question.
Why would you want everything encrypted?  If you have a dasd box in your
datacenter, what is the reason to encrypt all your data?  I can see that
maybe for mirroring where the data gets sent long distances over
communication lines, but why would the average datacenter need this?

Eric

--
Eric Bielefeld
Systems Programmer
Washington University
St Louis, Missouri
314-935-3418

 "Scott T. Harder"  wrote: 
> Just curious if anyone has heard anything about new DASD coming out
any
> time soon (or not so soon) that will have encryption built in, where
> anything written to a volume on a unit supporting this would
> automatically get encrypted; and decrypted when read, of course.
> 
>  
> 
> Thanks!
> 
> Scott
> 
>  
> 
> Scott T. Harder
> 
> Tech Support & Product Development
> 
> ASPG, Inc.
> 
> Ph:   239-649-1548 / Ext. 203
> 
> Fax:  239-649-6391
> 
> General Support Email:  aspgt...@aspg.com
> 
>  
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

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


Re: Crypto-DASD?

2009-02-10 Thread Scott T. Harder
I really didn't want this to turn into an argument over whether this is
necessary.  Sarbanes Oxley, PCI, and other government regulations say
it's necessary to comply, so anyone needing to comply with a whole host
of these regs has the need to encrypt data at rest.  Now... you don't
need DASD that has encryption built-in to do it, of course.  

In fact, you could purchase MegaCryption from ASPG, Inc. and use it very
nicely *and* get the additional benefits of being able to use it for B2B
exchange of encrypted data, as well as to easily encrypt DSS and/or
CA-DISK backups; all taking advantage of ICSF and/or CPACF hardware when
it makes sense to do so.  ;-)

Sorry... I couldn't resist.

Scott T. Harder
Tech Support & Product Development
ASPG, Inc.
Ph:   239-649-1548 / Ext. 203
Fax:  239-649-6391
General Support Email:  aspgt...@aspg.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Hal Merritt
Sent: Tuesday, February 10, 2009 2:05 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Crypto-DASD?

I been reading about such, but only in a PC context.

IMNSHO, DASD encryption does not add any real security value. Every
record of every file is in a unpublished, often proprietary  format. The
data is then compressed and written in yet another proprietary format
over several physical devices. Encrypted data would defeat most all
compression algorithms, increasing raw storage requirements
substantially. That's serious dollars to mitigate a near nonexistent
threat. 

Encryption is being pushed by auditors in response to sensitive data on
PC hard drives.


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Scott T. Harder
Sent: Tuesday, February 10, 2009 11:23 AM
To: IBM-MAIN@bama.ua.edu
Subject: Crypto-DASD?

Just curious if anyone has heard anything about new DASD coming out any
time soon (or not so soon) that will have encryption built in, where
anything written to a volume on a unit supporting this would
automatically get encrypted; and decrypted when read, of course.

 

Thanks!

Scott

 

Scott T. Harder

Tech Support & Product Development

ASPG, Inc.

Ph:   239-649-1548 / Ext. 203

Fax:  239-649-6391

General Support Email:  aspgt...@aspg.com

 


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

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

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


Re: Crypto-DASD?

2009-02-11 Thread Scott T. Harder
Now, that's what I'm talkin' about.  Thanks, Timothy, for the info.

FWIW... to me, data stored on disk is data at rest.  It may not be all
the time, but I think that the intent of that phrase, as used in the
regulations, is pretty clear.  Whether they were correct in using it can
be argued, for sure, but

Thanks to everyone.  

Scott T. Harder
Tech Support & Product Development
ASPG, Inc.
Ph:   239-649-1548 / Ext. 203
Fax:  239-649-6391
General Support Email:  aspgt...@aspg.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Timothy Sipples
Sent: Wednesday, February 11, 2009 8:29 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Crypto-DASD?

Yes, IBM announced full disk encryption for several DS8000 series
storage
models:

http://www.ibm.com/common/ssi/rep_ca/0/897/ENUS109-120/ENUS109-120.PDF

Lots of other interesting stuff in that announcement (and other
announcements on February 10th), including Solid State Disk (SSD)
support.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Based in Tokyo, Serving IBM Japan / Asia-Pacific
E-Mail: timothy.sipp...@us.ibm.com

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

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


Re: Crypto-DASD?

2009-02-12 Thread Scott T. Harder
Scott T. Harder
Tech Support & Product Development
ASPG, Inc.
Ph:   239-649-1548 / Ext. 203
Fax:  239-649-6391
General Support Email:  aspgt...@aspg.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Russell Witt
Sent: Wednesday, February 11, 2009 4:42 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Crypto-DASD?

Scott,

>Okay, if you think data stored on disk is "data at rest"; please define
>"disk". Does a SSD (Solid-State Drive) count as a disk drive? What
about a
>RAM drive (using either SRAM or DRAM)? If a RAM drive using SRAM or
DRAM is
>a disk; then what is the difference between a RAM drive and memory in a
>computer?

I think what the regs mean by "data at rest" is "where the data lives"
or "it's home location".  As you say, the term "disk" is quite
interchangeable these days. 
 
>And of course as Phil said, the decryption should not be done on an
>"automatic" basis; but rather based on rules. And who will control
those
>rules; the external-security system. So, if the external-security
system
>will control who can access the data via automatic decryption; how is
that
>different than having the external-security system control access to
the
>data in the first place.

Agreed.  But is access to encryption keys (whether stored in ICSF
hardware or otherwise) not controlled by the security system (CSFKEYS /
CSFSERV)??  I think you could make this argument about any data you
encrypt on the system.  If you have the key, you can get to the
cleartext and access to the key is controlled by RACF, CA-ACF2, CA-TSS,
etc.

>Just my opinion, but PCI really needs to do a better job of defining
what
>needs to be done.

This is the real rub of it all, isn't it?  Absolutely agreed.

Thanks!
Scott


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on
Behalf Of Scott T. Harder
Sent: Wednesday, February 11, 2009 11:46 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Crypto-DASD?


Now, that's what I'm talkin' about.  Thanks, Timothy, for the info.

FWIW... to me, data stored on disk is data at rest.  It may not be all
the time, but I think that the intent of that phrase, as used in the
regulations, is pretty clear.  Whether they were correct in using it can
be argued, for sure, but

Thanks to everyone.  

Scott T. Harder

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

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


Re: Crypto-DASD?

2009-02-12 Thread Scott T. Harder
Ron,

Can't disagree with a thing you said.  Not sure where I've argued to the
other side of any of this.  

Thanks!

Scott T. Harder
Tech Support & Product Development
ASPG, Inc.
Ph:   239-649-1548 / Ext. 203
Fax:  239-649-6391
General Support Email:  aspgt...@aspg.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ron Hawkins
Sent: Thursday, February 12, 2009 5:57 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Crypto-DASD?

Scott,

Has your Storage Vendor ever replaced a failed or failing drive? Do you
know where that drive is now?

I know of several customer that purchase and stored their failed drives
because they cannot be erased using commercial software once they stop
working. I also know of one customer that has an annual "bash and burn"
session. 

A normal DASD init does not securely overwrite data on the disk drive.
It is no longer easy to read, but neither is it completely masked.
Writing over a track on disk is like driving over someone else's tire
tracks - you never completely cover up the first set of tracks unless
you drive over them a few times. 

Secure Erasure is built into the latest HDS controllers, or you can use
software like the FDR/ERASE. However, that doesn't protect data on
replaced drives, hence the requests by customers for vendors to look at
encryption of data at rest.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Eric Bielefeld
> Sent: Tuesday, February 10, 2009 11:31 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Crypto-DASD?
> 
> Scott,
> 
> I still can't see why if you have a box in your datacenter, that will
never
> leave your datacenter until after its useful life is over, should be
> encrypted.  How are you going to access that data accept by the z/OS
operating
> system?  That's why we have security systems.  When the box is done,
and you
> sell it or scrap it, you can always initialize all the disks.
> 
> I asked my boss at P&H Mining if he wanted me to init all the disks,
or if he
> just wanted to let Hitachi do the initialize they do whenever a box is
sold,
> and he said just let Hitachi do it.  There was sensitive data in many
files,
> but I highly doubt if anyone could have recovered any of it after it
was
> initialized by Hitachi.  This was when P&H shut down z/OS for good.
> 
> I can see the value of encrypting data on PC hard drives, after all of
the
> problems people have had with stolen PCs with sensitive data on them,
but
> mainframe dasd?  I just can't see it, or any regulations requiring it.
> 
> Eric
> 
> --
> Eric Bielefeld
> Systems Programmer
> Washington University
> St Louis, Missouri
> 314-935-3418
> 
>  "Scott T. Harder"  wrote:

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

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


Re: OPS/MVS Rexx Question with SQL

2009-02-19 Thread Scott T. Harder
Hi Lizette,

I'm an old AutoMate/MVS guy but didn't really get to work with OPS too
much before moving on (miss it a lot, though).  I would try posting this
question on the ProTech automation list:

AUTOMATION (Hosted by ProTech) 
Discussion forum for Data Center Automation and Enterprise Systems
Management.  You can join this group by sending the message "join
automation" (in body of email) to list...@protechpts.com

HTH,
Scott

Scott T. Harder
Tech Support & Product Development
ASPG, Inc.
Ph:   239-649-1548 / Ext. 203
Fax:  239-649-6391
General Support Email:  aspgt...@aspg.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Lizette Koehler
Sent: Wednesday, February 18, 2009 1:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: OPS/MVS Rexx Question with SQL

I am trying to help a friend create some OPS/MVS Rule to read the STCTBL
and retrieve only those entries that begin with CICS on LPARx.

I know in SQL you can code
Select * from STCBL
Where name like 'CICS'

However I am not finding something similar in OPS/MVS Rexx.

Any body point me in the right direction?

Lizette

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

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


ListServ Help

2009-04-01 Thread Scott T. Harder
Hi List,

After 10 years with ASPG, Inc., I must report that I am no longer affiliated
with that company.  I have now subscribed to this list using my personal
email address (below) and will do so for the other lists I belong to
(RACF-L, ISPF-L, DB2-L, etc.).  I have a question, however, about my
subscriptions that are under my “old” work email address.  Specifically,
what is the easiest way for me to unsubscribe my ASPG work email
subscriptions?  I have referenced the ListServ RefCard and I don’t even see
“unsubscribe” anymore (at least in the copy of the RefCard that I have).  I
see SIGNOFF (syntax below), but have never used that before.  If someone
could, perhaps, throw me a bone on this subject, I sure would appreciate it.
I need to unsubscribe from all off the ListServ lists I belong to as my old
work email address and then I’ll subscribe using my personal email address
to all those same lists.

And… that is the good news for me.  I will be able to take an ACTIVE role in
this and other lists – usually having to hit the manuals to look things up
and I’ll usually be behind a response of 10 or more people who knew the
answer off the top of their heads – but I will be able to give the lists my
undivided attention and they will certainly help keep me sharp until I get
back in the game in terms of a real job.  ;-)

That’s the plan, anyway.  Thanks, folks!

Scott T. Harder




SIGNOFFRemove yourself:
 listname  - From the specified list
 * - From all lists on that
server
 * (NETWIDE- From all lists in the
network


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


Re: ListServ Help

2009-04-02 Thread Scott T. Harder
Hi Dave,

I guess that's one way to look at it, but I thought I'd be a good citizen
and not leave all that email being delivered every day.  I just let them
know that they will have to SIGNOFF by sending email from my old work
account to the LISTSERV email addresses.  Or, maybe only one address while
using the * (NETWIDE operand?  Either way, it is out of my hands.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Jousma, David
Sent: Wednesday, April 01, 2009 3:32 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ListServ Help

In reality, why do you care?  It is email going to prior employers email
servers.  Just subscribe under the new email address.  I had this
before, and the only way to fix was to have Darren fix it.  Not sure he
can anymore.

The only way that may work is to use the web interface and sign-on with
your old email address.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Eric Bielefeld
Sent: Wednesday, April 01, 2009 3:25 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ListServ Help

Using the very last line that is automatically appended to each post,
you
can unsubscribe from that web site.

Eric

Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434


- Original Message -----
From: "Scott T. Harder" 
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Wednesday, April 01, 2009 1:59 PM
Subject: ListServ Help


> Hi List,
>
> After 10 years with ASPG, Inc., I must report that I am no longer
> affiliated
> with that company.  I have now subscribed to this list using my
personal
> email address (below) and will do so for the other lists I belong to
> (RACF-L, ISPF-L, DB2-L, etc.).  I have a question, however, about my
> subscriptions that are under my "old" work email address.
Specifically,
> what is the easiest way for me to unsubscribe my ASPG work email
> subscriptions?  I have referenced the ListServ RefCard and I don't
even
> see
> "unsubscribe" anymore (at least in the copy of the RefCard that I
have).
> I
> see SIGNOFF (syntax below), but have never used that before.  If
someone
> could, perhaps, throw me a bone on this subject, I sure would
appreciate
> it.
> I need to unsubscribe from all off the ListServ lists I belong to as
my
> old
> work email address and then I'll subscribe using my personal email
address
> to all those same lists.
>
> And. that is the good news for me.  I will be able to take an ACTIVE
role
> in
> this and other lists - usually having to hit the manuals to look
things up
> and I'll usually be behind a response of 10 or more people who knew
the
> answer off the top of their heads - but I will be able to give the
lists
> my
> undivided attention and they will certainly help keep me sharp until I
get
> back in the game in terms of a real job.  ;-)
>
> That's the plan, anyway.  Thanks, folks!
>
> Scott T. Harder
>
>
>
>
> SIGNOFFRemove yourself:
> listname  - From the specified
list
> * - From all lists on that
> server
> * (NETWIDE- From all lists in the
> network

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

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

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

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


Re: Rexx

2009-04-03 Thread Scott T. Harder
Awesome!  I didn't even know this list existed.  Thanks very much, Lizette.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Lizette Koehler
Sent: Friday, April 03, 2009 9:54 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Rexx

If you know CLIST or BASIC language you are fairly well on your way with
REXX.  The only thing that every through me with the language was  the use
of STEM vars.  But I have that mostly under control.

Like any language you need to learn the syntax and what it can and cannot
do.  Start by writing code.  Use some of the example code that is out there
in various websites.  Then ask the TSO-REXX group for guidance.  We are very
friendly over there.

TSO REXX Discussion List at Marist College.
For TSO-REXX subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO TSO-REXX


Also check our various college websites with REXX coursed.  One I like is
http://www.malone.edu/erodd/rexxcls.htm

Also the REXX language Group
http://www.rexxla.org/index.html





What is the are you will be using REXX for?  Automation, tools ??

By knowing what you are needing to do will help us help you.

Most of the REXX books are either more like reference manuals or very
technical.  I have not really found a good "basic" book.

The IBM REXX REFERENCE guide and REXX USER'S GUIDE are a good starting place
if you already know programming and a language like CLIST.

Lizette

>
> I need to learn REXX and fast.  Does anyone know a good REXX "for dummies"
> book?
>

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

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


Re: Rexx

2009-04-03 Thread Scott T. Harder
I used to support a product that provided samples in both REXX and Clist.
MAJOR pain.  Once you go to REXX, you won't look back.  Much more powerful
in terms of numbers and it just seems so much more intuitive.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Gibney, Dave
Sent: Friday, April 03, 2009 10:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Rexx

  Assuming it's not your first, second, or third language, grab the
reference manual, find some examples in the Ssamplibs, remember STEMs
are only somewhat like arrays :), that blanks as part of variable values
count and the ' Quote is not the same a " double quote.

  Probably a few other idiosyncrasyies and you're set. Very powerful
language, oh and another thing, ACS routines and other rexx-like things
ARE NOT REXX.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of gsg
> Sent: Friday, April 03, 2009 6:02 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Rexx
>
> I need to learn REXX and fast.  Does anyone know a good REXX "for
dummies"
> book?
>
> TIA
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

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


Re: Rexx

2009-04-04 Thread Scott T. Harder
Hi Ed,

You are "the man", and I mean that sincerely (your questions and comments at
the TDM's are legendary as far as I'm concerned), but isn't the parsing in
REXX better than Clist?  I have no knowledge of IKJPARS and you can bet I'll
be looking it up; I always found the PROC statement problematic, and that is
the only way I knew to pass data between.  I'm *sure* I am needing to learn
here.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Edward Jaffe
Sent: Saturday, April 04, 2009 2:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Rexx

Scott T. Harder wrote:
> I used to support a product that provided samples in both REXX and Clist.
> MAJOR pain.  Once you go to REXX, you won't look back.  Much more powerful
> in terms of numbers and it just seems so much more intuitive.
>

The worst thing about REXX is that is has no interface to IKJPARS. CLIST
keyword parameter parsing is unmatched. Emulating this processing in
REXX code is a fairly large undertaking.

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

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

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


Re: Rexx

2009-04-04 Thread Scott T. Harder
"; I always found the PROC statement problematic, and that is
the only way I knew to pass data between."

Stupid statement.  I know there are other ways.  Didn't think that one
through.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Scott T. Harder
Sent: Saturday, April 04, 2009 3:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Rexx

Hi Ed,

You are "the man", and I mean that sincerely (your questions and comments at
the TDM's are legendary as far as I'm concerned), but isn't the parsing in
REXX better than Clist?  I have no knowledge of IKJPARS and you can bet I'll
be looking it up; I always found the PROC statement problematic, and that is
the only way I knew to pass data between.  I'm *sure* I am needing to learn
here.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Edward Jaffe
Sent: Saturday, April 04, 2009 2:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Rexx

Scott T. Harder wrote:
> I used to support a product that provided samples in both REXX and Clist.
> MAJOR pain.  Once you go to REXX, you won't look back.  Much more powerful
> in terms of numbers and it just seems so much more intuitive.
>

The worst thing about REXX is that is has no interface to IKJPARS. CLIST
keyword parameter parsing is unmatched. Emulating this processing in
REXX code is a fairly large undertaking.

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

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

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

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


Re: Rexx

2009-04-04 Thread Scott T. Harder
Understood.  As evidenced by the many home-grown gyrations that we have all
seen in different REXX execs that are gone through in order to place the
arguments passed into the desired REXX variables.  I can see, by your
explanation, how Clist provides some better support there.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Edward Jaffe
Sent: Saturday, April 04, 2009 11:55 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Rexx

Scott T. Harder wrote:
> Hi Ed,
>
> You are "the man", and I mean that sincerely (your questions and comments
at
> the TDM's are legendary as far as I'm concerned), ...

Thanks for that ...

> ... but isn't the parsing in
> REXX better than Clist?I have no knowledge of IKJPARS and you can bet I'll
> be looking it up; I always found the PROC statement problematic, and that
is
> the only way I knew to pass data between.  I'm *sure* I am needing to
learn
> here.
>

Don't get me wrong. I agree the REXX PARSE statement is *extremely*
powerful. But, all REXX parsing must be done by the REXX program itself.
CLIST gets the benefit(?) of IKJPARS processing before it even gets
control. And, the TSO/E positional and keyword parameters paradigm,
while sometimes problematic (how many quotes do I need?), also has
tremendous advantages.

For example, suppose you have PROC 3 POS1 POS2 KWD1(default) KW1()
KWORD2()  KWD3

TSO/E takes care of prompting the user for missing positional parameters
POS1 and POS2, understands the minimum number of characters required to
identify any keyword, substitutes what the user specifies or supplies
defaults from the PROC statement for keyword parameters with
parenthetical specifications, and substitutes naked keywords with their
own values (e.g.) KWD3='KWD3' if specified.

I have experience transparently replacing CLIST with REXX without
changing the caller--i.e., a plug-compatible replacement. THIS WAS NOT
EASY! Writing REXX code to simulate all of the IKJPARS functionality,
automatically provided to CLIST, turned out to be a *days-long* project.
I ended up writing a large REXX external function to do the guts of the
work. It is passed (via the data stack) both a complete PROC statement
and the arguments obtained by its caller using PARSE ARG. The resulting
parameters are passed back as entries on the data stack.

It would be nice if there was a way to call IKJPARS directly from REXX
and let it do some or all of this work...

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

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

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


Re: Rexx

2009-04-04 Thread Scott T. Harder
I know this may sound trite, but the IBM REXX manuals are VERY good.  I
learned a lot just from reading these cover to cover (albeit, a few times).
Very understandable and easy to follow.  There are many areas within IBM
where criticism of the doc may be warranted, but REXX is not one of them.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/EZ2ZBK0G?filter
=REXX&SUBMIT=Search+titles


All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Mark Zelden
Sent: Saturday, April 04, 2009 12:52 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Rexx

On Fri, 3 Apr 2009 20:02:23 -0500, gsg  wrote:

>I need to learn REXX and fast.  Does anyone know a good REXX "for dummies"
>book?

In addition to all the other good resources mentioned, I have the slides
(word
doc) from an "Introduction to TSO/E REXX" class I gave to a few of my
past clients available in the JOBs/DOC section of my web site.  If you
already
know CLIST, there is a chart at the end that helps translate CLIST to REXX
statements.  It was a fast look... I usually went through the material in
about 4 hours.

http://home.flash.net/~mzelden/mvsutil.html

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

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


Re: Where are the device codes (returned by LOCATE) defined?

2009-04-27 Thread Scott T. Harder
Hi Guys and Gals,

I'm back.

Bin...  The only other HSM-like product I have experience with is CA-DISK
(back before it was CA-DISK... can't even remember the name now offhand).
But - at least at the time - used a volser of ARCIVE.  I think it is still
the same.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Gerhard Postpischil
Sent: Monday, April 27, 2009 9:26 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Where are the device codes (returned by LOCATE) defined?

Binyamin Dissen wrote:
> I was hoping that there was some bit combination that would indicate a
> migrated dataset.

Not to my knowledge. For HSM, a migrated data set has serial of
MIGRAT, then third byte of x'20' for level 1, and 'x80' for
level 2. IIRC, similar information is available from IDCAMS
DCOLLECT.

> Do all products (HSM, FDR, etc.) use the string MIGRAT as the VOLSER?

I'd love to find out also, but have only had the annoyance of
HSM 

Gerhard Postpischil
Bradford, VT

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


Prices, software, charts & analysis.  Click here to open your online FX trading 
account.
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYV6oJGSrQm7cOG7ph2CcnHUjfzC72rMjzzkLSGAmtM6VlzCqSbHkk/

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


Re: DFHSM QUESTION - HRECOVER

2009-04-28 Thread Scott T. Harder
Hi All,

Just did a very quick search through the HSM manuals, as I'm sure you did as
well, Esmie.  Nothing jumped right out, but it *was* a quick search.

Is there any way you can temporarily define the required SC?  Would that
work?  Don't know, and sorry no system to test it on at the moment.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of esmie moo
Sent: Tuesday, April 28, 2009 1:36 PM
To: IBM-MAIN@bama.ua.edu
Subject: DFHSM QUESTION - HRECOVER

Good Morning Gentle Readers,

I am trying to recover a dsn that was migrated by DFHSM.  The original
dataset was deleted today (15 minutes ago).  My problem is that when I
submit the HRECOVER I get the following error.  I looked up the error
message and it points to an SMS problem.  Since this dsn was created in 1996
and the storage class no longer exists how can I bypass SMS ?
ARC1001I SML.THH.LIB RECOVER FAILED, RC=0070, REAS=0002
ARC1170I DFSMSHSM ENCOUNTERED AN SMS-RELATED ERROR WHILE PROCESSING A DATA
SET

I tried the  BYPASSACS(**) -  but the command was rejected.





  __
The new Internet Explorer(r) 8 - Faster, safer, easier.  Optimized for
Yahoo!  Get it Now for Free! at
http://downloads.yahoo.com/ca/internetexplorer/

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


Click now to find great remedies for hangovers!
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYX6cQbXIdQfmVHqTCpcNiTk2XwVsJJlvG7H0mSVutfxxTAQJoRLIM/

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


Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

2009-04-28 Thread Scott T. Harder
Sorry... the word is obviously "lest".  DOH!

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Scott T. Harder
Sent: Tuesday, April 28, 2009 2:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

Exactly.  Let's not forget that DSS was not originally designed for a
distributed environment.  Central control by the Storage Administrators.  I
still like that idea, less data run amok and, in many cases, completely
unmanaged.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of John Kelly
Sent: Tuesday, April 28, 2009 2:14 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]


There's a peculiar tunnel vision on this list.  Remember not all users are
administrators.


hence SECURITY. If you can't use ADMIN and don't have READ access to a DSN
why would the system let you recover/restore it?

Jack Kelly
202-502-2390 (Office)

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


Click here to become a professional counselor in less time than you think.
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYbtObFlKaHlHzc8QyVSXVkR
KhGdNbWo3UDzk1uFuCh57kZCtYV61K/

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

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


Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]

2009-04-28 Thread Scott T. Harder
Exactly.  Let's not forget that DSS was not originally designed for a
distributed environment.  Central control by the Storage Administrators.  I
still like that idea, less data run amok and, in many cases, completely
unmanaged.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of John Kelly
Sent: Tuesday, April 28, 2009 2:14 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ADRDSSU protection [was:RE: Using FTP to send loadlib]


There's a peculiar tunnel vision on this list.  Remember not all users are
administrators.


hence SECURITY. If you can't use ADMIN and don't have READ access to a DSN
why would the system let you recover/restore it?

Jack Kelly
202-502-2390 (Office)

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


Click here to become a professional counselor in less time than you think.
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYbtObFlKaHlHzc8QyVSXVkRKhGdNbWo3UDzk1uFuCh57kZCtYV61K/

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


Re: Possible new SYSTEM symbols in JCL.

2009-04-28 Thread Scott T. Harder
Hi Gary,

Sounds awesome!  If you can share, that would be gr8.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Gary Green
Sent: Tuesday, April 28, 2009 8:06 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Possible new SYSTEM symbols in JCL.

John,

Not certain if this helps but I have some Rexx code which I execute in
batch.  This particular Rexx will take input file(s) and process each line
from each input file and resolve any symbolics it finds and then passes the
input line to a specific output DD name.  I use the standard system
symbolics and a few of my own.

The output file is then passed down to another step in the job which never
knows where the SYSIN control cards came from.

Works like a champ.

Perhaps you could put something together like this?  I would offer to pass
it along but I would need permission first. (new employer)


Gary Green
Never use a 2x4 when a 2x6 will do just as well!

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of John McKown
Sent: Tuesday, April 28, 2009 12:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Possible new SYSTEM symbols in JCL.

On Tue, 28 Apr 2009 11:36:31 -0500, Rick Fochtman  wrote:

>John, geting the JOBNAME shouldn't be too much of a problem; the value
>could be set at conversion time. Getting the job number might be more
>of a problem, since JES would have to get involved here.
>
>You might wanty to consider an Assember routine that will query JES2
>for job number and your ASCB for the job name. Then do a dynamic
>allocation of the HFS/ZFS file and create the appropriate JCL, then
>pump it through the internal reader for your PERL step. Consider using
>the DYNAM routine from the CBTTAPE to do the allocation.
>
>--
>Rick

I could do the above. If I did not feel so tired that even typing this email
is difficult (ongoing medical condition). I guess what I should really do if
I want any "new system symbols" is simply write a JES2 exit 2 to insert a
bunch of

// SET symbol=value

cards immediately after the JOB card. But that is way too much trouble too.
And, in any case, that would violate our standard of "No mods, no exits, no
customization! Plain vanilla or death!"

--
John

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

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


Click to receive credit card help and get out of debt fast.
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYVrpdTMHlKJSw5OlO4vzyAkFUH7EjESB8el9A6NOv7Ndmkc3VBwDe/

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


Re: Possible new SYSTEM symbols in JCL.

2009-04-29 Thread Scott T. Harder
John,

You are not the only one.  I've always found it frustrating that &SYSUID is
the only available symbol/variable that is available for use in batch.
Seems to me that there should be many more.  Aside from the temp data set
names you can use - and this is no news to everyone - we have to hardcode
EVERYTHING in JCL.  IBM should start to look at JCL like more of a scripting
language, IMO, and provide a lot more of what you originally posted about.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of John McKown
Sent: Wednesday, April 29, 2009 7:32 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Possible new SYSTEM symbols in JCL.

On Tue, 28 Apr 2009, Gary Green wrote:

> John,
>
> Not certain if this helps but I have some Rexx code which I execute in
> batch.  This particular Rexx will take input file(s) and process each line
> from each input file and resolve any symbolics it finds and then passes
the
> input line to a specific output DD name.  I use the standard system
> symbolics and a few of my own.
>
> The output file is then passed down to another step in the job which never
> knows where the SYSIN control cards came from.
>
> Works like a champ.
>
> Perhaps you could put something together like this?  I would offer to pass
> it along but I would need permission first. (new employer)
>
>
> Gary Green
> Never use a 2x4 when a 2x6 will do just as well!

Thanks for the offer. I could do that myself. As I said in an earlier
post, I'm being very lazy and was just wondering if anybody else thought
these symbols would be helpful. Apparently I'm the only one who would.
It's not a big deal.

--
Trying to write with a pencil that is dull is pointless.

Maranatha!
John McKown

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


Be your own boss today with Contractor Training. Click here.
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYbjI6nfMHQ88gcW8G9z1I2teBevVFwukILQmsm0t7z492K2U5t65i/

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


Re: CICS Region oddity

2009-04-29 Thread Scott T. Harder
Did you try FORCE , ARM?

How did it go?  "Unpredictable results can occur" ?

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Richards, Robert B.
Sent: Wednesday, April 29, 2009 7:55 AM
To: IBM-MAIN@bama.ua.edu
Subject: CICS Region oddity

My CICS guy has an interesting problem that now has me a tiny bit
concerned. He attempted to force a region down and a /D JOBS, shows
the job is still out there:



CICSRTT1 CICSRTT1 CICS IN NFS   A=00C0   PER=NO   SMC=000

PGN=N/A  DMN=N/A  AFF=NONE

CT=014.735S  ET=01.27.59

WUID=S0144040 USERID=TESTCICS

WKL= SCL= P=0

RGP= SRVR=NO  QSC=NO

ADDR SPACE ASTE=03625000



SDSF DA does not show this region. The IEE115I message seems to indicate
that the address space is hosed (the NFS in the display above). Any clue
as to why this address space refused to die its horrible death? Let's
ignore, for the moment, the eventual loss of the address space. Any
clues as to where I should start to look?



Bob


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


Be your own boss.  Click here for information on starting your own business.
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYRRJTSXIUzjU2Bt5IJbfKmm5xNsUGJuQEr5SCSYIKkJgVHFKCjHFm/

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


Re: CICS Region oddity

2009-04-29 Thread Scott T. Harder
Man...   The region put up fits getting FORCEd off the system and then hangs
again on restart??  I'd start removing loadlib's - one at a time - probably
application ones - from the list and see how that affects the region on
startup.  At least to get to the point where the region will get to "control
given...".

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Richards, Robert B.
Sent: Wednesday, April 29, 2009 9:59 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CICS Region oddity

Eileen,

We are running CICS TS 3.2

Bob


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Barkow, Eileen
Sent: Wednesday, April 29, 2009 9:13 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CICS Region oddity

i do not know what release of CICS you are running, but if it is 6.2
(cics ts 2.2), then you might want to look this ptf.




  APAR Identifier .. PK08265  Last Changed  05/07/08
  RLS I/O HANGS, CICS WILL HANG IN FCVRWAIT, POSSIBLE ABEND0F4 IN
  IDAVRBFM RSN6117FB6CDFHFC0308

  Symptom .. LP hang  Status ... CLOSED  CAN
  Severity ... 1  Date Closed . 05/07/08
  Component .. 5697E9300  Duplicate of 
  Reported Release . 200  Fixed Release 
  Component Name CICS Z/OS V6 Special Notice
  Current Target Date ..05/08/11  Flags
  SCP ...
  Platform 

  Status Detail: APARCLOSURE - APAR is being closed.

  PE PTF List:

  PTF List:

 Snipped

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


Be a Certified Nursing Assistant. Get local training today.
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYgDBifBZqJYKpdsiPMHVe8xpD9hdYTMUhYtgRHDewOAdvv2hZP7lm/

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


Re: Possible new SYSTEM symbols in JCL.

2009-04-29 Thread Scott T. Harder
Wow Cool !

Will check it out.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Clement Clarke
Sent: Wednesday, April 29, 2009 10:17 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Possible new SYSTEM symbols in JCL.

The Jol Universal Command language (which can be used as a replacement
for JCL and Clists, and which can run jobs in Batch or TSO) has quite a
few symbolic variables preset.

Furthermore, User Exits or Macros can be used to set additional
Symbolics at startup, or later.  Symbolic Variables can be tested, or
changed, and full arithmetic expressions (similar to PL/I) can be
performed on them.

These are some of the Symbolic Variables that are set at startup:

%SYSDATE   The current date in Julian format e.g. 09290
%DAY   MONDAY, TUESDAY, etc.
%MONTH JANUARY, FEBRUARY, etc.
%MONTHNO   01, 02 Through 12
%DAYNO 01 through 31
%YEAR  2009, 2010, etc.
%HOURS 0 through 23
%MINS  0 through 59
%SECS  0 through 59

%SYSUIDSystem user identification
%SYSPREF   Dataset prefix
%SYSPFKProgram function key number from PANELs

%SYSTEMMFT, MVT, VS1, VS2, VM, etc.
%SPOOL HASP, ASP, JES1, JES2, JES3, or Blank

Jol is a free form scripting language similar to PL/I and Rexx.

It is available for Z/OS and a Windows version can create JCL to be
submitted to the mainframe.


Clement Clarke



Scott T. Harder wrote:
> John,
>
> You are not the only one.  I've always found it frustrating that &SYSUID
is
> the only available symbol/variable that is available for use in batch.
> Seems to me that there should be many more.  Aside from the temp data set
> names you can use - and this is no news to everyone - we have to hardcode
> EVERYTHING in JCL.  IBM should start to look at JCL like more of a
scripting
> language, IMO, and provide a lot more of what you originally posted about.
>
> All the best,
> Scott T. Harder
>
>


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


Looking for insurance?  Click to compare and save big.
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYVv6vtKLTM9AIrKwmPYyaMZnK8PMtei4cMfUGcJF3rxBIdmnfl9Ak/

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


Re: Possible new SYSTEM symbols in JCL.

2009-04-29 Thread Scott T. Harder
Bingo.

All the best,
Scott T. Harder

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf
Of Paul Gilmartin
Sent: Wednesday, April 29, 2009 12:28 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Possible new SYSTEM symbols in JCL.

On Wed, 29 Apr 2009 22:16:55 +0800, Clement Clarke wrote:

>The Jol Universal Command language (which can be used as a replacement
>for JCL and Clists, and which can run jobs in Batch or TSO) has quite a
>few symbolic variables preset.
>...
>Jol is a free form scripting language similar to PL/I and Rexx.
>
>It is available for Z/OS and a Windows version can create JCL to be
>submitted to the mainframe.
>
Does this imply that on z/OS it does not submit JCL?

Does it perform DSN ENQs en masse to preclude the possibility of
deadlock?

Can it be used to create multi-file tapes?  To do this reasonably,
one needs (analogues of) VOL=REF and RETAIN, available in JCL
but not in TSO.

>> You are not the only one.  I've always found it frustrating that &SYSUID
is
>> the only available symbol/variable that is available for use in batch.
>> Seems to me that there should be many more.  Aside from the temp data set
>> names you can use - and this is no news to everyone - we have to hardcode
>> EVERYTHING in JCL.  IBM should start to look at JCL like more of a
scripting
>> language, IMO, and provide a lot more of what you originally posted
about.
>>
I'm the third one.

Alas, what we want is contrary to the design objectives of JCL, which
needs to perform a static assessment of resources required by a job
in order to avoid deadlocks and preventable locking of idle resources.

The suggestions frequently made here that the ambiguities between
Reader values, Converter values, and Execution values could be
resolved by providing multiple symbols are naive (or perhaps
sarcastically rhetorical): given the need for static assessment,
probably only the first, certainly not the last, is technically
feasible.

But granted that much, the wish most frequently expressed here is
for time and date to incorporate in data set names.  For this
purpose, the Reader time would be widely useful; it corresponds
closely to the tailoring, scripting, exit, and periodically
updated INCLUDE member circumventions that many of us have used.

We're adults.  If new system symbols were available in batch JCL
such as RDRTIME and RDRDATE with the obvious mnemonic value,
we're capable of understanding that if a job lingers in the input
queue for 6 months, those variables will have old values, not
current ones, even as we understand the similar behavior of our
tailoring etc. circumventions.

As an analogy, SDSF allows me to sort on a job's submit time,
start time, or completion time.  In fact, I've chosen the first
because it is notionally closest to my concept of chronological
order.

Users should be given a choice between the hazards of DYNALLOC
and the exaggerated (in my view) uncertainties of static time
variables.

-- gil

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


Hit it out of the park with a new bat. Click now!
http://thirdpartyoffers.netzero.net/TGL2241/fc/BLSrjpYan8tO2gQZaPWx7sTfaMsI0yN1VNDipZpYI6PAdiRyHiJg14zpL8k/

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