Re: FW: FW: TSO/E PROFILE PREFIX in z/OS 2.3

[Mainframe Sysprog]

Thankyou Lizette. I'll keep an eye on this APAR.

Meanwhile, I opened a pmr with L2 to find out any other clues. They
suggested me to check if we have any exits installed for user profile table
(which I doubt, but I am not sure, I'll have to ask around from someone on
this site - is there a way to check that?).

Thanks
Varun

On Tue, Mar 6, 2018 at 10:54 AM, Lizette Koehler 
wrote:

> FYI
>
>
> From: Marna Walle 
> Sent: Monday, March 05, 2018 12:00 PM
> To: Lizette Koehler 
> Subject: Re: FW: TSO/E PROFILE PREFIX in z/OS 2.3
>
>  Hi Lizette,
> This is a defect.  OA55019 is the APAR taken for it.
>
> APAR= OA55019  SER=IN INCORROUT
> TSO/E PROFILE NOPREFIX DOES NOT GET SAVED ACROSS LOGOFF/LOGON
> WHEN THE LWABUPT FLAG IS ON.
> STAT= OPEN FESN6528502- CTID= PK2710 ISEV= 3
> SB18/02/27  RC18/02/28  CL  PD   SEV= 3
>
> No migration action :).
>
> Thanks,
>
>
> Marna Walle
>
> Senior Technical Staff Member
> Member of the IBM Academy of Technology
> z/OS Development, IBM z Systems
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Managing JESYSMSG size

[Robin Atwood]

Yes, after a fruitless search through the text units I found the flag in the 
RB. I will implement a configuration option so customers can turn off the 
allocation messages when doing initial check-outs or other operations involving 
large numbers of members.

Thanks for the tip!
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Price
Sent: 05 March 2018 19:39
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Managing JESYSMSG size

On 2018-03-05 5:50 PM, Robin Atwood wrote:
> Greg-
> The SVC 99s are under my control and that is very useful to know!
> 
> Thanks
> Robin


Robin,

Great!
:)
But I was slightly inaccurate.
:(

It is not in a text unit, it is in the RB proper - bit S99MSGL0 in byte 
S99FLG11.

In a batch program (HSIPINQ) which allocates lots of DDs, I use the flag in 
both the allocation and deallocation requests to reduce spooled output size, as 
well as the number of pages one has to scroll down to get to the start of the 
SYSPRINT report. (Sometimes this is being viewed outside SDSF where N 3 works 
well.)

The main purpose I like all those allocation and data set disposition messages 
in the general case is so that I can quickly see which data sets are allocated 
at the time of an abend, and can usually figure out which DDs are allocated to 
which data sets.

Naturally, the data sets disposed of after the abend are the ones which were 
allocated at the time of the abend.

Of course, sometimes customer flower boxes from their IEFACTRT routine can be 
helpful in this area too.

Anyway, in the SYSPRINT report line which reports the data sets as they are 
processed I now also display the DD name just in case it's needed.

IIRC, I went looking for this flag one day when trying to figure out how 
BPXWDYN can do allocations and deallocations without generating such messages. 
Given its component prefix, perhaps it was written with a view to operating in 
spawned address spaces which usually leave no spooled relic of their existence.

Cheers,
Greg

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

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

Re: Product license key program

[Brian Westerman]

Tom

As for adding keys to your software, yes, I believe it's a good thing, but you 
have to remember that simply locking up your software really, really tight is 
not a good solution.  They idea is to balance protecting your software but not 
putting the screws in so tight that the client can't use it properly.

It's really really easy to get the CPU serial number programmatically, and IBM 
even has a service you can call to get the machine information from an 
authorized or non-authorized environment.  You can get it from COBOL as well as 
via C.  

As for protection, many vendors simply "scramble" the characters of the CPUID 
and the "expiration date" they want to assign among either a bunch of useless 
characters or keep single bytes all over the place within your program, then 
you get the CPU serial (and machine type information if you want to use that 
also), and the current date, then you simply compare the values you know (the 
CPUID and other data you authorized in your program), with the values you just 
got from the system you are executing on.  If they don't match (serial number, 
etc.) then you can just send a message that you have expired or just end 
without saying anything (which is very unhelpful).  Then if that matches, you 
compare the dates, and if it's within the end date you allowed, then you just 
go on as if nothing happened.  If you are getting close to the date (i.e. the 
last 30 days) then you can put out a "warning" message that you will expire 
soon.  You can (and probably should) add code to allow "grace" period.  

Now, if you want to get really fancy, you can take the information that you 
normally would have kept within your code, and instead place it in a key record 
(some encrypted record that you provide to the user to make available to your 
program, either in a dataset or as a parm to the execution.  You program should 
then have some decryption code that checks the provided key information against 
the execution time information (CPUID, MACHINE Type, current date), just like 
the previous method, except that you have externalized the "key" and can 
replace it very easily for your client.

The encryption method can be a secure one (128bit or 256 bit secure method or 
you can devise your own encryption code, even something as simple as inverting 
each character by some known amount and also having scrambled up the order of 
the information is probably more than enough to do what you want.  After all, 
most sites are not really trying to steal your code, and besides a really 
concerted and smart person with enough time can break your encryption anyway, 
but the idea is really just to remove the temptation to keep copies of your 
code and/or sell them to other people.

I have literally seen probably 100 (or more) different ways of implementing the 
code, and everyone has their favorites and everyone thinks that theirs is the 
best (but I know mine is), and there is no real "right" way to do it.

If you need help setting up the code to get the information from the system 
during execution, let me know and I'll help you, as for coming up with the 
encryption code, you probably want to do that yourself so that you know that no 
one else will give your method away.  But if you need help I can help you there 
as well.  It's really very simple once you know where to get the information at 
run time.

What you will notice is that once you are able to get the data from the system, 
it becomes more addictive and you will want to start getting things like the 
jobname of the job that is executing you, or the owning userid and such.  The 
skys the limit once you start down that road.

Just remember that you don't need to go overboard. You certain can if you want, 
but protection doesn't have to be overly complex to be effective.

Brian  

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

FW: FW: TSO/E PROFILE PREFIX in z/OS 2.3

[Lizette Koehler]

FYI


From: Marna Walle  
Sent: Monday, March 05, 2018 12:00 PM
To: Lizette Koehler 
Subject: Re: FW: TSO/E PROFILE PREFIX in z/OS 2.3

 Hi Lizette,
This is a defect.  OA55019 is the APAR taken for it.

APAR= OA55019  SER=                            IN INCORROUT  
TSO/E PROFILE NOPREFIX DOES NOT GET SAVED ACROSS LOGOFF/LOGON
WHEN THE LWABUPT FLAG IS ON.                                 
STAT= OPEN         FESN6528502-     CTID= PK2710 ISEV= 3     
SB18/02/27  RC18/02/28  CL          PD           SEV= 3      

No migration action :).

Thanks,


Marna Walle

Senior Technical Staff Member
Member of the IBM Academy of Technology
z/OS Development, IBM z Systems

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

Re: Product license key program

[Wayne Bickerdike]

BobL said:

 *   I have to disagree on Compuware products.  We have a bunch, and the
License administration application works fine.  We just go into the panels,
set DR mode, and we're good for 14 (?) days.   For us at least, it's a very
workable solution for DR.*

Spoken like a systems programmer!

The License panel asks for Port Number, Host Name, Host Address, TCP STC
name.

Remember that the DR user is not always you.

I had to look all this up, because it's not my gig. But our guys who deal
with vendors and licences hate the process.


On Tue, Mar 6, 2018 at 3:56 AM, Lester, Bob  wrote:

> Hi Wayne,
>
>  I have to disagree on Compuware products.  We have a bunch, and the
> License administration application works fine.  We just go into the panels,
> set DR mode, and we're good for 14 (?) days.   For us at least, it's a very
> workable solution for DR.
>
> Thanks!
> BobL
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Wayne Bickerdike
> Sent: Sunday, March 4, 2018 1:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Product license key program [ EXTERNAL ]
>
> We always have issues during DR with licence keys.
>
> Worst vendor is Compuware, convoluted process and activation procedure.
>
> We like to expose "novice" users to the DR process, it's a test of
> documentation and process, not systems skills.
>
> One vendor had the cheek to tell us to give more warning. I told them we
> are testing you as much as DR.
>
> Don't mind CA, they don't disable just give warnings.
>
> On Mon, Mar 5, 2018 at 6:55 AM, Seymour J Metz  wrote:
>
> >  1. BTDT,GTS - I'm not talking ideology or abstract theory, but history.
> > Vendor promises are worthless when push comes to shove.
> >
> >  2. In the incidents I was referring to we *did* get the keys in advance;
> > they didn't work and the vendor failed to respond within the
> > contractually
> > guarantied time window. That's why I asked about how you handled
> > DR tests.
> >
> >  3. I'm not concerned with the customer who has delayed renewing, I'm
> > concerned with the customer who is fully paid up and doesn't get
> > what he paid for.
> >
> >  4. "To indemnify for or from what exactly?" The cost of the DR
> > facilities that could be
> > tested because of the bad keys would have been a start.
> >
> >  5. "what associated risk?  The risk that they will not pay their
> > license fee and therefore
> >  lose the use of the software?"
> >
> > More straw dummies. Stop trying to put words in my mouth.
> >
> >  6. "you are assuming that the Key or the requirement thereof will
> > somehow, through the
> >  fault of the "key", cause an outage. ".
> >
> > No, *you* are assuming that I don't have empirical evidence. See
> > item
> > 2 above.
> >
> >  7. "4) What about it?  They paid for the key, it's implemented, and
> > it works."
> > Were that true I wouldn't have commented. We paid for the keys, it
> > was implemented
> > and it *didn't* work.
> >
> >  8. "and not a generation issue or some other purely human factor?"
> > From the customer perspective the vendor is a black box; he doesn't
> > care whether the outage cased by the vendor was due to hardware,
> > software or human error.
> >
> >  9. "I don't think most vendors try to tell the client what metrics to
> > use in
> >  evaluation (aside from CA maybe:))"
> >
> > CA never had the nerve to patronizingly dismiss our concerns. They
> > accepted
> > them as legitimate and addressed them as best they could.
> >
> > 10. "6) What danger inherent in the enforcement method? "
> > See item 2 above.
> >
> > 11. "The key works or it doesn't, if it doesn't, either it expired, the
> > software has been altered or changed or it never worked in the
> > first place. "
> > How do you propose that the customer tests whether a DR key works
> prior
> > to going to the DR site and testing?
> >
> > 12. " I really don't mean to sound flippant, but sending software out
> > without keys
> > would be similar (maybe only to me) as Ford sending out all of
> > their cars without
> >  an ignition key or secure button. "
> > Only to you; Ford doesn't try to lock its customer out of the car.
> >
> > Bottom line: keys are bad because historically they have caused
> > problems for legitimate users, often problems that the vendor had
> > promised wouldn't occur.
> >
> > --
> > Shmuel (Seymour J.) Metz
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Es
> > metz3&d=DwIBaQ&c=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k&r=1KMMjoS
> > vFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4&m=1l6hpNNXgTiCCpbDJWg8VLAjcwY3ccs
> > 7JKJn3oF8I2A&s=Ap59KzoG5pNDC3N598NDZ-cKLXf4Aac-cJgMJiZzTDk&e=
> >
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Brian Westerman 
> > Sent: Saturday, March 3, 2018 1:22 AM
> > To: IBM-MAIN@listserv.ua.edu

Re: Product license key program

[David Boyes]

> Back to the keys question, I've tried to figure out how to even have keys in 
> the application system.  
> Places that I've worked at, there have been times when getting paid for our 
> software or services has been difficult to collect, so what about keys ??
> Well, that becomes a challenge when we have always delivered the code to the 
> customer...not really sure how to do that.

I've always liked the approach that DEC used for VMS software: engineer a 
common license database and a set of tools to manipulate it, and create a way 
to check if the license was valid for the machine in question that was usable 
from every supported programming language on the system. Everybody pretty much 
had a gentleman's agreement that this was the way to control software usage, 
and DEC actively discouraged products and vendors that didn't play nice. Their 
tool had the ability to lock software to a specific machine, CPUtype, number of 
users, and about a dozen other things, and had options for how long to tolerate 
running without a license and a whole lot more. You could audit your licenses 
by running the LICENSE command and all your licenses from all your vendors were 
in one place. The same system was used for the OS and applications alike, and 
the license file could contain multiple licenses for the same product that 
could be queried to determine which license to use on this system (it was 
designed for clustered machines). 

IBM made an abortive attempt at something like this back in the 80s, but 
inserted IBM into the licensing process in a stupid way. Predictably, it got 
shot down by the ISVs who didn't want to change their code and/or have IBM 
involved in their licensing. Perhaps it's time to try again -- I know I 
wouldn't mind having such a thing available, and I detest inventing and/or 
dealing with stuff like this. Just have the OS vendor do it correctly once; 
they're in the best position to architect it to fit the underlying system best, 
and it generally isn't a performance or functionality critical thing so there 
isn't likely to be a need to allow replacement systems.

 


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

Re: Feel free to reuse

[Steve Horein]

Received.
Applied.
Tested.
Accepted.

Thank you sir! :-)

On Mon, Mar 5, 2018 at 11:22 AM, Robert Prins 
wrote:

> Hi all,
>
> Recently I got this (slightly edited) email:
>
> > I recently got into MVS/IBM z via [edited out], and was thinking of
> > writing about my progress. ~20 years of Unix is enough for anyone, I
> feel.
> >
> > Would it be OK to er... 'borrow' the CSS from
> > ? I'm leaning towards
> going with
> > an ISPF kind of look for the whole thing.
>
> My reply:
> ===
> Feel free to "borrow" the file @ 
> I've put a copyright notice on it, but have also slapped a GPL3 licence on
> it, like I've done with all of the REXX code that you can find on my z/OS
> page. If you want you can also copy the z/OS favicon  https://prino.neocities.org/images/zOS.png> (Watch the capitalisation!).
> Just give me a back-link.
>
> For what it's worth, a large part of the css file is commented out, as it
> has nothing to do with z/OS but everything with my hitchhiking <
> https://prino.neocities.org/indez.html> pages.
> ===
>
> If anyone else here wants to grab a copy, feel free to do so, and let's
> populate the internet with "3270" screens. ;)
>
> Robert
> --
> Robert AH Prins
> robert.ah.pr...@gmail.com
> Some programming  @ 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Product license key program

[Jesse 1 Robinson]

I’m sympathetic to a vendor's need for keys. A (long gone) shop I worked in 
suffered the grab-and-run of a well-known product from its licensed location to 
an unlicensed one. Thanks to a rogue operator who I guess wanted to make his 
day to day job a little easier and figured out how to do a copy over NJE. ISV 
threw a fit, wanted an extraordinary penalty. Not from the miscreant himself of 
course. 

We now deal with many ISVs. Most of the big ones plus some dogies as well. We 
do frequent DR tests as we own the DR environment. I'm not aware that our keys 
in general include the DR machine, but everything works. Warnings are fine; I 
personally appreciate the reminder that I'm running a DR system, which 
otherwise looks exactly like production.

Our biggest concern is getting renewal keys in time to keep a product from 
imploding. That issue is seldom the fault of the ISV. Can you spell bean 
counter?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Savor, Thomas (Alpharetta)
Sent: Monday, March 05, 2018 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Product license key program

That's the problem. If you give customer Source code, they can get around the 
key.
The only thing I could think of, was to only deliver object to certain Batch 
and Online modules that never change.  Sort of Black Box those modules.

On the contract thingwell in our case at the time, it was a software sell 
and a bunch of mods we did for this Turkish Bank.  They owed us around 1 
million dollars...then they decided not to pay at all...all support for them 
ended.  The problem was that it was a State Owned Bankso we had to eat it.
It was a hard lesson to learn.

But even the keys, it was fascinating to see these keys.  I've tried to 
understand how in the World these workedi've seen a zap before to extended 
a product from now to next yearnow the zap looked like a couple of LA's 
applied to a module...and the product extended to next year.  But you don’t 
find ANY dates in this program, so how this is done has always been "Magic". 

Thanks,

Tom Savor


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Grinsell, Don
Sent: Monday, March 05, 2018 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

Tom,

I guess it all depends on your contract terms.  If the software requires a key 
to run, then you should be able to get paid for delivering an updated key.  If 
you are delivering source code, well any competent programmer could probably 
circumvent your key logic and be prepared to face the consequences if you 
choose to audit them.  On the other hand, if the license key is for support, 
then they have rights to use the software as delivered, but upgrades or help 
would require an active subscription easily verified on your end.  

Regards,

Don

--
 
Donald Grinsell, Systems Programmer
Enterprise Technology Services Bureau
SITSD/Montana Department of Administration
406.444.2983 (D)


"It was as true as taxes is.  And nothing's truer than them."
~ Charles Dickens (1812-70)

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Savor, Thomas (Alpharetta)
> Sent: Monday, March 05, 2018 2:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Product license key program
> 
> 
> Back to the keys question, I've tried to figure out how to even have 
> keys in the application system.
> Places that I've worked at, there have been times when getting paid 
> for our software or services has been difficult to collect, so what about 
> keys ??
> Well, that becomes a challenge when we have always delivered the code 
> to the customer...not really sure how to do that.
> 
> Thanks,
> 
> Tom Savor


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

Re: Product license key program

[Savor, Thomas (Alpharetta)]

That's the problem. If you give customer Source code, they can get around the 
key.
The only thing I could think of, was to only deliver object to certain Batch 
and Online modules that never change.  Sort of Black Box those modules.

On the contract thingwell in our case at the time, it was a software sell 
and a bunch of mods we did for this Turkish Bank.  They owed us around 1 
million dollars...then they decided not to pay at all...all support for them 
ended.  The problem was that it was a State Owned Bankso we had to eat it.
It was a hard lesson to learn.

But even the keys, it was fascinating to see these keys.  I've tried to 
understand how in the World these workedi've seen a zap before to extended 
a product from now to next yearnow the zap looked like a couple of LA's 
applied to a module...and the product extended to next year.  But you don’t 
find ANY dates in this program, so how this is done has always been "Magic". 

Thanks,

Tom Savor


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Grinsell, Don
Sent: Monday, March 05, 2018 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

Tom,

I guess it all depends on your contract terms.  If the software requires a key 
to run, then you should be able to get paid for delivering an updated key.  If 
you are delivering source code, well any competent programmer could probably 
circumvent your key logic and be prepared to face the consequences if you 
choose to audit them.  On the other hand, if the license key is for support, 
then they have rights to use the software as delivered, but upgrades or help 
would require an active subscription easily verified on your end.  

Regards,

Don

--
 
Donald Grinsell, Systems Programmer
Enterprise Technology Services Bureau
SITSD/Montana Department of Administration
406.444.2983 (D)


"It was as true as taxes is.  And nothing's truer than them."
~ Charles Dickens (1812-70)

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Savor, Thomas (Alpharetta)
> Sent: Monday, March 05, 2018 2:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Product license key program
> 
> 
> Back to the keys question, I've tried to figure out how to even have 
> keys in the application system.
> Places that I've worked at, there have been times when getting paid 
> for our software or services has been difficult to collect, so what about 
> keys ??
> Well, that becomes a challenge when we have always delivered the code 
> to the customer...not really sure how to do that.
> 
> Thanks,
> 
> Tom Savor
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Product license key program

[Savor, Thomas (Alpharetta)]

Your right...my bad.  Spelling is my crutch !!!

Thanks,

Tom Savor

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J R
Sent: Monday, March 05, 2018 4:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program

I apologize up front for my pedantry.  However, in the context of this argument 
... er ... discussion, it seems apropos:
You typed 'incite' I think you meant 'insight'.
You typed 'site' I think you meant 'cite'  (twice).

Peace!

On Mar 5, 2018, at 16:02, Savor, Thomas (Alpharetta) 
mailto:thomas.sa...@fiserv.com>> wrote:

I would love to get your incite on something

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

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

Re: Product license key program

[Grinsell, Don]

Tom,

I guess it all depends on your contract terms.  If the software requires a key 
to run, then you should be able to get paid for delivering an updated key.  If 
you are delivering source code, well any competent programmer could probably 
circumvent your key logic and be prepared to face the consequences if you 
choose to audit them.  On the other hand, if the license key is for support, 
then they have rights to use the software as delivered, but upgrades or help 
would require an active subscription easily verified on your end.  

Regards,

Don

--
 
Donald Grinsell, Systems Programmer
Enterprise Technology Services Bureau
SITSD/Montana Department of Administration
406.444.2983 (D)


"It was as true as taxes is.  And nothing's truer than them."
~ Charles Dickens (1812-70)

> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Savor, Thomas (Alpharetta)
> Sent: Monday, March 05, 2018 2:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Product license key program
> 
> 
> Back to the keys question, I've tried to figure out how to even have keys in
> the application system.
> Places that I've worked at, there have been times when getting paid for our
> software or services has been difficult to collect, so what about keys ??
> Well, that becomes a challenge when we have always delivered the code to the
> customer...not really sure how to do that.
> 
> Thanks,
> 
> Tom Savor
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Product license key program

[J R]

I apologize up front for my pedantry.  However, in the context of this argument 
... er ... discussion, it seems apropos:
You typed 'incite' I think you meant 'insight'.
You typed 'site' I think you meant 'cite'  (twice).

Peace!

On Mar 5, 2018, at 16:02, Savor, Thomas (Alpharetta) 
mailto:thomas.sa...@fiserv.com>> wrote:

I would love to get your incite on something

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

Re: FDRMOVE sample jcl

[Gibney, Dave]

   I run both. FDR/DSF/ABR and DF/DSS/HSM  They're both useful in their own 
way. And Innovation is reasonably priced for our size.  
   I once tried to migrate our HSM implementation to FDRABR's archive. I don't 
remember all the glitches, but it didn't handle expiration well enough and I 
think the volume level approach didn't to multi-volume stripped data well.
  On the other hand I had some very unpleasant (many years ago now) trying to 
use HSM fullvolume DUMP and run forward via incrementals in restoring. The 
reserve HSM used when DUMPing also caused problems. As I said, a long time ago. 
Might be better now. And I also have since moved my Usercatalogs to Non-SMS 
(HSM is only used for SMS) storage.
   
  On the OP, I generally use DFDSS to move individual datesets.  Mostly habit, 
as I'm sure FDR would do just as well.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Pew, Curtis G
> Sent: Monday, March 05, 2018 12:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FDRMOVE sample jcl
> 
> On Mar 5, 2018, at 1:55 PM, Carmen Vitullo  wrote:
> >
> > got ya, and I've never been at a site with DFSMSDSS DISABLED, bet disabling
> would be quite interesting :)
> 
> No, it’s quite boring, if you have the Innovation products. The only time I’ve
> noticed is when a vendor sent me an install that assumed I could use
> ADRDSSU. Previous installs had all used TSO TRANSMIT format, so I just got
> them to send me the new stuff that way too.
> 
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
> ITS Systems/Core/Administrative Services
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Product license key program

[Savor, Thomas (Alpharetta)]

" OK, this discussion has reached the level of diminishing returns."

Man, I guess sothis "was" a very interesting discussion about software keys 
that has dissolved quickly.
Guys, I'm not a systems programmer, never have beenbut I'm kind of the 
Applications systems programmer if that exists.
Anyway, I thought Brian asked very thoughtful questions and asked for an 
opinion about which way to go...not a bunch of crap.   
I don’t know Brian at all, but if I could follow his questions, then they were 
probably pretty well explained.

Then there's SeymourI don’t know you either, but as an observation, you 
remind me of my brother.  He will argue with me about the sky being blue.
Some people "must" argue or correct you about everything...it's like it's their 
job or something.
I would love to get your incite on something without the constant seemingly 
condescending corrections to everything.
You may not mean to be condescending, but you come across that way to me.
If I worked at your shop, I wouldn’t ask you for help even if I knew you knew 
the answer, I wouldn’t want to hear the constant argument 
about what I'm doing.

Seymour, you are probably a genius...But at the end of the day, these constant 
corrections or arguments - Does it really matter ??
I site a couple years ago the constant bitching about UNIX or UCC.  People 
learn something and its called something at a site, as long as everyone 
understands what they are talking about...again, does it matter ?? If you 
alienate people, then they aren’t going to listen to you.  
There was a time when all your answer/emails went to the Trash can...and your 
drifting towards that again.  
Most of the time, when you site a sentence or even a wordI have no clue 
what you are talking about.  

Back to the keys question, I've tried to figure out how to even have keys in 
the application system.  
Places that I've worked at, there have been times when getting paid for our 
software or services has been difficult to collect, so what about keys ??
Well, that becomes a challenge when we have always delivered the code to the 
customer...not really sure how to do that.

Thanks,

Tom Savor

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

Actually www.ibm.com/us-en was Re: Connor Krukosky is on the Main Webpage at www.ibm.com

[Clark Morris]

[Default] On 5 Mar 2018 12:14:50 -0800, in bit.listserv.ibm-main
charl...@mcn.org (Charles Mills) wrote:

>I can select the ca-en page from the US. A corollary might be that you could
>select us-en from Canada. I just overtyped the URL.

That worked.

Clark Morris
>
>Charles
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of Clark Morris
>Sent: Monday, March 5, 2018 12:00 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Connor Krukosky is on the Main Webpage at www.ibm.com
>
>[Default] On 5 Mar 2018 11:46:12 -0800, in bit.listserv.ibm-main
>jesse1.robin...@sce.com (Jesse 1 Robinson) wrote:
>
>>Marvel seems always to be on the lookout for a new superhero character...
>>
>I don't see it in Canada where IBM forces me to the ca-en page.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SMS/HSM QUESTION

[Graham Harris]

PSM should expire eligible datasets, regardless of volume residency levels.

Have a look at the bottom few paragraphs here, specifically:

"Pass 1 of automatic primary space management

 (non-data-movement function in primary space management) and extent
reduction are performed for all volumes in storage groups defined with AM=Y
and AM=I (SG1, SG2, and SG3). Pass 2 of automatic primary space management

 (migration) is performed only for those volumes that are above the low
threshold after pass 1 and extent reduction have completed."

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.arcf000/stgbmgd.htm

Have a look at the HSM log messages being produced for the datasets which
you expect to be expired.  They should indicate why they are not being
expired.


On 5 March 2018 at 18:26, Mike Schwab  wrote:

> Set one volume to Quiesce,New and migrate the volume.  Whatever is
> left try to manually migrate and note error.  Return to spare if you
> don't need the space, or Enable to return to active use.  Proceed with
> next volume.  Or just reduce high threshold so it will process all
> volumes, return after cleanup.
>
> On Mon, Mar 5, 2018 at 10:37 AM, willie bunter
> <001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:
> > I verified the MC and DSORGs.  No problem found.  No patches either
> which would impede the PSM.  I remember reading or being told that once the
> SM conditions had been met, HSM stops looking at the volume(s).
> >
> >   From: Graham Harris 
> >  To: IBM-MAIN@LISTSERV.UA.EDU
> >  Sent: Friday, March 2, 2018 6:05 PM
> >  Subject: Re: SMS/HSM QUESTION
> >
> > Primary space management should normally process all volumes in a storage
> > group. And PSM should normally look to reduce utilisation of a volume
> down
> > to the low threshold (caveat - various PATCHes can alter DFHSM standard
> > behaviour).
> > Have you checked the messages for space management actions for these
> > datasets?
> > It could be that they need to be backed-up before being expired, and
> > auto-backup may not be running against that SG (as an example of a
> > condition that could potentially give rise to what you are seeing).
> > Or another possibility is that they cant be backed up, because, for
> > example, they may have a null DSORG.  If they cant be backed-up, and the
> > management class says they must be backed up, then DFHSM will not expire
> > them until they are backed up.
> >
> > The above may not precisely match what you are experiencing, but it may
> > perhaps point you in a better direction.
> >
> > On 1 March 2018 at 16:18, Willie Bunter <
> > 001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> Thanks for the info., however it doesn't answer my question as to which
> >> threshold I should modify.
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Connor Krukosky is on the Main Webpage at www.ibm.com

[PINION, RICHARD W.]

Connor is famous!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Monday, March 05, 2018 3:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Connor Krukosky is on the Main Webpage at www.ibm.com

[External Email]

[Default] On 5 Mar 2018 11:46:12 -0800, in bit.listserv.ibm-main 
jesse1.robin...@sce.com (Jesse 1 Robinson) wrote:

>Marvel seems always to be on the lookout for a new superhero character...
>
I don't see it in Canada where IBM forces me to the ca-en page.

Clark Morris
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ?=== NEW
>robin...@sce.com
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Lizette Koehler
>Sent: Monday, March 05, 2018 5:41 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Connor Krukosky is on the Main Webpage at 
>www.ibm.com
>
>In case you are interested
>
>The 'mainframe kid' follows his passion  Connor Krukosky rebuilt an old 
>z890 in his basement - and became a tech legend
>
>
>Just in case you want to see the z890 or Connor
>
>
>
>Lizette Koehler
>statistics: A precise and logical method for stating a half-truth 
>inaccurately
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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

Re: Connor Krukosky is on the Main Webpage at www.ibm.com

[Charles Mills]

I can select the ca-en page from the US. A corollary might be that you could
select us-en from Canada. I just overtyped the URL.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Monday, March 5, 2018 12:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Connor Krukosky is on the Main Webpage at www.ibm.com

[Default] On 5 Mar 2018 11:46:12 -0800, in bit.listserv.ibm-main
jesse1.robin...@sce.com (Jesse 1 Robinson) wrote:

>Marvel seems always to be on the lookout for a new superhero character...
>
I don't see it in Canada where IBM forces me to the ca-en page.

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

Re: FDRMOVE sample jcl

[Pew, Curtis G]

On Mar 5, 2018, at 1:55 PM, Carmen Vitullo  wrote:
> 
> got ya, and I've never been at a site with DFSMSDSS DISABLED, bet disabling 
> would be quite interesting :) 

No, it’s quite boring, if you have the Innovation products. The only time I’ve 
noticed is when a vendor sent me an install that assumed I could use ADRDSSU. 
Previous installs had all used TSO TRANSMIT format, so I just got them to send 
me the new stuff that way too.

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: Connor Krukosky is on the Main Webpage at www.ibm.com

[Clark Morris]

[Default] On 5 Mar 2018 11:46:12 -0800, in bit.listserv.ibm-main
jesse1.robin...@sce.com (Jesse 1 Robinson) wrote:

>Marvel seems always to be on the lookout for a new superhero character...
>
I don't see it in Canada where IBM forces me to the ca-en page.

Clark Morris
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler 
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ?=== NEW
>robin...@sce.com
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Lizette Koehler
>Sent: Monday, March 05, 2018 5:41 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Connor Krukosky is on the Main Webpage at www.ibm.com
>
>In case you are interested
>
>The 'mainframe kid' follows his passion  Connor Krukosky rebuilt an old z890 
>in his basement - and became a tech legend
>
>
>Just in case you want to see the z890 or Connor
>
>
>
>Lizette Koehler
>statistics: A precise and logical method for stating a half-truth inaccurately
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: FDRMOVE sample jcl

[Carmen Vitullo]

got ya, and I've never been at a site with DFSMSDSS DISABLED, bet disabling 
would be quite interesting :) 


Carmen Vitullo 

- Original Message -

From: "RICHARD W. PINION"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, March 5, 2018 1:52:30 PM 
Subject: Re: FDRMOVE sample jcl 

I'm not necessarily disagreeing with you, but DSS has a separate entry in 
IFAPRDxx. I said, we're not paying for it. But we are until we can convert 
application level backups to use FDRAPPL. But, if what you say is true, then 
maybe applications can continue to use DSS. I'm not the person who keeps up 
with the contracts and licensing. 

PRODUCT OWNER('IBM CORP') 
NAME('z/OS') 
ID(5650-ZOS) 
VERSION(*) RELEASE(*) MOD(*) 
FEATURENAME(DFSMSDSS) 
STATE(ENABLED) 
PRODUCT OWNER('IBM CORP') 
NAME('z/OS') 
ID(5650-ZOS) 
VERSION(*) RELEASE(*) MOD(*) 
FEATURENAME(DFSMSHSM) 
STATE(DISABLED) 
PRODUCT OWNER('IBM CORP') 
NAME('z/OS') 
ID(5650-ZOS) 
VERSION(*) RELEASE(*) MOD(*) 
FEATURENAME(DFSMSRMM) 
STATE(ENABLED) 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Monday, March 05, 2018 2:46 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FDRMOVE sample jcl 

[External Email] 

HSM and RMM are other payable products/services under the DF/SMS service, but 
DF/DSS 'data set services' are not payable services or product, its part of the 
base or base + features. 



Carmen Vitullo 

- Original Message - 

From: "RICHARD W. PINION"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, March 5, 2018 1:34:50 PM 
Subject: Re: FDRMOVE sample jcl 

DF/DSS & HSM can be deleted from the list of IBM products, and thus not be 
charged for them. In our shop, we have FDR/ABR/CPK and pay for those, but we 
not do pay for DF/DSS & HSM. 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Monday, March 05, 2018 2:31 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FDRMOVE sample jcl 

[External Email] 

It BEEN a part of DPF for so many years, I don't order DFS services or ADRDSSU 
separately or get charged for these services. 
I know most folks, if they get use to using FDR they'd rather use FDR for some 
functions, I know you can copy/move using ADRDSSU and once you have some good 
JCL and control cards (I use ISMF to create some samples) its quite easy, but 
so is FDR if you're use to it. 



Carmen Vitullo 

- Original Message - 

From: "retired mainframer"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, March 5, 2018 1:22:12 PM 
Subject: Re: FDRMOVE sample jcl 

Doesn't ADRDSSU come with SMS automatically? Is it really a separately priced 
product? 

> -Original Message- 
> From: IBM Mainframe Discussion List  On 
> Behalf Of Clark Morris 
> Sent: Monday, March 05, 2018 10:39 AM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: FDRMOVE sample jcl 
> 
> [Default] On 5 Mar 2018 10:11:44 -0800, in bit.listserv.ibm-main 
> retired-mainfra...@q.com (retired mainframer) wrote: 
> 
> >Why must it be FDR? Won't ADRDSSU do it? 
> 
> Probably because the original poster has the Innovation products and 
> doesn't have the DSS/HSM products. 

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


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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer. 


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


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

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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua

Re: FDRMOVE sample jcl

[PINION, RICHARD W.]

I'm not necessarily disagreeing with you, but DSS has a separate entry in 
IFAPRDxx.  I said, we're not paying for it.  But we are until we can convert 
application level backups to use FDRAPPL.  But, if what you say is true, then 
maybe applications can continue to use DSS.  I'm not the person who keeps up 
with the contracts and licensing.

PRODUCT OWNER('IBM CORP')  
NAME('z/OS')   
ID(5650-ZOS)   
VERSION(*) RELEASE(*) MOD(*)   
FEATURENAME(DFSMSDSS)  
STATE(ENABLED) 
PRODUCT OWNER('IBM CORP')  
NAME('z/OS')   
ID(5650-ZOS)   
VERSION(*) RELEASE(*) MOD(*)   
FEATURENAME(DFSMSHSM)  
STATE(DISABLED)
PRODUCT OWNER('IBM CORP')  
NAME('z/OS')   
ID(5650-ZOS)   
VERSION(*) RELEASE(*) MOD(*)   
FEATURENAME(DFSMSRMM)  
STATE(ENABLED) 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Monday, March 05, 2018 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl

[External Email]

HSM and RMM are other payable products/services under the DF/SMS service, but 
DF/DSS 'data set services' are not payable services or product, its part of the 
base or base + features.



Carmen Vitullo

- Original Message -

From: "RICHARD W. PINION" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, March 5, 2018 1:34:50 PM
Subject: Re: FDRMOVE sample jcl

DF/DSS & HSM can be deleted from the list of IBM products, and thus not be 
charged for them. In our shop, we have FDR/ABR/CPK and pay for those, but we 
not do pay for DF/DSS & HSM.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Monday, March 05, 2018 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl

[External Email]

It BEEN a part of DPF for so many years, I don't order DFS services or ADRDSSU 
separately or get charged for these services.
I know most folks, if they get use to using FDR they'd rather use FDR for some 
functions, I know you can copy/move using ADRDSSU and once you have some good 
JCL and control cards (I use ISMF to create some samples) its quite easy, but 
so is FDR if you're use to it.



Carmen Vitullo

- Original Message -

From: "retired mainframer" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, March 5, 2018 1:22:12 PM
Subject: Re: FDRMOVE sample jcl

Doesn't ADRDSSU come with SMS automatically? Is it really a separately priced 
product?

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Clark Morris
> Sent: Monday, March 05, 2018 10:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FDRMOVE sample jcl
>
> [Default] On 5 Mar 2018 10:11:44 -0800, in bit.listserv.ibm-main 
> retired-mainfra...@q.com (retired mainframer) wrote:
>
> >Why must it be FDR? Won't ADRDSSU do it?
>
> Probably because the original poster has the Innovation products and 
> doesn't have the DSS/HSM products.

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


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

Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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


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

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

Re: Connor Krukosky is on the Main Webpage at www.ibm.com

[Jesse 1 Robinson]

Marvel seems always to be on the lookout for a new superhero character...

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, March 05, 2018 5:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Connor Krukosky is on the Main Webpage at www.ibm.com

In case you are interested

The 'mainframe kid' follows his passion  Connor Krukosky rebuilt an old z890 in 
his basement - and became a tech legend


Just in case you want to see the z890 or Connor



Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately


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

Re: FDRMOVE sample jcl

[Carmen Vitullo]

HSM and RMM are other payable products/services under the DF/SMS service, but 
DF/DSS 'data set services' are not payable services or product, its part of the 
base or base + 
features. 



Carmen Vitullo 

- Original Message -

From: "RICHARD W. PINION"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, March 5, 2018 1:34:50 PM 
Subject: Re: FDRMOVE sample jcl 

DF/DSS & HSM can be deleted from the list of IBM products, and thus not be 
charged for them. In our shop, we have FDR/ABR/CPK and pay for those, but we 
not do pay for DF/DSS & HSM. 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Monday, March 05, 2018 2:31 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FDRMOVE sample jcl 

[External Email] 

It BEEN a part of DPF for so many years, I don't order DFS services or ADRDSSU 
separately or get charged for these services. 
I know most folks, if they get use to using FDR they'd rather use FDR for some 
functions, I know you can copy/move using ADRDSSU and once you have some good 
JCL and control cards (I use ISMF to create some samples) its quite easy, but 
so is FDR if you're use to it. 



Carmen Vitullo 

- Original Message - 

From: "retired mainframer"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, March 5, 2018 1:22:12 PM 
Subject: Re: FDRMOVE sample jcl 

Doesn't ADRDSSU come with SMS automatically? Is it really a separately priced 
product? 

> -Original Message- 
> From: IBM Mainframe Discussion List  On 
> Behalf Of Clark Morris 
> Sent: Monday, March 05, 2018 10:39 AM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: FDRMOVE sample jcl 
> 
> [Default] On 5 Mar 2018 10:11:44 -0800, in bit.listserv.ibm-main 
> retired-mainfra...@q.com (retired mainframer) wrote: 
> 
> >Why must it be FDR? Won't ADRDSSU do it? 
> 
> Probably because the original poster has the Innovation products and 
> doesn't have the DSS/HSM products. 

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


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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer. 


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


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

Re: FDRMOVE sample jcl

[PINION, RICHARD W.]

DF/DSS & HSM can be deleted from the list of IBM products, and thus not be 
charged for them.  In our shop, we have FDR/ABR/CPK and pay for those, but we 
not do pay for DF/DSS & HSM.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Monday, March 05, 2018 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl

[External Email]

It BEEN a part of DPF for so many years, I don't order DFS services or ADRDSSU 
separately or get charged for these services.
I know most folks, if they get use to using FDR they'd rather use FDR for some 
functions, I know you can copy/move using ADRDSSU and once you have some good 
JCL and control cards (I use ISMF to create some samples) its quite easy, but 
so is FDR if you're use to it.



Carmen Vitullo

- Original Message -

From: "retired mainframer" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, March 5, 2018 1:22:12 PM
Subject: Re: FDRMOVE sample jcl

Doesn't ADRDSSU come with SMS automatically? Is it really a separately priced 
product?

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Clark Morris
> Sent: Monday, March 05, 2018 10:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FDRMOVE sample jcl
>
> [Default] On 5 Mar 2018 10:11:44 -0800, in bit.listserv.ibm-main 
> retired-mainfra...@q.com (retired mainframer) wrote:
>
> >Why must it be FDR? Won't ADRDSSU do it?
>
> Probably because the original poster has the Innovation products and 
> doesn't have the DSS/HSM products.

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


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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: FDRMOVE sample jcl

[Steve Beaver]

ADRDSSU is part of DF/DSS

FDR/PAS and FDR/Move are priced by terra byes you move

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of retired mainframer
Sent: Monday, March 5, 2018 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FDRMOVE sample jcl

Doesn't ADRDSSU come with SMS automatically?  Is it really a separately
priced product?

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Clark Morris
> Sent: Monday, March 05, 2018 10:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FDRMOVE sample jcl
> 
> [Default] On 5 Mar 2018 10:11:44 -0800, in bit.listserv.ibm-main 
> retired-mainfra...@q.com (retired mainframer) wrote:
> 
> >Why must it be FDR?  Won't ADRDSSU do it?
> 
> Probably because the original poster has the Innovation products and 
> doesn't have the DSS/HSM products.

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

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

Re: FDRMOVE sample jcl

[Carmen Vitullo]

It BEEN a part of DPF for so many years, I don't order DFS services or ADRDSSU 
separately or get charged for these services. 
I know most folks, if they get use to using FDR they'd rather use FDR for some 
functions, I know you can copy/move using ADRDSSU and once you have some good 
JCL and control cards (I use ISMF to create some samples) its quite easy, but 
so is FDR if you're use to it. 



Carmen Vitullo 

- Original Message -

From: "retired mainframer"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, March 5, 2018 1:22:12 PM 
Subject: Re: FDRMOVE sample jcl 

Doesn't ADRDSSU come with SMS automatically? Is it really a separately 
priced product? 

> -Original Message- 
> From: IBM Mainframe Discussion List  On Behalf 
> Of Clark Morris 
> Sent: Monday, March 05, 2018 10:39 AM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: FDRMOVE sample jcl 
> 
> [Default] On 5 Mar 2018 10:11:44 -0800, in bit.listserv.ibm-main 
> retired-mainfra...@q.com (retired mainframer) wrote: 
> 
> >Why must it be FDR? Won't ADRDSSU do it? 
> 
> Probably because the original poster has the Innovation products and 
> doesn't have the DSS/HSM products. 

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


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

Re: FDRMOVE sample jcl

[retired mainframer]

Doesn't ADRDSSU come with SMS automatically?  Is it really a separately
priced product?

> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Clark Morris
> Sent: Monday, March 05, 2018 10:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FDRMOVE sample jcl
> 
> [Default] On 5 Mar 2018 10:11:44 -0800, in bit.listserv.ibm-main
> retired-mainfra...@q.com (retired mainframer) wrote:
> 
> >Why must it be FDR?  Won't ADRDSSU do it?
> 
> Probably because the original poster has the Innovation products and
> doesn't have the DSS/HSM products.

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

Re: FDRMOVE sample jcl

[Clark Morris]

[Default] On 5 Mar 2018 10:11:44 -0800, in bit.listserv.ibm-main
retired-mainfra...@q.com (retired mainframer) wrote:

>Why must it be FDR?  Won't ADRDSSU do it?

Probably because the original poster has the Innovation products and
doesn't have the DSS/HSM products.

Clark Morris 
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf
>> Of Jake Anderson
>> Sent: Monday, March 05, 2018 5:38 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: FDRMOVE sample jcl
>> 
>> Hi
>> 
>> Does anyone have a sample JCL which does move a group of datasets from one
>> SMS class to another SMS class ? Does it takes care of VSAM dataset ?
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: FDRMOVE sample jcl

[Lizette Koehler]

I think with DFSMS DFDSS you need to use NULL SMS coding then let your SMS 
routines place it in the right places.

I think FDR may be more user friendly

And for DATACLAS, you need to Delete/ALLOC the file to get it



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> retired mainframer
> Sent: Monday, March 05, 2018 11:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FDRMOVE sample jcl
> 
> Why must it be FDR?  Won't ADRDSSU do it?
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Jake Anderson
> > Sent: Monday, March 05, 2018 5:38 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: FDRMOVE sample jcl
> >
> > Hi
> >
> > Does anyone have a sample JCL which does move a group of datasets from
> > one SMS class to another SMS class ? Does it takes care of VSAM dataset ?
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Feel free to reuse

[Mike Schwab]

Trying for light second number 2 next year?

On Mon, Mar 5, 2018 at 11:22 AM, Robert Prins  wrote:
> Hi all,
>
> Recently I got this (slightly edited) email:
>
>> I recently got into MVS/IBM z via [edited out], and was thinking of
>> writing about my progress. ~20 years of Unix is enough for anyone, I feel.
>>
>> Would it be OK to er... 'borrow' the CSS from
>> ? I'm leaning towards
> going with
>> an ISPF kind of look for the whole thing.
>
> My reply:
> ===
> Feel free to "borrow" the file @ 
> I've put a copyright notice on it, but have also slapped a GPL3 licence on
> it, like I've done with all of the REXX code that you can find on my z/OS
> page. If you want you can also copy the z/OS favicon  https://prino.neocities.org/images/zOS.png> (Watch the capitalisation!).
> Just give me a back-link.
>
> For what it's worth, a large part of the css file is commented out, as it
> has nothing to do with z/OS but everything with my hitchhiking <
> https://prino.neocities.org/indez.html> pages.
> ===
>
> If anyone else here wants to grab a copy, feel free to do so, and let's
> populate the internet with "3270" screens. ;)
>
> Robert
> --
> Robert AH Prins
> robert.ah.pr...@gmail.com
> Some programming  @ 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Product license key program

[Lester, Bob]

+1

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Boyes
Sent: Monday, March 5, 2018 11:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program [ EXTERNAL ]

>On 3/5/18, 12:53 PM, "IBM Mainframe Discussion List on behalf of Seymour J 
>Metz"  wrote:
 >[.snip.]

OK, this discussion has reached the level of diminishing returns. 

There seems to be a general agreement that the concept of keys is not the 
problem, but the execution of the keying process is. The desirable behavior is 
that the product run without a key for a reasonable transition period to permit 
updates, etc without making it into a critical situation while some other 
critical thing is happening. A nice thing that some vendors provide is an 
automated way to issue a temporary key, followed by a call from the vendor to 
the customer to check in on the use of the temporary key. 

Now, can we go back to the boring usual issues, like Charles originally 
requested several days ago?






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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


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

Re: SMS/HSM QUESTION

[Mike Schwab]

Set one volume to Quiesce,New and migrate the volume.  Whatever is
left try to manually migrate and note error.  Return to spare if you
don't need the space, or Enable to return to active use.  Proceed with
next volume.  Or just reduce high threshold so it will process all
volumes, return after cleanup.

On Mon, Mar 5, 2018 at 10:37 AM, willie bunter
<001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:
> I verified the MC and DSORGs.  No problem found.  No patches either which 
> would impede the PSM.  I remember reading or being told that once the SM 
> conditions had been met, HSM stops looking at the volume(s).
>
>   From: Graham Harris 
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Sent: Friday, March 2, 2018 6:05 PM
>  Subject: Re: SMS/HSM QUESTION
>
> Primary space management should normally process all volumes in a storage
> group. And PSM should normally look to reduce utilisation of a volume down
> to the low threshold (caveat - various PATCHes can alter DFHSM standard
> behaviour).
> Have you checked the messages for space management actions for these
> datasets?
> It could be that they need to be backed-up before being expired, and
> auto-backup may not be running against that SG (as an example of a
> condition that could potentially give rise to what you are seeing).
> Or another possibility is that they cant be backed up, because, for
> example, they may have a null DSORG.  If they cant be backed-up, and the
> management class says they must be backed up, then DFHSM will not expire
> them until they are backed up.
>
> The above may not precisely match what you are experiencing, but it may
> perhaps point you in a better direction.
>
> On 1 March 2018 at 16:18, Willie Bunter <
> 001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Thanks for the info., however it doesn't answer my question as to which
>> threshold I should modify.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Product license key program

[David Boyes]

>On 3/5/18, 12:53 PM, "IBM Mainframe Discussion List on behalf of Seymour J 
>Metz"  wrote:
 >[.snip.]

OK, this discussion has reached the level of diminishing returns. 

There seems to be a general agreement that the concept of keys is not the 
problem, but the execution of the keying process is. The desirable behavior is 
that the product run without a key for a reasonable transition period to permit 
updates, etc without making it into a critical situation while some other 
critical thing is happening. A nice thing that some vendors provide is an 
automated way to issue a temporary key, followed by a call from the vendor to 
the customer to check in on the use of the temporary key. 

Now, can we go back to the boring usual issues, like Charles originally 
requested several days ago?






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

Re: FDRMOVE sample jcl

[retired mainframer]

Why must it be FDR?  Won't ADRDSSU do it?

> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Jake Anderson
> Sent: Monday, March 05, 2018 5:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: FDRMOVE sample jcl
> 
> Hi
> 
> Does anyone have a sample JCL which does move a group of datasets from one
> SMS class to another SMS class ? Does it takes care of VSAM dataset ?

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

Re: Product license key program

[Seymour J Metz]

 1. Been There Done That, Got The Scars

 2.  Whether the vendors were bad or not is irrelevant; the keys were an
additional risk factor.

 3. The issue is risk, not assigning blame.

 4. And I asked you to stop putting words in my mouth.

 5. " than tell me that my promises are "worthless" solely because I'm a 
vendor."
There you go again. If you want me to be civil, then you have to be civil, 
and
that includes not attributing things to me that I didn't write.

 6. "but you must also take into account what the vendor has to be concerned 
with."
No, I don't. If the product doesn't suit my needs then I don't acquire it, 
regardless
of why the vendor made the decisions he made.

 7. " Also, we still don't know that you didn't get "what you paid for"."
Who is we? Those who read my posts instead of going into denial understood.
Which part of " the vendor failed to respond within the contractually  
guarantied time window."
didn't you understand?

 8. " If this were a test and you sent them the information and they sent you a 
bad key, so what?
 Just call them up and get it fixed. "
Why are you pretending to respond to what I wrote when you obviously 
weren't paying attention.
I told you; we did call, the contract required them to responded within a 
stipulated interval
and they didn't.

 9. "If you expected them to be 24x7 and they are not, is that their fault or 
yours?"
When the expectation is based on a contractual requirement that they be 
24x7,
whose fault do you think it is?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Brian Westerman 
Sent: Monday, March 5, 2018 3:02 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Product license key program

Hi Shmuel,

Sorry to be slow, I don't know what BTDT,GTS means.

Also, this discussion is supposed to be about keys and whether they are 
justified or bad or good or "whatever".  If you had a bad vendor, then whether 
or not they had keys in their software is almost irrelevant.  If the vendor 
screwed up in some way and it was 100% their fault, then shame on them, but you 
should not really blame keys for the rest of your life just because some vendor 
screwed up and didn't call you back in time.

If you have an agreement with a vendor to supply you with DR keys, and you did 
everything you were supposed to do, (i.e. you called them with the "correct" DR 
CPU info, and you notified them as soon as you could that the DR event 
started), then I would have to agree with you that it sounds like they screwed 
up badly if you were without keys for an extended period of time.  By extended 
I mean anything over 30 minutes.  If, on the other hand, you didn't have a good 
DR plan that included contacting your vendors (all of them, whether they have 
keys or not), then you plan is already flawed and any delays you experience are 
partly if not all your own fault.  You might be about to complain that no one 
knows of a disaster ahead of time and calling ahead of time for a DR test is 
not a "real" test of the plan, but you are wrong.  Part of a "good" DR plan is 
supposed to be stuff that you do all the time before the Disaster strikes, 
which is more than just running FDR every day.

I have been part to literally hundreds of DR tests and thankfully only a 
handful of actual disasters.  I was at a foreign country site one day when 
someone tossed a hand grenade into the command tent where the "datacenter" was 
located.  Let me tell you, getting vendors to call you back to the Middle East 
ain't easy, so you have to be sure you have have your DR plan ready to go.

You should have (somewhere in the DR "bible" book) all of the contact 
information for the vendor and someone is "supposed" to make sure it's tested 
periodically for validity, (vendors change offices and numbers too).  Also, if 
your vendor used to be 24x7 and now they aren't, it's your responsibility (as 
part of the DR plan) to know that.  The vendor might have sent out a email 
"blast" to tell you about it 6 months before, but everyone knows that no one 
reads the crap from a vendor so missing it is a possibility that should have 
been addressed int he DR plan.  If it wasn't, then that's also a flawed plan.

I'm not trying to say that your vendor didn't screw up royally.  I'm just 
saying that it's not logical to blame all vendors that use keys for something 
that one vendor did, which may not even be entirely their fault, and if you 
"should" have kept this from happening in your DR plan itself, then you need to 
accept at least part of the responsibility.

Now back to the numbered stuff:

1) Some vendor promises are indeed worthless, but then so are a lot of other 
people's promises (for instance, car salesmen), so why would you expect more or 
less from a vendor?  All promises are worthless if they cannot be relied upon.  
Having keys or not having keys

Fwd: Feel free to reuse

[Robert Prins]

Recently I got this (slightly edited) email:

> I recently got into MVS/IBM z via [edited out], and was thinking of
> writing about my progress. ~20 years of Unix is enough for anyone, I feel.
>
> Would it be OK to er... 'borrow' the CSS from
> ? I'm leaning towards
going with
> an ISPF kind of look for the whole thing.

My reply:
===
Feel free to "borrow" the file @ 
I've put a copyright notice on it, but have also slapped a GPL3 licence on
it, like I've done with all of the REXX code that you can find on my z/OS
page. If you want you can also copy the z/OS favicon https://prino.neocities.org/images/zOS.png> (Watch the capitalisation!).
Just give me a back-link.

For what it's worth, a large part of the css file is commented out, as it
has nothing to do with z/OS but everything with my hitchhiking <
https://prino.neocities.org/indez.html> pages.
===

If anyone else here wants to grab a copy, feel free to do so, and let's
populate the internet with "3270" screens. ;)

Robert
-- 
Robert AH Prins
robert.ah.pr...@gmail.com
Some programming  @ 

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

Feel free to reuse

[Robert Prins]

Hi all,

Recently I got this (slightly edited) email:

> I recently got into MVS/IBM z via [edited out], and was thinking of
> writing about my progress. ~20 years of Unix is enough for anyone, I feel.
>
> Would it be OK to er... 'borrow' the CSS from
> ? I'm leaning towards
going with
> an ISPF kind of look for the whole thing.

My reply:
===
Feel free to "borrow" the file @ 
I've put a copyright notice on it, but have also slapped a GPL3 licence on
it, like I've done with all of the REXX code that you can find on my z/OS
page. If you want you can also copy the z/OS favicon https://prino.neocities.org/images/zOS.png> (Watch the capitalisation!).
Just give me a back-link.

For what it's worth, a large part of the css file is commented out, as it
has nothing to do with z/OS but everything with my hitchhiking <
https://prino.neocities.org/indez.html> pages.
===

If anyone else here wants to grab a copy, feel free to do so, and let's
populate the internet with "3270" screens. ;)

Robert
-- 
Robert AH Prins
robert.ah.pr...@gmail.com
Some programming  @ 

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

Re: Product license key program

[Lester, Bob]

Hi Wayne,

 I have to disagree on Compuware products.  We have a bunch, and the 
License administration application works fine.  We just go into the panels, set 
DR mode, and we're good for 14 (?) days.   For us at least, it's a very 
workable solution for DR.

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Bickerdike
Sent: Sunday, March 4, 2018 1:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product license key program [ EXTERNAL ]

We always have issues during DR with licence keys.

Worst vendor is Compuware, convoluted process and activation procedure.

We like to expose "novice" users to the DR process, it's a test of 
documentation and process, not systems skills.

One vendor had the cheek to tell us to give more warning. I told them we are 
testing you as much as DR.

Don't mind CA, they don't disable just give warnings.

On Mon, Mar 5, 2018 at 6:55 AM, Seymour J Metz  wrote:

>  1. BTDT,GTS - I'm not talking ideology or abstract theory, but history.
> Vendor promises are worthless when push comes to shove.
>
>  2. In the incidents I was referring to we *did* get the keys in advance;
> they didn't work and the vendor failed to respond within the 
> contractually
> guarantied time window. That's why I asked about how you handled
> DR tests.
>
>  3. I'm not concerned with the customer who has delayed renewing, I'm
> concerned with the customer who is fully paid up and doesn't get 
> what he paid for.
>
>  4. "To indemnify for or from what exactly?" The cost of the DR 
> facilities that could be
> tested because of the bad keys would have been a start.
>
>  5. "what associated risk?  The risk that they will not pay their 
> license fee and therefore
>  lose the use of the software?"
>
> More straw dummies. Stop trying to put words in my mouth.
>
>  6. "you are assuming that the Key or the requirement thereof will 
> somehow, through the
>  fault of the "key", cause an outage. ".
>
> No, *you* are assuming that I don't have empirical evidence. See 
> item
> 2 above.
>
>  7. "4) What about it?  They paid for the key, it's implemented, and 
> it works."
> Were that true I wouldn't have commented. We paid for the keys, it 
> was implemented
> and it *didn't* work.
>
>  8. "and not a generation issue or some other purely human factor?"
> From the customer perspective the vendor is a black box; he doesn't
> care whether the outage cased by the vendor was due to hardware,
> software or human error.
>
>  9. "I don't think most vendors try to tell the client what metrics to 
> use in
>  evaluation (aside from CA maybe:))"
>
> CA never had the nerve to patronizingly dismiss our concerns. They 
> accepted
> them as legitimate and addressed them as best they could.
>
> 10. "6) What danger inherent in the enforcement method? "
> See item 2 above.
>
> 11. "The key works or it doesn't, if it doesn't, either it expired, the
> software has been altered or changed or it never worked in the 
> first place. "
> How do you propose that the customer tests whether a DR key works prior
> to going to the DR site and testing?
>
> 12. " I really don't mean to sound flippant, but sending software out 
> without keys
> would be similar (maybe only to me) as Ford sending out all of 
> their cars without
>  an ignition key or secure button. "
> Only to you; Ford doesn't try to lock its customer out of the car.
>
> Bottom line: keys are bad because historically they have caused 
> problems for legitimate users, often problems that the vendor had 
> promised wouldn't occur.
>
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Es
> metz3&d=DwIBaQ&c=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k&r=1KMMjoS
> vFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4&m=1l6hpNNXgTiCCpbDJWg8VLAjcwY3ccs
> 7JKJn3oF8I2A&s=Ap59KzoG5pNDC3N598NDZ-cKLXf4Aac-cJgMJiZzTDk&e=
>
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Brian Westerman 
> Sent: Saturday, March 3, 2018 1:22 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Product license key program
>
> Hi Shmuel,  this is just a friendly discussion, and I know I tend to 
> have a odd sense of humor sometimes, so please don't take any of what 
> I mean as levity as something personal.  I really am trying to 
> understand your point.  If you can convince me that there is some 
> inherent danger in using keys, then I will address the problem and see 
> about coming up with something that removes the danger but still 
> provides protection for the vendor.  Just because vendors have used 
> keys for years (and years) doesn't make it right, nor does it make it 
> wrong, that's why I'm trying to understand your side of this.  I  
> think I'm fairly smart, and if I had to come up with a substitute for 
> keys, I could probably do it, but I'm su

Re: SMS/HSM QUESTION

[willie bunter]

I verified the MC and DSORGs.  No problem found.  No patches either which would 
impede the PSM.  I remember reading or being told that once the SM conditions 
had been met, HSM stops looking at the volume(s).

  From: Graham Harris 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Friday, March 2, 2018 6:05 PM
 Subject: Re: SMS/HSM QUESTION
   
Primary space management should normally process all volumes in a storage
group. And PSM should normally look to reduce utilisation of a volume down
to the low threshold (caveat - various PATCHes can alter DFHSM standard
behaviour).
Have you checked the messages for space management actions for these
datasets?
It could be that they need to be backed-up before being expired, and
auto-backup may not be running against that SG (as an example of a
condition that could potentially give rise to what you are seeing).
Or another possibility is that they cant be backed up, because, for
example, they may have a null DSORG.  If they cant be backed-up, and the
management class says they must be backed up, then DFHSM will not expire
them until they are backed up.

The above may not precisely match what you are experiencing, but it may
perhaps point you in a better direction.

On 1 March 2018 at 16:18, Willie Bunter <
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:

> Thanks for the info., however it doesn't answer my question as to which
> threshold I should modify.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


   

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

Re: FDRMOVE sample jcl

[Carmen Vitullo]

this is some very old FDR move control cards 





//STEP1 EXEC PGM=FDRCOPY,REGION=5M 
//SYSPRINT DD SYSOUT=* 

//SYSIN DD * 
MOVE TYPE=DSF,MULTF=130,BYPASSACS 
SELECT DSG=DSE019,STORCLAS=SCBNE,MGMTCLAS=MCBNE 




this may be what you're looking for - some tweaking would be needed. 




Carmen Vitullo 

- Original Message -

From: "Jake Anderson"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, March 5, 2018 7:37:59 AM 
Subject: FDRMOVE sample jcl 

Hi 

Does anyone have a sample JCL which does move a group of datasets from one 
SMS class to another SMS class ? Does it takes care of VSAM dataset ? 

Jake 

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


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

Connor Krukosky is on the Main Webpage at www.ibm.com

[Lizette Koehler]

In case you are interested

The 'mainframe kid' follows his passion  Connor Krukosky rebuilt an old z890 in
his basement - and became a tech legend


Just in case you want to see the z890 or Connor



Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately

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

Re: Tape to tape copy jcl

[Gil Cardenas]

Attached is a copy of the routine.  It is documented within the script and 
fairly self-explanatory, nothing fancy.  I do have  some references to HSM 
commands because we were using HSM.  It is fairly old 11+ years so you may need 
to update to current TLMS standards...

Best Regards,
Gil.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
/* REXX */
/*  */
/* AUTHOR:   GILBERT CARDENAS   */
/* DATE: AUGUST 21,2006 */
/* PURPOSE:  TO BUILD THE JCL TO PERFORM A TAPE TO TAPE COPY*/
/* DESCRIPTION: */
/* 1. PERFORM A DN DSN= INQUIRY AGAINST TLMS TO */
/*RETRIEVE ALL THE DATASET DCB INFORMATION FOR OUTPUT FILE. */
/* 2. BUILD THE JCL WITH ALL THE APPROPRIATE INFORMATION*/
/*  */
/*  */
/* BEGIN TLMS INQUIRY LOGIC */
/*  */
/* TRACE I */
   ARG DATASET
 /* ECHO */
  /* SAY  "ARGS:"  DATASET DATE() TIME() MVSVAR('SYSNAME') */
   IF DATASET = '' THEN DO
  SAY '*** TAPECPY NEEDS 1 PARAMETER: TAPE DATASET NAME'
  SAY "*** EXAMPLE SYNTAX: 'TAPECPY TAPE.DATASET.G0001V00'"
  EXIT 8
  END

 /*NEWDSN = STRIP(DATASET,L,"'")  STRIP OFF LEADING QUOTE'  */
 /*NEWDSN = STRIP(DATASET,L,"'")  STRIP OFF LEADING QUOTE'  */
 NEWDSN = STRIP(DATASET,B,"'")   /*STRIP OFF LEADING&TRAILING QUOTES*/

 /*  SAY  "NEWDSN="  NEWDSN  */

 DSNLEN = LENGTH(NEWDSN) /* LENGTH OF THE DATASET NAME */
 STARTVER = DSNLEN-2 /* GET POINTER FOR START OF VERSION */
 CURGEN   = SUBSTR(NEWDSN,1,STARTVER) /*IDENTIFY CURRENT GENERATION */
 CURVER = SUBSTR(NEWDSN,(STARTVER+1),2)  /*IDENTIFY CURRENT VERSION */
 NEWVER = CURVER+01 /* CALCULATE NEXT VERION#*/
 NEWVER = RIGHT(NEWVER,2,'0')   /* FORMAT NEW VERSION NUMBER */
 OUTDSN = CURGEN||NEWVER/* BUILD OUTPUT DATASET NAME */
 /*  SAY  "OUTDSN="  OUTDSN */

  TRAPDS = USERID().TEMP.LIST
 IF SYSDSN("'"TRAPDS"'") = 'OK' THEN
 JUNK = MSG(OFF)
 DO
 "HDELETE  '"TRAPDS"'"   /* DELETE PREVIOUS WORK FILE IF MIGRATED */
 "DELETE  '"TRAPDS"'"/* DELETE PREVIOUS WORK FILE */
 JUNK = MSG(ON)
 END

 "ALLOC FILE(SYSPRINT) DATASET('"TRAPDS"') NEW CATALOG SPA(1,1) TR",
 "DSORG(PS) RECFM(F,B) LRECL(133) BLKSIZE(27930) REUSE"
 "ALLOC FILE(CAIVMF) DATASET('SAMPLE.TLMS.VMF') SHR REUSE"
 "ALLOC FILE(CAIVMFI) DATASET('SAMPLE.TLMS.VMF') SHR REUSE"
 "ALLOC FILE(CAIVMFS) DATASET('SAMPLE.TLMS.VMF') SHR",
 "OPTCD(C) BUFNO(10) REUSE"
 "ALLOC FILE(CAIRMF) DATASET('SAMPLE.TLMS.RMF') SHR REUSE"
 "ALLOC FILE(CAIVMFXI) DATASET('SAMPLE.TLMS.VMFINDEX') SHR REUSE"
 "ALLOC FILE(BKUP) DATASET('SAMPLE.TLMS.ALOG') SHR REUSE"
 "ALLOC FILE(SYSIN) SPACE(1,1) TRACK LRECL(80) RECFM(F,B) BLKSIZE(80)",
 "REUSE"

 TLMSCARD = "DN DSN="||NEWDSN
 PUSH TLMSCARD/* PUT COMMAND ON DATA STACK */
 'EXECIO 1 DISKW SYSIN (FINIS'   /*WRITE FROM DATA STACK TO FILE SYSIN*/
 ADDRESS TSO
 "CALL 'SAMPLE.TLMS.CAILIB(TLMSRPTS)'"
/*  */
/* FREE ALL INPUT DATASETS SINCE THEY ARE NOT NEEDED ANYMORE*/
/*  */
 "FREE F(SYSPRINT)"
 "FREE F(SYSIN)"
 "FREE F(CAIVMF)"
 "FREE F(CAIVMFI)"
 "FREE F(CAIVMFS)"
 "FREE F(CAIRMF)"
 "FREE F(CAIVMFXI)"
 "FREE F(BKUP)"
/*  */
/* END OF TLMS INQUIRY LOGIC*/
/*  */
/*  */
/* DEFINE THE OUTPUT DATASET AND THEN ALLOCATE INPUT FILE   */
/*  */
  JCLOUT = USERID().TAPECPY.JCL
 IF SYSDSN("'"JCLOUT"'") = 'OK' THEN
 JUNK = MSG(OFF)
 DO
 "HDELETE  '"JCLOUT"'"   /* DELETE PREVIOUS WORK FILE IF MIGRATED */
 "DELETE  '"JCLOUT"'"/* DELETE PREVIOUS WORK FILE */
 JUNK = MSG(ON)
 END

 "ALLOC FILE(INPUTFL) DATASET('"TRAPDS"') SHR REUSE"
 "ALLOC FILE(JCLOUT) DATASET('"JCLOUT"') NEW CATALOG SPA(1,1) TR",
 "DSORG(PS) RECFM(F,B) LRECL(80) BLKSIZE(27920) REUSE"

/* REXX /
/* THIS EXEC LOOPS THROUGH THE DATA SET ALLOCATED TO INPUTFL TO*/
/* FIND THE FIRST OCCURRENCE OF THE STRING "BLKSIZE". ONCE THE */
/* STRING BLKSIZE IS DETECTED, THE LINE IS PARSED INTO THE FOUR*/
/* VARIABLES BUT ONLY 3 WILL BE USED: BLKSIZE, LRECL, RECFM*/
/***/
DONE =

FDRMOVE sample jcl

[Jake Anderson]

Hi

Does anyone have a sample JCL which does move a group of datasets from one
SMS class to another SMS class ? Does it takes care of VSAM dataset ?

Jake

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

Re: Managing JESYSMSG size

[Greg Price]

On 2018-03-05 5:50 PM, Robin Atwood wrote:

Greg-
The SVC 99s are under my control and that is very useful to know!

Thanks
Robin



Robin,

Great!
:)
But I was slightly inaccurate.
:(

It is not in a text unit, it is in the RB proper - bit S99MSGL0 in byte 
S99FLG11.


In a batch program (HSIPINQ) which allocates lots of DDs, I use the flag 
in both the allocation and deallocation requests to reduce spooled 
output size, as well as the number of pages one has to scroll down to 
get to the start of the SYSPRINT report. (Sometimes this is being viewed 
outside SDSF where N 3 works well.)


The main purpose I like all those allocation and data set disposition 
messages in the general case is so that I can quickly see which data 
sets are allocated at the time of an abend, and can usually figure out 
which DDs are allocated to which data sets.


Naturally, the data sets disposed of after the abend are the ones which 
were allocated at the time of the abend.


Of course, sometimes customer flower boxes from their IEFACTRT routine 
can be helpful in this area too.


Anyway, in the SYSPRINT report line which reports the data sets as they 
are processed I now also display the DD name just in case it's needed.


IIRC, I went looking for this flag one day when trying to figure out how 
BPXWDYN can do allocations and deallocations without generating such 
messages. Given its component prefix, perhaps it was written with a view 
to operating in spawned address spaces which usually leave no spooled 
relic of their existence.


Cheers,
Greg

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

Re: Product license key program

[Brian Westerman]

Hi Shmuel,

Sorry to be slow, I don't know what BTDT,GTS means.  

Also, this discussion is supposed to be about keys and whether they are 
justified or bad or good or "whatever".  If you had a bad vendor, then whether 
or not they had keys in their software is almost irrelevant.  If the vendor 
screwed up in some way and it was 100% their fault, then shame on them, but you 
should not really blame keys for the rest of your life just because some vendor 
screwed up and didn't call you back in time.  

If you have an agreement with a vendor to supply you with DR keys, and you did 
everything you were supposed to do, (i.e. you called them with the "correct" DR 
CPU info, and you notified them as soon as you could that the DR event 
started), then I would have to agree with you that it sounds like they screwed 
up badly if you were without keys for an extended period of time.  By extended 
I mean anything over 30 minutes.  If, on the other hand, you didn't have a good 
DR plan that included contacting your vendors (all of them, whether they have 
keys or not), then you plan is already flawed and any delays you experience are 
partly if not all your own fault.  You might be about to complain that no one 
knows of a disaster ahead of time and calling ahead of time for a DR test is 
not a "real" test of the plan, but you are wrong.  Part of a "good" DR plan is 
supposed to be stuff that you do all the time before the Disaster strikes, 
which is more than just running FDR every day.  

I have been part to literally hundreds of DR tests and thankfully only a 
handful of actual disasters.  I was at a foreign country site one day when 
someone tossed a hand grenade into the command tent where the "datacenter" was 
located.  Let me tell you, getting vendors to call you back to the Middle East 
ain't easy, so you have to be sure you have have your DR plan ready to go.  

You should have (somewhere in the DR "bible" book) all of the contact 
information for the vendor and someone is "supposed" to make sure it's tested 
periodically for validity, (vendors change offices and numbers too).  Also, if 
your vendor used to be 24x7 and now they aren't, it's your responsibility (as 
part of the DR plan) to know that.  The vendor might have sent out a email 
"blast" to tell you about it 6 months before, but everyone knows that no one 
reads the crap from a vendor so missing it is a possibility that should have 
been addressed int he DR plan.  If it wasn't, then that's also a flawed plan.  

I'm not trying to say that your vendor didn't screw up royally.  I'm just 
saying that it's not logical to blame all vendors that use keys for something 
that one vendor did, which may not even be entirely their fault, and if you 
"should" have kept this from happening in your DR plan itself, then you need to 
accept at least part of the responsibility. 

Now back to the numbered stuff: 

1) Some vendor promises are indeed worthless, but then so are a lot of other 
people's promises (for instance, car salesmen), so why would you expect more or 
less from a vendor?  All promises are worthless if they cannot be relied upon.  
Having keys or not having keys is not going to make them a "better" or "worse" 
vendor.  I'm a vendor, and I like to think that if I give my word on something, 
it's more important than the contract.  

Your statement says that my promises are worthless, solely because I'm a 
vendor.  I'm also a systems programmer with almost certainly MUCH more 
experience than you, solely because of my training and the fact that I have 
worked in many more environments, and also perform contracts for most of the 
bigger vendors (IBM, CA, ASG, Sterling, Candle, and many, many others over the 
years) so I know most of their software quiet well.  I was trained by the best 
people in the world when it comes to IBM operating systems, IBM.  My teachers 
were some of the internal IBM developers in OS/VS1&2 and MVT and MVS.  I have 
worked for and with them in IBM development and later, Level2, for JES, IOS, 
HSM, SMS and several other areas, as well as having developed a lot of code 
that runs in every z/OS system that exists today.  I was, and still am, both an 
IBM business partner and internals developer.  I have met good vendors and bad 
vendors, I have met good people and bad people, I have met people with big guns 
who would sooner kill me and defecate on my remains and I have met people also 
with big guns in uniform (and out) who make sure that the other ones don't get 
me, but I would never make statements like you have about someone whom I have 
never even met and not feel very bad or very stupid for doing so.  

I asked you to be calm and civil and I am asking again, if you can't force 
yourself to do that, then just don't reply.  If you want to have a civil 
conversation about the good and bad of keys then I'm willing to do so.  If you 
want to rant and rave, then you have the wrong forum for that.  I believe 
that's what Facebook,