COBOL 5.1 Share presentations
Tom, Could you share the SHARE presentations you have given on COBOL V5? I just sent them over, they should be live soon at: http://www-01.ibm.com/support/docview.wss?uid=swg21634215 'Soon' meaning that more than a week later these presentations are still not there. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
Charles Mills wrote: *Most* time fields are built by the individual record cutting product. If a product wants to record time as Latvian Summer Time expressed in Roman numerals in its SMF records it is free to do so. Thus one cannot say SMF time fields are thus and such (unfortunately). Indeed true for record types 128 - 255. You fill in your own headers yourself when working with SMFWTM or SMFEWTM. Paul Gilmartin wrote: I'm shocked and dismayed. You mean that SMF (whatever that is) doesn't prefix a standard header to the information supplied by the record cutting product!? SMFWTM or SMFEWTM will fill in (partially) for you for 0 - 127, but still you can write in whatever you want with IEFU83 if you want. You are free to be shocked+dismayed. Join the already shocked auditors for free... ;-D My auditors once b*tched in my tired ears about this. Too bad. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5.1 Share presentations
Can you view the SHARE proceedings? https://share.confex.com/share/121/webprogram/Session13662.html In a message dated 09/18/13 01:23:46 Central Daylight Time, nitz-...@gmx.net writes: 'Soon' meaning that more than a week later these presentations are still not there. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5.1 Share presentations
Ed Thanks, for some reason it I must have been searching incorrectly in the SHARE.ORG presentations 13662: How to Take Advantage of the New COBOL V5 Compiler - Migration It is interesting on the ARCH statement. It says ARCH(09) for z196 and ARCH(10) for EC10. I have both, dev system is z196 and prod is zEC10. So I am not sure I would see the correct performance assistance since I would test on an z196 but run as production on zEC10. I will have to research that more. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of efinnell15 Sent: Wednesday, September 18, 2013 12:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL 5.1 Share presentations Can you view the SHARE proceedings? https://share.confex.com/share/121/webprogram/Session13662.html In a message dated 09/18/13 01:23:46 Central Daylight Time, nitz-...@gmx.net writes: 'Soon' meaning that more than a week later these presentations are still not there. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5.1 Share presentations
Thanks for the direct link. Yes, I have now downloaded the presentation. https://share.confex.com/share/121/webprogram/Session13662.html Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
Yes, the first 18 bytes are consistent. I know of no inconsistencies there for IBM or non-IBM products. But beyond that point there is no consistent standardization of time (or other) even within IBM products (Types 0 - 127). Thus we have, within the beyond-18 data for IBM products SMF14RST - 0cyydddF Local SMF42PTS - STCK SMF119TN_NITime - 0cyydddF UTC etc. I could go on and on for non-time fields but this thread is about time fields. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Wednesday, September 18, 2013 3:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CVTLSO, SMF, and RMF (was: Where environment variables ...) Charles Mills wrote: *Most* time fields are built by the individual record cutting product. If a product wants to record time as Latvian Summer Time expressed in Roman numerals in its SMF records it is free to do so. Thus one cannot say SMF time fields are thus and such (unfortunately). Indeed true for record types 128 - 255. You fill in your own headers yourself when working with SMFWTM or SMFEWTM. Paul Gilmartin wrote: I'm shocked and dismayed. You mean that SMF (whatever that is) doesn't prefix a standard header to the information supplied by the record cutting product!? SMFWTM or SMFEWTM will fill in (partially) for you for 0 - 127, but still you can write in whatever you want with IEFU83 if you want. You are free to be shocked+dismayed. Join the already shocked auditors for free... ;-D -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
Charles Mills wrote: Yes, the first 18 bytes are consistent. I know of no inconsistencies there for IBM or non-IBM products. Neither me, unless I missed something. But beyond that point there is no consistent standardization of time (or other) even within IBM products (Types 0 - 127). Thus we have, within the beyond-18 data for IBM products SMF14RST - 0cyydddF Local SMF42PTS - STCK SMF119TN_NITime - 0cyydddF UTC etc. And also for SMF70IST (0hhmmssF) and the queer format of SMF70INT (mmsstttF) or this fun one SMF70CYC (000F)! And remember that SMF42LTM (4 bytes) which is 'Time since midnight, in seconds.', mind you. ;-) Granted, usage type of each of those fields are different, but if you're not careful, you sit with wrong values especially at UNPK statement. I could go on and on for non-time fields but this thread is about time fields. Yes, AFAIK there are more sitting and waiting to ambush all of us. :-) *You should take your time to check up those time bits and pieces.* ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
LOOKAT and 2.1
Are we there yet? http://publibz.boulder.ibm.com/cgi-bin/zoslib/lookat?msgid=IEC141Irelease=ZOS%2FV2R1 ... gives me: Products Servers Enterprise Servers OS/390 LookAt LookAt - z/OS and OS/390 message help Message id IEC141I was not found. Ensure the message id is complete/correct. It is possible this message id is documented in a book that is not yet LookAt-enabled. You might try a newer release. You may use LookAt feedback to inform IBM. Fill in I miss Bookie. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Tuesday, September 17, 2013 9:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEBCOPY - MOVE On Tue, 17 Sep 2013 12:21:06 -0700, Jon Perryman jperr...@pacbell.net wrote: If you have the ISPF Productivity Toolkit' http://www.redbooks.ibm.com/abstracts/tips0936.html installed, then you can use it's batch utility. Alternatively and free, it would very easy to write a REXX exec using ISPEXEC LMMOVE and running a batch ISPF job. Jon Perryman. Not nearly as easy as PDS86, but that wasn't my question. Plus that the point of IEBCOPY - at least for me - would be performance. It happens that I need to move a selected group of members repeatedly between many (and large) PDS(E)'s. Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5.1 Share presentations
It is interesting on the ARCH statement. It says ARCH(09) for z196 and ARCH(10) for EC10. I have both, dev system is z196 and prod is zEC10. So I am not sure I would see the correct performance assistance since I would test on an z196 but run as production on zEC10. You need to use ARCH(09). If you use 10 you may not be able to run the code on the z196 processor. Bib Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DYNALLOC reusing DUMMY
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Wednesday, September 18, 2013 4:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DYNALLOC reusing DUMMY In 6532243242202950.wa.paulgboulderaim@listserv.ua.edu, on 09/17/2013 at 09:41 AM, Paul Gilmartin paulgboul...@aim.com said: You didn't read my code example. You're right; I didn't notice that the subroutine call was betwwen the allocate and the unallocate. 25.2.2.4 Using an Existing Allocation to Fulfill a Dsname Allocation Request in z/OS MVS Programming: Authorized Assembler Services Guide, SA22-7608-14: Characteristics Required in the Existing Allocation: To be used to satisfy your request, the data set that is the existing allocation must have the following properties: It must not be in use. So there is something fishy. OTOH, there is no dataset in action here. Just a ddname plus the dummy function... Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOOKAT and 2.1
Paul Gilmartin wrote:
Are we there yet?
http://publibz.boulder.ibm.com/cgi-bin/zoslib/lookat?msgid=IEC141Irelease=ZOS%2FV2R1
Ok, I tried it out at this one:
http://www-03.ibm.com/systems/z/os/zos/bkserv/lookat/index.html
I see no 2.1, only up to 1.13. How did you entered at 2.1 (yes, I can type in
that releas=ZOS... in to see where it jumps, but...)?
... gives me:
Products Servers Enterprise Servers OS/390 LookAt
LookAt - z/OS and OS/390 message help
Message id IEC141I was not found.
Ensure the message id is complete/correct.
It is possible this message id is documented in a book that is not yet
LookAt-enabled. You might try a newer release.
You may use LookAt feedback to inform IBM.
Fill in
or this ... :-D
System Programmer Response: If the error recurs blah blah blah...
I miss Bookie.
Me too. *LookAtMe!*
I don't know what I will do in the future, since I implemented, gazillion years
ago, a thing from SHARE (or was it CBTTAPE?) which let us just use PF13 (or
'any PF key') in SDSF and we are taken to a Bookie panel with the explanation
of that string where the cursor was sitting.
The best of all, that thing do a MVSVAR('SYSOPSYS') in REXX and then get the
correct bookshelf ready to display the right message for the right z/OS. No
need for us lazy lot to select a z/OS version in a lame web page. ;-)
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOOKAT and 2.1
On Wed, 18 Sep 2013 07:00:42 -0500, Elardus Engelbrecht wrote:
I see no 2.1, only up to 1.13. How did you entered at 2.1 (yes, I can type in
that releas=ZOS... in to see where it jumps, but...)?
It's magic!:
#! /bin/sh
zOSver=release=ZOS%2F${REL-V1R13} # Hammer and file to fit.
URL=http://publibz.boulder.ibm.com/cgi-bin/os390/lookat?msgid=$1$zOSver;
case `uname -s` in
*Darwin*) ${lookapp=open} $URL;;
*CYGWIN*) ${lookapp=cygstart} $URL;;
*Linux*) ${lookapp=xdg-open} $URL;;
*SunOS*) ${lookapp=gnome-open} $URL;;
esac
I miss Bookie.
Me too. *LookAtMe!*
Somewhere, IBM touts the advantage of InfoCenter in that it
is indexed by Google (Isn't Publibz/Bookie likewise, or does it
block robots?) But I see no way to limit the search to a specific
release (such as 2.1, 1.13, ...) or to a specific shelf (such as
TSO, SMP/E, z/OS Unix, ...).
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMIGRATE in parallel
So the original post was snip We've got a scenario where we should do a backup of some data to data sets and after succesful backup send the previous copy to ML2 (so we've got only the latest on DASD). Since there are multiple backup jobs, we've tried to send a TSO command (via IKJEFT01 in the jobs) to HMIGRATE the old data sets, but as it turns out, HSM mounts only one tape per LPAR (if jobs are distributed to 2 LPARs = 2 parallel migrations). Since that's a bit slow, we're looking how to get some more instances running. /snip And the OP has not responded back to us with any additional details on what problem is trying to be solved. I am guessing application backups, but it could be something else. The poster wants more than one process doing HSM migrates but HSM Serializes. There is no indication as to how many tapes (real or virtual) the poster has in the shop, the size of the tapes, or why this requirement is in place. Or what type of files this request covers, SEQ, GDGs, VSAM. I think he could do better with either more BACKUP versions of his datasets or use DFDSS or FDR to dump the files. Hopefully he will write back and provide some more detail. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Glenn Wilcock Sent: Tuesday, September 17, 2013 8:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HMIGRATE in parallel Hi, are you using the WAIT or NOWAIT option? Even though it is single tasked, NOWAIT should just submit the request and then return control back so that the job is not waiting for the migration to complete. Glenn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
SMF records are various. In particular, they confront very different temporal granularities. For some the resolution of an STCKE value is appropriate; for others the millisecond is the appropriate unit A standard header is innocuous, but standardizing their substantive timestamp formats would be inappropriate. Delusive exactitude is an old problem. The quotation is now hackneyed, but Emerson disposed of such issues long ago: . . . a foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5.1 Share presentations
On Wed, 18 Sep 2013 11:50:01 +, Bob Shannon bshan...@rocketsoftware.com wrote: You need to use ARCH(09). If you use 10 you may not be able to run the code on the z196 processor. Or maybe something less, depending on what kind of processor you have available at your DR site. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOOKAT and 2.1
Limiting searches to a particular release of something has its [limited] uses. Limiting searches to a shelf does not. The information one is seeking is often in the 'wrong' manual, and serendipity is anyway too important to be sacrificed to notional efficiency. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOOKAT and 2.1
Paul Gilmartin wrote:
I see no 2.1, only up to 1.13. How did you entered at 2.1 (yes, I can type in
that releas=ZOS... in to see where it jumps, but...)?
It's magic!:
Who is that guy who sang: 'It is a kind of Magic!' ? :-D
zOSver=release=ZOS%2F${REL-V1R13} # Hammer and file to fit.
URL=http://publibz.boulder.ibm.com/cgi-bin/os390/lookat?msgid=$1$zOSver;
Agreed! it is amazing magic! :-D Those string replacings are amazing
inventions! ;-D
Somewhere, IBM touts the advantage of InfoCenter in that it is indexed by
Google (Isn't Publibz/Bookie likewise, or does it
block robots?) But I see no way to limit the search to a specific release
(such as 2.1, 1.13, ...) or to a specific shelf (such as
TSO, SMP/E, z/OS Unix, ...).
You can limit the search, but that little details will become one of my
favourite pet peeves because of this:
You can setup on that InfoCentre your search scope where you can 'pre-select'
your bookshelves or 'scopes' to do you searches/browsing - one catch, your
actions is remembered in a tasteless 'cookie' only on that PC/Laptop... :-(
Another problem is while you select your 'scope', you will have to wait for
every elements to be downloaded before an element on the page(s) is useable
(clickable).
Now if the internet is down or time-out. don't get me started...
I like to have Bookie on my laptop, on shared network drives (not one of
course)!, on z/OS and perhaps also on IBM's InfoCentre.
Ok, enough ranting! ;-)
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
Can you tell me that an SMF 42 operation (PDS DESERV) confronts more temporal granularity than an SMF 14/15 operation (xSAM OPEN)? SMF 42 stores STCK but SMF 14/15 stores seconds*100. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Wednesday, September 18, 2013 8:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CVTLSO, SMF, and RMF (was: Where environment variables ...) SMF records are various. In particular, they confront very different temporal granularities. For some the resolution of an STCKE value is appropriate; for others the millisecond is the appropriate unit A standard header is innocuous, but standardizing their substantive timestamp formats would be inappropriate. Delusive exactitude is an old problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
I still, perversely(?), wish that every product which produces an SMF record would have a routine which can be invoked by the IFASMFDP routine which would reformat the record into a text only type output record. Perhaps in a documented XML format. Users could then fairly easily be able to read this using Java programs. Or download to another system, such as z/Linux or shudder/ Windows, to process. I like what the RACF people have done for the IRRADU00 (RACF activity) output. That's what I think would be _excellent_. On Wed, Sep 18, 2013 at 7:42 AM, John Gilmore jwgli...@gmail.com wrote: SMF records are various. In particular, they confront very different temporal granularities. For some the resolution of an STCKE value is appropriate; for others the millisecond is the appropriate unit A standard header is innocuous, but standardizing their substantive timestamp formats would be inappropriate. Delusive exactitude is an old problem. The quotation is now hackneyed, but Emerson disposed of such issues long ago: . . . a foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. 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: IEBCOPY - MOVE
On Wed, 18 Sep 2013 13:49:11 +0200, Thomas Berg thomas.b...@swedbank.se wrote: Plus that the point of IEBCOPY - at least for me - would be performance. It happens that I need to move a selected group of members repeatedly between many (and large) PDS(E)'s. So you actually have a good business case! I posted the question because I was asked by an off shore person. To them it seemed logical that there should be a *standard* utility to do this and I can see why they think that. I've never really thought about it but after I was asked I could think of many times it would have come in handy. At my current shop, and some others I have been at, changes that go in during a maintenance window are preferred to have batch jobs pre-staged. So instead of step 10 in the implementation plan being use ISPF to copy / move / rename PDS members from a to b it should be in a batch job. It ends up being quicker and less error prone. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOOKAT and 2.1
John Gilmore wrote: Limiting searches to a particular release of something has its [limited] uses. Limiting searches to a shelf does not. Could you be kind to elaborate on this? For me, limiting is about speed of search and dropping fake results. The information one is seeking is often in the 'wrong' manual, Not if you care and feed your Bookie properly. and serendipity is anyway too important to be sacrificed to notional efficiency. It is important enough. Look at OA33871 for example and there are also 'Documentation Error' I see often in APARs. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
In zOS v2R1, we hope to have a pointer to their product documentation but will no longer try to keep a copy of it. Kevin Minerley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
(MVS) data areas are not yet ready for v2r1. Kevin Minerley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Wednesday, September 18, 2013 3:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEBCOPY - MOVE On Wed, 18 Sep 2013 13:49:11 +0200, Thomas Berg thomas.b...@swedbank.se wrote: Plus that the point of IEBCOPY - at least for me - would be performance. It happens that I need to move a selected group of members repeatedly between many (and large) PDS(E)'s. So you actually have a good business case! I posted the question because I was asked by an off shore person. To them it seemed logical that there should be a *standard* utility to do this and I can see why they think that. I've never really thought about it but after I was asked I could think of many times it would have come in handy. At my current shop, and some others I have been at, changes that go in during a maintenance window are preferred to have batch jobs pre-staged. So instead of step 10 in the implementation plan being use ISPF to copy / move / rename PDS members from a to b it should be in a batch job. It ends up being quicker and less error prone. The last point isn't the least one... ! (Another point - design - is that when you have a tool that handles PDS members why restrict it to just copy (+rename) ? Moving should come naturally together with copy...) Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
On Wed, 18 Sep 2013 15:30:14 +0200, Thomas Berg thomas.b...@swedbank.se wrote: Moving should come naturally together with copy...) Exactly how someone new(ish) to the platform would see it. I've just always accepted that IEBCOPY didn't do that and I needed another job step to do the delete. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOOKAT and 2.1
Clever ;-) (and, yes, you could change the platform and the VRM) -- that is, if this were a published and agreed upon interface. Unfortunately, it is not; so, any sweet REXX, exec, or other scripts may or may not work. Also, as mentioned many months ago in IBM-MAIN, LookAt is being sunset. It is NOT available starting in zOS v2r1. The weekly LookAt build updates have been shut down for weeks. The LookAt build server is gone. Many of the pieces we used under the covers from BookManager are also no longer supported. LookAt was always provided as a free courtesy with no guarantee implied or expressed that it would always continue to run. IBM corporate direction is Information Centers (for now) and, soon, Knowledge Centers as the only means search IBM technical documentation (including for message look up akin to what LookAt provides). Kevin Minerley (LookAt's architect from it's inception). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5.1 Share presentations
The searching on the SHARE website is a bit squirrelly. Searching for 2.1 doesn't give the expected results. V2.1 works, and V2R1 works, but only if that string is in the title or description, of course. I guess it has to do with a search term starting with a number. 6.3 for z/vm and 5.1 for cics have the same problem. MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMF 120 subtype 9
Here is what I am seeing in the SMF 120-9 records: SM120PRS DSF Offset To ProductSection = 000B SM120PRL DSF Length Of Product Section = 0001 SM120PRN DSF Number Of Product Sections = 0001 These values look invalid to me… Is this a bug? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF 120 subtype 9
Looks funny to me. Offsets are *usually* even, often a multiple of 4. Length and number are *usually* halfwords (but I don't have the 120 layout in front of me). Length of 1 seems a little short. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Donald Likens Sent: Wednesday, September 18, 2013 10:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF 120 subtype 9 Here is what I am seeing in the SMF 120-9 records: SM120PRS DSF Offset To ProductSection = 000B SM120PRL DSF Length Of Product Section = 0001 SM120PRN DSF Number Of Product Sections = 0001 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF 120 subtype 9
SMF120PRS is in subtype 8 and 20 but not subtype 9 and that segment ends in byte 36 of the data portion of the record, and my SMF 120 subtype 8 records have decimal values of PRS=76 PRL=32 and PRN=1 so I believe you are misaligned. Barry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Wednesday, September 18, 2013 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF 120 subtype 9 The length of the standard SMF header is 18 bytes (X'12') so a value of X'0B' looks wrong to me. Note that certain DB2 SMF records (and therefore it could include MQ) sometimes use a blob style triplet descriptor when the data pointed to by the triplet contains a variable amount of data which is subdivided into smaller structures - so seeing lengths of X'01' or 'X00' is not always indicative of a problem in that case. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Donald Likens Sent: 18 September 2013 15:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF 120 subtype 9 Here is what I am seeing in the SMF 120-9 records: SM120PRS DSF Offset To ProductSection = 000B SM120PRL DSF Length Of Product Section = 0001 SM120PRN DSF Number Of Product Sections = 0001 These values look invalid to me… Is this a bug? -- 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
Does z/OS 2.1 support COBOL 4.2?
Hello All, I would like to know where to find what IBM products z/OS 2.1 supports. Respectfully, Willie C. Rouse Senior Mainframe Consultant Prince George's County, Maryland Office of Information Technology 9201 Basil Court/ Room B8 Largo, MD 20774 Voice: 301-883-7189 Fax: 301-883-3790 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM Information centers font size.
All, I am *trying* to embrace IBM's direction of moving internet based Documentation into Information centers. However, for me when I use them the detailed text on the right is very small. It seems to be a 7 or 8pt font. If I use the zoom feature of IE, the text gets cut off on the right side. Interestingly, Tables imbedded in the doc do not. If I check the IE config box to ignore website font sizes things get better, but then the fonts for all other websites is not pretty. What is your experience? _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF 120 subtype 9
The length of the standard SMF header is 18 bytes (X'12') so a value of X'0B' looks wrong to me. Note that certain DB2 SMF records (and therefore it could include MQ) sometimes use a blob style triplet descriptor when the data pointed to by the triplet contains a variable amount of data which is subdivided into smaller structures - so seeing lengths of X'01' or 'X00' is not always indicative of a problem in that case. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Donald Likens Sent: 18 September 2013 15:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF 120 subtype 9 Here is what I am seeing in the SMF 120-9 records: SM120PRS DSF Offset To ProductSection = 000B SM120PRL DSF Length Of Product Section = 0001 SM120PRN DSF Number Of Product Sections = 0001 These values look invalid to me… Is this a bug? -- 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: IBM Information centers font size.
I have in the past with IE had to check the COMPATABILITY VIEW under TOOLs to get the Info center to display correctly. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Wednesday, September 18, 2013 8:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM Information centers font size. All, I am *trying* to embrace IBM's direction of moving internet based Documentation into Information centers. However, for me when I use them the detailed text on the right is very small. It seems to be a 7 or 8pt font. If I use the zoom feature of IE, the text gets cut off on the right side. Interestingly, Tables imbedded in the doc do not. If I check the IE config box to ignore website font sizes things get better, but then the fonts for all other websites is not pretty. What is your experience? _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does z/OS 2.1 support COBOL 4.2?
Good question! Because the Software Product Compatibility Reports tool http://pic.dhe.ibm.com/infocenter/prodguid/v1r0/clarity/index.jsp doesn't know anything (yet) about z/OS V2.1. I did a fdbk about this. No answer yet. But I'm sure z/OS V2.1 supports COBOL 4.2 Often in the announcement letters under Software requirements is indicated such a thing as: Version/Release xyz or later. Didn' check the 4.2 announcement letter, but i'm sure the or later' is there. Jan On Wed, Sep 18, 2013 at 5:24 PM, Rouse, Willie wro...@co.pg.md.us wrote: Hello All, I would like to know where to find what IBM products z/OS 2.1 supports. Respectfully, Willie C. Rouse Senior Mainframe Consultant Prince George's County, Maryland Office of Information Technology 9201 Basil Court/ Room B8 Largo, MD 20774 Voice: 301-883-7189 Fax: 301-883-3790 -- 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: HMIGRATE in parallel
Hi, Please provide more detail related to your environment so that we can better help. Thanks, Glenn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does z/OS 2.1 support COBOL 4.2?
Effective ?Jan 1?, 2014, Cobol 3 and 4 prices will be raised to match Cobol 5. On Wed, Sep 18, 2013 at 10:24 AM, Rouse, Willie wro...@co.pg.md.us wrote: Hello All, I would like to know where to find what IBM products z/OS 2.1 supports. Respectfully, Willie C. Rouse -- 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: IBM Information centers font size.
Same annoying behaviour, and even worse on tablet with non-IE. On Wednesday, 18 September 2013, Jousma, David wrote: All, I am *trying* to embrace IBM's direction of moving internet based Documentation into Information centers. However, for me when I use them the detailed text on the right is very small. It seems to be a 7 or 8pt font. If I use the zoom feature of IE, the text gets cut off on the right side. Interestingly, Tables imbedded in the doc do not. If I check the IE config box to ignore website font sizes things get better, but then the fonts for all other websites is not pretty. What is your experience? _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com javascript:; 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; with the message: INFO IBM-MAIN -- S pozdravem * Mit freundlichen Grüßen * Sincerely, Peter Ondruška Česká spořitelna, a.s. CEN 8650_04, tým řešitelské centrum pro Operations Antala Staška 32/1292, Praha 4, 140 00 mobile: +420 724 500 286 mailto: pondru...@csas.cz http://www.csas.cz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does z/OS 2.1 support COBOL 4.2?
This web link has end of service dates for IBM products. http://www-01.ibm.com/software/support/lifecycle/index_e.html Regards, John K Willie Rouse of the IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 09/18/2013 10:24:08 AM: I would like to know where to find what IBM products z/OS 2.1 supports. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Information centers font size.
I will second Lizette's solution. I have ibm.com in my IE9 Compatibility Views Settings list and that seems to make it work much better on all of the ibm.com websites. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Wednesday, September 18, 2013 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Information centers font size. I have in the past with IE had to check the COMPATABILITY VIEW under TOOLs to get the Info center to display correctly. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Wednesday, September 18, 2013 8:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM Information centers font size. All, I am *trying* to embrace IBM's direction of moving internet based Documentation into Information centers. However, for me when I use them the detailed text on the right is very small. It seems to be a 7 or 8pt font. If I use the zoom feature of IE, the text gets cut off on the right side. Interestingly, Tables imbedded in the doc do not. If I check the IE config box to ignore website font sizes things get better, but then the fonts for all other websites is not pretty. What is your experience? -- 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: SMF 120 subtype 9
Are you sure of what you say? I'm pretty familiar with the DB2 trace records. In my experience, the length in the triplet is always either correct (and typically more than 1) or else zero, which means the first 16 bits of the section contains the length. Any subdivision of the section is a separate matter. The triplet length is always (IMHO) the total length of the section, or zero. The comments in the DSNDQWSP assembly support me on this. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Wednesday, September 18, 2013 11:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF 120 subtype 9 The length of the standard SMF header is 18 bytes (X'12') so a value of X'0B' looks wrong to me. Note that certain DB2 SMF records (and therefore it could include MQ) sometimes use a blob style triplet descriptor when the data pointed to by the triplet contains a variable amount of data which is subdivided into smaller structures - so seeing lengths of X'01' or 'X00' is not always indicative of a problem in that case. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF 120 subtype 9
I have definitely seen a zero length field - and I seem to recall also seeing x'01' as well. I did report a few bugs in this area to IBM a while ago although my memory is slightly faded. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: 18 September 2013 16:44 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF 120 subtype 9 Are you sure of what you say? I'm pretty familiar with the DB2 trace records. In my experience, the length in the triplet is always either correct (and typically more than 1) or else zero, which means the first 16 bits of the section contains the length. Any subdivision of the section is a separate matter. The triplet length is always (IMHO) the total length of the section, or zero. The comments in the DSNDQWSP assembly support me on this. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Wednesday, September 18, 2013 11:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF 120 subtype 9 The length of the standard SMF header is 18 bytes (X'12') so a value of X'0B' looks wrong to me. Note that certain DB2 SMF records (and therefore it could include MQ) sometimes use a blob style triplet descriptor when the data pointed to by the triplet contains a variable amount of data which is subdivided into smaller structures - so seeing lengths of X'01' or 'X00' is not always indicative of a problem in that case. -- 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: Does z/OS 2.1 support COBOL 4.2?
Re. Effective ?Jan 1?, 2014, Cobol 3 and 4 prices will be raised to match Cobol True. But going COBOL 5.1 may possibly be a serious migration/upgrade project. Look at several COBOL 5.1 and/or PDSE threads earlier this month, all the consequence of the 5.1 executables having to reside in PDSEs, no longer in PDSs. PDS/E, Shared Dasd, and COBOL V5https://listserv.ua.edu/cgi-bin/wa?A1=ind1309L=ibm-main#59 *(81 messages) *entre autres jan On Wed, Sep 18, 2013 at 5:39 PM, Mike Schwab mike.a.sch...@gmail.comwrote: Effective ?Jan 1?, 2014, Cobol 3 and 4 prices will be raised to match Cobol 5. On Wed, Sep 18, 2013 at 10:24 AM, Rouse, Willie wro...@co.pg.md.us wrote: Hello All, I would like to know where to find what IBM products z/OS 2.1 supports. Respectfully, Willie C. Rouse -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF 120 subtype 9
TRIPLETs validation has ALWAYS been the NUMBER of entries; the offset and lengths may or may not have data, but if the NUMBER of entries is non-zero, the segment exists. ZERO LENGTH segments with NON ZERO NUMBER was introduced by DB2 several versions ago, and they are VALID and documented that that zero length just tells you that the actual length is in the first two bytes at the offset. Barry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Wednesday, September 18, 2013 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF 120 subtype 9 I have definitely seen a zero length field - and I seem to recall also seeing x'01' as well. I did report a few bugs in this area to IBM a while ago although my memory is slightly faded. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: 18 September 2013 16:44 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF 120 subtype 9 Are you sure of what you say? I'm pretty familiar with the DB2 trace records. In my experience, the length in the triplet is always either correct (and typically more than 1) or else zero, which means the first 16 bits of the section contains the length. Any subdivision of the section is a separate matter. The triplet length is always (IMHO) the total length of the section, or zero. The comments in the DSNDQWSP assembly support me on this. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Wednesday, September 18, 2013 11:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF 120 subtype 9 The length of the standard SMF header is 18 bytes (X'12') so a value of X'0B' looks wrong to me. Note that certain DB2 SMF records (and therefore it could include MQ) sometimes use a blob style triplet descriptor when the data pointed to by the triplet contains a variable amount of data which is subdivided into smaller structures - so seeing lengths of X'01' or 'X00' is not always indicative of a problem in that case. -- 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
SPAM or ?
All: I received this email a few minutes ago. I have not been active on the RACF for a year . Anyone else get something similar? ++ +PASTE+++ Hi Ed, I found your email address from google groups on RACF. Your expertise and help is required for a situation that we have right now and are looking for some expert advice. We have a situation where access to CICS region is enabled through security software RACF using application group profile. There are additional controls such as the respective different Transaction classes or Program Table Classes under RACF General Resource control, as well as the respective User Group profiles that controls the access of user to the respective different countries applications. What is impact of having DFHSIP – Bypass Password Protection set to YES in this case. Thanks for all the help. Regards, Anupam Sarda +END PASTE +++ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
EMC DLm8000 and synchronous update
So, I have been asked to review the EMC DLm8000 and how its synchronous replication for 200km, replication works for the mainframe. I would think if your primary and secondary sites are greater than 200Km it would have to be asynchronous. Does anyone current have this in their shop and wish to share? Or has anyone reviewed this hardware and come to any conclusions they wish to share. Thanks Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
Maybe it's time for an IEBPDS or IEBMBR utility ? :) (Or if we want follow the current logic: IEBMOVE ?) Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Wednesday, September 18, 2013 6:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEBCOPY - MOVE Mark, I had a discussion at SHARE (long time ago grant you) with an IBM type. I think I remember this from the discussion. IEBCOPY is for copying COPY does not delete the input as it is a copy. The design was never meant for moving, ie copy then deleting the source member. END conversation--- I think a solid easily made requirement for a separate utility for moving members. ie a replacement for IEHMOVE (shudder) can be made. Ed On Sep 18, 2013, at 8:36 AM, Mark Zelden wrote: On Wed, 18 Sep 2013 15:30:14 +0200, Thomas Berg thomas.b...@swedbank.se wrote: Moving should come naturally together with copy...) Exactly how someone new(ish) to the platform would see it. I've just always accepted that IEBCOPY didn't do that and I needed another job step to do the delete. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ ateExperts/ -- 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: IEBCOPY - MOVE
Mark, I had a discussion at SHARE (long time ago grant you) with an IBM type. I think I remember this from the discussion. IEBCOPY is for copying COPY does not delete the input as it is a copy. The design was never meant for moving, ie copy then deleting the source member. END conversation--- I think a solid easily made requirement for a separate utility for moving members. ie a replacement for IEHMOVE (shudder) can be made. Ed On Sep 18, 2013, at 8:36 AM, Mark Zelden wrote: On Wed, 18 Sep 2013 15:30:14 +0200, Thomas Berg thomas.b...@swedbank.se wrote: Moving should come naturally together with copy...) Exactly how someone new(ish) to the platform would see it. I've just always accepted that IEBCOPY didn't do that and I needed another job step to do the delete. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ ateExperts/ -- 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: SPAM or ?
I am occasionally active on the RACF group. I did not get any message similar to that. Doesn't really seem SPAM-ish to me. More like somebody did a Google/Bing search and your email somehow popped up. On Wed, Sep 18, 2013 at 12:03 PM, Ed Gould edgould1...@comcast.net wrote: All: I received this email a few minutes ago. I have not been active on the RACF for a year . Anyone else get something similar? ++**++** +++PASTE++**+ Hi Ed, I found your email address from google groups on RACF. Your expertise and help is required for a situation that we have right now and are looking for some expert advice. We have a situation where access to CICS region is enabled through security software RACF using application group profile. There are additional controls such as the respective different Transaction classes or Program Table Classes under RACF General Resource control, as well as the respective User Group profiles that controls the access of user to the respective different countries applications. What is impact of having DFHSIP – Bypass Password Protection set to YES in this case. Thanks for all the help. Regards, Anupam Sarda ++**+++END PASTE+** ++ --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. 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: IBM Information centers font size.
Well, so it does. Thanks for that tidbit Lizette and Peter! _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Wednesday, September 18, 2013 11:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Information centers font size. I will second Lizette's solution. I have ibm.com in my IE9 Compatibility Views Settings list and that seems to make it work much better on all of the ibm.com websites. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Wednesday, September 18, 2013 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Information centers font size. I have in the past with IE had to check the COMPATABILITY VIEW under TOOLs to get the Info center to display correctly. Lizette This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Get CPUID and srial number from JAVA code
Hi Arye, this will give you the CPUID from the first PCCA. long cvt = ZUtil.peekOSMemory(16, 4); long cvtpccat = ZUtil.peekOSMemory(cvt+764, 4); long pcca = ZUtil.peekOSMemory(cvtpccat + 0*4, 4); byte[] cpuid = new byte[12]; ZUtil.peekOSMemory(pcca+4, cpuid, 0, 12); System.out.println(new String(cpuid)); Output Example: FF112097 Matches D M=CPU Output: RESPONSE=SYS1 IEE174I 16.50.42 DISPLAY M 166 PROCESSOR STATUS ID CPU SERIAL 00 + 112097 Its z/OS dependent code. Hope it helps. Denis. -Original Message- From: Arye Shemer aryeshe...@gmail.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Tue, Sep 17, 2013 9:21 pm Subject: Re: Get CPUID and srial number from JAVA code Thank you guys, I will consider all the options. Thanks again, Arye. On 17 September 2013 18:54, Bernd Oppolzer bernd.oppol...@t-online.dewrote: I wrote an ANSI C function that fetched this information using the callable service CSRSI (System Information Service), so if nothing else helps, you should IMO be able to call this using JNI. Kind regards Bernd Am 17.09.2013 15:28, schrieb Arye Shemer: Hi, Has anyone know how I can get CPUID and machine serial number from JAVA code ? Is there a z/OS Java forum that I can get help on this issue ? thanks, Arye Shemer. --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
On Wed, 18 Sep 2013 11:52:02 -0500, Ed Gould wrote:
Mark,
I had a discussion at SHARE (long time ago grant you) with an IBM type.
I think I remember this from the discussion.
IEBCOPY is for copying
COPY does not delete the input as it is a copy.
The design was never meant for moving, ie copy then deleting the
source member.
END conversation---
I think a solid easily made requirement for a separate utility for
moving members. ie a replacement for IEHMOVE (shudder) can be made.
Why not an enhancement to IEBCOPY. DRY.
But what about ISPF LM services in batch? Is the COPY/MOVE
utility readily available that way? And doesn't ISPF nowadays
employ IEBCOPY for copying. (I find some 30-year samples
suggesting that SPFCOPY exist{s|ed} as an interface to IEBCOPY).
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5.1 Share presentations
AMEN. Thank goodness for search engines! I just went in and did SHARE COBOL v5.1 and got to the confex site. It seems to be more 'googlized' than SHARE.ORG-hint,hint... In a message dated 09/18/13 09:33:05 Central Daylight Time, maryanne4...@gmail.com writes: The searching on the SHARE website is a bit squirrelly. Searching for 2.1 doesn't give the expected results. V2.1 works, and V2R1 works, but only if that string is in the title or description, of course. I guess it has to do with a search term starting with a number. 6.3 for z/vm and 5.1 for cics have the same problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Get CPUID and srial number from JAVA code
Minor suggestion; should use: System.out.println( new String(cpuid, ZFile.DEFAULT_EBCDIC_CODE_PAGE) ); otherwise, the default file.encoding is used, which is very often ISO8849-1 on z/OS Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Sep 18, 2013 at 12:08 PM, Denis Gäbler denisgaeb...@netscape.netwrote: Hi Arye, this will give you the CPUID from the first PCCA. long cvt = ZUtil.peekOSMemory(16, 4); long cvtpccat = ZUtil.peekOSMemory(cvt+764, 4); long pcca = ZUtil.peekOSMemory(cvtpccat + 0*4, 4); byte[] cpuid = new byte[12]; ZUtil.peekOSMemory(pcca+4, cpuid, 0, 12); System.out.println(new String(cpuid)); Output Example: FF112097 Matches D M=CPU Output: RESPONSE=SYS1 IEE174I 16.50.42 DISPLAY M 166 PROCESSOR STATUS ID CPU SERIAL 00 + 112097 Its z/OS dependent code. Hope it helps. Denis. -Original Message- From: Arye Shemer aryeshe...@gmail.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Tue, Sep 17, 2013 9:21 pm Subject: Re: Get CPUID and srial number from JAVA code Thank you guys, I will consider all the options. Thanks again, Arye. On 17 September 2013 18:54, Bernd Oppolzer bernd.oppol...@t-online.de wrote: I wrote an ANSI C function that fetched this information using the callable service CSRSI (System Information Service), so if nothing else helps, you should IMO be able to call this using JNI. Kind regards Bernd Am 17.09.2013 15:28, schrieb Arye Shemer: Hi, Has anyone know how I can get CPUID and machine serial number from JAVA code ? Is there a z/OS Java forum that I can get help on this issue ? thanks, Arye Shemer. --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.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: IBM Information centers font size.
I echo the thanks - and thanks, David for asking it. I just started a new job and get to use IE instead of Firefox and my old eyes were getting tired trying to read the tiny font. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Wednesday, September 18, 2013 12:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Information centers font size. Well, so it does. Thanks for that tidbit Lizette and Peter! _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Wednesday, September 18, 2013 11:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Information centers font size. I will second Lizette's solution. I have ibm.com in my IE9 Compatibility Views Settings list and that seems to make it work much better on all of the ibm.com websites. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Wednesday, September 18, 2013 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Information centers font size. I have in the past with IE had to check the COMPATABILITY VIEW under TOOLs to get the Info center to display correctly. Lizette This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NSA foils much internet encryption
“NIST would not deliberately weaken a cryptographic standard.” (But the NSA wouldn't let a cryptographic standard out the door unless they could decode it. - Mike Schwab). http://www.scientificamerican.com/article.cfm?id=nsa-nist-encryption-scandal Computer scientists for years suspected that such a backdoor existed in Dual_EC_DRBG. Security researchers from Eindhoven University of Technology in the Netherlands noted in May 2006 that the algorithm was insecurehttp://www.propublica.org/documents/item/786216-cryptanalysis-of-the-dual-elliptic-curveand that an attack against it was easy enough to launch on “an ordinary PC”. The following year two Microsoft engineers flagged Dual_EC_DRBG as potentially containing a backdoor (pdf)http://rump2007.cr.yp.to/15-shumow.pdf, although they stopped short of accusing NIST and the NSA of inserting it there intentionally. NIST denies the accusationshttp://www.nist.gov/director/cybersecuritystatement-091013.cfm, pointing out on its Web site that the agency is “required by statute” to consult with the NSA and stating, “NIST would not deliberately weaken a cryptographic standard.”* Yet that is exactly what appears to have happened. Documents provided by Snowden show the spy agency played a crucial role in writing the standard that NIST is now cautioning against using, the *New York Times* reportedhttp://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/?_r=0. NIST published the cryptography standard in 2006, and the International Organization for Standardization (ISO) later adopted it for its 163 member countries. Despite Dual_EC_DRBG’s known flaws, prominent tech companies including Microsoft, Cisco, Symantec and RSA include the algorithm in their product’s cryptographic librarieshttp://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.htmlprimarily because they need it to be eligible for government contracts, cryptographer Bruce Schneier https://www.schneier.com/ says. It is up to the private sector companies that buy these products to decide whether to enable the algorithm, something they are unlikely to do in the case of Dual_EC_DRBG, according to RSA’s Juels. On Tue, Sep 17, 2013 at 6:15 AM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In 8913686268300756.wa.ip4workgmail@listserv.ua.edu, on 09/16/2013 at 10:56 AM, J.P. ip4w...@gmail.com said: NSA is pushing ecliptic curves NSA is into astronomy? -- -- 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: HMIGRATE in parallel
snip I agree. What should not be hard for HSM to create multiple migration subtasks (each with its own ML2 dataset) and have the master task pass one dataset at a time to each subtask (ie: The subtask does the same work as is currently done for a migrate). As each subtask finishes it asks the master task for another dataset to migrate. That way you are migrating as many datasets in parallel as you have subtasks allocated. /snip ...which is exactly what HSM provides for automatic migration, under the control of maxmigration task setsys settings. What HSM does not provide is such controls/parallelism for manual (HMIGRATE) migration, which is what the OP is seemingly wanting, but no explanation as to why he wants this, as opposed to letting HSM do what it was designed to do. The OP's statement seems a perfect fit with GDG processing, whereby only the latest version is retained online using standard HSM/SMS-mgmtclas '# GDGS ONLINE' settings. But as others have already stated, more details from the OP are needed. On 18 September 2013 16:36, Glenn Wilcock wilc...@us.ibm.com wrote: Hi, Please provide more detail related to your environment so that we can better help. Thanks, Glenn -- 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: IEBCOPY - MOVE
In cae1xxdhg5hqaoa9r7aod0fisynm77e7coyv_e88rp0xzkah...@mail.gmail.com, on 09/17/2013 at 10:07 PM, John Gilmore jwgli...@gmail.com said: Moreover, it had some interesting design features. It was the first IBM utility that allocated and used a dataset without having a JCL DD statement for it available. No. it has always had a bad rap. It earned it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DYNALLOC reusing DUMMY
In
a90e503c23f97441b05ee302853b0e629018f88...@fspas01ev010.fspa.myntet.se,
on 09/18/2013
at 01:52 PM, Thomas Berg thomas.b...@swedbank.se said:
OTOH, there is no dataset in action here. Just a ddname plus the
dummy function...
Equivalent to DSN('NULLFILE')
The key point is reusing an allocation that is not marked as not in
use. That's squirrely even if it's documented somewhere.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DYNALLOC reusing DUMMY
On Wed, 18 Sep 2013 17:10:12 -0400, Shmuel Metz (Seymour J.) wrote:
on 09/18/2013 at 01:52 PM, Thomas Berg said:
OTOH, there is no dataset in action here. Just a ddname plus the
dummy function...
Equivalent to DSN('NULLFILE')
The key point is reusing an allocation that is not marked as not in
use. That's squirrely even if it's documented somewhere.
Is in use synonymous with open? Squirrely either way. How can
the user control the in use status? Does either TSO ALLOCATE
or BPXWDYN provide a keyword?
I discover that:
o If I supply an attribute, such as recfm(V,B), the allocation is not
reused, even if I supplied the identical attribute on the previous
allocation.
o path('/dev/./null') pathopts(ORDWR) is not reused. ( path('/dev/null')
is converted to DUMMY for some documented but inexplicable reason.)
What economy is gained by reusing/converting allocations? I doubt that
it offsets the complexity, confusion, and pitfalls the practice inflicts on
programmers.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DYNALLOC reusing DUMMY
Paul Gilmartin wrote: Is in use synonymous with open? Squirrely either way. How can the user control the in use status? Does either TSO ALLOCATE or BPXWDYN provide a keyword? They are not the same. You can have a dataset closed, allocated to the step and the in use attribute set or not set. There is a SVC99 verb code (x'05') to remove the in use attribute. Unfortunately it only removes the in use attribute for the DSN and DD. It does not remove the SYSZVOLS enqueue on a tape volume. Another SVC99 brain deadness when trying to reuse a dynamically allocated output dataset for stacking on the same unit in a application program. I have no idea if there is a secret keyword for it in BPXWDYN. Alan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Get CPUID and srial number from JAVA code
Ah, the x'FF' indicates running under VM. Good for you! Cheers. Best Regards, Doug On Sep 18, 2013, at 13:08, Denis Gäbler denisgaeb...@netscape.net wrote: Hi Arye, this will give you the CPUID from the first PCCA. long cvt = ZUtil.peekOSMemory(16, 4); long cvtpccat = ZUtil.peekOSMemory(cvt+764, 4); long pcca = ZUtil.peekOSMemory(cvtpccat + 0*4, 4); byte[] cpuid = new byte[12]; ZUtil.peekOSMemory(pcca+4, cpuid, 0, 12); System.out.println(new String(cpuid)); Output Example: FF112097 Matches D M=CPU Output: RESPONSE=SYS1 IEE174I 16.50.42 DISPLAY M 166 PROCESSOR STATUS ID CPU SERIAL 00 + 112097 Its z/OS dependent code. Hope it helps. Denis. -Original Message- From: Arye Shemer aryeshe...@gmail.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Tue, Sep 17, 2013 9:21 pm Subject: Re: Get CPUID and srial number from JAVA code Thank you guys, I will consider all the options. Thanks again, Arye. On 17 September 2013 18:54, Bernd Oppolzer bernd.oppol...@t-online.dewrote: I wrote an ANSI C function that fetched this information using the callable service CSRSI (System Information Service), so if nothing else helps, you should IMO be able to call this using JNI. Kind regards Bernd Am 17.09.2013 15:28, schrieb Arye Shemer: Hi, Has anyone know how I can get CPUID and machine serial number from JAVA code ? Is there a z/OS Java forum that I can get help on this issue ? thanks, Arye Shemer. --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.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: IBM Information centers font size.
All, Obvious someone mad a bad decision in regard to viewing manuals with small font. Especially us olde folks ..even with a 27 inch monitor... Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Sep 18, 2013, at 11:33 AM, Lizette Koehler stars...@mindspring.com wrote: I have in the past with IE had to check the COMPATABILITY VIEW under TOOLs to get the Info center to display correctly. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Wednesday, September 18, 2013 8:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM Information centers font size. All, I am *trying* to embrace IBM's direction of moving internet based Documentation into Information centers. However, for me when I use them the detailed text on the right is very small. It seems to be a 7 or 8pt font. If I use the zoom feature of IE, the text gets cut off on the right side. Interestingly, Tables imbedded in the doc do not. If I check the IE config box to ignore website font sizes things get better, but then the fonts for all other websites is not pretty. What is your experience? _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -- 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: PDS/E, Shared Dasd, and COBOL V5
Tom Conley offers a nomination: Simple. With Java, we didn't have 40 years and thousands (millions?) of libraries to convert. That's what makes COBOL different, the conversion effort. Java had no code base to convert, so we could start new. OK, that's an interesting hypothesis for why z/OS customers running Java on z/OS might be different than z/OS customers running COBOL on z/OS. The problem is the hypothesis makes an assumption which is not correct. I thought another poster in this thread made it clear, but I'll explain the point again. Adopting Enterprise COBOL 5.1 does NOT require: 1. Recompiling every (or even any) COBOL program you already have; 2. Moving every (or even any) COBOL program you already have from PDS to PDSE; 3. (For the vast majority of programs) changing code if/when you do recompile. NONE of those steps are prerequisites for adopting Enterprise COBOL 5.1. Let's be very clear about the facts and not prone to hyperbole. You can keep older binaries, and you can keep them in PDSes. If your source code compiles in Enterprise COBOL 4.x then in the vast majority of cases it'll also compile unmodified in Enterprise COBOL 5.1 and behave exactly the same way (except more efficiently). The few exceptions will be if you have used a new reserve word. It has always been thus in every COBOL release upgrade, so by now you should be well familiar with that reserve word phenomenon and how to address it. (Ask if not.) The PDSE prerequisite is *only* for programs you compile with Enterprise COBOL 5.1. And this is why I'm asking the question and would like to hear some more constructive responses, because this is a very important point. I suspect that, in most COBOL shops with that 40 years and thousands (millions?) scenario you will be doing ONLY the following (at a high level) to adopt Enterprise COBOL 5.1: a. Allow running newly created and newly recompiled programs from PDSEs (if you haven't already); b. Keep existing unmodified COBOL binaries in PDSes forever; c. Make sure your development, testing, and runtime environments behave as you intend across PDSes and PDSEs. That would be the typical upgrade scenario at a high level, I would imagine. That is *exactly* what z/OS customers adopting Java on z/OS did (and do). Most of them also have large portfolios of COBOL (and/or PL/I and/or Assembler, etc.) applications that they write, test, deploy, and maintain. Java (their new compiler) requires PDSEs. So they implemented PDSEs if they didn't have them already. New and newly recompiled (Java) code goes into the PDSEs, and they run, successfully. Existing code stays put unless and until they have a compelling reason to touch it. This path worked and works. It's the same darn path except even simpler, isn't it? In this case there's no second programming language (all is COBOL), no new runtime environment (s) (unless you wish), and Enterprise COBOL 5.1-compiled programs interact directly with previously compiled COBOL programs even more easily -- no JNI, for example -- and just as you would expect. OK, let's summarize again I. IBM faced a *technical* decision (as Frank posted earlier -- thanks Frank). To adopt the (fabulous and continually getting more fabulous) Java backend for the next generation Enterprise COBOL compiler also required accepting Java backend prerequisites, and that means PDSEs, a technology IBM first introduced in 1989. The other choice was not to use the Java backend technology, in which case I'd/we'd be reading at least another decade worth of complaints here about how IBM is not delivering COBOL improvements. Yes, IBM looked really carefully at all alternatives, even some crazy ones. I think IBM really, really made the right fundamental technical decision here -- absolutely the right decision to promote a vibrant and growing future for COBOL. II. The PDSE prerequisite is *only* for COBOL programs that you compile specifically with Enterprise COBOL 5.1. Most of you will not and should not do anything with any previously compiled COBOL program in a PDS, especially if it is not particularly relevant to peak utilization, unless and until a developer needs to change the older program and recompile it. This is innovation via evolution, not revolution. III. IBM is not forcing you to do anything, including start your single version charge (SVC) period for Enterprise COBOL 5.1 until you've had a chance to trial it. However, the rest of the world often forces change. (Darn those pesky smartphones! Now get off my lawn. :-)) Again, how much is XX% code efficiency improvement worth? How much is constraint relief worth? There are many customers enjoying the benefits of Enterprise COBOL 5.1 now, and many more will follow. Some of them might be your competitors. But even within your own organizations, business users are going to seek ways to get their jobs done, with or without you. (Cue John Gilmore here.) Innovate (or at least improve), or die. I know IBM understands that. My
Re: PDS/E, Shared Dasd, and COBOL V5
-SNIP-- The problem is the hypothesis makes an assumption which is not correct. I thought another poster in this thread made it clear, but I'll explain the point again. Adopting Enterprise COBOL 5.1 does NOT require: 1. Recompiling every (or even any) COBOL program you already have; That was clear from day one. 2. Moving every (or even any) COBOL program you already have from PDS to PDSE; That is a BIG issue. And not allowing sharing across plexes is another big issue 3. (For the vast majority of programs) changing code if/when you do recompile. NONE of those steps are prerequisites for adopting Enterprise COBOL 5.1. Let's be very clear about the facts and not prone to hyperbole. You can keep older binaries, and you can keep them in PDSes. If your source code compiles in Enterprise COBOL 4.x then in the vast majority of cases it'll also compile unmodified in Enterprise COBOL 5.1 and behave exactly the same way (except more efficiently). The few exceptions will be if you have used a new reserve word. It has always been thus in every COBOL release upgrade, so by now you should be well familiar with that reserve word phenomenon and how to address it. (Ask if not.) I can't WAIT for the first PMR. How about compiling into a PDSe do we have a better idea what is going on. I had a problem where they wanted to change the compiler (maybe a bug in the compiler) and now all of a sudden there is a PDSe requirement in addition to just recompiling. Also I think either you (or IBM) is in for a big surprise as not many companies keep their COBOL (or for that matter any language) in an PDSe library. We never had issues with them (OEM libraries) just PDSe's. Ed The PDSE prerequisite is *only* for programs you compile with Enterprise COBOL 5.1. And this is why I'm asking the question and would like to hear some more constructive responses, because this is a very important point. I suspect that, in most COBOL shops with that 40 years and thousands (millions?) scenario you will be doing ONLY the following (at a high level) to adopt Enterprise COBOL 5.1: a. Allow running newly created and newly recompiled programs from PDSEs (if you haven't already); b. Keep existing unmodified COBOL binaries in PDSes forever; c. Make sure your development, testing, and runtime environments behave as you intend across PDSes and PDSEs. That would be the typical upgrade scenario at a high level, I would imagine. That is *exactly* what z/OS customers adopting Java on z/OS did (and do). Most of them also have large portfolios of COBOL (and/or PL/I and/or Assembler, etc.) applications that they write, test, deploy, and maintain. Java (their new compiler) requires PDSEs. So they implemented PDSEs if they didn't have them already. New and newly recompiled (Java) code goes into the PDSEs, and they run, successfully. Existing code stays put unless and until they have a compelling reason to touch it. This path worked and works. It's the same darn path except even simpler, isn't it? In this case there's no second programming language (all is COBOL), no new runtime environment (s) (unless you wish), and Enterprise COBOL 5.1-compiled programs interact directly with previously compiled COBOL programs even more easily -- no JNI, for example -- and just as you would expect. OK, let's summarize again I. IBM faced a *technical* decision (as Frank posted earlier -- thanks Frank). To adopt the (fabulous and continually getting more fabulous) Java backend for the next generation Enterprise COBOL compiler also required accepting Java backend prerequisites, and that means PDSEs, a technology IBM first introduced in 1989. The other choice was not to use the Java backend technology, in which case I'd/we'd be reading at least another decade worth of complaints here about how IBM is not delivering COBOL improvements. Yes, IBM looked really carefully at all alternatives, even some crazy ones. I think IBM really, really made the right fundamental technical decision here -- absolutely the right decision to promote a vibrant and growing future for COBOL. II. The PDSE prerequisite is *only* for COBOL programs that you compile specifically with Enterprise COBOL 5.1. Most of you will not and should not do anything with any previously compiled COBOL program in a PDS, especially if it is not particularly relevant to peak utilization, unless and until a developer needs to change the older program and recompile it. This is innovation via evolution, not revolution. III. IBM is not forcing you to do anything, including start your single version charge (SVC) period for Enterprise COBOL 5.1 until you've had a chance to trial it. However, the rest of the world often forces change. (Darn those pesky smartphones! Now get off my lawn. :-)) Again, how much is XX% code efficiency improvement worth? How much is constraint
Re: PDS/E, Shared Dasd, and COBOL V5
You're an enthusiastic prosletisor of the panacea you believe in! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Timothy Sipples sipp...@sg.ibm.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 19 Sep 2013 11:52:35 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 Tom Conley offers a nomination: Simple. With Java, we didn't have 40 years and thousands (millions?) of libraries to convert. That's what makes COBOL different, the conversion effort. Java had no code base to convert, so we could start new. OK, that's an interesting hypothesis for why z/OS customers running Java on z/OS might be different than z/OS customers running COBOL on z/OS. The problem is the hypothesis makes an assumption which is not correct. I thought another poster in this thread made it clear, but I'll explain the point again. Adopting Enterprise COBOL 5.1 does NOT require: 1. Recompiling every (or even any) COBOL program you already have; 2. Moving every (or even any) COBOL program you already have from PDS to PDSE; 3. (For the vast majority of programs) changing code if/when you do recompile. NONE of those steps are prerequisites for adopting Enterprise COBOL 5.1. Let's be very clear about the facts and not prone to hyperbole. You can keep older binaries, and you can keep them in PDSes. If your source code compiles in Enterprise COBOL 4.x then in the vast majority of cases it'll also compile unmodified in Enterprise COBOL 5.1 and behave exactly the same way (except more efficiently). The few exceptions will be if you have used a new reserve word. It has always been thus in every COBOL release upgrade, so by now you should be well familiar with that reserve word phenomenon and how to address it. (Ask if not.) The PDSE prerequisite is *only* for programs you compile with Enterprise COBOL 5.1. And this is why I'm asking the question and would like to hear some more constructive responses, because this is a very important point. I suspect that, in most COBOL shops with that 40 years and thousands (millions?) scenario you will be doing ONLY the following (at a high level) to adopt Enterprise COBOL 5.1: a. Allow running newly created and newly recompiled programs from PDSEs (if you haven't already); b. Keep existing unmodified COBOL binaries in PDSes forever; c. Make sure your development, testing, and runtime environments behave as you intend across PDSes and PDSEs. That would be the typical upgrade scenario at a high level, I would imagine. That is *exactly* what z/OS customers adopting Java on z/OS did (and do). Most of them also have large portfolios of COBOL (and/or PL/I and/or Assembler, etc.) applications that they write, test, deploy, and maintain. Java (their new compiler) requires PDSEs. So they implemented PDSEs if they didn't have them already. New and newly recompiled (Java) code goes into the PDSEs, and they run, successfully. Existing code stays put unless and until they have a compelling reason to touch it. This path worked and works. It's the same darn path except even simpler, isn't it? In this case there's no second programming language (all is COBOL), no new runtime environment (s) (unless you wish), and Enterprise COBOL 5.1-compiled programs interact directly with previously compiled COBOL programs even more easily -- no JNI, for example -- and just as you would expect. OK, let's summarize again I. IBM faced a *technical* decision (as Frank posted earlier -- thanks Frank). To adopt the (fabulous and continually getting more fabulous) Java backend for the next generation Enterprise COBOL compiler also required accepting Java backend prerequisites, and that means PDSEs, a technology IBM first introduced in 1989. The other choice was not to use the Java backend technology, in which case I'd/we'd be reading at least another decade worth of complaints here about how IBM is not delivering COBOL improvements. Yes, IBM looked really carefully at all alternatives, even some crazy ones. I think IBM really, really made the right fundamental technical decision here -- absolutely the right decision to promote a vibrant and growing future for COBOL. II. The PDSE prerequisite is *only* for COBOL programs that you compile specifically with Enterprise COBOL 5.1. Most of you will not and should not do anything with any previously compiled COBOL program in a PDS, especially if it is not particularly relevant to peak utilization, unless and until a developer needs to change the older program and recompile it. This is innovation via evolution, not revolution. III. IBM is not forcing you to do anything, including start your single version charge (SVC) period for Enterprise COBOL 5.1 until you've had a chance to trial it. However, the rest of the world often forces change. (Darn those pesky smartphones! Now get off my lawn. :-)) Again, how
Re: EMC DLm8000 and synchronous update
We have a client here replicating between DLm6000s less than 200km apart and it's asynch. Works well. I'd agree that 200km would probably be asynch for a production workload. Don't know about DLm8000s but I suspect they're similar to DLm6000s. cheers Peter On Wed, 18 Sep 2013 09:55:54 -0700, Lizette Koehler stars...@mindspring.com wrote: So, I have been asked to review the EMC DLm8000 and how its synchronous replication for 200km, replication works for the mainframe. I would think if your primary and secondary sites are greater than 200Km it would have to be asynchronous. Does anyone current have this in their shop and wish to share? Or has anyone reviewed this hardware and come to any conclusions they wish to share. Thanks Lizette -- 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: IBM Information centers font size.
On Wed, 18 Sep 2013 23:05:35 -0400, Scott Ford wrote: All, Obvious someone mad a bad decision in regard to viewing manuals with small font. Especially us olde folks ..even with a 27 inch monitor... Has anyone mentioned the notice: http://www-03.ibm.com/systems/z/os/zos/bkserv/ Note: If you are using Microsoft Internet Explorer® 8 or 9 to view our Information Centers and the font is too small, please see this article http://support.microsoft.com/kb/956197 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
