Re: [EXTERNAL] Vendor Licensing Frustrations

[Edward Gould]

> On Apr 24, 2017, at 10:07 AM, Dyck, Lionel B. (TRA)  
> wrote:
> —SNIP
> Lionel B. Dyck 

One of the things we did at DR was to run under VM and use the same serial 
numbers.
Hey it worked.
We were not cheating we were definitely doing DR.

Ed
> 
> 
> --
> 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: FTP Failing with space issues

[Paul Gilmartin]

On Mon, 24 Apr 2017 18:44:10 -0500, Bill Godfrey wrote:
>>>  
>>From "man ssh" (on Linux):
>>
>>NAME
>> ssh - OpenSSH SSH client (remote login program)
>>
>>SYNOPSIS
>> ssh [-options] [user@]hostname [command]
>>
>>DESCRIPTION
>> ...
>> If command is specified, it is executed on the remote host instead of a 
>> login shell.
>>
>>Note "instead of", providing a circumvention.
>>
>
>What actually happens is that the account's shell is executed with arguments 
>"-c" and the command text,
>which means the account's shell is not running as a "login shell".
>I'm speaking of Linux. I haven't worked with ssh/sshd on z/OS.
> 
Empirically, I confirm that.  The man page omits mentioning "the account's 
shell".

FILES
...
 ~/.ssh/rc
 Commands in this file are executed by ssh when the user logs in, 
just
 before the user's shell (or command) is started.  See the sshd(8) 
manual
 page for more information.

... so I tried:

546 $ grep wombat /etc/passwd
wombat:x:1001:1001:x,x,x,x,x:/home/wombat:/usr/lib/openssh/sftp-server
547 $ 
547 $ sudo ls -al ~wombat/.ssh
total 12
drwx-- 2 wombat wombat 4096 Apr 24 18:38 .
drwxr-xr-x 3 wombat wombat 4096 Apr 24 18:35 ..
-rwx-- 1 wombat wombat   29 Apr 24 18:43 rc
548 $ 
548 $ sudo cat ~wombat/.ssh/rc
/bin/id
/bin/uname
/bin/date

... I see no evidence that the commands in ~wombat/.ssh/rc were executed.
I can't tell exactly what happened.  Nor does the man page tell what processor
executes the commands in ~/.ssh/.rc "before the user's shell is started."  It
seems a contradiction to expect the user's shell to execute a script before it
is started.

-- gil

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

Re: KC Authentication failed

[Tom Conley]

On 4/24/2017 3:43 PM, Susan Shumway wrote:

Tom, are you still having trouble? I'm able to access
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.iea/iea.htm
and all Init Ref links on it. If you still can't, I'll try to
figure out why you're getting an authentication error for an open site...

Yours truly,
Sue Shumway



Sue,

Like so many intermittent outages with IBM Web based services like KC, 
SR, ShopZ, FTP, etc., it worked a few hours later.  You guys paid a high 
price for Google searchability.  Please don't ever get rid of the z/OS 
Internet Library with the links to the PDF's.  We'd be screwed without 
them when KC goes walkabout, which is all too often, based on the posts 
here.


Regards,
Tom Conley

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

Re: Vendor Licensing Frustrations

[Mike Schwab]

How about reaching an agreement with IBM.  When they get a SCRT report
that includes your product, they send you a copy.  Then when
contacting a site, the disclosure agreement to get the trial copy and
the final contract indicate that IBM will send you a copy of SCRT
results for billing purposes.  Base the monthly rate for current
utilization plus 5-10%.  Then when the review usage vs paid amount
comes in, you should be able to give them a credit for the lower
usage.

On Mon, Apr 24, 2017 at 8:59 AM, scott Ford  wrote:
> Timothy:
>
> What about theft of software products ? We all know it goes on ...
> How do you prevent it ?
>
> Scott
>
> On Mon, Apr 24, 2017 at 9:42 AM, Charles Mills  wrote:
>
>> Oh gee, let me try to respond to the most significant points here.
>>
>> > Charles Mills argues in defense of software product keys for mainframe
>> software.
>>
>> No, I argue in defense of vendors getting paid (so they can pay their
>> employees, their rent, their SHARE sponsorships, their IBM bills, ...).
>> Keys
>> are just a means to that end. I was asking you how SCRT provided a means to
>> that end. (As I suspected, you only defend it as a way of implementing MSU
>> pricing, not as a way of getting paid at all.) Speaking of things that
>> customers hate -- how about adding MSU pricing to the list, perhaps even
>> ahead of keys?
>>
>> > the scope for software product keys is substantially reduced?
>>
>> Not for vendors that do not MSU price.
>>
>> > you send your customer a bill for the difference up to the full machine
>> capacity
>>
>> Good luck getting paid.
>>
>> > you pursue available remedies. Including court remedies
>>
>> That's a winning customer relations strategy!
>>
>> > even if you still want to stick with them (misguidedly, in my personal
>> view)
>>
>> Misguided only if you neglect my other points.
>>
>> > if you're providing support and maintenance (and I hope you are), machine
>> serial number details are presumably available in dumps, traces, logs, etc.
>>
>> We get very few such problems. VERY few. I cannot tell my management that
>> that is to be our solution.
>>
>> > add machine serial numbers (where the product *might*
>> > run) to their product, up front, and in perpetuity
>>
>> Assuming they run that one box in perpetuity, which does not seem very
>> likely. Without even considering DR.
>>
>> > You put the "emergency" key(s) on a couple secured, cloud-hosted sites
>> (say, at IBM and Google)
>>
>> Agreed. Good solution. Takes a lot of work to get it right however.
>>
>> > Slightly function limit the trial version
>>
>> My management would NEVER agree to "sell" anything but the latest and
>> greatest. Hard to come up with a generalized subset that fully demonstrates
>> to non-technical management that we solve their particular problem/wish
>> list
>> but that is not "good enough" to use for months or years.
>>
>> > open download for everyone
>>
>> Including competitors? Does IBM do this for z/OS LOL?
>>
>> > Give me an idea of what your product does
>>
>> Not "mine," but here you go:
>> https://correlog.com/mainframe-security-solutions/sas-correlog-mainframe/
>>
>> > Send them a bill per the terms and conditions of your trial agreement
>> with
>> the customer
>>
>> Lots of luck!
>>
>> > forward it to collections
>>
>> And abandon ANY chance of ever actually getting the sale! That's the
>> problem
>> here. Remember, this is a prospect who is saying "we're going to buy your
>> product ... but my boss has been too busy to review your license." Easiest
>> solution is for the sales rep to be able to say "well, I can extend you
>> another ten days but that's absolutely it."
>>
>> Charles
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Timothy Sipples
>> Sent: Sunday, April 23, 2017 6:41 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Vendor Licensing Frustrations
>>
>> Charles Mills argues in defense of software product keys for mainframe
>> software.
>>
>> OK, let's pursue these arguments a bit. To start off, assuming IBM provides
>> what the z/OS 2.3 preview announcement describes, isn't it reasonable for
>> even the most "stodgy" vendor to concede that the scope for software
>> product
>> keys is substantially reduced? In particular, if your software product key
>> somehow limits runtime capacity on licensed/authorized machines, why? If
>> your customer has 100 MSUs licensed on machine serial number 12345 and
>> actually uses 110 MSUs, you send your customer a list price bill for the
>> additional 10 MSUs per your contractual agreement. If your customer doesn't
>> send a SCRT report for some month, you send your customer a bill for the
>> difference up to the full machine capacity, per your agreement. (If you
>> don't know the full machine capacity, and if your customer doesn't provide
>> reasonable evidence of the full machine capacity, then send a bill for the
>> 

Re: FTP Failing with space issues

[Bill Godfrey]

On Mon, 24 Apr 2017 16:36:29 -0600, Paul Gilmartin wrote:

>On 2017-04-24, at 16:17, Pew, Curtis G wrote:
>>> 
>>> sftp depends on ssh.  But ... is it possible to configure ssh so only the 
>>> sftp
>>> agent, not a shell, is allowed as an ssh agent on the server?
>> 
>> Yes, at least on Linux. We have a server where most of the accounts are 
>> specified with 'sftp-server' as the login shell, so authorized users can 
>> drop off or pick up files from those accounts, but cannot run any code.
>> 
>> I haven't tried this on z/OS.
>>  
>From "man ssh" (on Linux):
>
>NAME
> ssh - OpenSSH SSH client (remote login program)
>
>SYNOPSIS
> ssh [-options] [user@]hostname [command]
>
>DESCRIPTION
> ...
> If command is specified, it is executed on the remote host instead of a 
> login shell.
>
>Note "instead of", providing a circumvention.
>

What actually happens is that the account's shell is executed with arguments 
"-c" and the command text,
which means the account's shell is not running as a "login shell".
I'm speaking of Linux. I haven't worked with ssh/sshd on z/OS.

Bill

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

Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value

[Bill Woodger]

1. "This manual left intentionally blank". Try a DATASORT. If you have that, 
you probably have everything. 

2. Yes, symbols are great. SyncSORT doesn't call them symbols as such, I think 
they are "dictionary" or something like that.

I've been known to change Kolusu's inline comments to symbols...

There was mention of using WORD in Rexx to get the 10th word for something the 
other day.

//THIRDWRD EXEC PGM=SORT 
//SYSOUT   DD SYSOUT=* 
//SYMNAMES DD * 
THIRD-WORD,%01 
//SYMNOUNT DD SYSOUT=* 
//SORTOUT  DD SYSOUT=* 
//SYSINDD * 
 SORT FIELDS=COPY 
 INREC PARSE=(%=(ENDBEFR=BLANKS, 
 STARTAT=NONBLANK, 
 STARTAFT=BLANKS), 
  %=(ENDBEFR=BLANKS), 
  THIRD-WORD=(ENDBEFR=BLANKS, 
  FIXLEN=30)), 
   BUILD=(THIRD-WORD) 
//SORTIN   DD * 
 A120 B1230 C0 D12340 
E123450F1230  G120 H10 
  I0J0K0   L0 

Adapt by repeating the "%=(ENDBEFR=BLANKS)," an appropriate number of times, 
and change the symbol name (this is more the power of PARSE, than symbols, but 
I was reminded).

Also, it is very effective to generate a symbol-file in one step, and use the 
symbol-file in another step. It means, for instance, that you can have a 
modified value for INCLUDE/OMIT (like a formula to get a selection date), 
amongst other things.

Even for simply saving on the typos when using the same field for the sixth 
time... makes Sort Cards "self-documenting" :-)

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

Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value

[Bill Woodger]

If you don't need the physical file for anything except to extract from it, you 
can just establish a SEQNUM for each selection, and just use an OUTFIL (or 
more) with your selection by number. Saves the SORT, the creation of the new 
file, and the processing of the new file, just cutting straight to the chase, 
the extract(s) you want.

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

Re: FTP Failing with space issues

[Paul Gilmartin]

On 2017-04-24, at 16:17, Pew, Curtis G wrote:
>> 
>> sftp depends on ssh.  But ... is it possible to configure ssh so only the 
>> sftp
>> agent, not a shell, is allowed as an ssh agent on the server?
> 
> Yes, at least on Linux. We have a server where most of the accounts are 
> specified with ‘sftp-server’ as the login shell, so authorized users can drop 
> off or pick up files from those accounts, but cannot run any code.
> 
> I haven’t tried this on z/OS.
>  
From "man ssh" (on Linux):

NAME
 ssh — OpenSSH SSH client (remote login program)

SYNOPSIS
 ssh [-options] [user@]hostname [command]

DESCRIPTION
 ...
 If command is specified, it is executed on the remote host instead of a 
login shell.

Note "instead of", providing a circumvention.

And, on z/OS, the BPXWUNIX I mentioned earlier.

Just don't let "most of the accounts" access/alter critical resources.

-- gil

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

Re: FTP Failing with space issues

[Paul Gilmartin]

On 2017-04-24, at 12:20, Nims,Alva John (Al) wrote:
> 
> ... you have to write to zFS first and then you can do a "!cp / 
> //'CH2ICST.X.Y.R1'" (without the double quotes) to get it to MVS.
>  
Why bother with a copy.  Just leave it in zFS and adjust DD statements
in subsequent jobs as needed.

With regard to John M.'s concern of "untold damage", the perpetrator
can do nothing that couldn't be done by logging on to the z/OS account
and executing the command there.

If a security administrator has disabled shell on that z/OS account,
there remains the need to similarly disable BPXWUNIX.  Best just to
limit the capabilities of that z/OS account:  Protect the resources;
don't rely on locking tools.  That's how RACF works best.

-- gil

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

Re: Who Needs Spill/Overflow Pools anymore?

[Jesse 1 Robinson]

I guess that my SVCDUMP problem sort of triggered this threadlet. The main 
purpose for 'overflow' is when you have a 'proprietary' pool that is more or 
less dedicated to one business unit or function. In our case, SVCDUMPs need to 
be taken to a specific set of volumes so that our RYO dump management process 
can find and process them. Overflow appeared be a simple and convenient way to 
make sure that a vey large dump can be taken even though the designated 
pool cannot contain it. Unfortunately, OVERFLOW immediately sucked up all 
SVCDUMPs such that our RYO process never saw any of them. Worst possible 
'solution'. We're now looking at larger SVCDUMP volumes even though 99% of the 
time extra space is unnecessary.

In the application arena, we have some big-gun folks who have historically been 
blessed with their own pools just to make sure that they will always get what 
they need--when they need it. Probably long overdue for a revision in policy, 
but big guns fire big bullets. OVERFLOW seems to resolve the problem pretty 
well because that can service multiple proprietary groups, and those folks 
generally don't care much about volser.   

.
.
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 Cafiero, Tobias M.
Sent: Monday, April 24, 2017 1:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Who Needs Spill/Overflow Pools anymore?

Team, 
 I agree with the below. There is usually some Testing that doesn't get 
announced or unexpected work load. It's better have extra around, then 
explaining why you have x amount of TB's available, but Applications abended on 
space. 


Tobias Cafiero
Data Resource Management
Core Systems Technology
Lead System Architect
DTCC  New York
Office: 212-855-1117
E-mail: tcafi...@dtcc.com
Web: www.dtcc.com  on behalf of 
Lizette Koehler 
Sent: Monday, April 24, 2017 6:51:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Who Needs Spill/Overflow Pools anymore?

This is just a discussion topic (Thank you Skip for making me think about this
;-O)

In the past we needed to have them as we were tight on storage.

But today, is that still the case.  What is a good reason to either have or 
don't have SPILL/OVERFLOW pools when we can just add more storage to the pool.

I can add a MOD54 to a pool but that mod54 is not full until I use up all of 
the allotted storage to the MOD54 in the storage array.  So the storage array 
can be over provisioned until I need to go and get management to buy more 
physical storage.

Do I lose anything by having datasets "spill" over to a different pool that may 
not have the same protection as the one it is in?  HSM Backup, Dump, Cleanup 
processes?  Or are there other considerations.

Just asking a question or two.

So basically, why use SPILL/OVERFLOW when you can just add dasd, or do lots of 
migration?

We have the automation tool set up to monitor the pools and if they get too 
full, then start migration on the datasets in that pool.  No manual 
intervention required.



DFHSM and DFSMS do not think like humans when it comes to dataset management.
So there a need to out maneuver them to make datasets go where we want.




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

Re: FTP Failing with space issues

[Pew, Curtis G]

On Apr 24, 2017, at 5:05 PM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> sftp depends on ssh.  But ... is it possible to configure ssh so only the sftp
> agent, not a shell, is allowed as an ssh agent on the server?

Yes, at least on Linux. We have a server where most of the accounts are 
specified with ‘sftp-server’ as the login shell, so authorized users can drop 
off or pick up files from those accounts, but cannot run any code.

I haven’t tried this on z/OS.

-- 
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: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value

[Steve Smith]

Just some general suggestions that may be helpful:

1. ICETOOL has a number of commands that may make it easier to do what you
want.  It's worth getting familiar with it.  I've recently discovered that
SYNCTOOL handles my ICETOOL jobs just fine.  I've not seen a byte of doc on
SYNCTOOL, so there may be other options.

2. SORT symbols make almost all sorting (and ICETOOLing) much easier to
write, read, and maintain.  Symbol definitions are easy to create from
DSECTs, header files, etc. by anyone who has edit skillz (or scripting).
Again, SYNCSORT supports the same syntax as DFSORT as far as my tests go.

sas

On Mon, Apr 24, 2017 at 5:40 PM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> Thanks Bill, that put me on the right track.  Another regular poster also
> offered me some other options offline that might require fewer passes,
> which I am exploring.
>
> I will report back for the archives when I figure out what I am going to
> use.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Woodger
> Sent: Monday, April 24, 2017 3:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for
> changes in RESTART value
>
> Also, your initial BUILD creates the extra byte which is used. You can
> change the subsequent BUILDs to OVERLAY which just change the one byte at
> column 5: (will save you one BUILD per record, you'll notice).
>
> If 220k+ were really large, you could also (since the test values are
> mutually exclusive) put the header and trailer processing before the
> WHEN=NONE. That you may not notice on 220k+ records.
> --
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Re: FTP Failing with space issues

[Paul Gilmartin]

On Mon, 24 Apr 2017 13:34:09 -0500, John McKown wrote:
>
>​NO!
>
>You can NOT do a "!cp ..." to copy the file on the _server_ to a dataset on
>the _server_. That is because the "!..." sftp command runs the given
>command _ON THE CLIENT_ (i.e. your machine). Otherwise, some clever person
>could possibly do untold damage by running some arbitrary command that they
>just ftp'd to the server on the server. The thought makes me shudder.​
>
sftp depends on ssh.  But ... is it possible to configure ssh so only the sftp
agent, not a shell, is allowed as an ssh agent on the server?

Otherwise, there's the possibility of:

cat malicious.script | ssh z/OS "sh"  # to do untold damage.

Or, in fact:

ssh z/OS
put malicious.script .profile

... and wait for untold damage to happen.

-- gil

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

Re: Vendor Licensing Frustrations

[zMan]

So C- as in, "Not great but they would have passed"? Just clarifying...

On Mon, Apr 24, 2017 at 3:30 PM, Jesse 1 Robinson 
wrote:

> Some time ago I heard an interview on the efficacy of SOX in the real
> world of IT. The interviewee estimated--hypothetically and well after the
> fact--that Enron would likely have scored a C- in a full SOX audit. As I
> said, minimal protection achieved.
>
> .
> .
> 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 Anne & Lynn Wheeler
> Sent: Thursday, April 20, 2017 2:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Vendor Licensing Frustrations
>
> jesse1.robin...@sce.com (Jesse 1 Robinson) writes:
> > Unfortunately legislative bodies are dominated by lawyers, especially
> > in the U.S. Sarbanes-Oxley (SOX), Congress's blunderbuss response to
> > the Enron debacle, achieves maximum burden with minimal protection. A
> > classic case of lawyers meddling in IT.
>
> the rhetoric on flr of congress was that it would guarantee that
> executives and auditors went to jail (but it required SEC to do
> something) ... the joke was that congress felt so bad about accounting
> firm going under ... it was full employment gift to the audit industry.
>
> possibly even GAO didn't believe GAO was doing anything, it started doing
> reports of public company fraudulent financial filings ... even showing
> uptic/increase after SOX goes into effect (and nobody doing jailtime).
>
> After SOX goes into effect, there is EU conference of CEOs and exchange
> presidents in Liechtenstein about how SOX audit requirements were leaking
> into EU companies (that had contracts with US companies) ... and I'm asked
> to talk about how it wasn't really meaningful (as well as being able to
> program corporate computers to beat SOX audit).
>
> --
> virtualization experience starting Jan1968, online at home since Mar1970
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value

[Farley, Peter x23353]

Thanks Bill, that put me on the right track.  Another regular poster also 
offered me some other options offline that might require fewer passes, which I 
am exploring.

I will report back for the archives when I figure out what I am going to use.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Monday, April 24, 2017 3:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for 
changes in RESTART value

Also, your initial BUILD creates the extra byte which is used. You can change 
the subsequent BUILDs to OVERLAY which just change the one byte at column 5: 
(will save you one BUILD per record, you'll notice).

If 220k+ were really large, you could also (since the test values are mutually 
exclusive) put the header and trailer processing before the WHEN=NONE. That you 
may not notice on 220k+ records. 
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Who Needs Spill/Overflow Pools anymore?

[Cafiero, Tobias M.]

Team, 
 I agree with the below. There is usually some Testing that doesn't get 
announced or unexpected work load. It's better have extra around, then 
explaining why you have x amount of TB's available, but Applications abended on 
space. 


Tobias Cafiero
Data Resource Management
Core Systems Technology
Lead System Architect
DTCC  New York
Office: 212-855-1117
E-mail: tcafi...@dtcc.com
Web: www.dtcc.com From my experience, I try to over-provision many of the storagepools with a 
>certain amount, so that overflowing does not happen on a regular basis. And I 
>monitor/analyse the growth of these storagepools. (And act on adding more 
>'MOD54's' when needed).


I think it really depends on what is being stored aswell. Some data is not 
really eligible to be migrated if it's (for example) required for online 
processing. However, data that does not need to meet any criteria in terms of 
'response time' can easily be migrated to save DASD.


I was just wondering, are you using HSM ODM to migrate data?


Ronald Kristel
NL


From: IBM Mainframe Discussion List  on behalf of 
Lizette Koehler 
Sent: Monday, April 24, 2017 6:51:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Who Needs Spill/Overflow Pools anymore?

This is just a discussion topic (Thank you Skip for making me think about this
;-O)

In the past we needed to have them as we were tight on storage.

But today, is that still the case.  What is a good reason to either have or 
don't have SPILL/OVERFLOW pools when we can just add more storage to the pool.

I can add a MOD54 to a pool but that mod54 is not full until I use up all of 
the allotted storage to the MOD54 in the storage array.  So the storage array 
can be over provisioned until I need to go and get management to buy more 
physical storage.

Do I lose anything by having datasets "spill" over to a different pool that may 
not have the same protection as the one it is in?  HSM Backup, Dump, Cleanup 
processes?  Or are there other considerations.

Just asking a question or two.

So basically, why use SPILL/OVERFLOW when you can just add dasd, or do lots of 
migration?

We have the automation tool set up to monitor the pools and if they get too 
full, then start migration on the datasets in that pool.  No manual 
intervention required.



DFHSM and DFSMS do not think like humans when it comes to dataset management.
So there a need to out maneuver them to make datasets go where we want.




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
DTCC DISCLAIMER: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error, please notify us 
immediately and delete the email and any attachments from your system. The 
recipient should check this email and any attachments for the presence of 
viruses.  The company accepts no liability for any damage caused by any virus 
transmitted by this email.

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

Re: Who Needs Spill/Overflow Pools anymore?

[Lizette Koehler]

So - ODM has replaced the previous functions in HSM. 

However, there are some pools that are small on purpose (like DB2 Offload Log 
Pool).  The only time we have issues with it - someone decides they need to run 
an analyze on the last month of DB2 logs.  That can recall a lot of logs and 
fill up the pool very quickly.

Otherwise, we try to keep abour 25% free space in most pools.  We rarely run 
into overflow or Spill requirements.

Lizette


-Original Message-
>From: Ronald Kristel 
>Sent: Apr 24, 2017 12:43 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Who Needs Spill/Overflow Pools anymore?
>
>What about 'in case of emergencies?'.
>
>(I think) almost all our storagegroups are directed to one substantial big 
>overflow storagepool, _just_ for occurances where for whatever reason, 
>something starts to heavily use a specific storage pool.
>
>I agree, it's not very efficient to have a massive amount of disks spinning 
>without holding any data most of it's lifetime. However, this has classified 
>more favorable then facing a time period with space abends.
>
>
>From my experience, I try to over-provision many of the storagepools with a 
>certain amount, so that overflowing does not happen on a regular basis. And I 
>monitor/analyse the growth of these storagepools. (And act on adding more 
>'MOD54's' when needed).
>
>
>I think it really depends on what is being stored aswell. Some data is not 
>really eligible to be migrated if it's (for example) required for online 
>processing. However, data that does not need to meet any criteria in terms of 
>'response time' can easily be migrated to save DASD.
>
>
>I was just wondering, are you using HSM ODM to migrate data?
>
>
>Ronald Kristel
>NL
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Lizette Koehler 
>Sent: Monday, April 24, 2017 6:51:38 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Who Needs Spill/Overflow Pools anymore?
>
>This is just a discussion topic (Thank you Skip for making me think about this
>;-O)
>
>In the past we needed to have them as we were tight on storage.
>
>But today, is that still the case.  What is a good reason to either have or
>don't have SPILL/OVERFLOW pools when we can just add more storage to the pool.
>
>I can add a MOD54 to a pool but that mod54 is not full until I use up all of 
>the
>allotted storage to the MOD54 in the storage array.  So the storage array can 
>be
>over provisioned until I need to go and get management to buy more physical
>storage.
>
>Do I lose anything by having datasets "spill" over to a different pool that may
>not have the same protection as the one it is in?  HSM Backup, Dump, Cleanup
>processes?  Or are there other considerations.
>
>Just asking a question or two.
>
>So basically, why use SPILL/OVERFLOW when you can just add dasd, or do lots of
>migration?
>
>We have the automation tool set up to monitor the pools and if they get too
>full, then start migration on the datasets in that pool.  No manual 
>intervention
>required.
>
>
>
>DFHSM and DFSMS do not think like humans when it comes to dataset management.
>So there a need to out maneuver them to make datasets go where we want.
>
>
>
>
>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: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value

[Bill Woodger]

Also, your initial BUILD creates the extra byte which is used. You can change 
the subsequent BUILDs to OVERLAY which just change the one byte at column 5: 
(will save you one BUILD per record, you'll notice).

If 220k+ were really large, you could also (since the test values are mutually 
exclusive) put the header and trailer processing before the WHEN=NONE. That you 
may not notice on 220k+ records.

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

Re: SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value

[Bill Woodger]

It doesn't matter where you physically locate the SORT control card, SORT will 
execute after INREC.

You need to put anything which the SORT relies upon in INREC, and anything 
which relies upon the SORT in OUTREC.

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

Re: KC Authentication failed

[Susan Shumway]

Tom, are you still having trouble? I'm able to access 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.iea/iea.htm 
and all Init Ref links on it. If you still can't, I'll try to 
figure out why you're getting an authentication error for an open site...


Yours truly,
Sue Shumway

On 04/21/17 8:59 AM, Allan Staller wrote:

Refrain: The "new tools" are neither as reliable,  available or functional as 
their predecessors.

IBM should be embarrassed.


Trying to get the z/OS Init and Tuning Reference on the Interweb, and KC is 
throwing 403:  Authentication Failed messages.  To quote General
Beringer:  "After very careful consideration, sir, I've come to the conclusion that your 
new  sucks."  If that makes me a pig-eyed sack o' !@#$, then so be 
it.



::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




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



--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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

Re: Who Needs Spill/Overflow Pools anymore?

[Ronald Kristel]

What about 'in case of emergencies?'.

(I think) almost all our storagegroups are directed to one substantial big 
overflow storagepool, _just_ for occurances where for whatever reason, 
something starts to heavily use a specific storage pool.

I agree, it's not very efficient to have a massive amount of disks spinning 
without holding any data most of it's lifetime. However, this has classified 
more favorable then facing a time period with space abends.


>From my experience, I try to over-provision many of the storagepools with a 
>certain amount, so that overflowing does not happen on a regular basis. And I 
>monitor/analyse the growth of these storagepools. (And act on adding more 
>'MOD54's' when needed).


I think it really depends on what is being stored aswell. Some data is not 
really eligible to be migrated if it's (for example) required for online 
processing. However, data that does not need to meet any criteria in terms of 
'response time' can easily be migrated to save DASD.


I was just wondering, are you using HSM ODM to migrate data?


Ronald Kristel
NL


From: IBM Mainframe Discussion List  on behalf of 
Lizette Koehler 
Sent: Monday, April 24, 2017 6:51:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Who Needs Spill/Overflow Pools anymore?

This is just a discussion topic (Thank you Skip for making me think about this
;-O)

In the past we needed to have them as we were tight on storage.

But today, is that still the case.  What is a good reason to either have or
don't have SPILL/OVERFLOW pools when we can just add more storage to the pool.

I can add a MOD54 to a pool but that mod54 is not full until I use up all of the
allotted storage to the MOD54 in the storage array.  So the storage array can be
over provisioned until I need to go and get management to buy more physical
storage.

Do I lose anything by having datasets "spill" over to a different pool that may
not have the same protection as the one it is in?  HSM Backup, Dump, Cleanup
processes?  Or are there other considerations.

Just asking a question or two.

So basically, why use SPILL/OVERFLOW when you can just add dasd, or do lots of
migration?

We have the automation tool set up to monitor the pools and if they get too
full, then start migration on the datasets in that pool.  No manual intervention
required.



DFHSM and DFSMS do not think like humans when it comes to dataset management.
So there a need to out maneuver them to make datasets go where we want.




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: Vendor Licensing Frustrations

[Jesse 1 Robinson]

Some time ago I heard an interview on the efficacy of SOX in the real world of 
IT. The interviewee estimated--hypothetically and well after the fact--that 
Enron would likely have scored a C- in a full SOX audit. As I said, minimal 
protection achieved. 

.
.
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 Anne & Lynn Wheeler
Sent: Thursday, April 20, 2017 2:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Vendor Licensing Frustrations

jesse1.robin...@sce.com (Jesse 1 Robinson) writes:
> Unfortunately legislative bodies are dominated by lawyers, especially 
> in the U.S. Sarbanes-Oxley (SOX), Congress's blunderbuss response to 
> the Enron debacle, achieves maximum burden with minimal protection. A 
> classic case of lawyers meddling in IT.

the rhetoric on flr of congress was that it would guarantee that executives and 
auditors went to jail (but it required SEC to do
something) ... the joke was that congress felt so bad about accounting firm 
going under ... it was full employment gift to the audit industry.

possibly even GAO didn't believe GAO was doing anything, it started doing 
reports of public company fraudulent financial filings ... even showing 
uptic/increase after SOX goes into effect (and nobody doing jailtime).

After SOX goes into effect, there is EU conference of CEOs and exchange 
presidents in Liechtenstein about how SOX audit requirements were leaking into 
EU companies (that had contracts with US companies) ... and I'm asked to talk 
about how it wasn't really meaningful (as well as being able to program 
corporate computers to beat SOX audit).

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


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

Re: FTP Failing with space issues

[Nims,Alva John (Al)]

You are correct!

Al Nims
University of Florida

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Monday, April 24, 2017 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP Failing with space issues

On Mon, Apr 24, 2017 at 1:20 PM, Nims,Alva John (Al)  wrote:

> I agree with Walt, you are using sftp, which is a different beast that 
> ftp and as far as I know, yes I have not worked with sftp, just had to 
> do a cursory look at it recently, but have not gone down the road, 
> sftp does NOT support MVS data sets directly, it only works with zFS 
> (USS), so you have to write to zFS first and then you can do a "!cp 
> / //'CH2ICST.X.Y.R1'" (without the double quotes) to get it to MVS.
>

​NO!

You can NOT do a "!cp ..." to copy the file on the _server_ to a dataset on the 
_server_. That is because the "!..." sftp command runs the given command _ON 
THE CLIENT_ (i.e. your machine). Otherwise, some clever person could possibly 
do untold damage by running some arbitrary command that they just ftp'd to the 
server on the server. The thought makes me shudder.​



>
> Al Nims
> University of Florida
>
>

--
"Irrigation of the land with seawater desalinated by fusion power is ancient. 
It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

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

Who Needs Spill/Overflow Pools anymore?

[Lizette Koehler]

This is just a discussion topic (Thank you Skip for making me think about this
;-O)

In the past we needed to have them as we were tight on storage.

But today, is that still the case.  What is a good reason to either have or
don't have SPILL/OVERFLOW pools when we can just add more storage to the pool.  

I can add a MOD54 to a pool but that mod54 is not full until I use up all of the
allotted storage to the MOD54 in the storage array.  So the storage array can be
over provisioned until I need to go and get management to buy more physical
storage.

Do I lose anything by having datasets "spill" over to a different pool that may
not have the same protection as the one it is in?  HSM Backup, Dump, Cleanup
processes?  Or are there other considerations.

Just asking a question or two.

So basically, why use SPILL/OVERFLOW when you can just add dasd, or do lots of
migration? 

We have the automation tool set up to monitor the pools and if they get too
full, then start migration on the datasets in that pool.  No manual intervention
required.



DFHSM and DFSMS do not think like humans when it comes to dataset management.
So there a need to out maneuver them to make datasets go where we want.




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: FTP Failing with space issues

[John McKown]

On Mon, Apr 24, 2017 at 1:20 PM, Nims,Alva John (Al)  wrote:

> I agree with Walt, you are using sftp, which is a different beast that ftp
> and as far as I know, yes I have not worked with sftp, just had to do a
> cursory look at it recently, but have not gone down the road, sftp does NOT
> support MVS data sets directly, it only works with zFS (USS), so you have
> to write to zFS first and then you can do a "!cp /
> //'CH2ICST.X.Y.R1'" (without the double quotes) to get it to MVS.
>

​NO!

You can NOT do a "!cp ..." to copy the file on the _server_ to a dataset on
the _server_. That is because the "!..." sftp command runs the given
command _ON THE CLIENT_ (i.e. your machine). Otherwise, some clever person
could possibly do untold damage by running some arbitrary command that they
just ftp'd to the server on the server. The thought makes me shudder.​



>
> Al Nims
> University of Florida
>
>

-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

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

Re: FTP Failing with space issues

[Nims,Alva John (Al)]

I agree with Walt, you are using sftp, which is a different beast that ftp and 
as far as I know, yes I have not worked with sftp, just had to do a cursory 
look at it recently, but have not gone down the road, sftp does NOT support MVS 
data sets directly, it only works with zFS (USS), so you have to write to zFS 
first and then you can do a "!cp / //'CH2ICST.X.Y.R1'" (without the 
double quotes) to get it to MVS.

Al Nims
University of Florida

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Monday, April 24, 2017 10:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP Failing with space issues

On Mon, 24 Apr 2017 08:17:55 -0500, Ron Thomas  wrote:

>i executed the below script from Linux VM  and the below is what it says. 
>Looks like site command is not supported . So any idea on how this could be 
>resolved or is there any work around ?
>
>Script
>---
>sftp to1c...@cray.cps.se.com
><< EOF
>site blocksize=0 lrecl=3000 recfm=fb prim=25 sec=25 cyl put 
>/sap/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt 
>//'CH2ICST.X.Y.R1'
>quit
>EOF
>
>Log Message
>
>sftp> site blocksize=0 lrecl=3000 recfm=fb prim=25 sec=25 cyl
>Invalid command.
>sftp> put /sas/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt 
>//'CH2ICST.X.Y.R1'
>Uploading /sas/comtekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt to 
>//CH2ICST.X.Y.R1
>/sap/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt
>   68% 2208KB   1.8MB/s   
>00:00 ETA
>Couldn't write to remote file "//CH2ICST.X.Y.R1": Failure

You're not using ftp. You're using sftp, which is entirely different and not 
related to ftp at all.

--
Walt

--
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: DFHEXLI vs DFHECI

[Frank Swarbrick]

I don't think that EXCI is truly being used in this case.  Unless the program 
is compiled with the CICS('EXCI') option, or it calls the "callable" EXCI 
routine (DFHXCIS) directly, the fact that you have linked in the EXCI stubs 
doesn't seem to matter.


As for DFHECI, isn't that an older CICS stub for COBOL programs?  For COBOL 
CICS links we include DFHELII.  I don't know if there is any real difference, 
other than that DFHECI has a few entry point labels and DFHELII has "quite a 
few".


The fact is, if you don't have any explicit include of a CICS stub, and you 
have AUTOLINK on, you will end up automatically linking in DFHEAI (the 
"assembler" CICS stub).  This is because SDFHLOAD has declared DFHEI1 (the 
entry point called by a non-EXCI EXEC CICS) as an alias for DFHEAI.


It seems to me that as long as your COBOL program isn't some how attempting to 
invoke an entry point other than DFHEI1, it does not appear to matter which 
CICS stub is actually linked in to the program.


I'm sure there is more to it, but I don't know what.


Here are some binder output examples...


When linking in DFHXCSTB (note, does not have the DFHEI1 label):
0  DFHXCSTB   CSECT   2AA  SYSLIB14  DFHXCSTB
   00 DFHXCISLABEL
 1BC  1BC DFHXCIELABEL

When linking DFHELII (includes DFHEI1 label):
0  DFHELIICSECT28  SYSLIN02  DFHELII
   00 DFHEPINLABEL
   88 DFHEXECLABEL
   88 DFHEI1 LABEL
   88 DFHEPI LABEL
   88 DFHEI2 LABEL
  [...a lot more labels...]

When linking DFHECI (includes DFHEI1 label):
0  DFHECI CSECT20  SYSLIN02  DFHECI
   88 DFHEI1 LABEL
   88 DLZEI01LABEL
   88 DLZEI02LABEL
   88 DLZEI03LABEL
   88 DLZEI04LABEL

When autolinking (no explicit binder statement):
  480  DFHEAI  *  CSECT28  SYSLIB08  DFHEI1
   8  488 DFHEI1 LABEL


Frank


From: IBM Mainframe Discussion List  on behalf of 
Tony Thigpen 
Sent: Sunday, April 23, 2017 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHEXLI vs DFHECI

I can verify that it really is an online program. It is in CICS and the
programmer just recompiled it with a small change to verify it was
really the right compile. The change showed up and I looked at the
linkmap (which I included with the last email).

Tony Thigpen

esst...@juno.com wrote on 04/23/2017 12:50 PM:
> Hello Tony
>
> I'm a bit confused ...
> Are You Sure this is a program that runs as a CICS Transaction ?
> Can  You issue CEMT I PROG(x), or CEMT I TRANS(*) PROG() or  
> better yet issue a CECI LOAD PRPGRAM()
> .
> I suspect its a Batch Submitted program using EXCI to LINK To or Start a 
> transaction
> in a CICS Region.
>
>
> -- Original Message --
> From: Tony Thigpen 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHEXLI vs DFHECI
> Date: Sat, 22 Apr 2017 15:53:51 -0400
>
> I had a little time and looked at this closer. I am trying to determine
> what they are really doing and why.
>
> Here is the JCL that they use to compile:
>
> ... translate step
> ... cobol step with output going to
> //SYSLIN   DD DSN=&,DISP=(MOD,PASS),
> //UNIT=,SPACE=(80,(250,100))
> ... then
> //COPYLINK EXEC PGM=IEBGENER,COND=(7,LT,COB)
> //SYSUT1   DD DSN=(DFHEXLI),DISP=SHR
> //SYSUT2   DD DSN=&,DISP=(NEW,PASS),
> //DCB=(LRECL=80,BLKSIZE=400,RECFM=FB),
> //UNIT=,SPACE=(400,(20,20))
> //SYSPRINT DD SYSOUT=
> //SYSINDD DUMMY
> //*
> //LKED   EXEC PGM=IEWL,REGION=,
> //PARM='',COND=(5,LT,COB)
> //SYSLIB   DD DSN=,DISP=SHR
> // DD DSN=,DISP=SHR
> // DD DSN=,DISP=SHR
> // DD DSN=,DISP=SHR
> // DD DSN=,DISP=SHR
> // DD DSN=,DISP=SHR
> //SYSLMOD  DD DSN=.,DISP=SHR
> //SYSUT1   DD UNIT=,DCB=BLKSIZE=1024,
> //SPACE=(1024,(200,20))
> //SYSPRINT DD SYSOUT=
> //SYSLIN   DD DSN=&,DISP=(OLD,DELETE)
> // DD DSN=&,DISP=(OLD,DELETE)
> // DD DDNAME=SYSIN
>
> They run the compile using:
> /HBCC08  EXEC CICSCCLH,.
> //TRN.SYSIN DD *
> ./ INCLUDE HBCC08,LIB=PROD
> /*
> //LKED.SYSIN DD *
>   NAME HBCC08(R)
> /*
> //
>
> It seems that ..SDFHMAC(DFHEXLI) only contains one line:
> INCLUDE SYSLIB(DFHXCSTB)
>
> DFHXCSTB is in ..SDFHEXCI
>
> It appears that during the link stage, DFHEI1 is being pulled in
> automatically.
>
> BATCH EMULATOR  JOB(HBCC08  ) STEP(HBCC08  ) PGM= IEWL
> PROCEDURE(LKED)
> IEW2278I B352 INVOCATION 

SYNCSORT SEQNUM not restarting at 1 or incrementing by 1 for changes in RESTART value

[Farley, Peter x23353]

I am trying to partition a fairly large RECFM=VB dataset (220K+ records) by 
various characteristics of the records using a unique identifier byte and a 
SEQNUM.  The goal is to be able to subsequently extract in a second pass some 
"count" number of records by "type" to create an extracted sample file with a 
counted number of each type of record.  The original input is sequenced by a 
record key in bytes 1-136.

To start with I am partitioning the records by type, assigning a type 
identifier and a SEQNUM, but the problem is that the SEQNUM does not restart at 
1 for each unique identifier and does not consistently increment by 1 for each 
record of each type.

This is the SYSIN control input:

  SORT FIELDS=(5,147,CH,A)
  INREC IFTHEN=(WHEN=INIT,
BUILD=(1,4,5:C' ',
   6:SEQNUM,10,ZD,START=1,RESTART=(5,1),
   16:5)),
IFTHEN=(WHEN=(16,2,CH,EQ,X''),   HEADER RECORD (1 PER 
FILE)
BUILD=(1,4,5:C'A',6)),
IFTHEN=(WHEN=(16,2,CH,EQ,X''),   TRAILER RECORD (1 PER 
FILE)
BUILD=(1,4,5:C'Z',6)),
IFTHEN=(WHEN=(16,2,CH,EQ,C'D1',AND,  FIRST TYPE
  (1370,1,CH,EQ,C'Y',OR,
   1371,1,CH,EQ,C'Y')),
BUILD=(1,4,5:C'C',6)),
IFTHEN=(WHEN=(16,2,CH,EQ,C'D1',AND, SECOND TYPE (none of this 
type occur in the example input file)
  1604,2,CH,EQ,C'CD'),
BUILD=(1,4,5:C'D',6)),
IFTHEN=(WHEN=(16,2,CH,EQ,C'D1',AND, THIRD TYPE
  (1145,1,CH,EQ,C'2',OR,
   1145,1,CH,EQ,C'4')),
BUILD=(1,4,5:C'E',6)),
IFTHEN=(WHEN=NONE,  NOT ONE OF 
THE OTHER TYPES
BUILD=(1,4,5:C'B',6))

This control input results in output identifiers "A", "B" and "Z" each getting 
a SEQNUM starting at 1, but identifiers "C" and "E" (there are no "D" types in 
the example input file) each seem to start at numbers equal to their record 
number in the original dataset minus 1 (e.g., input record # 51 is the first 
type "C" record and gets SEQNUM 50).

Subsequent records of each type do not get "prior SEQNUM of unique type + 1" 
value, but again a SEQNUM equal to their record number in the original dataset 
minus 1 (e.g., third record of type "C" gets SEQNUM 52 but fourth record of 
type "C" gets SEQNUM 125).

What I want to see in the output is that all unique identifiers get a SEQNUM 
starting at 1 and incrementing by 1 for each record of that type.  Below are 
example outputs showing the SEQNUM values resulting from the above SORT control 
instructions.

Any help you can provide in generating the result I am aiming to produce is 
appreciated.

Peter

Example output results showing only identifier, SEQNUM and first 2 bytes of 
record:

A01..   (This is the header record)
B01D1
B02D1
. . .
B225201D1
C50D1 (First "C" record Is not SEQNUM 1)
C51D1
C52D1
C000125D1 (Fourth "C" record is not thired-record-SEQNUM + 
1)
C000126D1
. . .
C224188D1
E016714D1 (Same issue as for "C" records)
E016715D1
E016716D1
E016717D1
E016736D1 (Same issue as for "C" records)
E016737D1
. . .
E223279D1 (Same issue as for "C" records)
E223280D1
E224051D1 (Same issue as for "C" records)
E224052D1
Z01..(This is the trailer record)

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Vendor Licensing Frustrations

[Charles Mills]

Please allow me to add that I have been thinking about this problem space
for 25 years. I did not wake up one morning and say "what could I do today
to annoy mainframe customers?" I feel the customer pain. I have also felt
the pain of "how am I going to make payroll this week?"

I have been responsible for two significant mainframe products. Both came to
market without "keys." In both cases we added keys -- not because we had
nothing else to do -- but in response to specific market problems.

In the case of the current product, we had a customer -- a large shop, a
household name, everyone on this list would recognize the name in a
heartbeat -- license half a dozen LPARs and then run it on twenty -- and get
semi-belligerent when asked to come into compliance: "we thought we could
run it on all our LPARs." In their defense, the original mistake was
probably innocent: there were two layers of outsourcers and a lot of
management turnover. But frankly, it would have been easier for *everyone*
if the product had refused to run on the unlicensed LPARs from the get-go.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Monday, April 24, 2017 6:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Vendor Licensing Frustrations

Oh gee, let me try to respond to the most significant points here.

> Charles Mills argues in defense of software product keys for mainframe
software.

No, I argue in defense of vendors getting paid (so they can pay their
employees, their rent, their SHARE sponsorships, their IBM bills, ...). Keys
are just a means to that end. I was 

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

Re: RMM question

[Mike Wood]

Richard, Just chanced upon this question from you . and cant see any reply 
yet, so will try to answer it.

You cannot mix RETAINBY volume and RETAINBY set for VRS retention. However that 
does not really answer the question 
What rmm will do for a "set" of volumes depends on what is actually written to 
that set and how the files are retained.

If you have a single file written on a "set" - i.e. multi-volume data set. 
and that is VRS retained - rmm retains all the volumes in that set. 
If multiple files are written to a multi-volume set, how many are retained by 
VRS in that set depends on each individual data sets' VRS retention - if all 
files (data sets) are retained by VRS the set should be retained.

Mike (rmm - retired)

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

Re: FTP Failing with space issues

[Paul Gilmartin]

On Mon, 24 Apr 2017 09:45:02 -0500, Walt Farrell wrote:

>On Mon, 24 Apr 2017 08:17:55 -0500, Ron Thomas wrote:
>>
>>Script
>>---
>>sftp to1c...@cray.cps.se.com 
>><< EOF
>>site blocksize=0 lrecl=3000 recfm=fb prim=25 sec=25 cyl
>>put /sap/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt 
>>//'CH2ICST.X.Y.R1'
>>quit
>>EOF
>>
>>Log Message 
>>
>>sftp> site blocksize=0 lrecl=3000 recfm=fb prim=25 sec=25 cyl
>>Invalid command.
>>sftp> put /sas/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt 
>>//'CH2ICST.X.Y.R1'
>>Uploading /sas/comtekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt to 
>>//CH2ICST.X.Y.R1
>>/sap/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt   
>>68% 2208KB   1.8MB/s  
>> 00:00 ETA
>>Couldn't write to remote file "//CH2ICST.X.Y.R1": Failure
>
>You're not using ftp. You're using sftp, which is entirely different and not 
>related to ftp at all.
>
And sftp does not deal with Classic data sets; only with UNIX files, to which
BLKSIZE, LRECL, RECFM, PRIM, and SEC are irrelevant.

Unless you install the Dovetailed enhancements.
https://dovetail.com/products/sftp.html

But your source file is probably a stream-structured file for which
a z/OS UNIX file is a better match than a Classic data set.

-- gil

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

Re: [EXTERNAL] Re: Vendor Licensing Frustrations

[Dyck, Lionel B. (TRA)]

There has been some great discussion on this topic - I can only hope/pray that 
somehow change happens.

I've been working on DR planning for one of our locations and out of 15 non-IBM 
products, ONLY 3 will continue to operate without temp codes, and of those 3, 1 
expires after 2 days and the others after 7 days. For the 12 vendor products I 
have to contact 7 different vendors to get temporary DR license keys. 

The odds of all of them having fully staffed 24/7 support to immediately 
provide keys is a question.

The odds that they will let anyone on the DR team call to get keys is also a 
question - some will only talk to authorized/registered contacts. Something 
that is not always possible in a DR (as the contacts may have been impacted by 
the disaster).

At least 2 of the vendors allow us to put in our DR serial numbers at no 
additional charge which does help somewhat but only for 2 of the products.

A DR is stressful enough without having to go through the hassle of (a) contact 
the vendors for temporary license keys and (b) adding the license codes to the 
appropriate places in the correct way (is it a text file, do I need to update 
assembler code and assemble/link, is it smp/e, . . .).  And can any of this be 
done on the provisioning LPAR prior to IPL'ing the DR LPAR.  

It's time for some sanity in this arena.  Is SCRT the correct approach?  I 
don't know but it sounds pretty good to me after this exercise.

--
Lionel B. Dyck 


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

Re: Erase on Scratch

[Larre Shiller]

Ed -

Yes.

Larre

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

Re: FTP Failing with space issues

[Walt Farrell]

On Mon, 24 Apr 2017 08:17:55 -0500, Ron Thomas  wrote:

>i executed the below script from Linux VM  and the below is what it says. 
>Looks like site command is not supported . So any idea on how this could be 
>resolved or is there any work around ?
>
>Script
>---
>sftp to1c...@cray.cps.se.com 
><< EOF
>site blocksize=0 lrecl=3000 recfm=fb prim=25 sec=25 cyl
>put /sap/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt 
>//'CH2ICST.X.Y.R1'
>quit
>EOF
>
>Log Message 
>
>sftp> site blocksize=0 lrecl=3000 recfm=fb prim=25 sec=25 cyl
>Invalid command.
>sftp> put /sas/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt 
>//'CH2ICST.X.Y.R1'
>Uploading /sas/comtekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt to 
>//CH2ICST.X.Y.R1
>/sap/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt
>   68% 2208KB   1.8MB/s   
>00:00 ETA
>Couldn't write to remote file "//CH2ICST.X.Y.R1": Failure

You're not using ftp. You're using sftp, which is entirely different and not 
related to ftp at all.

-- 
Walt

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

Re: Vendor Licensing Frustrations

[Elardus Engelbrecht]

scott Ford wrote:

>What about theft of software products ? We all know it goes on ...
>How do you prevent it ?

Y, tell me. 

As a private programmer (moonlighting) years ago writing programs in Turbo 
Pascal, Clarion, Clipper, etc. on PCs in those good DOS days, it is pretty easy 
for them to steal my work forcing me to build in 'nagging' prompts, something 
like 'pay me in x days or this thing dies' (Not these exact but blunt words of 
course, but you get the idea. ;-p ) 

I do that twice, one for deposito pay and another for final pay, then all these 
nagging disappear forever after I gave them the passwords (not stored of 
course) upon payment. Tampering with BIOS date/time and filesystem timestamp 
immediately expire my products.

That was before shareware and open-source became the norm.

Back to IBM. Many years ago, we once enabled in IFAPRDxx the 'Toolkit Debugger 
and Dissambler' after telling IBM and in their presence, we want to see if we 
can use these goodies for IVP and for later formal activation. After testing we 
immediately disabled that.

We could of course not tell IBM, but there is a probability that IBM could do 
an audit, which they do now and them.

Groete / Greetings
Elardus Engelbrecht

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

Re: FTP Failing with space issues

[Lizette Koehler]

Have you talked to you

z/OS Sysprogs

Linux Sysprogs

Vtam/Comm Server Sysprogs

TCP/IP Sysprogs?

Your shop may have restrictions the list is not aware of - for example EXITS 
for FTP that impact the usage of common functions.

If you talk to them, you may be able to solve your problem faster.

Lizette




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ron Thomas
> Sent: Monday, April 24, 2017 7:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FTP Failing with space issues
> 
> with the modified one like "quote site blocksize=0 lrecl=3000 recfm=fb wrap
> prim=25 sec=25 cyl" it is showing the same error. Thanks!
> 
> 

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

Re: FTP Failing with space issues

[Ron Thomas]

with the modified one like "quote site blocksize=0 lrecl=3000 recfm=fb wrap 
prim=25 sec=25 cyl" it is showing the same error. Thanks!

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

Re: How to parse rows using SORT

[Bill Ashton]

Kolusu, thanks for the fix - I had not noticed this problem in my test
cases, but now believe I have a more accurate process. I appreciate your
time and attention! Have a magnificent Monday!

On Fri, Apr 21, 2017 at 5:51 PM, Sri h Kolusu  wrote:

> Bill,
>
> I apologize for the oversight in parsing the dataset name.  As soon as I
> sent my earlier reply I realized that I did not cover all the scenarios
> for the dataset name.  If the HLQ is less than 6 bytes the parse would
> grab the time which starts before the dataset name.
>
> for example the records in red color
>
> Dec 29 10:23 HOLDDATA.BIN
> Apr  3 12:28 REPORT1.TXT
> Nov 15 11:33 NEWDATA.BIN
> Nov 15 11:34 a.BIN
> Nov 15 11:35 abc.BIN
> Nov 15 11:36 abcd.BIN
> Nov 15 11:37 abcde.BIN
> Nov 15 11:38 abcdef.BIN
> Nov 15 11:39 abcdefg.BIN
> Nov 15 11:40 abcdefgh.BIN
>
> So you need to change your INREC IFTHEN statements to handle these dataset
> names.  Here are the updated control cards ( Only the INREC IFTHEN
> statments need to be changed.)
>
> INREC IFOUTLEN=80,
>   IFTHEN=(WHEN=(1,3,CH,EQ,C'250'),
>PARSE=(%01=(STARTAFT=C'"',ENDBEFR=C'"',FIXLEN=50)),
>BUILD=(C'250 ',%01)),
>
>   IFTHEN=(WHEN=(1,3,CH,EQ,C'EZA'),
>PARSE=(%=(ENDAT=C'.BIN'),
> %02=(SUBPOS=12,FIXLEN=12)),
>BUILD=(C'BIN ',%02),HIT=NEXT),
>
>   IFTHEN=(WHEN=(1,3,CH,EQ,C'BIN'),
>   OVERLAY=(5:5,12,JFY=(SHIFT=LEFT)),HIT=NEXT),
>
>   IFTHEN=(WHEN=(1,3,CH,EQ,C'BIN',AND,5,8,SS,EQ,C' '),
>PARSE=(%03=(ABSPOS=5,STARTAFT=C' ',ENDAT=C'.BIN',FIXLEN=12)),
> BUILD=(01:C'BIN ',56:%03)),
>
>   IFTHEN=(WHEN=(1,3,CH,EQ,C'BIN',AND,5,8,SS,NE,C' '),
> BUILD=(01:C'BIN ',56:5,12))
>
>
>
> Further if you have any questions please let me know
>
> Thanks,
> Kolusu
> DFSORT Development
>
>
>
> From:   Bill Ashton 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   04/21/2017 01:41 PM
> Subject:Re: How to parse rows using SORT
> Sent by:IBM Mainframe Discussion List 
>
>
>
> Thanks, Kolusu - that is better now! I will go and learn about HIT=NEXT,
> as
> I have not run into that before.
>
> Have a good weekend!
>
>
> On Fri, Apr 21, 2017 at 4:24 PM, Sri h Kolusu  wrote:
>
> > Bill,
> >
> > You really don't need to complicate the control to get the desired
> > results. I have optimized your control cards a bit which would give you
> > the desired results
> >
> > //SYSINDD *
> >   OPTION COPY
> >   INCLUDE COND=(1,003,CH,EQ,C'250',OR,
> > 1,100,SS,EQ,C'.BIN ')
> >
> >   INREC IFOUTLEN=80,
> > IFTHEN=(WHEN=(1,3,CH,EQ,C'250'),
> >  PARSE=(%01=(STARTAFT=C'"',ENDBEFR=C'"',FIXLEN=50)),
> >  BUILD=(C'250 ',%01)),
> >
> > IFTHEN=(WHEN=(1,3,CH,EQ,C'EZA'),
> >  PARSE=(%=(ENDAT=C'.BIN'),
> >   %02=(SUBPOS=12,FIXLEN=12)),
> >  BUILD=(C'BIN ',%02),HIT=NEXT),
> >
> > IFTHEN=(WHEN=(1,3,CH,EQ,C'BIN'),
> >  PARSE=(%03=(STARTAFT=C' ',ENDAT=C'.BIN',FIXLEN=12)),
> >   BUILD=(01:C'BIN ',56:%03))
> >
> >   OUTREC IFTHEN=(WHEN=GROUP,BEGIN=(1,3,CH,EQ,C'250'),PUSH=(05:5,50))
> >
> >   OUTFIL INCLUDE=(1,3,CH,EQ,C'BIN'),
> >   BUILD=(05,75,SQZ=(SHIFT=LEFT,LEAD=C'get  ',MID=C'/',
> > TRAIL=C' //DD:LIST',LENGTH=80))
> > //*
> >
> > The output from this job is
> >
> > get  /sys01/new2017/input/TESTFL1.BIN //DD:LIST
> > get  /sys12/y2017/processed/HOLDDATA.BIN //DD:LIST
> > get  /sys12/y2017/processed/NEWDATA.BIN //DD:LIST
> >
> >
> > Further if you have any questions please let me know
> >
> > Thanks,
> > Sri Hari Kolusu
> > DFSORT Development
> > IBM Corporation
> > Email: skol...@us.ibm.com
> > Phone: 520-799-2237 Tie Line: 321-2237
> >
> > IBM Mainframe Discussion List  wrote on
> > 04/21/2017 12:45:56 PM:
> >
> > > From: Bill Ashton 
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Date: 04/21/2017 12:46 PM
> > > Subject: Re: How to parse rows using SORT
> > > Sent by: IBM Mainframe Discussion List 
> > >
> > > Hi Kolusu, I think I messed up my original note by trying to keep the
> > > characters in order.
> > >
> > > I have attached a file that shows my JCL with input and output
> expected.
> > > The current run, though has a problem with the Parse for %02 and %03.
> I
> > > hope you can help me with this - it is probably simple.
> > >
> > > Thanks!
> > > B
> > >
> > > On Fri, Apr 21, 2017 at 2:05 PM, Sri h Kolusu 
> > wrote:
> > >
> > > > Bill,
> > > >
> > > > Why bother about the position. From the looks of it, you need to
> pick
> > the
> > > > last qualifier. So go find the last byte space and then subtract 12
> > bytes
> > > > to get to your dataset name.
> > > >
> > > > something like this
> > > >
> > > > //STEP0100 EXEC PGM=SORT
> > > > //SYSOUT   DD SYSOUT=*
> > > > //SORTIN   DD *
> > > >
> >
> 

Re: Vendor Licensing Frustrations

[scott Ford]

Timothy:

What about theft of software products ? We all know it goes on ...
How do you prevent it ?

Scott

On Mon, Apr 24, 2017 at 9:42 AM, Charles Mills  wrote:

> Oh gee, let me try to respond to the most significant points here.
>
> > Charles Mills argues in defense of software product keys for mainframe
> software.
>
> No, I argue in defense of vendors getting paid (so they can pay their
> employees, their rent, their SHARE sponsorships, their IBM bills, ...).
> Keys
> are just a means to that end. I was asking you how SCRT provided a means to
> that end. (As I suspected, you only defend it as a way of implementing MSU
> pricing, not as a way of getting paid at all.) Speaking of things that
> customers hate -- how about adding MSU pricing to the list, perhaps even
> ahead of keys?
>
> > the scope for software product keys is substantially reduced?
>
> Not for vendors that do not MSU price.
>
> > you send your customer a bill for the difference up to the full machine
> capacity
>
> Good luck getting paid.
>
> > you pursue available remedies. Including court remedies
>
> That's a winning customer relations strategy!
>
> > even if you still want to stick with them (misguidedly, in my personal
> view)
>
> Misguided only if you neglect my other points.
>
> > if you're providing support and maintenance (and I hope you are), machine
> serial number details are presumably available in dumps, traces, logs, etc.
>
> We get very few such problems. VERY few. I cannot tell my management that
> that is to be our solution.
>
> > add machine serial numbers (where the product *might*
> > run) to their product, up front, and in perpetuity
>
> Assuming they run that one box in perpetuity, which does not seem very
> likely. Without even considering DR.
>
> > You put the "emergency" key(s) on a couple secured, cloud-hosted sites
> (say, at IBM and Google)
>
> Agreed. Good solution. Takes a lot of work to get it right however.
>
> > Slightly function limit the trial version
>
> My management would NEVER agree to "sell" anything but the latest and
> greatest. Hard to come up with a generalized subset that fully demonstrates
> to non-technical management that we solve their particular problem/wish
> list
> but that is not "good enough" to use for months or years.
>
> > open download for everyone
>
> Including competitors? Does IBM do this for z/OS LOL?
>
> > Give me an idea of what your product does
>
> Not "mine," but here you go:
> https://correlog.com/mainframe-security-solutions/sas-correlog-mainframe/
>
> > Send them a bill per the terms and conditions of your trial agreement
> with
> the customer
>
> Lots of luck!
>
> > forward it to collections
>
> And abandon ANY chance of ever actually getting the sale! That's the
> problem
> here. Remember, this is a prospect who is saying "we're going to buy your
> product ... but my boss has been too busy to review your license." Easiest
> solution is for the sales rep to be able to say "well, I can extend you
> another ten days but that's absolutely it."
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Timothy Sipples
> Sent: Sunday, April 23, 2017 6:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Vendor Licensing Frustrations
>
> Charles Mills argues in defense of software product keys for mainframe
> software.
>
> OK, let's pursue these arguments a bit. To start off, assuming IBM provides
> what the z/OS 2.3 preview announcement describes, isn't it reasonable for
> even the most "stodgy" vendor to concede that the scope for software
> product
> keys is substantially reduced? In particular, if your software product key
> somehow limits runtime capacity on licensed/authorized machines, why? If
> your customer has 100 MSUs licensed on machine serial number 12345 and
> actually uses 110 MSUs, you send your customer a list price bill for the
> additional 10 MSUs per your contractual agreement. If your customer doesn't
> send a SCRT report for some month, you send your customer a bill for the
> difference up to the full machine capacity, per your agreement. (If you
> don't know the full machine capacity, and if your customer doesn't provide
> reasonable evidence of the full machine capacity, then send a bill for the
> difference between the largest available capacity IBM currently sells and
> the customer's licensed capacity.) If your customer doesn't pay the bill
> you
> think your customer is supposed to pay, then you pursue available remedies.
> Including court remedies if necessary. (Which need not cost anything
> out-of-pocket since lawyers and bill collectors in many countries operate
> on
> contingency, if/as you wish.)
>
> I hope we can all agree that adoption of SCRT -- assuming IBM delivers what
> it plans to deliver -- at least reduces the "problem space." And thus
> properly ought to reduce the burden, complexity, and scope of product keys,
> even if you still want 

Re: FTP Failing with space issues

[Wheeler, Simon]

Would the QUOTE command help in this instance, e.g. quote site

Regards,
Simon.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron Thomas
Sent: 24 April 2017 14:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP Failing with space issues

i executed the below script from Linux VM  and the below is what it says. Looks 
like site command is not supported . So any idea on how this could be resolved 
or is there any work around ?

Script
---
sftp to1c...@cray.cps.se.com
<< EOF
site blocksize=0 lrecl=3000 recfm=fb prim=25 sec=25 cyl put 
/sap/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt 
//'CH2ICST.X.Y.R1'
quit
EOF

Log Message

sftp> site blocksize=0 lrecl=3000 recfm=fb prim=25 sec=25 cyl
Invalid command.
sftp> put /sas/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt 
//'CH2ICST.X.Y.R1'
Uploading /sas/comtekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt to 
//CH2ICST.X.Y.R1
/sap/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt 
  68% 2208KB   1.8MB/s   
00:00 ETA
Couldn't write to remote file "//CH2ICST.X.Y.R1": Failure

Regards
Ron T

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

**
The information in this E-Mail is confidential and may be legally privileged. 
It may not represent the views of the SSE Group. 
It is intended solely for the addressees. Access to this E-Mail by anyone else 
is unauthorised. 
If you are not the intended recipient, any disclosure, copying, distribution or 
any action taken or omitted to be taken in reliance on it, is prohibited and 
may be unlawful.
Any unauthorised recipient should advise the sender immediately of the error in 
transmission. Unless specifically stated otherwise, this email (or any 
attachments to it) is not an offer capable of acceptance or acceptance of an 
offer and it does not form part of a binding contractual agreement.

SSE plc
Registered Office: Inveralmond House 200 Dunkeld Road Perth PH1 3AQ
Registered in Scotland No. SC117119
Authorised and regulated by the Financial Conduct Authority for certain 
consumer credit activities.
www.sse.com

**


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

Re: Erase on Scratch

[Edward Gould]

Larre:

Are you currently running 2.2 on all your production machines?

Ed
> On Apr 24, 2017, at 4:57 AM, Larre Shiller 
> <0102cb4997b0-dmarc-requ...@listserv.ua.edu> wrote:
> 
> I have been involved in a number of offline discussions as well as multiple 
> IBM PMRs and problem records with our DASD hardware vendor concerning EOS and 
> although this is potentially a most useful function, the overhead involved is 
> not zero--there will always be *some* amount of overhead involved in 
> re-writing every bit of a data set, no matter how much improvement IBM has 
> made to the function at the OS level (such as the 95+% reduction in EXCP's 
> since the initial implementation of EOS).  During our testing, we find that 
> it takes an additional 1 hour of processing time for every 500G of data in 
> order to use EOS.  If you have a tight batch window or any kind of 
> time-sensitive processing, you should make sure that you can afford to use 
> EOS before simply activating it for every data set in your enterprise.  Since 
> this is a security-related function, I will not comment publicly 
> if/when/where we do or do not use it, but I will simply recommend that you 
> perform a benchmark evaluation of the overhead involved on your hardware 
> before activating EOS.
> 
> Larre Shiller
> US Social Security Administration
> 
> "The opinions expressed in this message are mine personally and do not 
> necessarily reflect the opinion of the US Social Security Administration 
> and/or the US Government."
> 
> --
> 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: Vendor Licensing Frustrations

[Charles Mills]

Oh gee, let me try to respond to the most significant points here.

> Charles Mills argues in defense of software product keys for mainframe
software.

No, I argue in defense of vendors getting paid (so they can pay their
employees, their rent, their SHARE sponsorships, their IBM bills, ...). Keys
are just a means to that end. I was asking you how SCRT provided a means to
that end. (As I suspected, you only defend it as a way of implementing MSU
pricing, not as a way of getting paid at all.) Speaking of things that
customers hate -- how about adding MSU pricing to the list, perhaps even
ahead of keys?

> the scope for software product keys is substantially reduced?

Not for vendors that do not MSU price.

> you send your customer a bill for the difference up to the full machine
capacity

Good luck getting paid.

> you pursue available remedies. Including court remedies

That's a winning customer relations strategy!

> even if you still want to stick with them (misguidedly, in my personal
view)

Misguided only if you neglect my other points.

> if you're providing support and maintenance (and I hope you are), machine
serial number details are presumably available in dumps, traces, logs, etc.

We get very few such problems. VERY few. I cannot tell my management that
that is to be our solution.

> add machine serial numbers (where the product *might*
> run) to their product, up front, and in perpetuity

Assuming they run that one box in perpetuity, which does not seem very
likely. Without even considering DR.

> You put the "emergency" key(s) on a couple secured, cloud-hosted sites
(say, at IBM and Google)

Agreed. Good solution. Takes a lot of work to get it right however.

> Slightly function limit the trial version

My management would NEVER agree to "sell" anything but the latest and
greatest. Hard to come up with a generalized subset that fully demonstrates
to non-technical management that we solve their particular problem/wish list
but that is not "good enough" to use for months or years.

> open download for everyone

Including competitors? Does IBM do this for z/OS LOL?

> Give me an idea of what your product does

Not "mine," but here you go:
https://correlog.com/mainframe-security-solutions/sas-correlog-mainframe/ 

> Send them a bill per the terms and conditions of your trial agreement with
the customer

Lots of luck!

> forward it to collections

And abandon ANY chance of ever actually getting the sale! That's the problem
here. Remember, this is a prospect who is saying "we're going to buy your
product ... but my boss has been too busy to review your license." Easiest
solution is for the sales rep to be able to say "well, I can extend you
another ten days but that's absolutely it."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Timothy Sipples
Sent: Sunday, April 23, 2017 6:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Vendor Licensing Frustrations

Charles Mills argues in defense of software product keys for mainframe
software.

OK, let's pursue these arguments a bit. To start off, assuming IBM provides
what the z/OS 2.3 preview announcement describes, isn't it reasonable for
even the most "stodgy" vendor to concede that the scope for software product
keys is substantially reduced? In particular, if your software product key
somehow limits runtime capacity on licensed/authorized machines, why? If
your customer has 100 MSUs licensed on machine serial number 12345 and
actually uses 110 MSUs, you send your customer a list price bill for the
additional 10 MSUs per your contractual agreement. If your customer doesn't
send a SCRT report for some month, you send your customer a bill for the
difference up to the full machine capacity, per your agreement. (If you
don't know the full machine capacity, and if your customer doesn't provide
reasonable evidence of the full machine capacity, then send a bill for the
difference between the largest available capacity IBM currently sells and
the customer's licensed capacity.) If your customer doesn't pay the bill you
think your customer is supposed to pay, then you pursue available remedies.
Including court remedies if necessary. (Which need not cost anything
out-of-pocket since lawyers and bill collectors in many countries operate on
contingency, if/as you wish.)

I hope we can all agree that adoption of SCRT -- assuming IBM delivers what
it plans to deliver -- at least reduces the "problem space." And thus
properly ought to reduce the burden, complexity, and scope of product keys,
even if you still want to stick with them (misguidedly, in my personal
view).

Also, customers understandably might ask, "If it's good enough for IBM and
other vendors (SCRT, no product keys), why isn't it good enough for you?"
Think carefully before you answer. :-) Customers aren't often stupid.
They're going to assign penalty marks to products with keys. Keys increase
their risks and operational costs, and 

Re: FTP Failing with space issues

[Ron Thomas]

i executed the below script from Linux VM  and the below is what it says. Looks 
like site command is not supported . So any idea on how this could be resolved 
or is there any work around ?

Script
---
sftp to1c...@cray.cps.se.com 
<< EOF
site blocksize=0 lrecl=3000 recfm=fb prim=25 sec=25 cyl
put /sap/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt 
//'CH2ICST.X.Y.R1'
quit
EOF

Log Message 

sftp> site blocksize=0 lrecl=3000 recfm=fb prim=25 sec=25 cyl
Invalid command.
sftp> put /sas/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt 
//'CH2ICST.X.Y.R1'
Uploading /sas/comtekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt to 
//CH2ICST.X.Y.R1
/sap/co2ekh/backup/global_chgback_escoa_2017-01-22:22:00:10.txt 
  68% 2208KB   1.8MB/s   
00:00 ETA
Couldn't write to remote file "//CH2ICST.X.Y.R1": Failure

Regards
Ron T

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

Re: SMS STORGRP question

[Cafiero, Tobias M.]

Hello,
  Why not use Spill volumes. Create a STOrGRPP called SGSPILL put it under your 
 Dump volumes enable it to spill and problem solved.


Tobias Cafiero
Data Resource Management
Core Systems Technology
Lead System Architect
DTCC  New York
Office: 212-855-1117
E-mail: tcafi...@dtcc.com
Web: www.dtcc.com  -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jesse 1 Robinson
> Sent: 22 April, 2017 2:43
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMS STORGRP question
> 
> 'Forever' we have directed DUMPSRV SVC dumps via ACS routine to 
> STORGRP 'SVCDUMP', which is defined to a small set of volumes called 
> SVCDxx. We had a (major) problem a while back when DB2/CICS wanted to 
> take a humongous dump that exceeded the available capacity of of the 
> SVCDxx volumes. So we *added* group 'OVERFLOW' to the ACS routine 
> expecting this much larger group to accommodate dumps that SVCDUMP 
> could not handle. Much to our chagrin, from that moment forward, *all* 
> SVCDUMPs went directly to OVERFLOW without even trying to find space 
> in group SVCDUMP. We have an RYO mechanism to manage dumps created on 
> volume SVCDxx, so dumps created elsewhere are a problem we can live 
> with on occasion but not regularly.
> 
> I know there are various ways to resolve to this problem, but I want 
> to know why SMS is behaving this way and whether there is a purely SMS
> solution: try SVCDUMP first; if no room, then try OVERFLOW. In that 
> order.
> 
> .
> .
> 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
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DTCC DISCLAIMER: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error, please notify us 
immediately and delete the email and any attachments from your system. The 
recipient should check this email and any attachments for the presence of 
viruses.  The company accepts no liability for any damage caused by any virus 
transmitted by this email.

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

Re: SETRP with DUMP=YES

[Greg Dyck]

On 4/22/2017 10:24 AM, esst...@juno.com wrote:

Can I issue a SETRP DUMP=YES without other parameters.
.
Meaning I don't want to specify a retry routine nor do I want to specify a 
return code.
I simply want to issue SETRP DUMP=YES and return to the next sequential 
instruction following
the SETRP.


Most certainly you can.  SETRP DUMP=YES/NO simply sets/resets bit 
SDWAREQ in the SDWA for later use by RTM2.


Regards,
Greg

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

Re: SETRP with DUMP=YES

[Peter Relson]

The "abend dump" (SYSABEND, SYSUDUMP, SYSMDUMP depending on JCL) that is 
the subject of the DUMP=YES/DUMP=NO option of SETRP is initiated by RTM 
prior to retry, after the recovery routine returns. Recovery routines that 
want an SVC Dump must initiate that themselves.

Peter Relson
z/OS Core Technology Design


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

Re: Erase on Scratch

[Larre Shiller]

I have been involved in a number of offline discussions as well as multiple IBM 
PMRs and problem records with our DASD hardware vendor concerning EOS and 
although this is potentially a most useful function, the overhead involved is 
not zero--there will always be *some* amount of overhead involved in re-writing 
every bit of a data set, no matter how much improvement IBM has made to the 
function at the OS level (such as the 95+% reduction in EXCP's since the 
initial implementation of EOS).  During our testing, we find that it takes an 
additional 1 hour of processing time for every 500G of data in order to use 
EOS.  If you have a tight batch window or any kind of time-sensitive 
processing, you should make sure that you can afford to use EOS before simply 
activating it for every data set in your enterprise.  Since this is a 
security-related function, I will not comment publicly if/when/where we do or 
do not use it, but I will simply recommend that you perform a benchmark 
evaluation of the overhead involved on your hardware before activating EOS.

Larre Shiller
US Social Security Administration

"The opinions expressed in this message are mine personally and do not 
necessarily reflect the opinion of the US Social Security Administration and/or 
the US Government."

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

Re: SETRP with DUMP=YES

[Binyamin Dissen]

What do you expect DUMP=YES to do for you?

On Sun, 23 Apr 2017 16:32:45 GMT "esst...@juno.com"  wrote:

:>Thank You Peter and Charles for refreshing my memory.
:>If I issue several SETRP macros in a recovery routine,
:>and one of the SETRPs specifies DUMP=YES, I suspect 
:>the dump is taken when the Recovery Routine ends and
:>before The Retry Routine receives control.
:>.
:>.
:>Is My Assesment correct  ?
:>.
:>
:>Paul 
:>
:>-- Original Message --
:>From: Peter Relson 
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: SETRP with DUMP=YES
:>Date: Sun, 23 Apr 2017 08:28:49 -0400
:>
:>SETRP, IIRC, always "returns to the next sequential instruction" unless 
:>you specify the REGS parameter.
:>
:>One thing that I think you can't do is to set the "DUMP = Yes" option (or 
:>any other option for that matter) without also setting the "return code", 
:>as all the expansions set that, and the return code setting defaults to 
:>"continue with termination" (i.e., percolate). Thus it is often a good 
:>idea to set all the options (in one or more invocations) and then request 
:>retry last, to avoid resetting the return code from "retry" to 
:>"percolate".
:>
:>Peter Relson
:>z/OS Core Technology Design

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: SMS STORGRP question

[Vernooij, Kees (ITOPT1) - KLM]

You should implement TIERING. SMS first fills the first mentioned SG and only 
if it has not enough space, SMS will go to the second SG.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: 22 April, 2017 2:43
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMS STORGRP question
> 
> 'Forever' we have directed DUMPSRV SVC dumps via ACS routine to STORGRP
> 'SVCDUMP', which is defined to a small set of volumes called SVCDxx. We
> had a (major) problem a while back when DB2/CICS wanted to take a
> humongous dump that exceeded the available capacity of of the SVCDxx
> volumes. So we *added* group 'OVERFLOW' to the ACS routine expecting
> this much larger group to accommodate dumps that SVCDUMP could not
> handle. Much to our chagrin, from that moment forward, *all* SVCDUMPs
> went directly to OVERFLOW without even trying to find space in group
> SVCDUMP. We have an RYO mechanism to manage dumps created on volume
> SVCDxx, so dumps created elsewhere are a problem we can live with on
> occasion but not regularly.
> 
> I know there are various ways to resolve to this problem, but I want to
> know why SMS is behaving this way and whether there is a purely SMS
> solution: try SVCDUMP first; if no room, then try OVERFLOW. In that
> order.
> 
> .
> .
> 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
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

Re: SETRP with DUMP=YES

[Binyamin Dissen]

On Sun, 23 Apr 2017 08:28:49 -0400 Peter Relson  wrote:

:>SETRP, IIRC, always "returns to the next sequential instruction" unless 
:>you specify the REGS parameter.

:>One thing that I think you can't do is to set the "DUMP = Yes" option (or 
:>any other option for that matter) without also setting the "return code", 
:>as all the expansions set that, and the return code setting defaults to 
:>"continue with termination" (i.e., percolate). Thus it is often a good 
:>idea to set all the options (in one or more invocations) and then request 
:>retry last, to avoid resetting the return code from "retry" to 
:>"percolate".

Yes, there are many settings that you cannot set individually.even though
there are separate bits for them. To allow an FRR to sometimes return in
amode31 and other times in amode64 (but other similar options) requires (if
one wants to be clean and use SETRP rather than bits) two full SETRP
statements. 

It would be nice if one could

 IF condition1
 SETRP to return 64 
  if condition2
 free local lock
  if condition3 
  set retry addr1
  IF condition4
  set retry addr2 

 BRR14

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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