Re: Have I misunderstood TOD clock & leap seconds?
Hercules emulates the TOD clock, so what you see is Hercules behaviour and not the real hardware behaviour for any particular machine type. Additionally current releases of Hercules include support for emulating the IBM TOD clock steering facility. So Hercules will steer the emulated TOD clock to the value of the synchronization time -- presumably the time set in the host Linux system. I doubt that there is any ETR or STP capability though the Linux clock is generally synced to NTP, which is "close enough". Bottom line is that the steering takes care of leap seconds and you'd have to catch a steering window as a leap second occurred in real time to see it. On Thu, Nov 12, 2020 at 2:13 PM Rupert Reynolds wrote: > I did look for IBM docs online, but I haven't found anything very helpful. > > I read of someone using STCK and converting (the hard way!) to display > time, instead of using TIME DEC. So I tried it on my Hercules/MVS 3.8 > setup. > > I was expecting to have to account for all the leap seconds since 1972. I > mean that a hypothetical system running for decades would presumably have > been running its TOD clock during leap seconds. > > I'll improve the code to print out the exact difference, but should I > expect any difference, or have I made a mistake? > > As a quick check, I used TIME STCK, did the equivalent of a shift right by > 12 bits and dividing by (1,000,000*3600*24) for days, subtracted 28 leap > days and then divided by 365 for years. UNPK the remainder for days. > > I left this running overnight, looping roughly twice a second. I expected > my date from STCK to change sooner than TIME DEC by a few seconds due to > leap seconds since 1972, but it matched all night, including midnight. > > Perhaps the TOD clock is slowed or stalled for leap seconds, to keep > TOD-derived date and time in synch with solar time? > > It's amazing how much detail there is. > > Roops. > > -- > 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: Have I misunderstood TOD clock & leap seconds?
On Wed, Nov 11, 2020 at 9:13 PM Rupert Reynolds wrote: > > > Perhaps the TOD clock is slowed or stalled for leap seconds, to keep > TOD-derived date and time in synch with solar time? > > > Roops. > Correct. -- 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
Have I misunderstood TOD clock & leap seconds?
I did look for IBM docs online, but I haven't found anything very helpful. I read of someone using STCK and converting (the hard way!) to display time, instead of using TIME DEC. So I tried it on my Hercules/MVS 3.8 setup. I was expecting to have to account for all the leap seconds since 1972. I mean that a hypothetical system running for decades would presumably have been running its TOD clock during leap seconds. I'll improve the code to print out the exact difference, but should I expect any difference, or have I made a mistake? As a quick check, I used TIME STCK, did the equivalent of a shift right by 12 bits and dividing by (1,000,000*3600*24) for days, subtracted 28 leap days and then divided by 365 for years. UNPK the remainder for days. I left this running overnight, looping roughly twice a second. I expected my date from STCK to change sooner than TIME DEC by a few seconds due to leap seconds since 1972, but it matched all night, including midnight. Perhaps the TOD clock is slowed or stalled for leap seconds, to keep TOD-derived date and time in synch with solar time? It's amazing how much detail there is. Roops. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Looking for a security solution (http and batch jobs)
Hi All I'm looking for a piece of software that can sit between a batch job and a HTTP endpoint that runs on z/OS. The software would need to support RACF authentication/authorisation based on the userid of the batch job and then use its own RACF certificate for authentication/authorisation to perform some function against the HTTP endpoint (HTTP GET, POST, etc). I don't want to have to write something myself. Any ideas? Thanks Luke. "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
"BTW: Your case seem ridiculous (tenths of hour? Every job accounted?), but - this is more important - it has nothing to do with the problem." Yes. Chargebacks for mainframe time, and accounting when LPARs are leased to 3rd party customers. When I was a customer of a mainframe service provider, we paid $8,000 per CPU hour which was a very competitive rate for a 2 processor LPAR. So, you bet. A tenth of an hour was $800. BTW, lawyers bill their clients in tenths of an hour. At $1000/hr for a partner, 6 minutes is $100. And, the systems that lawyers use, have client matter codes for billing. They are required to for the court. Joe On Wed, Nov 11, 2020 at 4:39 PM R.S. wrote: > W dniu 05.11.2020 o 20:01, retired mainframer pisze: > >> -Original Message- > >> From: IBM Mainframe Discussion List On > >> Behalf Of R.S. > >> Sent: Thursday, November 05, 2020 4:20 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: JES2 Policies > >> > >> Joe, > >> > >> And I'm pretty sure no business department is interested in ACCNT field > >> and its content. Believe me or not: IT is a tool to achieve business > >> goal, but the details, guts, fields, commas are NOT in the scope of > >> business focus. They want working application, it is up to IT how to do > >> it. Changing ACCNT or classes are not strategic. > >> BTW: Gadi's further explanation sched more light on that. > >> That's why I proposed solution for real need. Not just abstract > >> excercise to solve. > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > > Why would you think that? When I was working, our office had several > different contracts active simultaneously. Many were "cost plus" rather > than "fixed fee." It was not unusual to spend a portion of each day on > different ones. We were required to daily document our time on each to the > nearest tenth of an hour. Similarly, when we logged on to TSO or submitted > a batch job, we were required to specify the account field that > corresponded to that contract. We had an exit (IEFACTRT?) that captured > this along with job statistics, such as CPU time, I/O counts, etc and cut > appropriate SMF records. These formed the basis for billing the > customers. It was also used by management to determine how accurate > initial estimates were and then refine our process for estimating future > bids. > > Why do I think that? This is my experience. I saw and *solved* many > scenarios where weird (OK, unusual) requirements were NOT business need, > but were derivative of those. Yes, I sustain - business dept has no > interest in ACCNT field, TRK vs CYL vs AVG and many other technical > things. BTW: I also saw other scenarios but I have *never* saw > reasonable explanation for them. Of course this is only my limited 25+ > yo experience. I would be happy to learn such cases. > > BTW: Your case seem ridiculous (tenths of hour? Every job accounted?), > but - this is more important - it has nothing to do with the problem. > Please, read Gadi's further explanations. In this case the only purpose > (*) of ACCNT field is to manage job class and service class assignment. > (*) > (Fine print: this is the only purpose we know. However why to suspect > there are other hidden purposes? How to satisfy them? And what's wrong > with CLASS= keyword in jobcard?) > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > 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, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully
Re: IPCS - DAE gets RC -71
"Ensure that the active IKJTSOxx parmlib member includes the program name ADYOPCMD in the AUTHCMD NAMES section. " -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Wednesday, November 11, 2020 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IPCS - DAE gets RC -71 how do I tell that? -- 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: JES2 Policies
This is matter of the tool used to do mass change. IMHO there is no rocket science to write some simple REXX script adding keyword parameter to existing statement with preserving JCL rules coding. Of course there is nothing wrong with two step approach - first for adding CLASS=existing_default, and second with change this value to other. BTW: many years ago I supported some "wannabe-programmer" and "wannabe - consultant", who was unable to change jobclass. Yes, the problem was CLASS=5 and his task was to change it to CLASS=A or just delete this parameter. It took him 7 hours and many attempts to surrender ...and demand JES2 reconfiguration. ;-) Yes, JCL syntax and ISPF Edit were black magic for him. Few years later his company hired me to teach JCL. Usually it takes 4.5 days (IBM course), but they demanded to compress it to one day. Oh, students had very weak knowledge about ISPF and Edit. -- Radoslaw Skorupka Lodz, Poland W dniu 05.11.2020 o 16:44, Mike Schwab pisze: Step 1 I would put the default CLASS= in every job. Easier to change the default than add a new line. On Thu, Nov 5, 2020 at 6:09 AM R.S. wrote: Now we know more. Maybe still not enough ;-) However we may assume: a) there is finite number of the jobs b) you know all the jobs - that means all PDS/PDSE's with the jobs. No secret libraries, no forgotten user libraries, etc. c) the jobs are not generated dynamically by some "black box" tool, so all the jobs are known. d) jobs have accnt field with some known/documented format and its content clearly tell you which class to use (let's simplify it to just jobclasses A, B, C - good, better, the best) In such scenario I would think about mass change. Simply, for any job with ACCNT containing GOOD place CLASS=A. For any job with ACCNT containing BTTR place CLASS=B, and for each job with BEST place CLASS=C. Note: it doesn't matter whether you have 100, 1000 or 1 jobs. OK, for 100 jobs it is still feasible to change it manually. ;-) Note2: Since the jobs are already in production, with NO classes, there is no big problem to change it gradually. Even "forgotten" libraries can be changed later, when detected. -- Radoslaw Skorupka Lodz, Poland W dniu 05.11.2020 o 06:21, Gadi Ben-Avi pisze: Hi Everone. Thanks for responding. We 'purchased' a system from another site. The jobs that came with the system do not have a CLASS parameter specified. They do have specific values in the accounting fields that are supposed to assign the job to specific classes. I assume they had an exit that did all of this. Up until now, all of the jobs ran in the same class, with the same service class. I've been asked to assign a lower service class to jobs that have a specific (not specified as yet) value in the accounting data. The simplest way would have been to tell the job owners to code a CLASS parameter on the JOB card, but they say that that is too much work. I looked at doing this using WLM definitions. It works if the value in the accounting data is in the first 8 bytes. Otherwise, it get complicated to write, debug, and read. I read about JES2 Policies, so I looked it up in the documentation. Gadi -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Wednesday, November 4, 2020 10:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies In a previous life at the late great Security Pacific, we an *elaborate* scheme based on account numbers. Even the job name was generated from account number. To control all this, we had a VSAM file containing all valid account numbers along with indications of who could submit jobs with each number. An array of JES2 and SMF exits were employed to make all this work. At the end of the year, account numbers were used for chargeback to respective departments for resource usage. There is no way in h*ll I would recommend this complex scheme for a modern shop. But yes, with enough time and $$, it can be done. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Wednesday, November 4, 2020 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: JES2 Policies *** EXTERNAL EMAIL - Use caution when opening links or attachments *** Initial Request: The current goal is to change a job's class or service class depending on certain values in the accounting information. It also seems to me that a JCL tool, Like JCLPLUS could put rules into JCL Scanning and force users to adhere to a standard. But that would mean you have a Source management system that is used to deploy Jobs to various systems. It could have rules that say, if Account Code is this, then the job should have Service Class STCLOW and CLASS X Lizette -Original Message- From:
Re: JES2 message $HASP375 Estimate exceeded
It's a SMOP: http://afpcinc.org/wp-content/uploads/2016/08/PTOCA-Reference-Presentation-Text-Object-Content-Architecture-Reference.pdf It's probably more trouble than it's worth unless there is an existing program to do it. The same is true of PDF. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Edward Finnell [000248cce9f3-dmarc-requ...@listserv.ua.edu] Sent: Wednesday, November 11, 2020 4:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 message $HASP375 Estimate exceeded AFP is a control stream to the printer starting with x'5a' in column 1. All the rest is text andsearchable. Is AFP searchable? -Original Message- From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wed, Nov 11, 2020 7:54 am Subject: Re: JES2 message $HASP375 Estimate exceeded On Tue, 10 Nov 2020 19:01:44 +, Seymour J Metz wrote: >Graphic SPOOL files should be in the format expected by the output device or >driver. Try sending PDF to a PCL only printer nand see what happens. > I haven't a PCL printer to try. I expect it to work fine if the PCL printer driver is PDF-savvy. Even as AFP works if the writer for the PCL printer writer is AFP-savvy. And PDF is more commonly supported than AFP. IBM distributes the z/OS doc as PDF, not AFP. Is AFP searchable? > >From: Paul Gilmartin >Sent: Tuesday, November 10, 2020 1:23 PM > ... >Ideally for portability, graphic spool files should be in a common format >such as PDF (MacOS appear to do that), ... -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
W dniu 05.11.2020 o 20:01, retired mainframer pisze: -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, November 05, 2020 4:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Joe, And I'm pretty sure no business department is interested in ACCNT field and its content. Believe me or not: IT is a tool to achieve business goal, but the details, guts, fields, commas are NOT in the scope of business focus. They want working application, it is up to IT how to do it. Changing ACCNT or classes are not strategic. BTW: Gadi's further explanation sched more light on that. That's why I proposed solution for real need. Not just abstract excercise to solve. -- Radoslaw Skorupka Lodz, Poland Why would you think that? When I was working, our office had several different contracts active simultaneously. Many were "cost plus" rather than "fixed fee." It was not unusual to spend a portion of each day on different ones. We were required to daily document our time on each to the nearest tenth of an hour. Similarly, when we logged on to TSO or submitted a batch job, we were required to specify the account field that corresponded to that contract. We had an exit (IEFACTRT?) that captured this along with job statistics, such as CPU time, I/O counts, etc and cut appropriate SMF records. These formed the basis for billing the customers. It was also used by management to determine how accurate initial estimates were and then refine our process for estimating future bids. Why do I think that? This is my experience. I saw and *solved* many scenarios where weird (OK, unusual) requirements were NOT business need, but were derivative of those. Yes, I sustain - business dept has no interest in ACCNT field, TRK vs CYL vs AVG and many other technical things. BTW: I also saw other scenarios but I have *never* saw reasonable explanation for them. Of course this is only my limited 25+ yo experience. I would be happy to learn such cases. BTW: Your case seem ridiculous (tenths of hour? Every job accounted?), but - this is more important - it has nothing to do with the problem. Please, read Gadi's further explanations. In this case the only purpose (*) of ACCNT field is to manage job class and service class assignment. (*) (Fine print: this is the only purpose we know. However why to suspect there are other hidden purposes? How to satisfy them? And what's wrong with CLASS= keyword in jobcard?) -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. 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, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 message $HASP375 Estimate exceeded
AFP is a control stream to the printer starting with x'5a' in column 1. All the rest is text andsearchable. Is AFP searchable? -Original Message- From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wed, Nov 11, 2020 7:54 am Subject: Re: JES2 message $HASP375 Estimate exceeded On Tue, 10 Nov 2020 19:01:44 +, Seymour J Metz wrote: >Graphic SPOOL files should be in the format expected by the output device or >driver. Try sending PDF to a PCL only printer nand see what happens. > I haven't a PCL printer to try. I expect it to work fine if the PCL printer driver is PDF-savvy. Even as AFP works if the writer for the PCL printer writer is AFP-savvy. And PDF is more commonly supported than AFP. IBM distributes the z/OS doc as PDF, not AFP. Is AFP searchable? > >From: Paul Gilmartin >Sent: Tuesday, November 10, 2020 1:23 PM > ... >Ideally for portability, graphic spool files should be in a common format >such as PDF (MacOS appear to do that), ... -- 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: IPCS - DAE gets RC -71
So in ISPF Option 6 enter PARMLIB and make sure the output matches you AUTHxxx entries for ADY programs Next find out the SYS1.**.PARMLIB dataset and review members ADYSETxx Compare them to the MANUAL Init and Tuning REF Manual I think If the ADYSET is correct, and TSO IKJTSOxx and PARMLIB command are correct You probably need to open a Case with IBM IPCS Support for assistance. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Wednesday, November 11, 2020 1:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IPCS - DAE gets RC -71 how do I tell that? -- 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: IPCS - DAE gets RC -71
Are the ADYSETxx member set up in PARMLIB? They are invoked by the IPCS Panels. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Wednesday, November 11, 2020 12:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IPCS - DAE gets RC -71 When I try to turn off dump suppression in IPCS / DAE I get the following: 586 *-*Address TSO "ADYOPCMD 1" /* Stop DAE @01A*/ +++ RC(-71) +++ -- 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: IPCS - DAE gets RC -71
how do I tell that? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS - DAE gets RC -71
But is it in the TSO authorized commands table? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Wednesday, November 11, 2020 3:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IPCS - DAE gets RC -71 yes, its in SYS1.LINKLIB. Bill -- 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: IPCS - DAE gets RC -71
yes, its in SYS1.LINKLIB. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS - DAE gets RC -71
Is ADYOPCMD authorized? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Wednesday, November 11, 2020 2:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IPCS - DAE gets RC -71 When I try to turn off dump suppression in IPCS / DAE I get the following: 586 *-*Address TSO "ADYOPCMD 1" /* Stop DAE @01A*/ +++ RC(-71) +++ -- 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
IPCS - DAE gets RC -71
When I try to turn off dump suppression in IPCS / DAE I get the following: 586 *-*Address TSO "ADYOPCMD 1" /* Stop DAE @01A*/ +++ RC(-71) +++ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
survey deadline extended
Hello IBM Z user, Thank you to those who have taken our survey to help us understand your experience with upgrading z/OS releases and adopting new function and enhancements through continuous delivery. We look forward to hearing from more of you so we are extending the deadline to Monday, Nov. 16, 2020. Here's the link to the survey: https://www.surveygizmo.com/s3/5953855/z-OS-Adoption-Research-October-2020 Thank you in advance for your participation! Regards, Cheryl D. Loughlin Product Design Lead for IBM Z Software IBM Studios Poughkeepsie Twitter: @CherylLoughlin E-mail: chery...@us.ibm.com 2455 South Rd Poughkeepsie, NY 12601-5400, U.S. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 message $HASP375 Estimate exceeded
Which part of "only" don't you understand? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Wednesday, November 11, 2020 8:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 message $HASP375 Estimate exceeded On Tue, 10 Nov 2020 19:01:44 +, Seymour J Metz wrote: >Graphic SPOOL files should be in the format expected by the output device or >driver. Try sending PDF to a PCL only printer nand see what happens. > I haven't a PCL printer to try. I expect it to work fine if the PCL printer driver is PDF-savvy. Even as AFP works if the writer for the PCL printer writer is AFP-savvy. And PDF is more commonly supported than AFP. IBM distributes the z/OS doc as PDF, not AFP. Is AFP searchable? > >From: Paul Gilmartin >Sent: Tuesday, November 10, 2020 1:23 PM >... >Ideally for portability, graphic spool files should be in a common format >such as PDF (MacOS appear to do that), ... -- 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: JES2 message $HASP375 Estimate exceeded
On Tue, 10 Nov 2020 19:01:44 +, Seymour J Metz wrote: >Graphic SPOOL files should be in the format expected by the output device or >driver. Try sending PDF to a PCL only printer nand see what happens. > I haven't a PCL printer to try. I expect it to work fine if the PCL printer driver is PDF-savvy. Even as AFP works if the writer for the PCL printer writer is AFP-savvy. And PDF is more commonly supported than AFP. IBM distributes the z/OS doc as PDF, not AFP. Is AFP searchable? > >From: Paul Gilmartin >Sent: Tuesday, November 10, 2020 1:23 PM >... >Ideally for portability, graphic spool files should be in a common format >such as PDF (MacOS appear to do that), ... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DAE to stop dump suppression
In addition to the methods that involve physically updating the DAE data
set (or stopping DAE entirely), you can also consider setting a SLIP error
trap that matches the event with ACTION=NOSUP ("NOSUP" is short for No
Suppress)
Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GSE UK Virtual Conference - Week 2 coming up - you can still register
All sessions (technical and general) are being recorded. Those who register for the virtual conference will have access to the 'live' sessions they have choosen to 'attend' and all the recordings at the end of the conference. Regards Parwez Hamid From: IBM Mainframe Discussion List on behalf of Wendell Lovewell <01e9c0ee0673-dmarc-requ...@listserv.ua.edu> Sent: 10 November 2020 20:57 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GSE UK Virtual Conference - Week 2 coming up - you can still register Thanks for the tip. These sessions are mostly too early in the morning for those of us in the Western hemisphere. The little "tape"(?) symbol that indicates a recording is available seems to only be for the general sessions. Are the technical sessions being recorded? Is there a way to listen to them other than being "live"? Thanks, Wendell -- 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: DAE to stop dump suppression
when I enter "T" I get the following: ADYOPCMD failed to stop DAE processing. Return Code=-71 Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
