Re: Sales PDFs - a rant

2017-10-05 Thread Paul Gilmartin
On Thu, 5 Oct 2017 08:48:16 -0700, Nightwatch RenBand wrote:
>
>Add on rant... The human eye can do speed reading effectively only when
>columns are a few inches wide. Spread text all across a wide screen and
>comprehension rate goes straight down.  There is a reason newspapers
>(remember those) and magazines use columns.
>
I could imagine a browser that displayed "responsive HTML" in 2, 3, ... columns 
at the option of the user.  If a document doesn't fit the screen scrolling with 
up/down arrow keys should snake the columns on the screen.

Unlikely to happen: it's wishing for someone to invent a razor when few
are is willing to supply blades.

Wide graphics are an additional challenge.

-- gil

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


Re: JCL 'SYMBOLS=' vs. IDCAMS SYMBOLICRELATE

2017-10-05 Thread Steve Horein
On Thu, Oct 5, 2017 at 6:54 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

>
> SYMBOLICRELATE is very different from using symbolic substitution in
> IDCAMS control statements. The former is done dynamically every time
> the alias is referenced. The latter at the time the alias or data set name
> is defined. When you define an alias with SYMBOLICRELATE, you can
> change the value assigned to the symbol and every reference to that
> alias will then pick up the new name.
>
> Furthermore, with SYMBOLICRELATE, you can have an alias in a catalog
> that is shared across a sysplex and different MVS images in the sysplex
> can use that alias to refer to different data sets simply by having a
> different value assigned to the symbol. You can't do that with symbolic
> substitution in the IDCAMS control statements.
>
> In addition, a normal alias must be defined in the same catalog that holds
> the related data set name. With SYMBOLICRELATE, that is not a requirement.
>
> --
> Tom Marchant
>


Ah yes!
I forgot about the dynamic nature of SYMBOLICRELATE. I guess with
leveraging symbolic substitution lately to retool distribution of resources
across several sysplexes and many systems, symbolic substitution appeared a
tad more shiny. The final resting places for the data sets don't require
periodic changes, but if they did, having both tools in the toolbox (and
knowing when to use the right one!) can certainly come in handy.

Thanks Mr. Marchant!

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


Re: Sales PDFs - a rant

2017-10-05 Thread Phil Smith III
Nightwatch RenBand wrote:

>Yes, PDF's are great and portable, but they are designed for print.

>It is high time to come up with something better which will adapt to any

>screen format.  Print should be secondary these days,

 

I think that's called "HTML". 

 

Alas, all too many "web designers" (insulting quotes
deliberate) are so focused on shiny that they forget the point of what
they're doing: to communicate information. Web pages with popup ads that
cover content; pages that cannot be scrolled using normal techniques; pages
that don't allow opening links in tabs.I could go on, but my blood pressure
is spiking. And I haven't even touched on the pages that simply don't work
IN ANY BROWSER because they're so heavily scripted that they were more or
less untestable. And of course there's no way to report the problem. Some
days I just shake my head and moan that the web is dying.


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


Re: Here's a horrifying thought for all you management types....

2017-10-05 Thread John McKown
On Thu, Oct 5, 2017 at 6:19 PM, scott Ford  wrote:

> Beverly,
>
> Not surprising, a lot of manglers don't have a clue what a real systems
> programmer does or know.
> Especially those who only know Windoze...
>
> I have z/OS customers who can't install simple software without us holding
> their hand and doing there work for them.
>

​Yeah, my boss got a response to the "possible sysprog opening" I posted.
The guy didn't know the difference between IEBGENER and IEBCOPY.​



>
> Sorry for the rant, been a day.
>
> Scott
>
>

-- 
*L'Shanah Tovah Tikatevu*

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: Here's a horrifying thought for all you management types....

2017-10-05 Thread scott Ford
Beverly,

Not surprising, a lot of manglers don't have a clue what a real systems
programmer does or know.
Especially those who only know Windoze...

I have z/OS customers who can't install simple software without us holding
their hand and doing there work for them.

Sorry for the rant, been a day.

Scott

On Thu, Oct 5, 2017 at 1:21 PM william janulin <
008d52e04f2e-dmarc-requ...@listserv.ua.edu> wrote:

> What goes around comes around.
>
>
> On Thursday, October 5, 2017 11:50 AM, "Savor, Thomas (Alpharetta)" <
> thomas.sa...@fiserv.com> wrote:
>
>
>  As an "Assembler" guy.that's great news !
>
> Thanks,
>
> Tom Savor
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Beverly Caldwell
> Sent: Thursday, October 05, 2017 11:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Here's a horrifying thought for all you management types
>
> From an IBM red book, the one which describes Walmart’s adventures with
> CICS in a cloud.
>
> From the section which describes the activities of the CICS and z/OS
> systems programmers:
>
>
> “The traditional role of systems programmers over time became focused on
> system administration functions. But, to extend the capabilities of CICS,
> the old-school, multi-role technician must reemerge and embrace the latest
> technologies”
>
>
> Well some of us never actually went away.
>
>
> But wait, there’s more. It gets worse. Further on in the same article
> there’s talk of:
>
> “Selecting HLASM and COBOL as service development languages.”
>
> Programming, Jim? *Assembler* language programming? I don’t think we need
> any of *that* here.
>
>
> What I would like to know is where were all the managers while all this
> programming was going on. Does Walmart have the most enlightened managers
> in the mainframe world or did they just not have a clue what was going on.
> I suspect the latter, it’s unlikely Walmart’s managers are any different
> from anyone else’s.
>
>
> A very interesting red book with lots of detailed information although I
> kept seeing the word 'service'. Not a word one would normally associate
> with Walmart.
>
> --
> 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
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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


Re: Sales PDFs - a rant

2017-10-05 Thread Paul Gilmartin
On Thu, 5 Oct 2017 17:00:28 +1100, Andrew Rowley wrote:
>
>... Responsive HTML ...
> 
It's dismaying that HTML has become so perverted from its original objective
that such a retronym ever arose.

-- gil

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


Re: IEAVPSE parameter question

2017-10-05 Thread Mike Schwab
The cache line size is 256 bytes.  The performance should be higher if
the token doesn't cross that boundary.

On Thu, Oct 5, 2017 at 10:31 AM, Charles Mills  wrote:
> Thanks!
>
> Should the doc contain a hint that performance would be improved if the
> token were doubleword aligned? I looked and looked for such an assertion,
> and finding none, took it that a character field is a character field is a
> character field. Why not document as two doublewords, or at least point out
> that doubleword alignment would be beneficial?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: Thursday, October 5, 2017 4:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEAVPSE parameter question
>
> It is fine with z/OS itself if you use the same field for both the input
> token and the updated token.
> Whether it works for you will depend on whether you care. Maybe your
> recovery looks at something that wants to know if you still have the old
> token vs the updated one.
>
> The functionality of IEAVPSE (and the other similar "pause" targets, but not
> "multi-pause" IEAVPME2 / IEA4PME2):
> -- does a LM of the token into registers while running in your state and key
> -- PC's to change state (where the target uses the registers
>and never looks at the parameter list)
> -- does a LM into registers of the updated token
> -- PR's back to your state and key
> -- STM's to your updated-token
>
> 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
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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


Re: PROCUSERMAX in OMVS Segment

2017-10-05 Thread Dan Little
Yes it does

On Oct 5, 2017, 08:37 -0400, Mark Jacobs - Listserv , 
wrote:
> This question might be better asked in the RACF or OMVS mailing lists,
> but I'm starting here.
>
> Does a value set in the OMVS segment for PROCUSERMAX override the
> setting of MAXPROCUSER in BPXPRMxx? It's documented that way for
> THREADSMAX, but not for PROCUSERMAX.
> --
>
> Mark Jacobs
> Time Customer Service
> Global Technology Services
>
> The standard you walk past is the standard you accept.
> Lt. Gen. David Morrison
>
>
> --
> 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: Sales PDFs - a rant

2017-10-05 Thread Farley, Peter x23353
Add on requirement:

With a "flowed" format of some sort it would also be worlds easier to just 
extract text for non-book purposes (like Abe K.'s website of instructions).

The Xpdf batch utility (Linux and Windows) pdftotext does pretty well (using 
the "-table" option) extracting text from the PoOP and preserving the 2-column 
format of text and keeping full-page-width tables intact, but then you have to 
write a 2-column to 1-column process yourself to get at the text.  Annoying and 
quite complex.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nightwatch RenBand
Sent: Thursday, October 05, 2017 11:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sales PDFs - a rant

In the words of Tevye: "From your lips to God's ears".
Yes, PDF's are great and portable, but they are designed for print.
It is high time to come up with something better which will adapt to any
screen format.  Print should be secondary these days,

Add on rant... The human eye can do speed reading effectively only when
columns are a few inches wide. Spread text all across a wide screen and
comprehension rate goes straight down.  There is a reason newspapers
(remember those) and magazines use columns.

--


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: Sales PDFs - a rant

2017-10-05 Thread ITschak Mugzach
Lionel

I promise to create 9x16 screen format brochures next time ;-) although it
was a one pager.

ITschak

בתאריך 5 באוק׳ 2017 5:48 אחה״צ,‏ "Nightwatch RenBand" <
johnmattson...@gmail.com> כתב:

> In the words of Tevye: "From your lips to God's ears".
> Yes, PDF's are great and portable, but they are designed for print.
> It is high time to come up with something better which will adapt to any
> screen format.  Print should be secondary these days,
>
> Add on rant... The human eye can do speed reading effectively only when
> columns are a few inches wide. Spread text all across a wide screen and
> comprehension rate goes straight down.  There is a reason newspapers
> (remember those) and magazines use columns.
>
> --
> 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: [EXTERNAL] Re: Sales PDFs - a rant

2017-10-05 Thread Dyck, Lionel B. (TRA)
Trust me - you weren't the straw that broke the camel's back ;-)

--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Thursday, October 05, 2017 2:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Sales PDFs - a rant

Lionel

I promise to create 9x16 screen format brochures next time ;-) although it was 
a one pager.

ITschak

בתאריך 5 באוק׳ 2017 5:48 אחה״צ,‏ "Nightwatch RenBand" < 
johnmattson...@gmail.com> כתב:

> In the words of Tevye: "From your lips to God's ears".
> Yes, PDF's are great and portable, but they are designed for print.
> It is high time to come up with something better which will adapt to 
> any screen format.  Print should be secondary these days,
>
> Add on rant... The human eye can do speed reading effectively only 
> when columns are a few inches wide. Spread text all across a wide 
> screen and comprehension rate goes straight down.  There is a reason 
> newspapers (remember those) and magazines use columns.
>
> --
> 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: JCL 'SYMBOLS=' vs. IDCAMS SYMBOLICRELATE

2017-10-05 Thread Jesse 1 Robinson
Ask and ye shall receive. Just not necessarily what you were hoping for. 

.
.
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 Paul Gilmartin
Sent: Thursday, October 05, 2017 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: JCL 'SYMBOLS=' vs. IDCAMS SYMBOLICRELATE

On Thu, 5 Oct 2017 07:04:17 -0400, John Eells wrote:
>
>As the person who got the Catalog/VSAM team to create SYMBOLICRELATE 
>some time ago, *I* certainly do not want it to go away, and I doubt 
>very much that it will go away.
>...
>That people found other uses for this function is a serendipitous byproduct.
>
At some point I opened an SR on an unexpected error when I used SYMBOLICRELATE.
Support replied that the problem was that I had no symbols in my alias.  But 
though z/OS 2.1, the IDCAMS Ref.  says:
SYMBOLICRELATE(entryname)
Allows the specification of the base data set name using system 
symbols. ...
"Allows" is permissive, not restrictive.  I insisted that there was a bug 
needing repair.

Alas, in z/OS 2.3 IDCAMS Ref. I see:
SYMBOLICRELATE(entryname)
Requires the specification of the base data set name using system 
symbols.

"Allows" became "Requires".  All too characteristic of IBM to document a 
deficiency rather than repairing it.

Sigh,
gil


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


Re: Interesting article in IEEE Annals of the History of Computing

2017-10-05 Thread Anne & Lynn Wheeler
dbo...@sinenomine.net (David Boyes) writes:
> IBM Branch Offices: What They Were, How They Worked, 1920s–1980s
>
> James W. Cortada
>
> Abstract:
> IBM branch offices were the company’s local face around the world in
> the 20th century. Its sales and customer support came out of these
> organizations, which are described here, using the example of one
> branch office as a historical case study. Additionally, personal
> perspectives on their role of having worked with these during the
> 1970s and 1980s are provided.
>
> Published in: IEEE Annals of the History of Computing ( Volume: 39, Issue: 3, 
> 2017 )

one of the issues after 23jun1969 unbundling announcement was how to
handle the training of new SEs ... previously it was sort of journeyman
training as part of large SE group at customer site. Unbundling started
to charge for SE time at the customer ... and they couldn't figure out
how to *NOT* charge for the SE trainee time. past posts mentiong
23jun1969 unbundling
http://www.garlic.com/~lynn/submain.html#unbundle

The solution was HONE ... hands-on network environment, online to
(originally) CP67 virtual machine datacenters (later moved to vm370)
... being able to practice with running guest operating systems in
virtual machines. I provided highly customized & enhanced CP67 operating
systems (and later VM370) to HONE from just about the beginning until
sometime in the mid-80s. One of early enhancements was to provide
simulation of the newly announced 370 instructions ... so guest
operating systems generated for 370s could be run under CP67. some
past posts mentioning HONE
http://www.garlic.com/~lynn/subtopic.html#hone

The science center (besides doing CP40, CP67, CMS, GML, internal network
... technology also used for the corporate sponsored university BITNET
... where ibm-main mailing list originated) ... early on, also ported
APL\360 to CMS as CMS\APL. HONE then started offering CMS\APL based
sales support applications ... eventually the sales
support applications started to dominate all HONE activity (salesmen
edging out trainee SEs at branch office terminals) ... and the original
HONE use for guest operating systems dwindled away. past posts
mentioning science center
http://www.garlic.com/~lynn/subtopic.html#545tech
post mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
posts mentioning corporate sponsored univ network
http://www.garlic.com/~lynn/subnetwork.html#bitnet

Mid-70s, all the US HONE datacenters were consolidated in Palo Alto
(trivia when FACEBOOK originally moved to silicon valley, it was into
new bldg next door to the old HONE datacenter). Their VM370 systems were
enhanced to support single-system-image ... possibly largest in the
world, eight large POK multiprocessor all operating as single complex
with load balancing and fall-over across the complex. In the early 80s,
this was replicated first in dallas and then in boulder ... with
fall-over for disaster survivability across the three datacenters.
Also, by mid-70s, mainframe configurations were getting so complex, that
all new customer orders had to be first be run through HONE
configurators.

Also by late 70s, various IBM factions were demanding that HONE be
migrated to MVS, the corporation's "favorite son operating system"
... and periodically all HONE resources were being devoted to MVS
migration, eventually fail ... and then things would settle back to
normal for a little while ... and then it would start all over. After
several of these failed attempts, in the first part of the 80s, they
started blaming me (and my enhanced vm370 operating systmes) for all the
failed attempts to migrate to MVS.

During the late 70s period, head of POK had made some internal
proclamations that VM370 was being killed as product (part of the
initial motivation for migrating HONE to MVS) ... which initiated huge
protests from HONE & marketing ... and POK had to spend several months
walking back the proclamation (reassuring HONE and marketing
organization).

-- 
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: :IEAVAPE return code doc wrong?

2017-10-05 Thread Farley, Peter x23353
And slightly mis-spelled, actual address is MHV... not MVH...:

mhvr...@us.ibm.com

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Thursday, October 05, 2017 2:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: :IEAVAPE return code doc wrong?

 
>To make it perhaps easier to remember, I'll add that "mvhrcfs" stands
for "Mid-Hudson Valley Reader Comment Forms."  Poughkeepsie is located in the 
Mid-Hudson Valley in New York State. 


ROTFLOL. I always wondered about that rather difficult to remember name, but 
never tried to imagine what it stands for. Thanks for that amusement.


--

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


AW: Re: :IEAVAPE return code doc wrong?

2017-10-05 Thread Peter Hunkeler

>To make it perhaps easier to remember, I'll add that "mvhrcfs" stands
for "Mid-Hudson Valley Reader Comment Forms."  Poughkeepsie is located
in the Mid-Hudson Valley in New York State.


ROTFLOL. I always wondered about that rather difficult to remember name, but 
never tried to imagine what it stands for. Thanks for that amusement.


--
Peter Hunkeler




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


Re: JCL 'SYMBOLS=' vs. IDCAMS SYMBOLICRELATE

2017-10-05 Thread Tom Marchant
On Thu, 5 Oct 2017 11:20:10 -0500, Paul Gilmartin wrote:

>I opened an SR on an unexpected error when I used SYMBOLICRELATE.
>Support replied that the problem was that I had no symbols in my alias.  But
>though z/OS 2.1, the IDCAMS Ref.  says:
>SYMBOLICRELATE(entryname)
>Allows the specification of the base data set name using system 
> symbols. ...
>"Allows" is permissive, not restrictive.  I insisted that there was a bug 
>needing
>repair.
>
>Alas, in z/OS 2.3 IDCAMS Ref. I see:
>SYMBOLICRELATE(entryname)
>Requires the specification of the base data set name using system 
> symbols.
>
>"Allows" became "Requires".  All too characteristic of IBM to document a 
>deficiency
>rather than repairing it.

If the intent when designing SYMBOLICRELATE was that symbols could be used but 
were not required, then it was a bug. If the intent was that SYMBOLICRELATE 
requires at least one symbol, then it is the doc that was in error.

-- 
Tom Marchant

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


Re: Here's a horrifying thought for all you management types....

2017-10-05 Thread william janulin
What goes around comes around.
 

On Thursday, October 5, 2017 11:50 AM, "Savor, Thomas (Alpharetta)" 
 wrote:
 

 As an "Assembler" guy.that's great news !

Thanks,

Tom Savor


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Beverly Caldwell
Sent: Thursday, October 05, 2017 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Here's a horrifying thought for all you management types

>From an IBM red book, the one which describes Walmart’s adventures with CICS 
>in a cloud.

>From the section which describes the activities of the CICS and z/OS systems 
>programmers:


“The traditional role of systems programmers over time became focused on system 
administration functions. But, to extend the capabilities of CICS, the 
old-school, multi-role technician must reemerge and embrace the latest 
technologies”


Well some of us never actually went away.


But wait, there’s more. It gets worse. Further on in the same article there’s 
talk of:

“Selecting HLASM and COBOL as service development languages.”

Programming, Jim? *Assembler* language programming? I don’t think we need any 
of *that* here.


What I would like to know is where were all the managers while all this 
programming was going on. Does Walmart have the most enlightened managers in 
the mainframe world or did they just not have a clue what was going on.
I suspect the latter, it’s unlikely Walmart’s managers are any different from 
anyone else’s.


A very interesting red book with lots of detailed information although I kept 
seeing the word 'service'. Not a word one would normally associate with Walmart.

--
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: ShopZ order response

2017-10-05 Thread Allan Staller
Might also be a flood of orders. CBPDO/SERVERPAC do require a lot of processing.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Thursday, October 5, 2017 11:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ShopZ order response

Good question. However, I did not hear last Friday (original delivery date) 
about anyone talking about z/OS 2.3. Perhaps shipment has been delayed. If it 
has been, that might explain why the status has remained "Manufacturing". 
Otherwise, you may want to try emailing this link:  SWG ESW ShopCat L2 Support  
  shopc...@dk.ibm.com

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nightwatch RenBand
Sent: Thursday, October 05, 2017 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ShopZ order response

On 2017-09-28 I placed my order for a new version of zOS online.  I received an 
eMail back from ShopZ the next day and online shows "Manufacturing"
.
Unfortunately the person who sent the original eMail has not returned eMail or 
phone calls, Attempts to call ShopZ have resulted in my leaving messages, but 
again, no returned calls.
Is this normal?
Should it take this long to process an order?
Is there some better way to contact ShopZ?

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


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


Re: ShopZ order response

2017-10-05 Thread Richards, Robert B.
Good question. However, I did not hear last Friday (original delivery date) 
about anyone talking about z/OS 2.3. Perhaps shipment has been delayed. If it 
has been, that might explain why the status has remained "Manufacturing". 
Otherwise, you may want to try emailing this link:  SWG ESW ShopCat L2 Support  
  shopc...@dk.ibm.com

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nightwatch RenBand
Sent: Thursday, October 05, 2017 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ShopZ order response

On 2017-09-28 I placed my order for a new version of zOS online.  I received an 
eMail back from ShopZ the next day and online shows "Manufacturing"
.
Unfortunately the person who sent the original eMail has not returned eMail or 
phone calls, Attempts to call ShopZ have resulted in my leaving messages, but 
again, no returned calls.
Is this normal?
Should it take this long to process an order?
Is there some better way to contact ShopZ?

--
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: JCL 'SYMBOLS=' vs. IDCAMS SYMBOLICRELATE

2017-10-05 Thread Paul Gilmartin
On Thu, 5 Oct 2017 07:04:17 -0400, John Eells wrote:
>
>As the person who got the Catalog/VSAM team to create SYMBOLICRELATE
>some time ago, *I* certainly do not want it to go away, and I doubt very
>much that it will go away.
>...
>That people found other uses for this function is a serendipitous byproduct.
>
At some point I opened an SR on an unexpected error when I used SYMBOLICRELATE.
Support replied that the problem was that I had no symbols in my alias.  But
though z/OS 2.1, the IDCAMS Ref.  says:
SYMBOLICRELATE(entryname)
Allows the specification of the base data set name using system 
symbols. ...
"Allows" is permissive, not restrictive.  I insisted that there was a bug 
needing
repair.

Alas, in z/OS 2.3 IDCAMS Ref. I see:
SYMBOLICRELATE(entryname)
Requires the specification of the base data set name using system 
symbols.

"Allows" became "Requires".  All too characteristic of IBM to document a 
deficiency
rather than repairing it.

Sigh,
gil

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


ShopZ order response

2017-10-05 Thread Nightwatch RenBand
On 2017-09-28 I placed my order for a new version of zOS online.  I
received an eMail back from ShopZ the next day and online shows "Manufacturing"
.
Unfortunately the person who sent the original eMail has not returned eMail
or phone calls, Attempts to call ShopZ have resulted in my leaving
messages, but again, no returned calls.
Is this normal?
Should it take this long to process an order?
Is there some better way to contact ShopZ?

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


Re: Sort Question

2017-10-05 Thread R D Boenig
Thanx Dave! 




From:   David Betten 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   10/02/2017 09:45 AM
Subject:Re: Sort Question
Sent by:IBM Mainframe Discussion List 



I see a couple things the DFSORT output

The reason for the small mainsize and DSA=0 is because the program is
passing MAINSIZE=00128000

ICE146I 0 END OF STATEMENTS FROM SORTCNTL - PARAMETER LIST STATEMENTS
FOLLOW

  SORT FIELDS=(0001,0013,CH,A)

  RECORD TYPE=F,LENGTH=(49,,)

  OPTION MAINSIZE=00128000



The small mainsize is leading to an intermediate merge.

ICE247I 0 INTERMEDIATE MERGE ENTERED - PERFORMANCE MAY BE DEGRADED


An intermediate merge happens when the sortworks are so fragmented, DFSORT
must do an intermediate merge before it can do the final merge to SORTOUT.
This greatly increases the sort work requirement as well as the elapsed
time.   So the earlier recommendation of passing MAINSIZE=MAX via SORTCNTL
or DFSPARM should resolve this.


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
email:  bet...@us.ibm.com


IBM Mainframe Discussion List  wrote on
10/02/2017 03:57:35 PM:

> From: "Pfister, Nathan" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 10/02/2017 03:57 PM
> Subject: Re: Sort Question
> Sent by: IBM Mainframe Discussion List 

>
> Sorry for the long post, but here's all the info.
>
> Here's the sort parameters:
>
> ITEM   JCL (ICEAM1) VALUE   INV (ICEAM2) VALUE   TSO
> (ICEAM3) VALUE   TSOINV (ICEAM4) VALUE
> --  
>  -
> ENABLE TD1  NONE TD1
NONE
>* NONE* NONE
>
> ABCODE MSG  MSG  MSG
MSG
> ALTSEQ SEE BELOWSEE BELOWSEE
> BELOWSEE BELOW
> ARESALL000
0
> ARESINVNOT APPLICABLE   0NOT
> APPLICABLE   0
> CFWYES  YES  YES
YES
> CHALT  NO   NO   NO
NO
> CHECK  YES  YES  YES
YES
> CINV   YES  YES  YES
YES
> COBEXITCOB2 COB2
> COB2 COB2
> DIAGSIMNO   NO   NO
NO
> DSA128  128  128
128
> DSPSIZEMAX  MAX  MAX
MAX
> DYNALOC(SYSDA,12)   (SYSDA,12)
> (SYSDA,8)(SYSDA,8)
>* (SYSDA,4)  * (SYSDA,4)  *
> (SYSDA,4)  * (SYSDA,4)
> DYNAPCT75   75   10
10
>* 10 * 10
> DYNAUTOYES  YES  YES
YES
> DYNSPC 1024 1024 256
256
>* 256* 256
> EFSNONE NONE
> NONE NONE
> EQUALS YES  YES  YES
YES
>* VLBLKSET   * VLBLKSET   *
> VLBLKSET   * VLBLKSET
> ERET   ABENDABEND
> RC16 RC16
>* RC16   * RC16
> ESTAE  YES  YES  YES
YES
> EXITCK STRONG   STRONG
> STRONG   STRONG
> EXPMAX MAX  MAX  MAX
MAX
> EXPOLD 50%  50%  50%
50%
> EXPRES 10%  10%  10%
10%
> FSZEST NO   NO   NO
NO
> GENER  NOT APPLICABLE   IEBGENR  NOT
> APPLICABLE   IEBGENR
> GNPAD  NOT APPLICABLE   RC0  NOT
> APPLICABLE   RC0
> GNTRUNCNOT APPLICABLE   RC0  NOT
> APPLICABLE   RC0
> HIPRMAXOPTIMAL  OPTIMAL
> OPTIMAL  OPTIMAL
> IDRCPCTNONE NONE
> NONE NONE
> IEXIT  NO   NO   NO
NO
> IGNCKPTYES  YES  YES
YES
> IOMAXBF35651584 35651584
> 35651584 35651584
> LIST   YES  YES  

Re: IEAVPSE parameter question

2017-10-05 Thread Steve Smith
Some more memory paged in (to my brain).  It's the Pause that returns
an updated PET, but while paused, something else needs that current
PET to Release you.  I suspect the updated PET isn't stored until the
Release is done, but that's internal processing and so isn't
guaranteed (although the usual considerations apply).

If the Pause immediately overwrote the current PET, you'd be in limbo
forever, I guess, as the correct PET would be lost (currently, it
could easily be "guessed" (from what I've seen), but IBM could also
easily get more creative in how they're updated).

Frankly, I'm not sure what problem the PET-updating is supposed to
solve.  It definitely makes the service harder to use, but maybe
that's the point ;-)

Re alignment: I suppose almost everything benefits from the best
alignment you can reasonably give it, all else equal.  LM and STM
don't imply doubleword alignment is especially needed, although again,
that's internals, and subject to change.

On Thu, Oct 5, 2017 at 11:31 AM, Charles Mills  wrote:
> Thanks!
>
> Should the doc contain a hint that performance would be improved if the
> token were doubleword aligned? I looked and looked for such an assertion,
> and finding none, took it that a character field is a character field is a
> character field. Why not document as two doublewords, or at least point out
> that doubleword alignment would be beneficial?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: Thursday, October 5, 2017 4:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEAVPSE parameter question
>
> It is fine with z/OS itself if you use the same field for both the input
> token and the updated token.
> Whether it works for you will depend on whether you care. Maybe your
> recovery looks at something that wants to know if you still have the old
> token vs the updated one.
>
> The functionality of IEAVPSE (and the other similar "pause" targets, but not
> "multi-pause" IEAVPME2 / IEA4PME2):
> -- does a LM of the token into registers while running in your state and key
> -- PC's to change state (where the target uses the registers
>and never looks at the parameter list)
> -- does a LM into registers of the updated token
> -- PR's back to your state and key
> -- STM's to your updated-token
>
> Peter Relson
> z/OS Core Technology Design
>

-- 
sas

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


Re: Here's a horrifying thought for all you management types....

2017-10-05 Thread Savor, Thomas (Alpharetta)
As an "Assembler" guy.that's great news !

Thanks,

Tom Savor


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Beverly Caldwell
Sent: Thursday, October 05, 2017 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Here's a horrifying thought for all you management types

From an IBM red book, the one which describes Walmart’s adventures with CICS in 
a cloud.

From the section which describes the activities of the CICS and z/OS systems 
programmers:


“The traditional role of systems programmers over time became focused on system 
administration functions. But, to extend the capabilities of CICS, the 
old-school, multi-role technician must reemerge and embrace the latest 
technologies”


Well some of us never actually went away.


But wait, there’s more. It gets worse. Further on in the same article there’s 
talk of:

“Selecting HLASM and COBOL as service development languages.”

Programming, Jim? *Assembler* language programming? I don’t think we need any 
of *that* here.


What I would like to know is where were all the managers while all this 
programming was going on. Does Walmart have the most enlightened managers in 
the mainframe world or did they just not have a clue what was going on.
I suspect the latter, it’s unlikely Walmart’s managers are any different from 
anyone else’s.


A very interesting red book with lots of detailed information although I kept 
seeing the word 'service'. Not a word one would normally associate with Walmart.

--
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: Sales PDFs - a rant

2017-10-05 Thread Nightwatch RenBand
In the words of Tevye: "From your lips to God's ears".
Yes, PDF's are great and portable, but they are designed for print.
It is high time to come up with something better which will adapt to any
screen format.  Print should be secondary these days,

Add on rant... The human eye can do speed reading effectively only when
columns are a few inches wide. Spread text all across a wide screen and
comprehension rate goes straight down.  There is a reason newspapers
(remember those) and magazines use columns.

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


Here's a horrifying thought for all you management types....

2017-10-05 Thread Beverly Caldwell
>From an IBM red book, the one which describes Walmart’s adventures with
CICS in a cloud.

>From the section which describes the activities of the CICS and z/OS
systems programmers:


“The traditional role of systems programmers over time became focused on
system
administration functions. But, to extend the capabilities of CICS, the
old-school, multi-role
technician must reemerge and embrace the latest technologies”


Well some of us never actually went away.


But wait, there’s more. It gets worse. Further on in the same article
there’s talk of:

“Selecting HLASM and COBOL as service development languages.”

Programming, Jim? *Assembler* language programming? I don’t think we need
any of *that* here.


What I would like to know is where were all the managers while all this
programming was going on. Does Walmart have the most enlightened managers
in the mainframe world or did they just not have a clue what was going on.
I suspect the latter, it’s unlikely Walmart’s managers are any different
from anyone else’s.


A very interesting red book with lots of detailed information although I
kept seeing the word 'service'. Not a word one would normally associate
with Walmart.

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


Re: IEAVPSE parameter question

2017-10-05 Thread Charles Mills
Thanks!

Should the doc contain a hint that performance would be improved if the
token were doubleword aligned? I looked and looked for such an assertion,
and finding none, took it that a character field is a character field is a
character field. Why not document as two doublewords, or at least point out
that doubleword alignment would be beneficial?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, October 5, 2017 4:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEAVPSE parameter question

It is fine with z/OS itself if you use the same field for both the input
token and the updated token.
Whether it works for you will depend on whether you care. Maybe your
recovery looks at something that wants to know if you still have the old
token vs the updated one.

The functionality of IEAVPSE (and the other similar "pause" targets, but not
"multi-pause" IEAVPME2 / IEA4PME2):
-- does a LM of the token into registers while running in your state and key
-- PC's to change state (where the target uses the registers 
   and never looks at the parameter list)
-- does a LM into registers of the updated token
-- PR's back to your state and key
-- STM's to your updated-token 

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

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


Re: :IEAVAPE return code doc wrong?

2017-10-05 Thread Charles Mills
I took that to mean "submit an RFC" and that is what I did.

Let me add that I have found the Mid-Hudson doc folks to be very diligent.
When I have submitted an RFC they have worked with me to make sure they got
it right, not just differently wrong. This one is a pretty simple error, but
in some cases the doc is "misleading" and the correction more subtle, and
they worked to get it right.

Diligent, not fast. I reported a PoOp problem a week ago and what I have so
far is an automated response "your concerns are important to us" but I am
confident they will get on it fairly shortly.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, October 5, 2017 4:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: :IEAVAPE return code doc wrong?

"Open a doc PMR"? Really?

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


Interesting article in IEEE Annals of the History of Computing

2017-10-05 Thread David Boyes
How things used to be done. Interesting perspective on process and benefits to 
the organization.


IBM Branch Offices: What They Were, How They Worked, 1920s–1980s

James W. Cortada

Abstract:
IBM branch offices were the company’s local face around the world in the 20th 
century. Its sales and customer support came out of these organizations, which 
are described here, using the example of one branch office as a historical case 
study. Additionally, personal perspectives on their role of having worked with 
these during the 1970s and 1980s are provided.

Published in: IEEE Annals of the History of Computing ( Volume: 39, Issue: 3, 
2017 )


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


Re: :IEAVAPE return code doc wrong?

2017-10-05 Thread Steve Smith
Well then, I guess I should mention that the manual's description of
the parmlist for IEA4APE2 is missing one (auth-level).  That caused a
bunch of "fun". IEAASM has it right, but I think I inferred it from
IEAVAPE2, which seems to be correct.

sas

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


PROCUSERMAX in OMVS Segment

2017-10-05 Thread Mark Jacobs - Listserv
This question might be better asked in the RACF or OMVS mailing lists, 
but I'm starting here.


Does a value set in the OMVS segment for PROCUSERMAX override the 
setting of MAXPROCUSER in BPXPRMxx? It's documented that way for 
THREADSMAX, but not for PROCUSERMAX.

--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


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


Re: :IEAVAPE return code doc wrong?

2017-10-05 Thread John Eells

Peter Relson wrote:

"Open a doc PMR"? Really?

By all means make sure that we get the doc updated, but that does not
require opening a PMR. I don't see our taking a doc APAR.
I'll get the ID folks to fix...



I have said this here before, but I guess it bears repeating:

When you post about z/OS documentation issues here, you can simply add 
mhvr...@us.ibm.com to the copy list.  That will get it to the right 
people without the mutual overheads associated with opening and 
following up on PMRs.


I am not trying to discourage people from opening PMRs for urgent issues 
related to documentation/code disagreement, of course, but for minor-ish 
things sending a note to this address is simply a more streamlined 
process on both sides, with fewer people involved.


To make it perhaps easier to remember, I'll add that "mvhrcfs" stands 
for "Mid-Hudson Valley Reader Comment Forms."  Poughkeepsie is located 
in the Mid-Hudson Valley in New York State.


--
John Eells
IBM Poughkeepsie
ee...@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: IEAVPSE parameter question

2017-10-05 Thread Peter Relson
It is fine with z/OS itself if you use the same field for both the input 
token and the updated token.
Whether it works for you will depend on whether you care. Maybe your 
recovery looks at something that wants to know if you still have the old 
token vs the updated one.

The functionality of IEAVPSE (and the other similar "pause" targets, but 
not "multi-pause" IEAVPME2 / IEA4PME2):
-- does a LM of the token into registers while running in your state and 
key
-- PC's to change state (where the target uses the registers 
   and never looks at the parameter list)
-- does a LM into registers of the updated token
-- PR's back to your state and key
-- STM's to your updated-token 

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: JCL 'SYMBOLS=' vs. IDCAMS SYMBOLICRELATE

2017-10-05 Thread Tom Marchant
On Wed, 4 Oct 2017 16:19:03 -0500, Steve Horein wrote:

>will SYMBOLICRELATE functionality eventually go
>away due to redundancy with the more flexible IAZSYMBL JES symbol service
>being available?

SYMBOLICRELATE is very different from using symbolic substitution in 
IDCAMS control statements. The former is done dynamically every time 
the alias is referenced. The latter at the time the alias or data set name 
is defined. When you define an alias with SYMBOLICRELATE, you can 
change the value assigned to the symbol and every reference to that 
alias will then pick up the new name.

Furthermore, with SYMBOLICRELATE, you can have an alias in a catalog 
that is shared across a sysplex and different MVS images in the sysplex 
can use that alias to refer to different data sets simply by having a 
different value assigned to the symbol. You can't do that with symbolic 
substitution in the IDCAMS control statements.

In addition, a normal alias must be defined in the same catalog that holds 
the related data set name. With SYMBOLICRELATE, that is not a requirement. 

-- 
Tom Marchant

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


Re: :IEAVAPE return code doc wrong?

2017-10-05 Thread Peter Relson
"Open a doc PMR"? Really?

By all means make sure that we get the doc updated, but that does not 
require opening a PMR. I don't see our taking a doc APAR.
I'll get the ID folks to fix...

FWIW, it appears that this isn't the only one that is incorrect in the 
same way (IEA_XFER_TO_SELF, IEA_XFER_FAILED).

In the z/OS 1.13 auth assembler services reference, IEA_PE_NOT_HOME is 
wrong in 2 places and right in 16. No rationale, just saying...

Peter Relson
z/OS Core Technology 


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


Re: [EXTERNAL] Re: Sales PDFs - a rant

2017-10-05 Thread Dyck, Lionel B. (TRA)
I agree - Responsive HTML would be the ideal solution since it is designed to 
be viewable on many platforms and formats.

That would address part of the issue - the multiple columns and having articles 
that are non-contiguous are another part of the challenge.

Authors, publishers, vendors should fix this.

--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Thursday, October 05, 2017 1:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Sales PDFs - a rant

I have to disagree. PDFs should be formatted for printing - if screen is your 
primary aim, PDF is the wrong format.

PDF is typically laid out with an intended page size and shape. Screens on the 
other hand vary from phones and tablets (portrait or landscape) through to 
large screen monitors. Responsive HTML is supposed to be the solution across 
all the different screen shapes and sizes.

On 5/10/2017 6:22 AM, Dyck, Lionel B. (TRA) wrote:
> I've received a number of PDF's from different sales organizations and 
> publishers - each one is formatted for a printing.
>
> 1.  I am not going to print the file to read it
> 2.  I am going to read it on my workstation monitor
> 3.  My workstation monitor is NOT in vertical page format but is 
> landscape orientation
> 4.  That means I have to scroll down and then back up for a multi-column 
> page
> 5.  Adobe Acrobat, and most/all PDF readers, will faithfully present the 
> supplied PDF I whatever format it receives them and thus does not reflow the 
> text/images for easy reading based on the platform
> 6.  Epub files are nice but not easily read - same for mobi (which can 
> only be read by a kindle or kindle app)
> 7.  PDF's that are intended to be read on a workstation monitor should be 
> formatted for easy reading that way
> a.  Don't have multiple columns that cross a page boundary
> b.  Don't split an article among non-contiguous pages
> c.   Keep the pages to something that can be easily read on a horizontal 
> display (think 17" display for most sitting around me or smaller if reading 
> on a laptop)
> 8.  Develop a pervasive file format that flows based on the display and 
> is easy to read and replace PDF's by 2020 (or sooner)
>

--
Andrew Rowley
Black Hill Software
+61 413 302 386

--
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: JCL 'SYMBOLS=' vs. IDCAMS SYMBOLICRELATE

2017-10-05 Thread John Eells

Steve Horein wrote:

I am in the process of building JCL to distribute resources across several
images. I've been leveraging 'SYMBOLS=' in JCL to assist in that capacity.
I've now come to a point where some conditional processing takes place, and
I am using IDCAMS IF-THEN logic to determine whether to ALTER - NEWNAME and
ALIAS - RELATE data set names to relieve GRS contention in certain
situations. The NEWNAME contains a system symbolic, which sparked the
memory of previously using SYMBOLICRELATE when it came to strategically
relating ALIAS entries.

Which lead me to wonder - will SYMBOLICRELATE functionality eventually go
away due to redundancy with the more flexible IAZSYMBL JES symbol service
being available?




As the person who got the Catalog/VSAM team to create SYMBOLICRELATE 
some time ago, *I* certainly do not want it to go away, and I doubt very 
much that it will go away.


The reason we created it was to make volumes containing things like 
subsystem data sets portable to help with software migration.  Put a 
usercat on the volume, named using the volume serial, use SYMBOLICRELATE 
for the alias, IMPORT CONNECT the catalog, and create or update a system 
symbol with the volume label.  In addition, this can make volumes with, 
for example, VSAM data sets portable.  If you use a rotating set of 
volume labels, it doesn't take much work to make the right levels of 
like-named data sets available when you replace one of these volumes.


That people found other uses for this function is a serendipitous byproduct.

--
John Eells
IBM Poughkeepsie
ee...@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: Sales PDFs - a rant

2017-10-05 Thread Andrew Rowley
I have to disagree. PDFs should be formatted for printing - if screen is 
your primary aim, PDF is the wrong format.


PDF is typically laid out with an intended page size and shape. Screens 
on the other hand vary from phones and tablets (portrait or landscape) 
through to large screen monitors. Responsive HTML is supposed to be the 
solution across all the different screen shapes and sizes.


On 5/10/2017 6:22 AM, Dyck, Lionel B. (TRA) wrote:

I've received a number of PDF's from different sales organizations and 
publishers - each one is formatted for a printing.

1.  I am not going to print the file to read it
2.  I am going to read it on my workstation monitor
3.  My workstation monitor is NOT in vertical page format but is landscape 
orientation
4.  That means I have to scroll down and then back up for a multi-column 
page
5.  Adobe Acrobat, and most/all PDF readers, will faithfully present the 
supplied PDF I whatever format it receives them and thus does not reflow the 
text/images for easy reading based on the platform
6.  Epub files are nice but not easily read - same for mobi (which can only 
be read by a kindle or kindle app)
7.  PDF's that are intended to be read on a workstation monitor should be 
formatted for easy reading that way
a.  Don't have multiple columns that cross a page boundary
b.  Don't split an article among non-contiguous pages
c.   Keep the pages to something that can be easily read on a horizontal display 
(think 17" display for most sitting around me or smaller if reading on a laptop)
8.  Develop a pervasive file format that flows based on the display and is 
easy to read and replace PDF's by 2020 (or sooner)



--
Andrew Rowley
Black Hill Software
+61 413 302 386

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