Re: FORTRAN reverse engineering
On 19 April 2015 at 05:39, Martin Packer martin_pac...@uk.ibm.com wrote: I wonder if compilers plant idiomatic machine code - from which higher-level constructs can be garnered. I would expect optimising (prefer improving) compilers would defeat that. Certainly older compilers did tend to have canned blocks of code that were brought in fairly predictably to implement language-specific patterns. But as you say, optimization tends to hide that, and perhaps even more so does the use of common compiler middle and back ends, to use GCC terminology. Perhaps the OP can tell us which FORTRAN compiler was used (should be easily identifiable from IDRs). Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
On Mon, 20 Apr 2015 11:46:57 -0500, Paul Gilmartin wrote: Had bit 0 not been pervasively exploited as a flag, 32-bit addressing could have been accomplished easily. If there had been no reason to run old code in AMODE 24, 32-bit addressing could have been accomplished easily. That was the hope when the System/360 Model 67 was designed. It proved to be difficult to eliminate all use of AMODE 24. It is easy for us to fault the designers of System/360 and OS/360 for not considering the future requirement for more than 16 MB. In 1964, that seemed like plenty of addressable memory. In their 1964 document, Architecture of IBM System/360, Amdahl, Blaauw and Brooks wrote that the design had to provide a dependable base for a decade of customer planning and customer programming and that Storage capacities of more than the commonly available 32,000 words would be required. The System/360 was IBM's first family of computers, spanning a wide range of capabilities. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/e FTP receive error - Help
You were right and IBM site did had some hiccup. What makes you say that? Did you open an ETR and did IBM tell you the download server was acting up? How do you know other factors, like excessive network traffic in your own enterprise, aren't the cause? Just curious. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
GSE UK Annual Conference - Large Systems Stream -- Call For Papers
All, We are beginning the process to build the agenda for the LSG stream of the next GSE UK Conference. This event will be held on November 3 4 at Whittlebury Hall in Northamptonshire. The LSG stream will comprise 10 sessions across the 2 days (5 x 60 minute sessions and 5 x 45 minute sessions). The conference has a suggested theme of 'z Systems: The Cloud has a silver lining' though presentation submissions on any Large Systems topic are welcomed. If you would like to present at one of these sessions please send your presentation title, a brief abstract of the presentation and a brief bio of the presenter to myself (mark.wil...@gse.org.ukmailto:mark.wil...@gse.org.uk) by the 30th May. Please remember that the objectives of the Conference are to provide guidance and education. The GSE policies prohibit presentations that are focused on selling or promoting a product. Instead, they should focus on technical issues. As an example, you could discuss a topical issue and how that issue can be resolved; you could describe enhancements to a product and how they can be exploited; other possible topics include explaining the mysteries of the mainframe to new technicians and students. We look forward to receiving your suggestions for presentations at this year's conference and to seeing you at the LSG stream. Regards Mark, Roger Andy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
A Data Studio question
Should I ask this on the DB2 forum, if so, how do I register? Sorry if dumb question .. am about to download/install Data Studio 4.1.1 and in the Quick Start Guide I find .. Step 5: Get started with the product 1. Set up the Data Studio web console. If you did not install the web console and plan to connect to a web console that is installed on a different computer, you can skip this step. a. If you did not run the Data Studio Configuration Assistant after the installation to configure the Data Studio web console, open it from the Start menu by clicking Configure the Data Studio web console. b. Open the web console in your browser and then log in as the default administrative user that you created with the Data Studio Configuration Assistant. c. From the Task Launcher, complete the appropriate getting started tasks for your environment. If you plan to share the web console with other users, select a repository database and configure user access to it. Found the instructions at 1. difficult to interpret. Assume: I 'did install the web console'. Question: should I do a. b. and c.? Please, thanks Graham Hobbs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
On Mon, Apr 20, 2015 at 9:41 AM, Steff Gladstone steff.gladst...@gmail.com wrote: The ENQ has to be transparent to the JCL. Could I dynamically allocate a dataset with DISP=(OLD,PASS)? As I recall the dynamic allocation does not permit the use of PASS. Hum, I'm going to go way out on a limb and start sawing. grin/ I wonder if it would be possible to do a directed ENQ of a SYSDSN to the initiator TCB and then modify the SWA to generate the internal information for a DD and place that as if it had been in a DD in the JCL. I am likely not saying that very well. But I'm thinking that products like CA-11 do this sort of thing for restart (in order to change GDG generation numbers). If this were possible, then perhaps the initiator would do the DEQ at end of job. Perhaps Chris, or another ISV person, would know. On Mon, Apr 20, 2015 at 5:30 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: I guess you could do that, assign the initiator TCB to the ENQ, but what happens if the job abends before the step you do the DEQ in? I think this will work - If the purpose is to prevent two similar processes, then why not use a common data set and allocate it as DISP=(OLD,PASS). That way the ENQ on the data set will last for the duration of the job, and if it dies early the ENQ automatically goes away. Chris Blaicher -- If you sent twitter messages while exploring, are you on a textpedition? 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
Fwd: ENQ for the life of the job
Greetings, How do I use the ISGENQ macro in such a way that the ENQ lasts for the life of the entire job (or several job steps) and not just for the life of a single job-step? Would specifying the TCB address of the initiator TCB on the TCB parameter work? Any better ideas? Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
On Mon, 20 Apr 2015 13:09:14 +0800, Timothy Sipples wrote: Clark Morris wrote: Given that IBM CSP and its descendants (IBM VisualAge generator) generate F signs for positive fields My understanding is that the currently supported descendants, i.e. EGL, don't behave this way. I'm a skeptic about Postel's Principle. Rather, I believe that hardware or software as appropriate should enforce preferred values for otherwise uncommited fields in instructions, data, and control blocks lest overly inventive programmers exploit them to smuggle a few bits of data through whatever interface. I'll even go so far as to say that if the original s/360 had raised an addressing excption when bits 0-7 of a base or index register were nonzero, transition from 24-bit to 32-bit addressing would have been much facilitated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
On Mon, Apr 20, 2015 at 9:13 AM, Steff Gladstone steff.gladst...@gmail.com wrote: How do I use the ISGENQ macro in such a way that the ENQ lasts for the life of the entire job (or several job steps) and not just for the life of a single job-step? Would specifying the TCB address of the initiator TCB on the TCB parameter work? Any better ideas? Thanks, Steff Gladstone I don't know that there is a _reliable_ way to do this. If you were to direct the ENQ to reside on the initiator's TCB, I am fairly sure that the ENQ would not go away at the end of your job because the initiator TCB does not terminate at end of job. I admit to being a bit curious as to why you need this, if you are allowed to say. -- If you sent twitter messages while exploring, are you on a textpedition? 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
Re: ENQ for the life of the job
The ENQ has to be transparent to the JCL. Could I dynamically allocate a dataset with DISP=(OLD,PASS)? As I recall the dynamic allocation does not permit the use of PASS. On Mon, Apr 20, 2015 at 5:30 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: I guess you could do that, assign the initiator TCB to the ENQ, but what happens if the job abends before the step you do the DEQ in? I think this will work - If the purpose is to prevent two similar processes, then why not use a common data set and allocate it as DISP=(OLD,PASS). That way the ENQ on the data set will last for the duration of the job, and if it dies early the ENQ automatically goes away. 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 Steff Gladstone Sent: Monday, April 20, 2015 10:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ENQ for the life of the job How do I use the ISGENQ macro in such a way that the ENQ lasts for the life of the entire job (or several job steps) and not just for the life of a single job-step? Would specifying the TCB address of the initiator TCB on the TCB parameter work? Any better ideas? Thanks, Steff Gladstone -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
On 19 Apr 2015 22:10:22 -0700, in bit.listserv.ibm-main you wrote: Clark Morris wrote: Given that IBM CSP and its descendants (IBM VisualAge generator) generate F signs for positive fields My understanding is that the currently supported descendants, i.e. EGL, don't behave this way. Let me see if I can re-thread the use case needle here, Clark, and please correct me if I'm wrong in any of these details. You're pointing out that, if a CSP or VisualAge Generator program needs to be recompiled, with Enterprise COBOL Version 5.1 and above the compiler option NUMPROC(NOPFD) is required since NUMPROC(MIG) is no longer available. NUMPROC(MIG) offered a performance advantage versus NUMPROC(NOPFD) with Enterprise COBOL 4.x and older compilers. You're requesting that the compiler development team consider implementing NUMPROC(MIG) in Enterprise COBOL 5.x. If I understand the EGL site correctly, if you are intelligent and don't use PACF, the sign nibble is C or D. http://www-01.ibm.com/support/knowledgecenter/SSMQ79_9.1.1/com.ibm.egl.lr.doc/topics/regl_core_num_type.html seems to have an error in the second bullet in point 9 where it says The repeated F characters may seem redundant to those unfamiliar with EBCDIC. Packed decimal data types (represented in EGL by DECIMAL, MONEY, and PACF) eliminate the redundancy. The packed decimal version of -150 is 150D. Positive 150 is 150, except in the PACF format, where it would be 150F. I think it should say Positive 150 is 150C except in the PACF format where it would be 150F. For those shops on CSP or Visual Gen, the issue is not the programs generated by those products but rather all of the other programs that use the data generated by those products. The programs that use CSP or Visual Gen generated numeric data are forced to use either NUMPROC(NOPFD) or NUMPROC(MIG) in order to obtain correct results. The ideal solution for those shops is to migrate to EGL changing all programs to use either DECIMAL or MONEY for packed fields and run a clean up set of programs for all files/databases updated by those programs. Until all of the CSP/Visual Gen programs at a site are eliminated by some type of migration, NUMPROC(MIG) is a valuable option for dealing with data created or updated by those programs. I suspect most application programming management will find this discussion arcane techy stuff and just systems programmer headache. Clark Morris Failing that, technical alternatives include: 1. Using NUMPROC(NOPFD); 2. Using Enterprise COBOL 4.2 only for these cases (when recompiling CSP and/or VisualAge Generator code); 3. Upgrading to IBM EGL. To ask a couple hard questions here: A. What would be, in your estimation, the net performance outcome using NUMPROC(NOPFD) with Enterprise COBOL 5.2 versus NUMPROC(MIG) with Enterprise COBOL 4.2, keeping in mind that Version 5.2 should already perform better than Version 4.2, other things being equal? Do you have any measurements suggesting otherwise that you could offer? Then, carrying that estimate forward, what percentage of workload would CSP/VisualAge Generator represent during the peak utilization interval? My informal observation is that there are indeed many shops still running CSP and/or VisualAge Generator code that they haven't yet recompiled using the supported EGL tool chain. (Many recompile when the opportunity arises, when normal code maintenance takes them there.) However, I haven't run into any shop yet where CSP and/or VisualAge Generator programs represent a significant fraction of peak utilization workload, most likely because keeping current with EGL already offered performance improvements, even before Enterprise COBOL 5.x. B. Relatedly, how often are customers recompiling CSP and/or VisualAge Generator programs nowadays, and what's your view of the trend? C. This is a rather odd case where there's a pair of compilers, roughly speaking: CSP and/or VisualAge Generator (that generate COBOL source code from the 4GL source), then the COBOL compiler. Thus far IBM has maintained backward compatibility so that customers can upgrade these compilers on different release schedules, and that's still true: there's a functionally correct option in Enterprise COBOL 5.2 technically compatible with unsupported CSP and VisualAge Generator. But did IBM have to do even this? Isn't it reasonable that if a customer is going to maintain one unsupported compiler (or code pre-processor, more precisely) in their environment, at some point in the future they might also have to maintain a corresponding older, second compiler as part of the chain if they adopt that particular approach to keeping CSP and/or VisualAge Generator? I'm sensitive to the fact the compiler teams undoubtedly have a long list of feature enhancement requests. Support for 64-bit data objects would get my vote, as an example. Given that reality, I'm trying to draw out just how important NUMPROC(MIG) would be. I'm not convinced it's that important
Re: SDSF QUESTION ; FILTER : OPTION 7
Thanks. It is what I am looking for. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
New Redbook: IBM z Systems Connectivity Handbook
http://www.redbooks.ibm.com/abstracts/sg245444.html?Open Abstract This IBM® Redbooks® publication describes the connectivity options available for use within and beyond the data center for the IBM z Systems® family of mainframes, which includes these systems: - IBM z Systems® z13 (z13) - IBM zEnterprise® EC12 (zEC12) - IBM zEnterprise BC12 (zBC12) - IBM zEnterprise 196 (z196) - IBM zEnterprise 114 (z114) This book highlights the hardware and software components, functions, typical uses, coexistence, and relative merits of these connectivity features. It helps readers understand the connectivity alternatives that are available when planning and designing their data center infrastructures. The changes to this edition are based on the z Systems hardware announcement dated January 14, 2015. This book is intended for data center planners, IT professionals, systems engineers, technical sales staff, and network planners who are involved in the planning of connectivity solutions for IBM z Systems. -- If you sent twitter messages while exploring, are you on a textpedition? 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
Re: ENQ for the life of the job
I suppose a final job-step to do the DEQ with COND=EVEN would not always do the trick. As I recall there are some types of abends that flush the job including steps with COND=EVEN, right? Very true. My favorite: S40D with a nice message about the initiator being terminated at end of memory. The S40D, IIRC, was caused by exhausting the LSQA. So the initiator couldn't do an GETMAINs in order to terminate properly. The real fun is that RTM did NOT get control and so _all_ the DSNs which were allocated to the job remained allocated (well, ENQUEUEd) until we IPL'd. Thankfully, that only happened once, about 7 years ago. Of course, I now know how to do a directed DEQ (not available at the time) to eliminate an ENQ that I don't like. grin/ In addition its task termination resource manager, which did not execute because of the 40D abnormal memory termination, GRS has a memory termination resource manager which should have executed and released ENQs held by the terminating address space. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SDSF QUESTION ; FILTER : OPTION 7
G'Day, I am trying to display all replies of each syslog on SYSPLEX envrionment via SDSF. When in SDSF I place the cursor unde Filter, next I choose 7 followed by *. The outstanding messages are displayed however the LPAR name is not shown. Is there something I have forgotten to do? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
On Mon, Apr 20, 2015 at 10:36 AM, Steff Gladstone steff.gladst...@gmail.com wrote: The job is performing a change management system operation (moving a new program version to production, saving previous generations, providing for possible fallback, etc.). The operation for various reasons must be performed in several job steps. We want to ENQ on the name of the program being handled to prevent other operations or changes being made to that program in parallel. Of course the ENQ must remain in effect for the duration of the entire operation. OK, with your kind indulgence, I will make a suggestion which many may consider obscene. You can use UNIX services to fork() and run another program (exec() or execmvs() ) in a separate address space. (you could use ASCRE instead to avoid UNIX). This other program, running in the separate address space, runs totally independently of your batch job. But you can communicate with it using a number of IPC (Inter Process Communications) protocols such as UNIX message queues or FIFO pipes (personally, I'd use a UNIX message queue). The other address space would do the ENQs and DEQs on demand and they be normal system level enqueues. Of course, this would require a communications protocol where the batch job would send the request, wait for reply, then continue while the UNIX program would wait for a request, ENQ/DEQ, reply, all in a loop. Each batch job would have its own associated UNIX daemon (as it might be called in UNIX). In any case, the last step of the job would be a program which tells the other address space to DEQ everything and shut down. If there is any problem with this other address space and it does not terminate properly, you can simply do a normal z/OS type CANCEL command on it and poof! the ENQs disappear normally. I mention this because all of this can be done by a normal (non-APF) program. This may be a selling point as many, myself included, dislike using APF frivolously. Yes, this is a bit complicated. But z/OS itself does not have a job execution level ENQ. -- If you sent twitter messages while exploring, are you on a textpedition? 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
Re: SDSF QUESTION ; FILTER : OPTION 7
John Dawes wrote: I am trying to display all replies of each syslog on SYSPLEX envrionment via SDSF. When in SDSF I place the cursor unde Filter, next I choose 7 followed by *. The outstanding messages are displayed however the LPAR name is not shown. Is there something I have forgotten to do? What is wrong with 'SRSystem requests ' in SDSF? SR gives you everything you want. Try it. HTH! 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's NUMPROC compiler option
On Mon, 20 Apr 2015 11:24:51 -0400, John Gilmore wrote: The transition was from 24- to 31-bit addressing. Apart from this quibble, Paul is right here. Unused fields should be initialized innocuously and, usually, marked as reserved. (From time to time there is of course a case for making user fields available in control blocks.) My use of 32- rather tnan 31- was quite deliberate. Had bit 0 not been pervasively exploited as a flag, 32-bit addressing could have been accomplished easily. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
On Mon, Apr 20, 2015 at 10:18 AM, Steff Gladstone steff.gladst...@gmail.com wrote: I suppose a final job-step to do the DEQ with COND=EVEN would not always do the trick. As I recall there are some types of abends that flush the job including steps with COND=EVEN, right? Very true. My favorite: S40D with a nice message about the initiator being terminated at end of memory. The S40D, IIRC, was caused by exhausting the LSQA. So the initiator couldn't do an GETMAINs in order to terminate properly. The real fun is that RTM did NOT get control and so _all_ the DSNs which were allocated to the job remained allocated (well, ENQUEUEd) until we IPL'd. Thankfully, that only happened once, about 7 years ago. Of course, I now know how to do a directed DEQ (not available at the time) to eliminate an ENQ that I don't like. grin/ -- If you sent twitter messages while exploring, are you on a textpedition? 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
Re: ENQ for the life of the job
I suppose a final job-step to do the DEQ with COND=EVEN would not always do the trick. As I recall there are some types of abends that flush the job including steps with COND=EVEN, right? On Mon, Apr 20, 2015 at 6:09 PM, John McKown john.archie.mck...@gmail.com wrote: On Mon, Apr 20, 2015 at 9:41 AM, Steff Gladstone steff.gladst...@gmail.com wrote: The ENQ has to be transparent to the JCL. Could I dynamically allocate a dataset with DISP=(OLD,PASS)? As I recall the dynamic allocation does not permit the use of PASS. Hum, I'm going to go way out on a limb and start sawing. grin/ I wonder if it would be possible to do a directed ENQ of a SYSDSN to the initiator TCB and then modify the SWA to generate the internal information for a DD and place that as if it had been in a DD in the JCL. I am likely not saying that very well. But I'm thinking that products like CA-11 do this sort of thing for restart (in order to change GDG generation numbers). If this were possible, then perhaps the initiator would do the DEQ at end of job. Perhaps Chris, or another ISV person, would know. On Mon, Apr 20, 2015 at 5:30 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: I guess you could do that, assign the initiator TCB to the ENQ, but what happens if the job abends before the step you do the DEQ in? I think this will work - If the purpose is to prevent two similar processes, then why not use a common data set and allocate it as DISP=(OLD,PASS). That way the ENQ on the data set will last for the duration of the job, and if it dies early the ENQ automatically goes away. Chris Blaicher -- If you sent twitter messages while exploring, are you on a textpedition? 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
Steff Gladstone wrote: The job is performing a change management system operation (moving a new program version to production, saving previous generations, providing for possible fallback, etc.). The operation for various reasons must be performed in several job steps. We want to ENQ on the name of the program being handled to prevent other operations or changes being made to that program in parallel. Of course the ENQ must remain in effect for the duration of the entire operation. Ok. You've got good replies plus a very good probing question from D Jousma: 1. ENQ macro at first step and DEQ macro in last step. (Just check up your GRS/MIM setup as well your keywords of course) 2. DD with DISP=(OLD,PASS) or IEFBR14 with an unreferenced DSN. Failsafe, unless a weird ABEND happens. 3. SMF/JES2 Exit. 4. CA-11 with GDG or so for restart purposes. I'm not sure about this one, but I accept what was written. While I have some experience with handling ENQ problems and testing it out with Assembler to test our defective tape management system with incorrectly setup GRS across the Sysplex, I have a good solution for you for that specific situation. Do you have automation? If so, set up a flag (condition flag or variable) indicationg your process is running with 1 or many jobs and 1 or many steps. Only when the whole story is completed you turn off [1] that flag allowing others to start a new operation. Now setup your automation so that nothing else can run while that flag is running (made TRUE). This is NOT a ENQ solution, but you can perhaps consider this way since you don't want any JCL changes. HTH! Groete / Greetings Elardus Engelbrecht [1] - I eventually did the reverse - I [rather, let the automation team do the dirty work] setup the flag when a SMF job on a LPAR has finished - Only when all and every SMF flags in the whole SysPlex were made TRUE, then a certain job is kicked off automagically for that day. Then all those flags were cleared out for the next set of runs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
Maybe if you can explain in more detail what situation you are trying to solve for would help? _ 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 Steff Gladstone Sent: Monday, April 20, 2015 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENQ for the life of the job I suppose a final job-step to do the DEQ with COND=EVEN would not always do the trick. As I recall there are some types of abends that flush the job including steps with COND=EVEN, right? On Mon, Apr 20, 2015 at 6:09 PM, John McKown john.archie.mck...@gmail.com wrote: On Mon, Apr 20, 2015 at 9:41 AM, Steff Gladstone steff.gladst...@gmail.com wrote: The ENQ has to be transparent to the JCL. Could I dynamically allocate a dataset with DISP=(OLD,PASS)? As I recall the dynamic allocation does not permit the use of PASS. Hum, I'm going to go way out on a limb and start sawing. grin/ I wonder if it would be possible to do a directed ENQ of a SYSDSN to the initiator TCB and then modify the SWA to generate the internal information for a DD and place that as if it had been in a DD in the JCL. I am likely not saying that very well. But I'm thinking that products like CA-11 do this sort of thing for restart (in order to change GDG generation numbers). If this were possible, then perhaps the initiator would do the DEQ at end of job. Perhaps Chris, or another ISV person, would know. On Mon, Apr 20, 2015 at 5:30 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: I guess you could do that, assign the initiator TCB to the ENQ, but what happens if the job abends before the step you do the DEQ in? I think this will work - If the purpose is to prevent two similar processes, then why not use a common data set and allocate it as DISP=(OLD,PASS). That way the ENQ on the data set will last for the duration of the job, and if it dies early the ENQ automatically goes away. Chris Blaicher -- If you sent twitter messages while exploring, are you on a textpedition? 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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: ENQ for the life of the job
The job is performing a change management system operation (moving a new program version to production, saving previous generations, providing for possible fallback, etc.). The operation for various reasons must be performed in several job steps. We want to ENQ on the name of the program being handled to prevent other operations or changes being made to that program in parallel. Of course the ENQ must remain in effect for the duration of the entire operation. On Mon, Apr 20, 2015 at 6:19 PM, Jousma, David david.jou...@53.com wrote: Maybe if you can explain in more detail what situation you are trying to solve for would help? _ 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 Steff Gladstone Sent: Monday, April 20, 2015 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENQ for the life of the job I suppose a final job-step to do the DEQ with COND=EVEN would not always do the trick. As I recall there are some types of abends that flush the job including steps with COND=EVEN, right? On Mon, Apr 20, 2015 at 6:09 PM, John McKown john.archie.mck...@gmail.com wrote: On Mon, Apr 20, 2015 at 9:41 AM, Steff Gladstone steff.gladst...@gmail.com wrote: The ENQ has to be transparent to the JCL. Could I dynamically allocate a dataset with DISP=(OLD,PASS)? As I recall the dynamic allocation does not permit the use of PASS. Hum, I'm going to go way out on a limb and start sawing. grin/ I wonder if it would be possible to do a directed ENQ of a SYSDSN to the initiator TCB and then modify the SWA to generate the internal information for a DD and place that as if it had been in a DD in the JCL. I am likely not saying that very well. But I'm thinking that products like CA-11 do this sort of thing for restart (in order to change GDG generation numbers). If this were possible, then perhaps the initiator would do the DEQ at end of job. Perhaps Chris, or another ISV person, would know. On Mon, Apr 20, 2015 at 5:30 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: I guess you could do that, assign the initiator TCB to the ENQ, but what happens if the job abends before the step you do the DEQ in? I think this will work - If the purpose is to prevent two similar processes, then why not use a common data set and allocate it as DISP=(OLD,PASS). That way the ENQ on the data set will last for the duration of the job, and if it dies early the ENQ automatically goes away. Chris Blaicher -- If you sent twitter messages while exploring, are you on a textpedition? 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
As previously suggested, initial IEFBR14 step (e.g.) //step1 exec pgm=iefbr14 //dd1dd dsn=hlq.program,disp=(mod,pass),space=(trk,1,1),unit=sysda And simply never reference hlq.program in the jobstream. This will prevent multiple concurrent processes on the same program and is a lot less work than some of the other suggestions in this thread. HTH, snip The job is performing a change management system operation (moving a new program version to production, saving previous generations, providing for possible fallback, etc.). The operation for various reasons must be performed in several job steps. We want to ENQ on the name of the program being handled to prevent other operations or changes being made to that program in parallel. Of course the ENQ must remain in effect for the duration of the entire operation. + On Mon, Apr 20, 2015 at 6:19 PM, Jousma, David david.jou...@53.com wrote: Maybe if you can explain in more detail what situation you are trying to solve for would help? _ 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 /snip -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steff Gladstone Sent: Monday, April 20, 2015 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENQ for the life of the job I suppose a final job-step to do the DEQ with COND=EVEN would not always do the trick. As I recall there are some types of abends that flush the job including steps with COND=EVEN, right? On Mon, Apr 20, 2015 at 6:09 PM, John McKown john.archie.mck...@gmail.com wrote: On Mon, Apr 20, 2015 at 9:41 AM, Steff Gladstone steff.gladst...@gmail.com wrote: The ENQ has to be transparent to the JCL. Could I dynamically allocate a dataset with DISP=(OLD,PASS)? As I recall the dynamic allocation does not permit the use of PASS. Hum, I'm going to go way out on a limb and start sawing. grin/ I wonder if it would be possible to do a directed ENQ of a SYSDSN to the initiator TCB and then modify the SWA to generate the internal information for a DD and place that as if it had been in a DD in the JCL. I am likely not saying that very well. But I'm thinking that products like CA-11 do this sort of thing for restart (in order to change GDG generation numbers). If this were possible, then perhaps the initiator would do the DEQ at end of job. Perhaps Chris, or another ISV person, would know. On Mon, Apr 20, 2015 at 5:30 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: I guess you could do that, assign the initiator TCB to the ENQ, but what happens if the job abends before the step you do the DEQ in? I think this will work - If the purpose is to prevent two similar processes, then why not use a common data set and allocate it as DISP=(OLD,PASS). That way the ENQ on the data set will last for the duration of the job, and if it dies early the ENQ automatically goes away. Chris Blaicher -- If you sent twitter messages while exploring, are you on a textpedition? 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL's NUMPROC compiler option
The transition was from 24- to 31-bit addressing. Apart from this quibble, Paul is right here. Unused fields should be initialized innocuously and, usually, marked as reserved. (From time to time there is of course a case for making user fields available in control blocks.) --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 -- 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: ENQ for the life of the job
OP is clear about not wanting to change JCL. I've never tried anything like this, but maybe code in a system exit would work. I'm thinking of either JES or SMF, both of which have exit points at job initialization and termination. One issue not mentioned so far is how any transparent mechanism is supposed to know which 'program name' to enqueue on. I assume that varies by job. Also, could a particular job execute more than one such program and therefore need multiple enqueues? Just another consideration... . . . 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 Staller, Allan Sent: Monday, April 20, 2015 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENQ for the life of the job As previously suggested, initial IEFBR14 step (e.g.) //step1 exec pgm=iefbr14 //dd1dd dsn=hlq.program,disp=(mod,pass),space=(trk,1,1),unit=sysda And simply never reference hlq.program in the jobstream. This will prevent multiple concurrent processes on the same program and is a lot less work than some of the other suggestions in this thread. HTH, snip The job is performing a change management system operation (moving a new program version to production, saving previous generations, providing for possible fallback, etc.). The operation for various reasons must be performed in several job steps. We want to ENQ on the name of the program being handled to prevent other operations or changes being made to that program in parallel. Of course the ENQ must remain in effect for the duration of the entire operation. + On Mon, Apr 20, 2015 at 6:19 PM, Jousma, David david.jou...@53.com wrote: Maybe if you can explain in more detail what situation you are trying to solve for would help? _ 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 /snip -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steff Gladstone Sent: Monday, April 20, 2015 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENQ for the life of the job I suppose a final job-step to do the DEQ with COND=EVEN would not always do the trick. As I recall there are some types of abends that flush the job including steps with COND=EVEN, right? On Mon, Apr 20, 2015 at 6:09 PM, John McKown john.archie.mck...@gmail.com wrote: On Mon, Apr 20, 2015 at 9:41 AM, Steff Gladstone steff.gladst...@gmail.com wrote: The ENQ has to be transparent to the JCL. Could I dynamically allocate a dataset with DISP=(OLD,PASS)? As I recall the dynamic allocation does not permit the use of PASS. Hum, I'm going to go way out on a limb and start sawing. grin/ I wonder if it would be possible to do a directed ENQ of a SYSDSN to the initiator TCB and then modify the SWA to generate the internal information for a DD and place that as if it had been in a DD in the JCL. I am likely not saying that very well. But I'm thinking that products like CA-11 do this sort of thing for restart (in order to change GDG generation numbers). If this were possible, then perhaps the initiator would do the DEQ at end of job. Perhaps Chris, or another ISV person, would know. On Mon, Apr 20, 2015 at 5:30 PM, Blaicher, Christopher Y. cblaic...@syncsort.com wrote: I guess you could do that, assign the initiator TCB to the ENQ, but what happens if the job abends before the step you do the DEQ in? I think this will work - If the purpose is to prevent two similar processes, then why not use a common data set and allocate it as DISP=(OLD,PASS). That way the ENQ on the data set will last for the duration of the job, and if it dies early the ENQ automatically goes away. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ for the life of the job
Using ENQ/DEQ is only good if all participants abide by it. You said: We want to ENQ on the name of the program being handled to prevent other operations or changes being made to that program in parallel.What other operations? Your other change management operations? Or do you mean general execution/access of the object(JCL, program, etc)? I ask because if you mean honoring enqueues just within your change management operations, that might be doable with what you are asking. If you mean controlling execution/copying/editing whatever object you are acting on, well, that’s an entirely different proposition, and highly unlikely to be successful unless you can control *all* avenues of getting to that object. How are these change management jobs being scheduled? Ad-hoc? From a scheduler? Is this a home-grown change management tool? I know you said the solution has to be independent of JCL. I'm wondering why? If you are using a ISV supplied change management package, most have the ability to lock a member. If homegrown, possibly using PDS's as repositories? How is the change manager JCL built? Dynamically? Without knowing your environment, it would seem to me that rather than spending a bunch of time writing/testing a RYO process that you, or your replacement one day down the road has to live with, I'd use standard JCL DISP=OLD processing on a dummy dataset name that includes the program name as part of it. _ 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 Elardus Engelbrecht Sent: Monday, April 20, 2015 1:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ENQ for the life of the job Steff Gladstone wrote: The job is performing a change management system operation (moving a new program version to production, saving previous generations, providing for possible fallback, etc.). The operation for various reasons must be performed in several job steps. We want to ENQ on the name of the program being handled to prevent other operations or changes being made to that program in parallel. Of course the ENQ must remain in effect for the duration of the entire operation. Ok. You've got good replies plus a very good probing question from D Jousma: 1. ENQ macro at first step and DEQ macro in last step. (Just check up your GRS/MIM setup as well your keywords of course) 2. DD with DISP=(OLD,PASS) or IEFBR14 with an unreferenced DSN. Failsafe, unless a weird ABEND happens. 3. SMF/JES2 Exit. 4. CA-11 with GDG or so for restart purposes. I'm not sure about this one, but I accept what was written. While I have some experience with handling ENQ problems and testing it out with Assembler to test our defective tape management system with incorrectly setup GRS across the Sysplex, I have a good solution for you for that specific situation. Do you have automation? If so, set up a flag (condition flag or variable) indicationg your process is running with 1 or many jobs and 1 or many steps. Only when the whole story is completed you turn off [1] that flag allowing others to start a new operation. Now setup your automation so that nothing else can run while that flag is running (made TRUE). This is NOT a ENQ solution, but you can perhaps consider this way since you don't want any JCL changes. HTH! Groete / Greetings Elardus Engelbrecht [1] - I eventually did the reverse - I [rather, let the automation team do the dirty work] setup the flag when a SMF job on a LPAR has finished - Only when all and every SMF flags in the whole SysPlex were made TRUE, then a certain job is kicked off automagically for that day. Then all those flags were cleared out for the next set of runs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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: ENQ for the life of the job
Jousma, David wrote: ... I'd use standard JCL DISP=OLD processing on a dummy dataset name that includes the program name as part of it. Maybe someone mentioned this already, but I was thinking even simpler - use the same job name each time if the user has no control over the JCL, with JES2 DUPL_JOB=DELAY which I think might be the default. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
