Re: Sales PDFs - a rant
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
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
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....
On Thu, Oct 5, 2017 at 6:19 PM, scott Fordwrote: > 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....
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
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
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 Millswrote: > 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
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
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
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
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
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
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?
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?
>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
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....
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
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
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
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
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
Thanx Dave! From: David BettenTo: 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
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 Millswrote: > 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....
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
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....
>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
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?
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
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?
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
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?
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
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
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?
"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
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
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
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