Re: PCI DSS compliance question
Cross posting to RACF and IBMMAIN And just when I thought the discussion had lessened, out on TECHTARGET are a couple of articles on PCI If you are interested, here is the link to the website. Videos, books and articles on PCI DSS. Note: They will ask you to join if you are not a subscriber (free) and then you get lots of adverts. So be forewarned. http://www.bitpipe.com/fulfillment/1406042659_218 Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article on COBOL's inevitable return
Fairly decent except for several major points of nonsense: *The Department of Defense even decreed that all businesses must run on COBOL in the 1960s.* A ludicrous assertion. *But the even bigger reason not to rock the boat is the sheer size and cost of replacing billions of lines of COBOL that exist today. Many of these programs contain sensitive information about people, like social security numbers, banking info, credit card info and healthcare records.* Sorry, no -- *programs* don't contain that data. Programs read/process data. WTF. *Without a doubt, it is a challenge to find a developer in Cobol who is not nearing retirement age,* That would surprise IBM Academic Initiative institutions. Yes, the overall point is valid: COBOL skills are retiring/dying. So more folks will learn it. Whoopee. Some of the comments are funny; one of my favorites is the guy who says he'd take $12,500 less per year to avoid COBOL. I understand his sentiment, just am baffled by his precision. OTOH, maybe it's like the old joke about the boss and the secretary (We've established that, we're negotiating...). On Tue, Jul 28, 2015 at 9:55 AM, John McKown john.archie.mck...@gmail.com wrote: http://blog.hackerrank.com/the-inevitable-return-of-cobol/ A fairly decent article. It doesn't appear to be a piece designed to promote some vendor or another. Not in depth, but with some good truths plainly stated. It might even be understandable to a Windows person. OOPS, there I go being tacky again. -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: All Flow-riders: z/OS V2.2 Migration Workflow Available
Thanks Marna, Just an aside - from the website Marna provided: This tool is not supported by the IBM Service organization, but rather by the tool owner on a best-can-do basis. Please report any problems, suggestions, or comments to zos...@us.ibm.com. If you would like to see a short demo on using the z/OS V2R1 migration workflow, visit the IBM z/OSMF V2.1 Migration Workflow Demo on YouTube - https://www.youtube.com/watch?v=7QBhC2yMEwM Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Marna WALLE Sent: Wednesday, July 29, 2015 7:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: All Flow-riders: z/OS V2.2 Migration Workflow Available If you are currently using z/OSMF V2.1 and want to see what you need to do for a migration from V2.1 to V2.2 (or even R13 to V2.2), the z/OS V2.2 Migration Workflow is available at http://www- 03.ibm.com/systems/z/os/zos/tools/downloads/zosmf-zos-v2r2-migration- workflow.html . In fact, if you are on the z/OS V2.1 to V2.2 migration path and use this Workflow you don't need to use the z/OS V2.2 Migration book! That's because the Workflow is identical to the book, and even has two additional benefits: 1) the Workflow will now invoke IBM Health Checker for z/OS checks were appropriate to determine migration applicability, and 2) the optional capability to provide feedback to IBM on each migration action and on your overall release migration. If you are on the R13 to V2.2 migration path, you can still use the z/OS V2.2 Migration Workflow, however you won't be able to fire it up until after you've started z/OSMF V2.2 on your target system. Those on the R13 path still will need to use the z/OS V2.2 Migration book. As always, if you have any questions about this migration workflow, please let me know! -Marna WALLE z/OS System Installation, IBM Poughkeepsie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article on COBOL's inevitable return
On Wed, 29 Jul 2015 12:11:56 -0400, Ted MacNEIL wrote: Why is it so ludicrous? The USDOD did develop COBOL for some reasom. And a generation later, they likewise required ADA. I don't know if that was ever countermanded. I know a programmer who argued that his assignment could not be accomplished in ADA. He was given an exemption and allowed to use assembler. � Original Message � From: zMan Sent: Wednesday, July 29, 2015 11:28 *The Department of Defense even decreed that all businesses must run on COBOL in the 1960s.* A ludicrous assertion. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article on COBOL's inevitable return
Hence NOT ludicrous! - -teD - Original Message From: Vince Coen Sent: Wednesday, July 29, 2015 12:54 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Article on COBOL's inevitable return I think you will find that was a demand (?) that all applications developed on behalf of the military (well at least the US Navy) had to be in Cobol - if nothing else to help with standards, maintenance migration. You have to remember that there was more than one supplier of mainframes in the 60's such as IBM, Burroughs, Honeywell Univac, Sperry Rand to name but a few and in Europe OK, the U.K., ICL (ICL), English Electric and of course the first commercial computer the LEO 3 and these were also included in UK manuals of the time. Check out the copyleft notice that is shown in all Cobol manuals and should also be in books although not in my one copy of a Cobol book - Cobol unleashed! . Vince Cobol since 1963, IT since 1961 (from 1403, 7094, 360/30 et al). On 29/07/15 17:20, Paul Gilmartin wrote: On Wed, 29 Jul 2015 12:11:56 -0400, Ted MacNEIL wrote: Why is it so ludicrous? The USDOD did develop COBOL for some reasom. And a generation later, they likewise required ADA. I don't know if that was ever countermanded. I know a programmer who argued that his assignment could not be accomplished in ADA. He was given an exemption and allowed to use assembler. � Original Message � From: zMan Sent: Wednesday, July 29, 2015 11:28 *The Department of Defense even decreed that all businesses must run on COBOL in the 1960s.* A ludicrous assertion. -- gil -- 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: Article on COBOL's inevitable return
On 07/29/2015 11:28 AM, zMan wrote: Fairly decent except for several major points of nonsense: SNIP *But the even bigger reason not to rock the boat is the sheer size and cost of replacing billions of lines of COBOL that exist today. Many of these programs contain sensitive information about people, like social security numbers, banking info, credit card info and healthcare records.* Sorry, no -- *programs* don't contain that data. Programs read/process data. WTF. SNIPPAGE I have worked on COBOL programs written under DOS (as in Mainframe), and who knows what the original O/S was in other cases where the COBOL code had originally been written (including NON-IBM systems). Some of those programs had hard coded SSNs, CC account#s, etc. However, I must confess, other than comments about the health (or lack thereof) of certain people and their programming abilities (or lack thereof), I've not seen healthcare records in source. I have read some interesting comments in German when the rest of the source was in English... I have also worked on ALC, RPG, RPGII on various systems where similar data was also hard coded in the source. So, yes, *programs* may well contain that data. As far as I am [was] concerned they shouldn't have, but, they did. And it was because of resource restrictions on/from the original systems where developed. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Aliases (was: z/OS 2.2 announcement)
Must a symbol replace an entire qualifier, or part of one, such as SYMBOLICRELATE(TEST.JNULL.CL.CNTL)? The symbol can replace part of a qualifier as in your example: DEFINE ALIAS (NAME(TEST.NEWER.JCL.CNTL) SYMBOLICRELATE(TEST.JNULL.CL.CNTL)) Referencing TEST.NEWER.JCL.CNTL translates to TEST.JCL.CNTL. Is the SYMBOLICRELATE name limited to 44 characters before substitution, or only after substitution? It is limited to 44 characters before substitution: DEFINE ALIAS (NAME(TEST.NEWER.JCL.CNTL) - SYMBOLICRELATE( - TEST.SOME.DATASET.NULL.NAME.LONGER.THAN.FORTY4)) IDC3201I CONSTANT 'TEST.SOME.DATASET.' EXCEEDS LENGTH LIMIT IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS 12 Bill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, July 29, 2015 10:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Aliases (was: z/OS 2.2 announcement) On 2015-07-29, at 09:59, Skeldum, William wrote: A symbolic symbol can be defined as: 'NULL='. I then defined an alias as follows: DEFINE ALIAS (NAME(TEST.NEW.JCL.CNTL) SYMBOLICRELATE(TEST.NULL.JCL.CNTL)) When I reference TEST.NEW.JCL.CNTL in DSLIST (ISPF 3.4) TEST.JCL.CNTL is displayed. Thanks for the research. I haven't the entitlement to create a symbolic symbol in my systemic system. Yaaay! o Hmmm... That ought to be a standard feature, just like DSN NULLFILE. (Does NULLFILE appear in a catalog?) o Nice: it swallows the terminating . so you don't get TEST..JCL.CNTL. o Must a symbol replace an entire qualifier, or part of one, such as SYMBOLICRELATE(TEST.JNULL.CL.CNTL)? o Is the SYMBOLICRELATE name limited to 44 characters before substitution, or only after substitution? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Aliases (was: z/OS 2.2 announcement)
A symbolic symbol can be defined as: 'NULL='. I then defined an alias as follows: DEFINE ALIAS (NAME(TEST.NEW.JCL.CNTL) SYMBOLICRELATE(TEST.NULL.JCL.CNTL)) When I reference TEST.NEW.JCL.CNTL in DSLIST (ISPF 3.4) TEST.JCL.CNTL is displayed. Bill -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, July 29, 2015 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Aliases (was: z/OS 2.2 announcement) On Wed, 29 Jul 2015 14:38:50 +, Staller, Allan wrote: ... Once *EVERYTHING has moved to the alias, the original dataset can be deleted and the process repeated in the other direction. This make take several (days, weeks, months,) depending on the installations policies and procedures. ... Merely re-point the existing alias to the new dataset. No problem here. Is there a utility to enumerate all ALIASes to a given RELATED DSN? If not, there's a problem.The information must exist: if the RELATED DSN is deleted, the ALIASes are quietly deleted. Integrity flaw: deleting a DSN when ALIASes exist ought at least to require confirmation. There's a minuscule timing window. SYMBOLIC aliases would be better; they persist when the referenced data set is deleted. But a SYMBOLIC alias must contain at least one substitutable symbol. Stupid rule! (Might one define a system symbol naming the null string, for incorporation in SYMBOLIC aliases?) -- gil -- 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 electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article on COBOL's inevitable return
I think you will find that was a demand (?) that all applications developed on behalf of the military (well at least the US Navy) had to be in Cobol - if nothing else to help with standards, maintenance migration. You have to remember that there was more than one supplier of mainframes in the 60's such as IBM, Burroughs, Honeywell Univac, Sperry Rand to name but a few and in Europe OK, the U.K., ICL (ICL), English Electric and of course the first commercial computer the LEO 3 and these were also included in UK manuals of the time. Check out the copyleft notice that is shown in all Cobol manuals and should also be in books although not in my one copy of a Cobol book - Cobol unleashed! . Vince Cobol since 1963, IT since 1961 (from 1403, 7094, 360/30 et al). On 29/07/15 17:20, Paul Gilmartin wrote: On Wed, 29 Jul 2015 12:11:56 -0400, Ted MacNEIL wrote: Why is it so ludicrous? The USDOD did develop COBOL for some reasom. And a generation later, they likewise required ADA. I don't know if that was ever countermanded. I know a programmer who argued that his assignment could not be accomplished in ADA. He was given an exemption and allowed to use assembler. � Original Message � From: zMan Sent: Wednesday, July 29, 2015 11:28 *The Department of Defense even decreed that all businesses must run on COBOL in the 1960s.* A ludicrous assertion. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Life cycle chart
On 7/29/2015 3:53 AM, Gibney, David Allen,Jr wrote: I used z/OS lifecycle and didn't come close :( Dave, Google gave me this link for z z/OS lifecycle search, first hit: http://www-01.ibm.com/software/support/systemsz/lifecycle/ Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article on COBOL's inevitable return
Why is it so ludicrous? The USDOD did develop COBOL for some reasom. - -teD - Original Message From: zMan Sent: Wednesday, July 29, 2015 11:28 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Article on COBOL's inevitable return Fairly decent except for several major points of nonsense: *The Department of Defense even decreed that all businesses must run on COBOL in the 1960s.* A ludicrous assertion. *But the even bigger reason not to rock the boat is the sheer size and cost of replacing billions of lines of COBOL that exist today. Many of these programs contain sensitive information about people, like social security numbers, banking info, credit card info and healthcare records.* Sorry, no -- *programs* don't contain that data. Programs read/process data. WTF. *Without a doubt, it is a challenge to find a developer in Cobol who is not nearing retirement age,* That would surprise IBM Academic Initiative institutions. Yes, the overall point is valid: COBOL skills are retiring/dying. So more folks will learn it. Whoopee. Some of the comments are funny; one of my favorites is the guy who says he'd take $12,500 less per year to avoid COBOL. I understand his sentiment, just am baffled by his precision. OTOH, maybe it's like the old joke about the boss and the secretary (We've established that, we're negotiating...). On Tue, Jul 28, 2015 at 9:55 AM, John McKown john.archie.mck...@gmail.com wrote: http://blog.hackerrank.com/the-inevitable-return-of-cobol/ A fairly decent article. It doesn't appear to be a piece designed to promote some vendor or another. Not in depth, but with some good truths plainly stated. It might even be understandable to a Windows person. OOPS, there I go being tacky again. -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Aliases (was: z/OS 2.2 announcement)
On 2015-07-29, at 09:59, Skeldum, William wrote: A symbolic symbol can be defined as: 'NULL='. I then defined an alias as follows: DEFINE ALIAS (NAME(TEST.NEW.JCL.CNTL) SYMBOLICRELATE(TEST.NULL.JCL.CNTL)) When I reference TEST.NEW.JCL.CNTL in DSLIST (ISPF 3.4) TEST.JCL.CNTL is displayed. Thanks for the research. I haven't the entitlement to create a symbolic symbol in my systemic system. Yaaay! o Hmmm... That ought to be a standard feature, just like DSN NULLFILE. (Does NULLFILE appear in a catalog?) o Nice: it swallows the terminating . so you don't get TEST..JCL.CNTL. o Must a symbol replace an entire qualifier, or part of one, such as SYMBOLICRELATE(TEST.JNULL.CL.CNTL)? o Is the SYMBOLICRELATE name limited to 44 characters before substitution, or only after substitution? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Different Security Products in a Sysplex
I have been asked if both RACF and Top Secret can run on different LPARs in the same parallel sysplex. I recall that NO that is not permitted but am having trouble finding where it is written. Any guidance is appreciated. CNA SURETY voted the #1 Carrier for Surety Bonds by PROPERTYCASUALTY360 Survey NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article on COBOL's inevitable return
I was in the US ARMY in Europe in the early 1970's. We were developing a COBOL based system that was entirely COBOL except for some BDAM DB access that was needed. The only assembler was an ONLINE system that could be used to gain access to the online DB. The system was to be used world wide (once it was chosen). Unfortunately the cost of 360/50's was to high and instead a DOS based system was chosen. AFAIK the mandate was COBOL through out (except some BDAM and online) the system was met. I also did some assembler coding but it could have been replaced by IBM utilities but it would have been cumbersome. Ed On Jul 29, 2015, at 1:01 PM, Gerhard Adam wrote: *The Department of Defense even decreed that all businesses must run on COBOL in the 1960s.* A ludicrous assertion. Actually not ludicrous. This occurred when I was in the military (1973) and was definitely an objective. The goal was that all applications would be written in COBOL. The only exceptions were programs that couldn't achieve their function. As a result, I was responsible for writing a number of access method interfaces [because we used a customized BDAM type of structure] so that COBOL programs could call these routines to read/ write records. Definitely true. Adam -- 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: 1403 at 60Hz
I remember that! Used to dump my card boxes and listings on the floor with regularity. I seem to picture a screw-drive driven by a dedicated motor a little bigger than a grapefruit. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Wednesday, July 29, 2015 11:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 1403 at 60Hz t...@vse2pdf.com (Tony Thigpen) wrote: Talked to a guy that has done several of these conversions in years past. This is what he said: snip The only motor in the 1403 ran a hydraulic pump. Should be able to just replace the motor with a current off-the-shelf motor as speed is not critical. There are at least two motors, one for the print train (or chain) and one for the hydraulic unit. The 1403N1 might also have a third motor for the power cover; I just can't recall how that worked now, but I think the hydraulic unit only ran the carriage (and the carriage tape assembly), and the print train motor certainly only drove the print train, so I suppose I'm leaning toward the existence of that third motor... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sort :- Last Month and Year
Ron, Look up DATE2-1 in here http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ice1ca60/3.15?DT=20110608113434#TBLPASDTCN Thanks, Kolusu DFSORT Development IBM Corporation IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 07/29/2015 12:52:35 PM: From: Ron Thomas ron5...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/29/2015 12:52 PM Subject: Sort :- Last Month and Year Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi . is there a way using SORT to get the lastmonth year in a file. For e.g if i am running today i need to get the o/p in a file as 201506 (year and last month) . If you are running in the comming January 2016 then it should be 201512 etc.. Thanks Ron T -- 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: Different Security Products in a Sysplex
Interesting. At the time we crafted the bronze-plex, I could not see any way to share multiple RACF databases within a sysplex because AFAIK RACF sharing requires fixed structure names: IRRXCF00_P001 and IRRXCF00_B001. Has that requirement changed? If not, I don't see how I could share two different databases. As it is, two guys share one database using those structures, while the third guy uses a different database non-shared, i.e. no structure needed. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Conley Sent: Wednesday, July 29, 2015 1:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Different Security Products in a Sysplex On 7/29/2015 4:13 PM, J O Skip Robinson wrote: I refrained from answering earlier because we're an all-RACF shop. However, I can comment the extent of (RACF) database sharing. We have a bronze-plex that resulted from bolting together two previously independent parallel sysplexes, one with two members and another with only one. These sysplexes were independent for business reasons. RACF databases could not be combined because a given userid or dataset might be defined in both with different access levels. The result is a single parallel sysplex in which the two like members share everything, while the third shares only enough to qualify for sysplex licensing. (An IBM-invented game.) This arrangement is far from ideal, but the two birds-of-a-feather share RACF while the odd man out has his own non-shared database. It's been working OK for several years. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com I run into this all the time, especially when production, test, and sandbox LPARs are mixed into a sysplex. Typically the production systems share a RACF DB, the test systems share a different RACF DB, etc. Works fine. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sort :- Last Month and Year
Thanks a lot Kolusu !! It worked perfect .. Regards Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Aliases (was: z/OS 2.2 announcement)
PATH does not equal ALIAS in VSAM... snip BTW, is there any good reason that an alias for a non-VSAM data set is called an ALIAS while an alias for a VSAM data set is called a PATH? (Might some object have both, in which case the distinction is meaningful?) /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Different Security Products in a Sysplex
On 7/29/2015 4:33 PM, J O Skip Robinson wrote: Interesting. At the time we crafted the bronze-plex, I could not see any way to share multiple RACF databases within a sysplex because AFAIK RACF sharing requires fixed structure names: IRRXCF00_P001 and IRRXCF00_B001. Has that requirement changed? If not, I don't see how I could share two different databases. As it is, two guys share one database using those structures, while the third guy uses a different database non-shared, i.e. no structure needed. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com I'm pretty sure we did not caysh the RACF database. As I remember, the sysplex sharing bits were not enabled in ICHRDSNT. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 at 60Hz
g...@ugcs.caltech.edu (glen herrmannsfeldt) wrote: snip https://ia601603.us.archive.org/35/items/bitsavers_ibm140xSY2nd3MaintManualDec71_21919776/SY24-3395-3_1403_Models_N1_and_3_Maint_Manual_Dec71.pdf See page 31 (or 1-26). Induction motors run slightly slower (they aren't perfectly synchronous) than some integer fraction of the line frequency. At 60Hz, one might run at 3500 RPM or 1750RPM or 1150RPM (a little slip below 3600, 1800, and 1200). A 50Hz motor might run at 2900 RPM or 1450RPM or 950RPM. But it isn't hard to change the gear coupling the motor to the chain or train, such that the speed is right. Proving, once again, that documentation beats memory! (I think the 3211 was direct drive and I confused the two.) I might tanke a trip down memory lane later by paging through the book...I haven't seen that book in a Long, Long Time! -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Different Security Products in a Sysplex
My bad for not clarifying what I meant by 'sharing'. The reason I wanted structure-sharing is that--at least back when this all started in the 90s--sysplex sharing makes certain changes available immediately to all members without having to issue REFRESH on every system. Not sure if that difference is still in effect... . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Conley Sent: Wednesday, July 29, 2015 1:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Different Security Products in a Sysplex On 7/29/2015 4:33 PM, J O Skip Robinson wrote: Interesting. At the time we crafted the bronze-plex, I could not see any way to share multiple RACF databases within a sysplex because AFAIK RACF sharing requires fixed structure names: IRRXCF00_P001 and IRRXCF00_B001. Has that requirement changed? If not, I don't see how I could share two different databases. As it is, two guys share one database using those structures, while the third guy uses a different database non-shared, i.e. no structure needed. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com I'm pretty sure we did not caysh the RACF database. As I remember, the sysplex sharing bits were not enabled in ICHRDSNT. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 at 60Hz
Talked to a guy that has done several of these conversions in years past. This is what he said: The DC to the hammers comes from the controller, not the 1403. So, not an issue. The only motor in the 1403 ran a hydraulic pump. Should be able to just replace the motor with a current off-the-shelf motor as speed is not critical. Some units had a very small transformer for a few circuits. If so, you should be able to just use a current off-the-shelf transformer. Tony Thigpen glen herrmannsfeldt wrote on 07/28/2015 07:23 PM: I wonder if anyone knows what has to change to move a 1403 from 50Hz to 60Hz? If they use synchronous motors, then some belts or gears would be different. For transformers, you need more iron in the core for 50Hz, so 50Hz transformers should be fine at 60Hz, but not always the other way around. That might also be true for motors, but synchronous motors will run faster. thanks, -- glen -- 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: Aliases (was: z/OS 2.2 announcement)
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, July 29, 2015 8:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Aliases (was: z/OS 2.2 announcement) Is there a utility to enumerate all ALIASes to a given RELATED DSN? If not, there's a problem.The information must exist: if the RELATED DSN is deleted, the ALIASes are quietly deleted. LISTCAT ENT(dsn) ALL. If dsn is not VSAM, the RELATED field in the output will show all aliases, if any. If dsn is VSAM, the PATH field will show any aliases. If dsn is a path or alias, the RELATED field will show the true name of the target -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 at 60Hz
t...@vse2pdf.com (Tony Thigpen) wrote: Talked to a guy that has done several of these conversions in years past. This is what he said: snip The only motor in the 1403 ran a hydraulic pump. Should be able to just replace the motor with a current off-the-shelf motor as speed is not critical. There are at least two motors, one for the print train (or chain) and one for the hydraulic unit. The 1403N1 might also have a third motor for the power cover; I just can't recall how that worked now, but I think the hydraulic unit only ran the carriage (and the carriage tape assembly), and the print train motor certainly only drove the print train, so I suppose I'm leaning toward the existence of that third motor... snip -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: All Flow-riders: z/OS V2.2 Migration Workflow Available
Thanks, Lizette! (We should put you on payroll :)!) For those that care, that zos...@us.ibm.com email comes directly into my inbox. -Marna WALLE z/OS System Install, IBM Poughkeepsie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 at 60Hz
(snip, I wrote) From one 1403 manual, I see some gears that are specified for 50Hz and for 60Hz, but I am not sure what they do. As far as I can tell, the train is powered by a synchronous motor (or close enough). I presume you don't want the train running 1.2 times as fast. (snip, John Eells wrote) The print train (or chain, depending on model) in 1403s was direct driven. The vertical motor shaft was keyed to the print train. If the motor speed were to change, the hammer flight timing set in the 2821 control unit would be far off, resulting in the printing of partial characters at best. Whether they compensated for this with motor wiring, a different motor, or different flight timing settings, I have no idea. (The factory took care of that stuff!) I don't recall any gears in the 1403, so it would be interesting to know where any were that got changed for operation at 50Hz. Are you sure they are gears and not hydraulic unit drive belt pulleys? https://ia601603.us.archive.org/35/items/bitsavers_ibm140xSY2nd3MaintManualDec71_21919776/SY24-3395-3_1403_Models_N1_and_3_Maint_Manual_Dec71.pdf See page 31 (or 1-26). Induction motors run slightly slower (they aren't perfectly synchronous) than some integer fraction of the line frequency. At 60Hz, one might run at 3500 RPM or 1750RPM or 1150RPM (a little slip below 3600, 1800, and 1200). A 50Hz motor might run at 2900 RPM or 1450RPM or 950RPM. But it isn't hard to change the gear coupling the motor to the chain or train, such that the speed is right. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
c/XDC
C C++ and Metal C support in z/XDC is coming soon. See www.xdc.com for more information. Dave Cole ColeSoft Marketing 414 Third Street, NE Charlottesville, VA 22902 EADDRESS:mailto:dbc...@colesoft.comdbc...@colesoft.com Home page: www.colesoft.com LinkedIn:www.xdc.com Facebook:www.facebook.com/colesoftware YouTube: www.youtube.com/user/colesoftware -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article on COBOL's inevitable return
Well, actually the original statement WAS self-apparently ludicrous because it stated that U.S. DoD decreed ALL businesses would use COBOL, period, and DoD has never had that much authority. DoD had zero control over businesses that did not work on defense contracts for DoD, and even those with defense contracts could only be constrained to DoD standards in the work they did on behalf of those defense contracts. The use of an unconstrained ALL is what made it ludicrous. The considerable influence of DoD as a major consumer forced the availability of COBOL and later ADA support and set the standards for code written for DoD projects, but DoD is not [yet] omnipotent. JC Ewing On 07/29/2015 12:04 PM, Ted MacNEIL wrote: Hence NOT ludicrous! - -teD - Original Message From: Vince Coen Sent: Wednesday, July 29, 2015 12:54 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Article on COBOL's inevitable return I think you will find that was a demand (?) that all applications developed on behalf of the military (well at least the US Navy) had to be in Cobol - if nothing else to help with standards, maintenance migration. You have to remember that there was more than one supplier of mainframes in the 60's such as IBM, Burroughs, Honeywell Univac, Sperry Rand to name but a few and in Europe OK, the U.K., ICL (ICL), English Electric and of course the first commercial computer the LEO 3 and these were also included in UK manuals of the time. Check out the copyleft notice that is shown in all Cobol manuals and should also be in books although not in my one copy of a Cobol book - Cobol unleashed! . Vince Cobol since 1963, IT since 1961 (from 1403, 7094, 360/30 et al). On 29/07/15 17:20, Paul Gilmartin wrote: On Wed, 29 Jul 2015 12:11:56 -0400, Ted MacNEIL wrote: Why is it so ludicrous? The USDOD did develop COBOL for some reasom. And a generation later, they likewise required ADA. I don't know if that was ever countermanded. I know a programmer who argued that his assignment could not be accomplished in ADA. He was given an exemption and allowed to use assembler. � Original Message � From: zMan Sent: Wednesday, July 29, 2015 11:28 *The Department of Defense even decreed that all businesses must run on COBOL in the 1960s.* A ludicrous assertion. -- gil -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Different Security Products in a Sysplex
Givens, Dennis W. wrote: I have been asked if both RACF and Top Secret can run on different LPARs in the same parallel sysplex. I recall that NO that is not permitted but am having trouble finding where it is written. It could be possible as long each database of each security system is *NOT* shared by more than one LPAR. You can only share ONE RACF DB in a Sysplex. Other LPARs can also share the same database or use their own *NON-SHARED* RACF database. What I wrote in previous sentence is *only* about RACF. I'm not sure how you could use different security products in one Sysplex, I also lost my sources [1] about this, but I believe you should setup standards for each LPAR and ensure nothing is shared at all - GRS, catalogs, security DBs, volsers, etc. You may have trouble managing your JES2/3 + HSM + SMS + Tape management resources across those LPARs using different security systems and standards as enforced by them. I may be wrong, but I have been in a Sysplex where each LPAR is having own RACF DB (only RACF in all LPARs) and that is already a dangerous, but manage-able minefield. [2] In fact - Sysplex is just this - sharing resources across LPARs - RACF or TopSecret, JES2/3, HSM, SMS, GRS/MIMS, Catalogs, volsers, etc. You could post your questions on RACF-L, I certainly know that there are good gurus who successfully converted from one security system to RACF. They would have a lot to tell you what to do... Good luck. Groete / Greetings Elardus Engelbrecht [1] - Google does not help me here - too much false search results... [2] - I eventually got standards the same across all those LPARs and then have one after the other LPARs move over to one *shared* RACF database in the Sysplex. Eventually all unshared databases were deleted. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Different Security Products in a Sysplex
On 7/29/2015 4:13 PM, J O Skip Robinson wrote: I refrained from answering earlier because we're an all-RACF shop. However, I can comment the extent of (RACF) database sharing. We have a bronze-plex that resulted from bolting together two previously independent parallel sysplexes, one with two members and another with only one. These sysplexes were independent for business reasons. RACF databases could not be combined because a given userid or dataset might be defined in both with different access levels. The result is a single parallel sysplex in which the two like members share everything, while the third shares only enough to qualify for sysplex licensing. (An IBM-invented game.) This arrangement is far from ideal, but the two birds-of-a-feather share RACF while the odd man out has his own non-shared database. It's been working OK for several years. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com I run into this all the time, especially when production, test, and sandbox LPARs are mixed into a sysplex. Typically the production systems share a RACF DB, the test systems share a different RACF DB, etc. Works fine. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 at 60Hz
The 370/165 and 168 ran on high frequency power. 400 or 420 HZ if I remember correctly. There may be others, but I worked with those. We had MG sets in sound proof enclosures. If you opened the covers you had better have sound proof ear muffs on. They were LOUD. Eh, what did you say? Chris Blaicher Technical Architect Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barry Merrill Sent: Wednesday, July 29, 2015 2:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 1403 at 60Hz Most old pre-solid-state aircraft electronics also used 415 Hz because transformers are much lighter at higher frequency. Barry Merrill, EI/W5GN (where I use 14MHZ!) Herbert W. “Barry” Merrill, PhD President-Programmer MXG Software Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229-5112 ba...@mxg.com Fax: 214 350 3694 – Still works, received as email Tel: 214 351 1966 – Unreliable, please use email www.mxg.comHomePage: FAQ answers most questions ad...@mxg.com License Forms, Invoice, Payment, ftp information supp...@mxg.comTechnical Issues MXG-L FREE ListServer http://www.mxg.com/mxg-l_listserver/ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of William Donzelli Sent: Wednesday, July 29, 2015 12:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 1403 at 60Hz As I understood it at the time, larger S/360 and S/370 also used motor-generator power supplies, though I don't know the output frequency. The higher frequency means less filtering. Generally 415 Hz. Why this odd number is beyond me. The Hitachi clones also used 415 Hz. But yes, you can run a CDC machine off an electronic converter. Most CDC Cybers are indeed 400 Hz machines, but a few were made with a 60 Hz option. Last week I drove to Texas to get a small departmental Cyber 932 - they were all (or nearly all?) 60 Hz models. -- Will -- 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 ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Different Security Products in a Sysplex
On 7/29/2015 2:07 PM, Givens, Dennis W. wrote: I have been asked if both RACF and Top Secret can run on different LPARs in the same parallel sysplex. I recall that NO that is not permitted but am having trouble finding where it is written. Any guidance is appreciated. CNA SURETY voted the #1 Carrier for Surety Bonds by PROPERTYCASUALTY360 Survey NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The main restriction here is that MVS commands entered on a TopSecret system but destined for a RACF system (e.g. RO *ALL) will likely fail, due to a proprietary SAF interface. IBM and CA were in discussions to fix this, but I haven't heard if they were able to yet. Your options are to turn off OPERCMDS on RACF (shyeah, right), or don't issue the commands from TopSecret systems. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS V2.2 PDFs available on the web
I finally found the z/OS V2.2 GA PDFs on the web.Thought others may want to see them too. http://www.ibm.com/systems/z/os/zos/library/bkserv/v2r2pdf/index.html Happy reading. -Marna WALLE z/OS System Installation, IBM Poughkeepsie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Sort :- Last Month and Year
Hi . is there a way using SORT to get the lastmonth year in a file. For e.g if i am running today i need to get the o/p in a file as 201506 (year and last month) . If you are running in the comming January 2016 then it should be 201512 etc.. Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Different Security Products in a Sysplex
I refrained from answering earlier because we're an all-RACF shop. However, I can comment the extent of (RACF) database sharing. We have a bronze-plex that resulted from bolting together two previously independent parallel sysplexes, one with two members and another with only one. These sysplexes were independent for business reasons. RACF databases could not be combined because a given userid or dataset might be defined in both with different access levels. The result is a single parallel sysplex in which the two like members share everything, while the third shares only enough to qualify for sysplex licensing. (An IBM-invented game.) This arrangement is far from ideal, but the two birds-of-a-feather share RACF while the odd man out has his own non-shared database. It's been working OK for several years. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Wednesday, July 29, 2015 12:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Different Security Products in a Sysplex Givens, Dennis W. wrote: I have been asked if both RACF and Top Secret can run on different LPARs in the same parallel sysplex. I recall that NO that is not permitted but am having trouble finding where it is written. It could be possible as long each database of each security system is *NOT* shared by more than one LPAR. You can only share ONE RACF DB in a Sysplex. Other LPARs can also share the same database or use their own *NON-SHARED* RACF database. What I wrote in previous sentence is *only* about RACF. I'm not sure how you could use different security products in one Sysplex, I also lost my sources [1] about this, but I believe you should setup standards for each LPAR and ensure nothing is shared at all - GRS, catalogs, security DBs, volsers, etc. You may have trouble managing your JES2/3 + HSM + SMS + Tape management resources across those LPARs using different security systems and standards as enforced by them. I may be wrong, but I have been in a Sysplex where each LPAR is having own RACF DB (only RACF in all LPARs) and that is already a dangerous, but manage-able minefield. [2] In fact - Sysplex is just this - sharing resources across LPARs - RACF or TopSecret, JES2/3, HSM, SMS, GRS/MIMS, Catalogs, volsers, etc. You could post your questions on RACF-L, I certainly know that there are good gurus who successfully converted from one security system to RACF. They would have a lot to tell you what to do... Good luck. Groete / Greetings Elardus Engelbrecht [1] - Google does not help me here - too much false search results... [2] - I eventually got standards the same across all those LPARs and then have one after the other LPARs move over to one *shared* RACF database in the Sysplex. Eventually all unshared databases were deleted. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Aliases (was: z/OS 2.2 announcement)
On Wed, 29 Jul 2015 11:26:58 -0700, retired mainframer wrote: LISTCAT ENT(dsn) ALL. If dsn is not VSAM, the RELATED field in the output will show all aliases, if any. If dsn is VSAM, the PATH field will show any aliases. If dsn is a path or alias, the RELATED field will show the true name of the target Seems to work. Thanks. BTW, is there any good reason that an alias for a non-VSAM data set is called an ALIAS while an alias for a VSAM data set is called a PATH? (Might some object have both, in which case the distinction is meaningful?) Is there any way to prevent deletion of a data set while an ALIAS (or PATH) exists? Extra credit if your solution precludes timing windows. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article on COBOL's inevitable return
http://www.cs.yale.edu/homes/tap/Files/hopper-story.html Grace Hopper on Codasyl committee helped write the first Cobol specs and participated in the first Cobol Compiler test in 1959. On Wed, Jul 29, 2015 at 11:54 AM, Vince Coen vbc...@gmail.com wrote: I think you will find that was a demand (?) that all applications developed on behalf of the military (well at least the US Navy) had to be in Cobol - if nothing else to help with standards, maintenance migration. You have to remember that there was more than one supplier of mainframes in the 60's such as IBM, Burroughs, Honeywell Univac, Sperry Rand to name but a few and in Europe OK, the U.K., ICL (ICL), English Electric and of course the first commercial computer the LEO 3 and these were also included in UK manuals of the time. Check out the copyleft notice that is shown in all Cobol manuals and should also be in books although not in my one copy of a Cobol book - Cobol unleashed! . Vince Cobol since 1963, IT since 1961 (from 1403, 7094, 360/30 et al). On 29/07/15 17:20, Paul Gilmartin wrote: On Wed, 29 Jul 2015 12:11:56 -0400, Ted MacNEIL wrote: Why is it so ludicrous? The USDOD did develop COBOL for some reasom. And a generation later, they likewise required ADA. I don't know if that was ever countermanded. I know a programmer who argued that his assignment could not be accomplished in ADA. He was given an exemption and allowed to use assembler. � Original Message � From: zMan Sent: Wednesday, July 29, 2015 11:28 *The Department of Defense even decreed that all businesses must run on COBOL in the 1960s.* A ludicrous assertion. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 at 60Hz
g...@ugcs.caltech.edu (glen herrmannsfeldt) wrote: (snip, someone wrote) I don't know power consuption, but nowadays it's not hard to get semiconductor-based power supply which generater 60Hz or 50Hz or any value you want (within some range). (snip, someone else wrote) (sorry for losing the attributions, I am copying from usenet) I suppose a 1403 requires a couple kW. That shouldn't be an obstacle: Yes, but an added complication. From one 1403 manual, I see some gears that are specified for 50Hz and for 60Hz, but I am not sure what they do. As far as I can tell, the train is powered by a synchronous motor (or close enough). I presume you don't want the train running 1.2 times as fast. The print train (or chain, depending on model) in 1403s was direct driven. The vertical motor shaft was keyed to the print train. If the motor speed were to change, the hammer flight timing set in the 2821 control unit would be far off, resulting in the printing of partial characters at best. Whether they compensated for this with motor wiring, a different motor, or different flight timing settings, I have no idea. (The factory took care of that stuff!) I don't recall any gears in the 1403, so it would be interesting to know where any were that got changed for operation at 50Hz. Are you sure they are gears and not hydraulic unit drive belt pulleys? snip -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: c/XDC
Very cool Dave! Thanks for your continual product improvements! Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Cole Sent: Wednesday, July 29, 2015 2:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: c/XDC C C++ and Metal C support in z/XDC is coming soon. See www.xdc.com for more information. Dave Cole -- 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: 1403 at 60Hz
(snip, someone wrote) I don't know power consuption, but nowadays it's not hard to get semiconductor-based power supply which generater 60Hz or 50Hz or any value you want (within some range). (snip, someone else wrote) (sorry for losing the attributions, I am copying from usenet) I suppose a 1403 requires a couple kW. That shouldn't be an obstacle: Yes, but an added complication. From one 1403 manual, I see some gears that are specified for 50Hz and for 60Hz, but I am not sure what they do. As far as I can tell, the train is powered by a synchronous motor (or close enough). I presume you don't want the train running 1.2 times as fast. I suspect that only synchronous motors need to run off a power converter, which would allow for a smaller converter, but more complication in wiring. https://en.wikipedia.org/wiki/High-voltage_direct_current CDC equipment circa 1970 used 400 Hz with rotating mechanical converters. As I understood it at the time, larger S/360 and S/370 also used motor-generator power supplies, though I don't know the output frequency. The higher frequency means less filtering. But yes, you can run a CDC machine off an electronic converter. Provided considerable immunity to power surges. Flywheels? -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 at 60Hz
As I understood it at the time, larger S/360 and S/370 also used motor-generator power supplies, though I don't know the output frequency. The higher frequency means less filtering. Generally 415 Hz. Why this odd number is beyond me. The Hitachi clones also used 415 Hz. But yes, you can run a CDC machine off an electronic converter. Most CDC Cybers are indeed 400 Hz machines, but a few were made with a 60 Hz option. Last week I drove to Texas to get a small departmental Cyber 932 - they were all (or nearly all?) 60 Hz models. -- Will -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article on COBOL's inevitable return
*The Department of Defense even decreed that all businesses must run on COBOL in the 1960s.* A ludicrous assertion. Actually not ludicrous. This occurred when I was in the military (1973) and was definitely an objective. The goal was that all applications would be written in COBOL. The only exceptions were programs that couldn't achieve their function. As a result, I was responsible for writing a number of access method interfaces [because we used a customized BDAM type of structure] so that COBOL programs could call these routines to read/write records. Definitely true. Adam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 at 60Hz
Most old pre-solid-state aircraft electronics also used 415 Hz because transformers are much lighter at higher frequency. Barry Merrill, EI/W5GN (where I use 14MHZ!) Herbert W. “Barry” Merrill, PhD President-Programmer MXG Software Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229-5112 ba...@mxg.com Fax: 214 350 3694 – Still works, received as email Tel: 214 351 1966 – Unreliable, please use email www.mxg.comHomePage: FAQ answers most questions ad...@mxg.com License Forms, Invoice, Payment, ftp information supp...@mxg.comTechnical Issues MXG-L FREE ListServer http://www.mxg.com/mxg-l_listserver/ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of William Donzelli Sent: Wednesday, July 29, 2015 12:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 1403 at 60Hz As I understood it at the time, larger S/360 and S/370 also used motor-generator power supplies, though I don't know the output frequency. The higher frequency means less filtering. Generally 415 Hz. Why this odd number is beyond me. The Hitachi clones also used 415 Hz. But yes, you can run a CDC machine off an electronic converter. Most CDC Cybers are indeed 400 Hz machines, but a few were made with a 60 Hz option. Last week I drove to Texas to get a small departmental Cyber 932 - they were all (or nearly all?) 60 Hz models. -- Will -- 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: Article on COBOL's inevitable return
Depends on what context you took it in. I (silly me) took it to mean all DoD business. - -teD - Original Message From: Joel Ewing Sent: Wednesday, July 29, 2015 15:16 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Article on COBOL's inevitable return Well, actually the original statement WAS self-apparently ludicrous because it stated that U.S. DoD decreed ALL businesses would use COBOL, period, and DoD has never had that much authority. DoD had zero control over businesses that did not work on defense contracts for DoD, and even those with defense contracts could only be constrained to DoD standards in the work they did on behalf of those defense contracts. The use of an unconstrained ALL is what made it ludicrous. The considerable influence of DoD as a major consumer forced the availability of COBOL and later ADA support and set the standards for code written for DoD projects, but DoD is not [yet] omnipotent. JC Ewing On 07/29/2015 12:04 PM, Ted MacNEIL wrote: Hence NOT ludicrous! - -teD - Original Message From: Vince Coen Sent: Wednesday, July 29, 2015 12:54 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Article on COBOL's inevitable return I think you will find that was a demand (?) that all applications developed on behalf of the military (well at least the US Navy) had to be in Cobol - if nothing else to help with standards, maintenance migration. You have to remember that there was more than one supplier of mainframes in the 60's such as IBM, Burroughs, Honeywell Univac, Sperry Rand to name but a few and in Europe OK, the U.K., ICL (ICL), English Electric and of course the first commercial computer the LEO 3 and these were also included in UK manuals of the time. Check out the copyleft notice that is shown in all Cobol manuals and should also be in books although not in my one copy of a Cobol book - Cobol unleashed! . Vince Cobol since 1963, IT since 1961 (from 1403, 7094, 360/30 et al). On 29/07/15 17:20, Paul Gilmartin wrote: On Wed, 29 Jul 2015 12:11:56 -0400, Ted MacNEIL wrote: Why is it so ludicrous? The USDOD did develop COBOL for some reasom. And a generation later, they likewise required ADA. I don't know if that was ever countermanded. I know a programmer who argued that his assignment could not be accomplished in ADA. He was given an exemption and allowed to use assembler. � Original Message � From: zMan Sent: Wednesday, July 29, 2015 11:28 *The Department of Defense even decreed that all businesses must run on COBOL in the 1960s.* A ludicrous assertion. -- gil -- Joel C. Ewing, Bentonville, AR jcew...@acm.org -- 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: 1403 at 60Hz
http://ibm-1401.info/1440Sys/WCP22_Project_Report_REV2013-12-13%20pm--1.pdf This was pretty interesting. We used to have a dangling ribbon in the Help Desk center that said 'Over printing is cool'. The ribbon stopped when over- printing so if you used overprint to play a song or something it would chew the ribbon up. In a message dated 7/29/2015 3:59:38 P.M. Central Daylight Time, ee...@us.ibm.com writes: Proving, once again, that documentation beats memory! (I think the 3211 was direct drive and I confused the two.) I might tanke a trip down memory lane later by paging through the book...I haven't seen that book in a Long, Long Time! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Article on COBOL's inevitable return
DoD is not a business. As noted, the claim is ludicrous. And any SSNs, CCNs, etc. hard-coded are clearly not what was being talked about, nor would those be hard to find and fix. On Wed, Jul 29, 2015 at 8:27 PM, Ted MacNEIL eamacn...@yahoo.ca wrote: Depends on what context you took it in. I (silly me) took it to mean all DoD business. - -teD - Original Message From: Joel Ewing Sent: Wednesday, July 29, 2015 15:16 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Article on COBOL's inevitable return Well, actually the original statement WAS self-apparently ludicrous because it stated that U.S. DoD decreed ALL businesses would use COBOL, period, and DoD has never had that much authority. DoD had zero control over businesses that did not work on defense contracts for DoD, and even those with defense contracts could only be constrained to DoD standards in the work they did on behalf of those defense contracts. The use of an unconstrained ALL is what made it ludicrous. The considerable influence of DoD as a major consumer forced the availability of COBOL and later ADA support and set the standards for code written for DoD projects, but DoD is not [yet] omnipotent. JC Ewing On 07/29/2015 12:04 PM, Ted MacNEIL wrote: Hence NOT ludicrous! - -teD - Original Message From: Vince Coen Sent: Wednesday, July 29, 2015 12:54 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Article on COBOL's inevitable return I think you will find that was a demand (?) that all applications developed on behalf of the military (well at least the US Navy) had to be in Cobol - if nothing else to help with standards, maintenance migration. You have to remember that there was more than one supplier of mainframes in the 60's such as IBM, Burroughs, Honeywell Univac, Sperry Rand to name but a few and in Europe OK, the U.K., ICL (ICL), English Electric and of course the first commercial computer the LEO 3 and these were also included in UK manuals of the time. Check out the copyleft notice that is shown in all Cobol manuals and should also be in books although not in my one copy of a Cobol book - Cobol unleashed! . Vince Cobol since 1963, IT since 1961 (from 1403, 7094, 360/30 et al). On 29/07/15 17:20, Paul Gilmartin wrote: On Wed, 29 Jul 2015 12:11:56 -0400, Ted MacNEIL wrote: Why is it so ludicrous? The USDOD did develop COBOL for some reasom. And a generation later, they likewise required ADA. I don't know if that was ever countermanded. I know a programmer who argued that his assignment could not be accomplished in ADA. He was given an exemption and allowed to use assembler. � Original Message � From: zMan Sent: Wednesday, July 29, 2015 11:28 *The Department of Defense even decreed that all businesses must run on COBOL in the 1960s.* A ludicrous assertion. -- gil -- Joel C. Ewing, Bentonville, AR jcew...@acm.org -- 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 -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.2 announcement
Just one problem with your implementation plan. Most sites I know would not want to recompile every COBOL program they run into a PDSE, then do a rename swap to implement. IEFOPZxx is great solution to this problem. You don't need to recompile them to store them in a PDSE. You can just reallocate a new PDSE, use IEBCOPY to copy them from the old PDS to the new PDSE. IEBCOPY will invoke the binder to relink them to the new format but the code remains unchanged. Then you can rename to new PDSE to replace the old PDS. No JCL changes needed. We just did that a few months ago on all our LPARs. - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Life cycle chart
I used z/OS lifecycle and didn't come close :( -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, July 28, 2015 7:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Life cycle chart I actually on the IBM website used z/os life cycle Came up Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, David Allen,Jr Sent: Tuesday, July 28, 2015 4:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Life cycle chart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Lizette Koehler Sent: Tuesday, July 28, 2015 2:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM Life cycle chart Since this comes up from time to time. Here is the link I use https://urldefense.proofpoint.com/v1/url?u=http://www- 01.ibm.com/software/support/systemsz/lifecycle/k=EWEYHnIvm0nsSxnW 5y 9VIw%3D%3D%0Ar=j6Xa1Y0fbuP2mfgCQ5Zxhg%3D%3D%0Am=G39pad7 N kmc%2FEiTd9h%2BijwGe1vzFJJYh0WtOgb7DjPc%3D%0As=0012cc95025c95f 4840f4b8314e5871d47cf1c7be8ea8836b882e23b4654a0e5 Thanks, you'd think this would show up easier when searching IBM :) 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 Life cycle chart
Gibney, David Allen,Jr wrote: I used z/OS lifecycle and didn't come close :( Try www.ibm.com and search for these 3 words: life cycle z/os or just search these 2 words: lifecycle z/os For both search I got this URL amongst a lot of others: http://www-01.ibm.com/software/support/systemsz/lifecycle/ 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: 1403 at 60Hz
I don't know power consuption, but nowadays it's not hard to get semiconductor-based power supply which generater 60Hz or 50Hz or any value you want (within some range). -- Radoslaw Skorupka Lodz, Poland W dniu 2015-07-29 o 02:15, Vince Coen pisze: .. and change settings for 120 to 230/240 volts is the biggest issue frequency is not so serious providing the specific model is dual power etc. Been a very long time since I had to set one up. On 29/07/15 00:23, glen herrmannsfeldt wrote: I wonder if anyone knows what has to change to move a 1403 from 50Hz to 60Hz? If they use synchronous motors, then some belts or gears would be different. For transformers, you need more iron in the core for 50Hz, so 50Hz transformers should be fine at 60Hz, but not always the other way around. That might also be true for motors, but synchronous motors will run faster. -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.840.228 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Life cycle chart
I use this link, as it includes CICS and other products: http://www-01.ibm.com/software/support/lifecycle/index_a_z.html B On Wed, Jul 29, 2015 at 6:12 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Gibney, David Allen,Jr wrote: I used z/OS lifecycle and didn't come close :( Try www.ibm.com and search for these 3 words: life cycle z/os or just search these 2 words: lifecycle z/os For both search I got this URL amongst a lot of others: http://www-01.ibm.com/software/support/systemsz/lifecycle/ 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 -- Thank you and best regards, *Billy Ashton* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Life cycle chart
Bill Ashton wrote: I use this link, as it includes CICS and other products: http://www-01.ibm.com/software/support/lifecycle/index_a_z.html Thanks. This list is a better one and there is an index at the top too. Much usable! Thanks again. 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: z/OS 2.2 announcement
In a large shop the old PDS would be in continuous use and therefore difficult to swap out. I agree with the people who say this is a recipe for confusion but I certainly understand IBM's thinking also. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Fred van der Windt Sent: Tuesday, July 28, 2015 10:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.2 announcement This was discussed at the vendor TDM but I think I am not talking out of school here now that this is announced ... One obstacle to customers converting to COBOL 5 is the requirement that the resulting executable programs reside in a PDSE. The customer presumably has thousands of jobs that say //STEPLIB DD DSN=OLD.PDS and no manpower to change them all. This would let them catalog COBOL 5 programs in NEW.PDSE and have it be automagically searched first whenever the JCL said DSN=OLD.PDS. AFAIR ... Charles Why would that require JCL changes? You could just replace OLD.PDS by a PDSE. I will admit that 'OLD.PDS' is a silly name for a PDSE but adding a .PDS suffix to a PDS seems silly to begin with. But is is an easy fix. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Aliases (was: z/OS 2.2 announcement)
On Wed, 29 Jul 2015 14:38:50 +, Staller, Allan wrote: ... Once *EVERYTHING has moved to the alias, the original dataset can be deleted and the process repeated in the other direction. This make take several (days, weeks, months,) depending on the installations policies and procedures. ... Merely re-point the existing alias to the new dataset. No problem here. Is there a utility to enumerate all ALIASes to a given RELATED DSN? If not, there's a problem.The information must exist: if the RELATED DSN is deleted, the ALIASes are quietly deleted. Integrity flaw: deleting a DSN when ALIASes exist ought at least to require confirmation. There's a minuscule timing window. SYMBOLIC aliases would be better; they persist when the referenced data set is deleted. But a SYMBOLIC alias must contain at least one substitutable symbol. Stupid rule! (Might one define a system symbol naming the null string, for incorporation in SYMBOLIC aliases?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.2 announcement (and rename data set in use)
On 2015-07-29, at 08:13, Staller, Allan wrote: Better yet, copy PDS to PDSE and define a dataset alias But be careful: o Don't you need at least to uncatalog the PDS to define the alias? Can this be done while an ENQ exists? I suspect, yes. o Initiator ENQ works differently, perhaps poorly, with aliases: - At job initiation the system obtains an ENQ on the ALIAS name. - At step initiation the system attempts to ENQ on the RELATED name. If this fails the system terminates the job rather than waiting for a DEQ. I believe that DEFINE ALIAS and DELETE ALIAS use no ENQ; neither on the ALIAS name nor on the RELATED name. (Empirical.) And, if you have an existing alias to the PDS, you're SOL. You can't define an alias of an alias. Stupid rule! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.2 announcement (and rename data set in use)
Yes you can. snip o Don't you need at least to uncatalog the PDS to define the alias? Can this be done while an ENQ exists? I suspect, yes. /snip Once *EVERYTHING has moved to the alias, the original dataset can be deleted and the process repeated in the other direction. This make take several (days, weeks, months,) depending on the installations policies and procedures. snip o Initiator ENQ works differently, perhaps poorly, with aliases: - At job initiation the system obtains an ENQ on the ALIAS name. - At step initiation the system attempts to ENQ on the RELATED name. If this fails the system terminates the job rather than waiting for a DEQ. /snip Merely re-point the existing alias to the new dataset. No problem here. snip I believe that DEFINE ALIAS and DELETE ALIAS use no ENQ; neither on the ALIAS name nor on the RELATED name. (Empirical.) And, if you have an existing alias to the PDS, you're SOL. You can't define an alias of an alias. Stupid rule! /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.2 announcement (and rename data set in use)
Better yet, copy PDS to PDSE and define a dataset alias snip In a large shop the old PDS would be in continuous use and therefore difficult to swap out. A shop must be prepared to do this in the event of hardware replacement. This sounds like a good argument for a facility to rename a data set while in use. Copy PDS to PDSE and swap the names. I know it wouldn't be easy, but I'm too familiar with the facility in UNIX not to recognize its value or to deem it worthless. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.2 announcement (and rename data set in use)
On Wed, 29 Jul 2015 06:17:31 -0700, Charles Mills wrote: In a large shop the old PDS would be in continuous use and therefore difficult to swap out. A shop must be prepared to do this in the event of hardware replacement. This sounds like a good argument for a facility to rename a data set while in use. Copy PDS to PDSE and swap the names. I know it wouldn't be easy, but I'm too familiar with the facility in UNIX not to recognize its value or to deem it worthless. -Original Message- From: Fred van der Windt Sent: Tuesday, July 28, 2015 10:40 PM ... The customer presumably has thousands of jobs that say //STEPLIB DD DSN=OLD.PDS and no manpower to change them all. This would let them catalog COBOL 5 programs in NEW.PDSE and have it be automagically searched first whenever the JCL said DSN=OLD.PDS. Charles Why would that require JCL changes? You could just replace OLD.PDS by a PDSE. ... What are the possible technical obstacles? o Are there any load modules that simply can't be converted to program objects? o Might a customer have a RECFM=U PDS that contains both load modules and non-program data objects? A better solution might be to extend the capability of PDSE, allowing a mixture of program objects and non-program objects. I know it might not be easy, but the restriction should never have been established in the first place. Or, I could envision a dual-fork scheme where a single catalogued DSN identifies both a PDS and a PDSE, but with no overlap in member names permitted. That would eliminate the auditing hazard. When an auditing process scans JCL to find all references to a DSN, should it automatically report both the PDS and the PDSE branches with the coming z/OS 2.2 facility? It would be valuable if: o That facility prohibits overlapping member names. o Facilities such as ISPF DDLIST correctly report members in either branch. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 at 60Hz
On 2015-07-29, at 05:57, R.S. wrote: I don't know power consuption, but nowadays it's not hard to get semiconductor-based power supply which generater 60Hz or 50Hz or any value you want (within some range). I suppose a 1403 requires a couple kW. That shouldn't be an obstacle: https://en.wikipedia.org/wiki/High-voltage_direct_current CDC equipment circa 1970 used 400 Hz with rotating mechanical converters. Provided considerable immunity to power surges. Flywheels? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
All Flow-riders: z/OS V2.2 Migration Workflow Available
If you are currently using z/OSMF V2.1 and want to see what you need to do for a migration from V2.1 to V2.2 (or even R13 to V2.2), the z/OS V2.2 Migration Workflow is available at http://www-03.ibm.com/systems/z/os/zos/tools/downloads/zosmf-zos-v2r2-migration-workflow.html . In fact, if you are on the z/OS V2.1 to V2.2 migration path and use this Workflow you don't need to use the z/OS V2.2 Migration book! That's because the Workflow is identical to the book, and even has two additional benefits: 1) the Workflow will now invoke IBM Health Checker for z/OS checks were appropriate to determine migration applicability, and 2) the optional capability to provide feedback to IBM on each migration action and on your overall release migration. If you are on the R13 to V2.2 migration path, you can still use the z/OS V2.2 Migration Workflow, however you won't be able to fire it up until after you've started z/OSMF V2.2 on your target system. Those on the R13 path still will need to use the z/OS V2.2 Migration book. As always, if you have any questions about this migration workflow, please let me know! -Marna WALLE z/OS System Installation, IBM Poughkeepsie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
