Re: Mobile pricing query

[Laurence Chiu]

Thanks for the responses.

I am looking at this page on mobile pricing.

https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/0/877/ENUSZP14-0280/index.html=en_locale=en

I think we use AWLC but need to check.

But given our workload seems to be growing from digital devices not so much
increased customer base, then this seemed like an option to investigate.

It seems our existing customers are interacting with us much more from a
digital device then they used to be from a desktop or the call centre.

On Fri, Jun 21, 2019, 9:53 AM Lizette Koehler 
wrote:

> I think that would depend on what is "MOBILE"
>
> Is it retrieving reports,
>
> Is it looking up financial data
>
> Is it the app dev teams logging on to the mainframe with a mobile device
> to review application issues?
>
> Probably other areas as well to investigate
>
>
>
> I have not seen any documentation suggesting how to charge for mobile
> access.  You may not get many answers
>
> Some shops may absorb those costs and charge it out through other venues.
>
> From personal experience with other apps. Most that I use charge based on
> MB used/downloaded/uploaded
>
> Beyond that - I sometimes pay for the privilege of downloading and using
> their app (20/year - 10 one-time charge)
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of
> > Laurence Chiu
> > Sent: Wednesday, June 19, 2019 1:29 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Mobile pricing query
> >
> > Looking at the options of using mobile pricing as a way to manage our
> > increasing CPU cost, just wondering if readers of this list have
> implemented
> > mobile pricing and if so, was it hard to do and the benefits worthwhile?
> >
> > I'm trying to counter some arguments internally that the reporting
> > requirements including potential application coding changes to tag the
> > workload, would outweigh any pricing benefits.
> >
> > I'm just interested in general experiences, nothing specific.
> >
> > Thanks
> >
> > Larry
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to
> > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Use of "trap" facility in z/OS?

[Chuck Arney]

The TRAP facility was originally implemented in the hardware for Y2K support.  
It was to be used by products to overlay clock related instructions so 
different clocks/dates could be simulated.  At least that is what I was told 
many years ago.

Chuck Arney

> On Jun 20, 2019, at 4:41 PM, Chuck  wrote:
> 
> The TRAP Instructions work fine John. You have used a product that uses them. 
> 
> Chuck Arney
> 
>> On Jun 20, 2019, at 7:16 AM, John McKown  
>> wrote:
>> 
>> This is purely speculation, but I like what I've read about the "trap"
>> facility. I think it is too bad that z/OS doesn't support the use of TRAP2,
>> TRAP4, as well as the compare-and-trap and load-and-trap. I agree that they
>> are not _necessary_ since the code can do basically the same thing. The
>> only reason that I even bring it up is that the paper "IBM Z / LinuxONE
>> System Processor Optimization Primer" by C. Kevin Shum on page 51
>> "Optimization - Instruction Selection (1)" recommends using
>> "compare-and-trap" where practical, in particular, for null-pointer
>> checking.
>> 
>> Perhaps I should have waited for Friday to post this since it is only
>> wishful thinking.
>> 
>> -- 
>> Money is the root of all evil.
>> Evil is the root of all money.
>> With that in mind, money is made by the government ...
>> 
>> 
>> 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
> 

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

Re: Use of "trap" facility in z/OS?

[Chuck]

The TRAP Instructions work fine John. You have used a product that uses them. 

Chuck Arney

> On Jun 20, 2019, at 7:16 AM, John McKown  wrote:
> 
> This is purely speculation, but I like what I've read about the "trap"
> facility. I think it is too bad that z/OS doesn't support the use of TRAP2,
> TRAP4, as well as the compare-and-trap and load-and-trap. I agree that they
> are not _necessary_ since the code can do basically the same thing. The
> only reason that I even bring it up is that the paper "IBM Z / LinuxONE
> System Processor Optimization Primer" by C. Kevin Shum on page 51
> "Optimization - Instruction Selection (1)" recommends using
> "compare-and-trap" where practical, in particular, for null-pointer
> checking.
> 
> Perhaps I should have waited for Friday to post this since it is only
> wishful thinking.
> 
> -- 
> Money is the root of all evil.
> Evil is the root of all money.
> With that in mind, money is made by the government ...
> 
> 
> 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

Re: Mobile pricing query

[Lizette Koehler]

I think that would depend on what is "MOBILE" 

Is it retrieving reports,

Is it looking up financial data

Is it the app dev teams logging on to the mainframe with a mobile device to 
review application issues?

Probably other areas as well to investigate



I have not seen any documentation suggesting how to charge for mobile access.  
You may not get many answers

Some shops may absorb those costs and charge it out through other venues.

>From personal experience with other apps. Most that I use charge based on MB 
>used/downloaded/uploaded

Beyond that - I sometimes pay for the privilege of downloading and using their 
app (20/year - 10 one-time charge)

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Laurence Chiu
> Sent: Wednesday, June 19, 2019 1:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Mobile pricing query
> 
> Looking at the options of using mobile pricing as a way to manage our
> increasing CPU cost, just wondering if readers of this list have implemented
> mobile pricing and if so, was it hard to do and the benefits worthwhile?
> 
> I'm trying to counter some arguments internally that the reporting
> requirements including potential application coding changes to tag the
> workload, would outweigh any pricing benefits.
> 
> I'm just interested in general experiences, nothing specific.
> 
> Thanks
> 
> Larry
> 
> --
> 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: Mobile pricing query

[Massimo Biancucci]

Larry,

the answer is yes, a couple of customers of mine's did the job.

Difficult ? Not so much this case. Only a different routing of traffic in
order to "be sure" those IP's were from Mobile devices (CICS transactions
fired by MQSeries or WebServices).

Worthwhile ? It depends on the effort you'll need to identify the sources.
Our case we had a "few" definition and not more.
So even few MSUs are better than nothing :D
In my experience, users using Mobile increase month by month. For the most,
less PC and Browser and more Cell and Apps.

Regards.
Max

Il giorno mer 19 giu 2019 alle ore 22:29 Laurence Chiu 
ha scritto:

> Looking at the options of using mobile pricing as a way to manage our
> increasing CPU cost, just wondering if readers of this list have
> implemented mobile pricing and if so, was it hard to do and the benefits
> worthwhile?
>
> I'm trying to counter some arguments internally that the reporting
> requirements including potential application coding changes to tag the
> workload, would outweigh any pricing benefits.
>
> I'm just interested in general experiences, nothing specific.
>
> Thanks
>
> Larry
>
> --
> 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: Use of "trap" facility in z/OS?

[Tony Harminc]

On Thu, 20 Jun 2019 at 10:58, Farley, Peter x23353
 wrote:
>
> Some time back I started a thread on this forum about writing authorized code 
> or a PC routine to update the DUCT
> architectural control block to populate the TRAP fields to make active use of 
> the variety of TRAP instructions now provided,
> and the common consensus at the time was for me to keep my grubby hands off 
> the DUCT lest I cause a catastrophic and
> possibly ipl-able failure.
>
> IIRC there was a comment in that thread by one of our regular IBM 
> contributors that at least one IBM product had gone ahead
> and used that technique without dispensation from the core z/OS developers 
> who were (at least at the time) not happy about
> the choice made by those product developers.

The interesting question, in my opinion, is how such a scheme got to
be in the architecture without z/OS software infrastructure
to use it. Dan Greiner commented in another thread about how BIC came
to be, and I understand that in recent years there has been close
collaboration between the hardware architects and the software people
in core z/OS, compilers, LE, and particularly Java groups. But if
there's no z/OS support...

> We have yet to see any further word from IBM on when or if z/OS will provide 
> the needed system-level interfaces to "safely"
> use TRAP and friends.  "Business justification needed" and "ROI" are of 
> course the usual reasons given for delaying support
> for the architected hardware capabilities.  Hiring more core z/OS developers 
> and testers to keep up with support for all of the
> hardware capabilities never seems to be on the list of possible solutions.
>
> z/Linux may or may not be ahead of z/OS in regard to actually using TRAP and 
> friends, but I don't know where one would look
> to find out if and/or how it is implemented there.

I'm not sure that any of the hardware architecture has been
implemented specifically for Linux. Certainly the IBM Linux coders
have shown themselves very adept at exploiting existing features in
ways that were perhaps not intended or anticipated by the hardware
architects.

Tony H.

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

Re: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

[CenturyLink Customer]

The longest record was 222 THIS TIME.  Given that they chose that specific DCB, 
you should be prepared for a different result at some future delivery.  If you 
change your VB parameters to allow a (much) longer record,  your job will 
process the current data with the same efficiency but will process later 
deliveries without the need for you to constantly check for the max record size.

- Original Message -
From: "Farley, Peter x23353" 
To: "IBM Mainframe Discussion List" 
Sent: Thursday, June 13, 2019 5:49:16 PM
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

In fact I did try it, and Rexx ignored the LRECL=200, as expected.  As I said 
in an earlier reply, the longest actual record (block) size was 222.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, June 13, 2019 5:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

I would hope that REXX would ignore LRECL for RECFM=U. If you try it, please 
let us know what happens.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, June 13, 2019 5:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

On Thu, 13 Jun 2019 21:03:17 +, Seymour J Metz wrote:

>> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998)
>
>Despite the LRECL, I take this to mean that the records can be up to 27998.
>
What do Rexx (and other utilities) do if a record/block exceeds 200?  Either 
for input or output.

-- 

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

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

Re: Use of "trap" facility in z/OS?

[Farley, Peter x23353]

Some time back I started a thread on this forum about writing authorized code 
or a PC routine to update the DUCT architectural control block to populate the 
TRAP fields to make active use of the variety of TRAP instructions now 
provided, and the common consensus at the time was for me to keep my grubby 
hands off the DUCT lest I cause a catastrophic and possibly ipl-able failure.

IIRC there was a comment in that thread by one of our regular IBM contributors 
that at least one IBM product had gone ahead and used that technique without 
dispensation from the core z/OS developers who were (at least at the time) not 
happy about the choice made by those product developers.

We have yet to see any further word from IBM on when or if z/OS will provide 
the needed system-level interfaces to "safely" use TRAP and friends.  "Business 
justification needed" and "ROI" are of course the usual reasons given for 
delaying support for the architected hardware capabilities.  Hiring more core 
z/OS developers and testers to keep up with support for all of the hardware 
capabilities never seems to be on the list of possible solutions.

z/Linux may or may not be ahead of z/OS in regard to actually using TRAP and 
friends, but I don't know where one would look to find out if and/or how it is 
implemented there.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John McKown
Sent: Thursday, June 20, 2019 9:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Use of "trap" facility in z/OS?

This is purely speculation, but I like what I've read about the "trap"
facility. I think it is too bad that z/OS doesn't support the use of TRAP2, 
TRAP4, as well as the compare-and-trap and load-and-trap. I agree that they are 
not _necessary_ since the code can do basically the same thing. The only reason 
that I even bring it up is that the paper "IBM Z / LinuxONE System Processor 
Optimization Primer" by C. Kevin Shum on page 51 "Optimization - Instruction 
Selection (1)" recommends using "compare-and-trap" where practical, in 
particular, for null-pointer checking.

Perhaps I should have waited for Friday to post this since it is only wishful 
thinking.

-- 

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: EXTERNAL: Mobile pricing query

[Crawford, Robert C.]

We were fortunate in that we implemented communication between our midrange and 
host through infrastructure.  The midrange infrastructure detects the mobile 
request and flags the message.  The host infrastructure records the flag in our 
performance data.  By using the infrastructure we didn't need to make any 
application coding changes.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822 

“Est multum ineptias atque in volumine petram et de illius ineptias est 
pulchellus frigus.”
- Virgil
Please send requests to Mainframe Management through our front door at go/mfm

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Laurence Chiu
Sent: Wednesday, June 19, 2019 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Mobile pricing query

Looking at the options of using mobile pricing as a way to manage our 
increasing CPU cost, just wondering if readers of this list have implemented 
mobile pricing and if so, was it hard to do and the benefits worthwhile?

I'm trying to counter some arguments internally that the reporting requirements 
including potential application coding changes to tag the workload, would 
outweigh any pricing benefits.

I'm just interested in general experiences, nothing specific.

Thanks

Larry

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

Use of "trap" facility in z/OS?

[John McKown]

This is purely speculation, but I like what I've read about the "trap"
facility. I think it is too bad that z/OS doesn't support the use of TRAP2,
TRAP4, as well as the compare-and-trap and load-and-trap. I agree that they
are not _necessary_ since the code can do basically the same thing. The
only reason that I even bring it up is that the paper "IBM Z / LinuxONE
System Processor Optimization Primer" by C. Kevin Shum on page 51
"Optimization - Instruction Selection (1)" recommends using
"compare-and-trap" where practical, in particular, for null-pointer
checking.

Perhaps I should have waited for Friday to post this since it is only
wishful thinking.

-- 
Money is the root of all evil.
Evil is the root of all money.
With that in mind, money is made by the government ...


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: RMM search with generic dataset

[Gormley, Steve]

Try the following search -

RMM SD DS('SOMETHING.**) LIM(*) OWNER(*) -

Steve   

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Thursday, June 20, 2019 5:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RMM search with generic dataset

Is it possible to list a tape based on a generic name of dataset for example : 
SOMETHING.**.

I would like to know in how many tales it is spread out

Even if the dataset are not catalogued

Is this is possible to list ?

Peter

--
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: RMM search with generic dataset

[Dana Mitchell]

Duh!  Didn't look at the title first :(

On Thu, 20 Jun 2019 06:57:55 -0500, Dana Mitchell  wrote:
> Tell us what  your shop is using: CA1, RMM, ZARA   etc.
>

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

Re: RMM search with generic dataset

[Dana Mitchell]

On Thu, 20 Jun 2019 08:28:52 +0400, Peter  wrote:

>Is it possible to list a tape based on a generic name of dataset for
>example : SOMETHING.**.
>

If the tapes are not cataloged,  that would have to be a function of your tape 
management software...  Tell us what  your shop is using: CA1, RMM, ZARA   etc.

Dana

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

Re: honorpriority=no in WLM

[Scott Chapman]

On Wed, 19 Jun 2019 13:34:09 -0500, Horst Sinram  wrote:

>The OP's question was about DB2 workloads. Resource group  capping for DB2 
>workloads would be pretty risky unless you could really guarantee that you do 
>not share resources with your production work.
>

Although I haven't counted them all, I maintain that there's more dev/test DB2 
subsystems in the world than production ones.

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

Re: ALLOWUSERKEYCSA and Z/OS 2.4

[Elardus Engelbrecht]

Holger Noach (UHN) wrote:

>We are to migrate to Z/OS 2.4 in future, and I can see that we are hit by the 
>restriction not to be able to modify USERCSA
I have set up a SLIP and GTF trace as indicated in link :

Ah, yes, the good old friend, OA53355, resurfaced again.   ;-)

Just apply above APAR and look below for the 2 Health Checks.


>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0zm100/BCP_vsm-rsm_userkeyCA_v2r3.htm

>But I am interested in a program to extract from SMF type 30 , which could 
>catch users/programs accessing this storage

>The flags are :
>SMF30_UserKeyCsaUsage
>SMF30_UserKeyCadsUsage
>SMF30_UserKeyChangKeyUsage
>SMF30_UserKeyRuCsaUsage

I have written a small Assembler program which extract above info plus other 
info.


>I canesee that it is previously suggested to use SAS/MXG to do this

It was indeed mentioned several times in IBM-MAIN. You can perhaps use 
Omegamon. Others also have written similar programs, like Tom Russell who wrote 
a REXX program just for that.

Just remember to activate these Health Checks: 

VSM_ALLOWUSERKEYCSA
ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM


>So do s anymore have some code extracting SMF type 30 for this purpose which 
>could be shared 

E-mail me offlist if you want the source code.

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

ALLOWUSERKEYCSA and Z/OS 2.4

[Holger Noach (UHN)]

Hi List

We are to migrate to Z/OS 2.4 in future, and I can see that we are hit by the 
restriction not to be able to modify USERCSA
I have set up a SLIP and GTF trace as indicated in link :

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0zm100/BCP_vsm-rsm_userkeyCA_v2r3.htm

But I am interested in a program to extract from SMF type 30 , which could 
catch users/programs accessing this storage

The flags are :
SMF30_UserKeyCsaUsage
SMF30_UserKeyCadsUsage
SMF30_UserKeyChangKeyUsage
SMF30_UserKeyRuCsaUsage


I can see that it is previously suggested to use SAS/MXG to do this

But customer does not have this installed .

So does anymore have some code extracting SMF type 30 for this purpose which 
could be shared 

Regards
Holger


Beskyttelse af dine personlige oplysninger er vigtig for os. Her finder du 
KMD’s Privatlivspolitik, der fortæller, 
hvordan vi behandler oplysninger om dig.

Protection of your personal data is important to us. Here you can read KMD’s 
Privacy Policy outlining how we process your 
personal data.

Vi gør opmærksom på, at denne e-mail kan indeholde fortrolig information. Hvis 
du ved en fejltagelse modtager e-mailen, beder vi dig venligst informere 
afsender om fejlen ved at bruge svarfunktionen. Samtidig beder vi dig slette 
e-mailen i dit system uden at videresende eller kopiere den. Selvom e-mailen og 
ethvert vedhæftet bilag efter vores overbevisning er fri for virus og andre 
fejl, som kan påvirke computeren eller it-systemet, hvori den modtages og 
læses, åbnes den på modtagerens eget ansvar. Vi påtager os ikke noget ansvar 
for tab og skade, som er opstået i forbindelse med at modtage og bruge e-mailen.

Please note that this message may contain confidential information. If you have 
received this message by mistake, please inform the sender of the mistake by 
sending a reply, then delete the message from your system without making, 
distributing or retaining any copies of it. Although we believe that the 
message and any attachments are free from viruses and other errors that might 
affect the computer or it-system where it is received and read, the recipient 
opens the message at his or her own risk. We assume no responsibility for any 
loss or damage arising from the receipt or use of this message.

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