Re: Assembler programmer wanted
What I actually meant is "high for this recruiter". Enterprise Solutions has mostly Indians working their phones, and I expect they hire mostly Indian contractors for low rates. I've never worked for them so I may be doing them an injustice. But the few times I've talked to one of theirs on the phone, I heard plenty of other voices on other phones in the background, so I picture a large collection of desks in an open room with no cubicle walls. And usually they're talking lower rates, although it's mostly for COBOL developers. On the other hand maybe it's just a negotiating tactic. There are several differences in the way Indian and Yankee recruiters approach me (and I assume everyone else too); maybe lowballing is just one of the ways they're used to doing business, with the assumption that they'll have to go higher to actually close the deal. ...$125/hr, really? I should maybe pay more attention to the advice a fellow contractor gave me a couple decades ago. I was working for ... well, apparently you would regard it as peanuts although it's always been adequate for me. But Joe said I should demand $250/hr. I'd work only about a third of the time, but since that's about three times what I typically was getting, it would come out even - and in the slack periods I could work on some saleable project. I understood what he was saying; I just couldn't find a way to say "$250/hr" with a straight face. Maybe that's a common foible. My ex made really high-end decorated cakes, the sort that we saw going for $150 and up at state fairs; but she couldn't bring herself to ask more for her work than the cost of materials. She just couldn't believe her work was worth it. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Important safety note: If you are explosively decompressed to vacuum, open your mouth and exhale immediately. (Fortunately, screaming in terror has just this effect.) -Geoffrey Landis and S J Van Sickle on sci.space.tech */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: Friday, December 1, 2023 17:37 I interpreted Bob's comment "...I think the rate is unusual; I'm guessing they don't think they can get one of their regulars to do it." as meaning he thought it (60-65 $/hr) was high. But I agree that finding someone with serious assembler chops for that price isn't going to be easy. $65/hour sounds much more like an all-in employee-with-benefits kind of rate back-calculated from a salary. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Friday, December 1, 2023 16:31 Agreed, very low. I asked for and received $125/hr back in 1999 for a complex assembler consulting job (BTAM / BDAM / multitasking / etc). With inflation and time passing the starting rate for that kind of work has to go over $200/hr at the very least to attract anyone with the talent and experience. If it is a truly junior position though, say maintaining and perhaps documenting old single-function utility ASM subroutines, that might not be a terrible starting point to negotiate upwards. Anything more complicated than that, start the negotiation higher, or much higher depending on the actual work to be done. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Shaw Sent: Friday, December 1, 2023 16:15 Gotta be low... -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gord Tomlin Sent: Friday, December 1, 2023 15:24 --- On 2023-12-01 14:14 PM, Bob Bridges wrote: Pure curiosity: unusually low or unusually high? -Original Message- From: robhbrid...@gmail.com Sent: Friday, December 1, 2023 14:14 I have a req here from Enterprise solutions for an assembler programmer, paying "60-65 $/hr" on corp-to-corp. Anyone wanted a copy, let me know and I'll pass it on. I've never done business with this recruiter but I think the rate is unusual; I'm guessing they don't think they can get one of their regulars to do it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACROUTE REQUEST=AUTH problem
Hi Jon, Muli-User *Single Address Space. Regards, David On 2023-12-01 02:19, Jon Perryman wrote: The one thing no one has mentioned is MUSASS configuration (Multi-User address spaces). Has the customer configured MUSASS changes like naming table, exits or ???. For instance, is the STC jobname being appended to distinguish between production and test? Maybe a RACF trace would show the real resource name and results. -- 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
TCPIP ECSALIMIT
I want to use ECSALIMIT, which is subparameter of GLOBALCONFIG. Its purpose is clear for me - TCPIP will not exhaust all the ECSA and will not cause system outage. However... What happens when TCPIP reach the ECSALIMIT? Will the TCPIP task abend or simply some less disruptive symptoms will be observed? -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES3plus & TDMF
Thanks! Looking through 'DS QD,VOL=vv,UCB' now. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Friday, December 1, 2023 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES3plus & TDMF CAUTION: This email originated from outside of the Texas Comptroller's email system. DO NOT click links or open attachments unless you expect them from the sender and know the content is safe. Those three APARs are over 20 years old and were fixed in 2001, so yes they're on. Have you looked at the DS QD command with the UCB option to display the UCB, Prefix and Common Extension? Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com On Friday, December 1st, 2023 at 12:46 PM, Michael Watkins <032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote: > Apologies for the double listing to anyone who's also seen this on the JES3-L > LISTSERV. > > The government agency that employs me has three z/OS LPARs (V2R5) running on > a z15 server. The lone mainframe storage subsystem is a non-replicated, > channel-attached DS8886. This has never been a JES2 installation and Phoenix > Software's JES3plus is now installed. While the JES3 initialization deck has > DEVICE statements for all tape drives, it has not contained a DEVICE > statement for a DASD address in over a decade. In other words, DASD > allocation is not managed by JES3. > > The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to > migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can > move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD > volumes where the coupling facility resides without issues. A co-worker > insists that all of the LPARs must be brought down, separately, so that each > LPAR's 'sensitive' volumes can be moved from another LPAR. > > IBM documents state: 'JES3 considerations: In order to ensure that JES3 > system defined volumes will migrate (not required for a Point-In-Time > migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and > OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS and > therefore, will allow the swapping of volumes. Important: All systems sharing > devices where JES3 manages the devices must be involved in the TDMF session > running. This ensures that all JES3 internal tables are properly updated. > Failure to do so will cause unpredictable results. It is recommended that the > user check the UCB for the following bit prior to copying volumes in a JES3 > environment: UCBJ3DV - device is defined to JES3. If the bit is off, TDMF > will migrate the volume(s) with no errors. If the bit is on, TDMF will make > the appropriate calls to JES3 to notify JES3 of the volume redirection > needed.' > > Since the DASD volumes at this installation are not managed by JES3, I don't > think these APARs are an issue. However, to assuage my co-worker's fears, I'd > like to see whether the corresponding PTFs have been applied. Unfortunately, > I cannot find the PTFs that correspond to any of them. > > Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457? > > Also, I'm not sure how to display the UCBs involved to verify that the > UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help you > can provide on would be appreciated, particularly on how to use either > UCBSCAN or UCBLOOK macros. > > > -- > 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: JES3plus & TDMF
Classification: Confidential From the APAR numbers, they are ancient and most likely do not apply to ans z/OS system (OS 390 or earlier perhaps). That coed is undoubtedly in the JES3 and Jes3/Plus base. I would not worry about them. One other thing. TDMF can move inactive page datasets. It will refuse to touch an in-use page dataset. The last time I did a DASD migration, I defined temporary page datasets and used pageadd/pagdel commands to move the paging activity. After the original page datasets had been moved, I repeated the process to go back to the original page datasets. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Watkins Sent: Friday, December 1, 2023 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES3plus & TDMF [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Apologies for the double listing to anyone who's also seen this on the JES3-L LISTSERV. The government agency that employs me has three z/OS LPARs (V2R5) running on a z15 server. The lone mainframe storage subsystem is a non-replicated, channel-attached DS8886. This has never been a JES2 installation and Phoenix Software’s JES3plus is now installed. While the JES3 initialization deck has DEVICE statements for all tape drives, it has not contained a DEVICE statement for a DASD address in over a decade. In other words, DASD allocation is not managed by JES3. The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD volumes where the coupling facility resides without issues. A co-worker insists that all of the LPARs must be brought down, separately, so that each LPAR’s ‘sensitive’ volumes can be moved from another LPAR. IBM documents state: ‘JES3 considerations: In order to ensure that JES3 system defined volumes will migrate (not required for a Point-In-Time migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS and therefore, will allow the swapping of volumes. Important: All systems sharing devices where JES3 manages the devices must be involved in the TDMF session running. This ensures that all JES3 internal tables are properly updated. Failure to do so will cause unpredictable results. It is recommended that the user check the UCB for the following bit prior to copying volumes in a JES3 environment: UCBJ3DV - device is defined to JES3. If the bit is off, TDMF will migrate the volume(s) with no errors. If the bit is on, TDMF will make the appropriate calls to JES3 to notify JES3 of the volume redirection needed.’ Since the DASD volumes at this installation are not managed by JES3, I don’t think these APARs are an issue. However, to assuage my co-worker’s fears, I’d like to see whether the corresponding PTFs have been applied. Unfortunately, I cannot find the PTFs that correspond to any of them. Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457? Also, I’m not sure how to display the UCBs involved to verify that the UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help you can provide on would be appreciated, particularly on how to use either UCBSCAN or UCBLOOK macros. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive
Assembler programmer wanted
I have a req here from Enterprise solutions for an assembler programmer, paying "60-65 $/hr" on corp-to-corp. Anyone wanted a copy, let me know and I'll pass it on. I've never done business with this recruiter but I think the rate is unusual; I'm guessing they don't think they can get one of their regulars to do it. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* anti-evolutionists [in 1925 Tennessee] were fearful that a scientific idea would undermine religious belief. Today, pro-evolutionists are fearful that a religious idea will undermine scientific belief. The former had insufficient confidence in religion; the latter insufficient confidence in scienceEach tells us something important about where we stand in the universe, and it is foolish to insist that they must despise each other. -Neil Postman, "The End of Education" */ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCPIP ECSALIMIT
Classification: Confidential I haven't actually experienced this, but I would expect TCPIP to cease functioning., while the rest of the system continues to function. This is almost (but not quite) as bad as a system crash, If you have a DVIPA, you could recycle the TCPIP task and the DVIPA backup configuration would preserve the sessions. Otherwise, bad, very very bad, HTH -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Friday, December 1, 2023 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: TCPIP ECSALIMIT [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] I want to use ECSALIMIT, which is subparameter of GLOBALCONFIG. Its purpose is clear for me - TCPIP will not exhaust all the ECSA and will not cause system outage. However... What happens when TCPIP reach the ECSALIMIT? Will the TCPIP task abend or simply some less disruptive symptoms will be observed? -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JES3plus & TDMF
Apologies for the double listing to anyone who's also seen this on the JES3-L LISTSERV. The government agency that employs me has three z/OS LPARs (V2R5) running on a z15 server. The lone mainframe storage subsystem is a non-replicated, channel-attached DS8886. This has never been a JES2 installation and Phoenix Software’s JES3plus is now installed. While the JES3 initialization deck has DEVICE statements for all tape drives, it has not contained a DEVICE statement for a DASD address in over a decade. In other words, DASD allocation is not managed by JES3. The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD volumes where the coupling facility resides without issues. A co-worker insists that all of the LPARs must be brought down, separately, so that each LPAR’s ‘sensitive’ volumes can be moved from another LPAR. IBM documents state: ‘JES3 considerations: In order to ensure that JES3 system defined volumes will migrate (not required for a Point-In-Time migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS and therefore, will allow the swapping of volumes. Important: All systems sharing devices where JES3 manages the devices must be involved in the TDMF session running. This ensures that all JES3 internal tables are properly updated. Failure to do so will cause unpredictable results. It is recommended that the user check the UCB for the following bit prior to copying volumes in a JES3 environment: UCBJ3DV - device is defined to JES3. If the bit is off, TDMF will migrate the volume(s) with no errors. If the bit is on, TDMF will make the appropriate calls to JES3 to notify JES3 of the volume redirection needed.’ Since the DASD volumes at this installation are not managed by JES3, I don’t think these APARs are an issue. However, to assuage my co-worker’s fears, I’d like to see whether the corresponding PTFs have been applied. Unfortunately, I cannot find the PTFs that correspond to any of them. Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457? Also, I’m not sure how to display the UCBs involved to verify that the UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help you can provide on would be appreciated, particularly on how to use either UCBSCAN or UCBLOOK macros. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEF211I - DATA SET RESERVATION UNSUCCESSFUL on relative GDG
Thank you very much for that explanation. The documented exception to WAITALLOC(YES) waiting is if: 1. This job (plus possibly others) have the data set as SHR, AND 2. This job is trying to upgrade from SHR to OLD I'm guessing the reason for this exception is because it would lead to deadlocks. And the lesson here is that if you have a job that requires a DISP=OLD on a relative GDG in some step, then the only way to avoid the IEF211I is for the FIRST use of the same relative GDG to also be DISP=OLD. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Scott Ballentine Sent: Friday, December 1, 2023 11:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEF211I - DATA SET RESERVATION UNSUCCESSFUL on relative GDG [Some people who received this message don't often get email from sbal...@us.ibm.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] It's pretty complicated, but yes, this is the way it has worked for a very long time. Apologies in advance for what's going to be a long read First, job initiator processing (it's not really JES) at the beginning of the job grabs all of the data set enqueues for those DDs in the JCL for all of the steps. Things like GDGs and aliases haven't been resolved yet, so it's only serializing using the names exactly as coded at this point. It grabs that resource at the highest level needed by the job. So in both your examples, it gets the data.set.name resource exclusive (since OLD was coded in at least one of the steps.) If some other job has those enqueues held, the job will wait for them to become available. Next, Allocation gets control for the first step, and it starts resolving data set names for that step only. That's when we figure out that data.set.name(0) translates to data.set.name.G0017V00 (or whatever absolute data set it is). We then go get the enqueue for data.set.name.G0017V00, based on what's specified in the JCL for this particular step. The run the job step program, and after it completes, go back to Allocation for the second step, etc. But... there is an ALLOCxx parmlib setting that matters here, called SDSN_WAIT WAITALLOC. The default is NO, and that tells Allocation that if it can't get the enqueue, cancel the job and issue IEF211I. If it's set to YES, it will wait - with an exception, and that exception is what you're seeing. See the documentation of this parameter for details: https://www.ibm.com/docs/en/zos/3.1.0?topic=defaults-statements-parameters-allocxx So let's walk through the two scenarios, assuming SDSN_WAIT WAITALLOC is set to YES: 1. First step has DISP=OLD,second has DISP=SHR. Job initiator gets the data.set.name enqueue exclusive, because some step needs it exclusive. At beginning of step 1, Allocation resolves data.set.name(0) to data.set.name.GVxx and requests that enqueue exclusive. We wait because somebody else holds it shared, and when they free it, we obtain it exclusive and move on. At beginning of step 2, Allocation resolves data.set.name(0) to data.set.name.GVxx, and we have that enqueue exclusive, so nothing changes. Everything runs successfully. 2. First step has DISP=SHR, second has DISP=OLD. Job initiator gets the data.set.name enqueue exclusive, because some step needs it exclusive. At beginning of step 1, Allocation resolves data.set.name(0) to data.set.name.GVxx and gets that enqueue shared, which works because the other holder has it shared too. At beginning of step 2, Allocation resolves data.set.name(0) to data.set.name.GVxx, and needs that enqueue exclusive but we only hold it shared. We try to upgrade it, but since somebody else holds it shared, we are not able to. (When upgrading, waiting isn't allowed, so we can only upgrade it if we are the only shared holder of the resource, otherwise the request fails.) Cancel the job. By the way, to clarify something from one of the responses - upgrading enqueues is allowed (with limitations, and that's why we try to obtain serialization the way we do), and downgrading is also allowed if you request it (see the DSENQSHR parameter on the JOB statement.) -Scott Ballentine, IBM z/OS Device Allocation sbal...@us.ibm.com -- 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: IEF211I - DATA SET RESERVATION UNSUCCESSFUL on relative GDG
It's pretty complicated, but yes, this is the way it has worked for a very long time. Apologies in advance for what's going to be a long read First, job initiator processing (it's not really JES) at the beginning of the job grabs all of the data set enqueues for those DDs in the JCL for all of the steps. Things like GDGs and aliases haven't been resolved yet, so it's only serializing using the names exactly as coded at this point. It grabs that resource at the highest level needed by the job. So in both your examples, it gets the data.set.name resource exclusive (since OLD was coded in at least one of the steps.) If some other job has those enqueues held, the job will wait for them to become available. Next, Allocation gets control for the first step, and it starts resolving data set names for that step only. That's when we figure out that data.set.name(0) translates to data.set.name.G0017V00 (or whatever absolute data set it is). We then go get the enqueue for data.set.name.G0017V00, based on what's specified in the JCL for this particular step. The run the job step program, and after it completes, go back to Allocation for the second step, etc. But... there is an ALLOCxx parmlib setting that matters here, called SDSN_WAIT WAITALLOC. The default is NO, and that tells Allocation that if it can't get the enqueue, cancel the job and issue IEF211I. If it's set to YES, it will wait - with an exception, and that exception is what you're seeing. See the documentation of this parameter for details: https://www.ibm.com/docs/en/zos/3.1.0?topic=defaults-statements-parameters-allocxx So let's walk through the two scenarios, assuming SDSN_WAIT WAITALLOC is set to YES: 1. First step has DISP=OLD,second has DISP=SHR. Job initiator gets the data.set.name enqueue exclusive, because some step needs it exclusive. At beginning of step 1, Allocation resolves data.set.name(0) to data.set.name.GVxx and requests that enqueue exclusive. We wait because somebody else holds it shared, and when they free it, we obtain it exclusive and move on. At beginning of step 2, Allocation resolves data.set.name(0) to data.set.name.GVxx, and we have that enqueue exclusive, so nothing changes. Everything runs successfully. 2. First step has DISP=SHR, second has DISP=OLD. Job initiator gets the data.set.name enqueue exclusive, because some step needs it exclusive. At beginning of step 1, Allocation resolves data.set.name(0) to data.set.name.GVxx and gets that enqueue shared, which works because the other holder has it shared too. At beginning of step 2, Allocation resolves data.set.name(0) to data.set.name.GVxx, and needs that enqueue exclusive but we only hold it shared. We try to upgrade it, but since somebody else holds it shared, we are not able to. (When upgrading, waiting isn't allowed, so we can only upgrade it if we are the only shared holder of the resource, otherwise the request fails.) Cancel the job. By the way, to clarify something from one of the responses - upgrading enqueues is allowed (with limitations, and that's why we try to obtain serialization the way we do), and downgrading is also allowed if you request it (see the DSENQSHR parameter on the JOB statement.) -Scott Ballentine, IBM z/OS Device Allocation sbal...@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: JES3plus & TDMF
Those three APARs are over 20 years old and were fixed in 2001, so yes they're on. Have you looked at the DS QD command with the UCB option to display the UCB, Prefix and Common Extension? Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com On Friday, December 1st, 2023 at 12:46 PM, Michael Watkins <032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote: > Apologies for the double listing to anyone who's also seen this on the JES3-L > LISTSERV. > > The government agency that employs me has three z/OS LPARs (V2R5) running on > a z15 server. The lone mainframe storage subsystem is a non-replicated, > channel-attached DS8886. This has never been a JES2 installation and Phoenix > Software’s JES3plus is now installed. While the JES3 initialization deck has > DEVICE statements for all tape drives, it has not contained a DEVICE > statement for a DASD address in over a decade. In other words, DASD > allocation is not managed by JES3. > > The DS8886 will soon be replaced by a DS8950F. TDMF software will be used to > migrate the contents of the DS8886 to the DS8950F. I believe that TDMF can > move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the DASD > volumes where the coupling facility resides without issues. A co-worker > insists that all of the LPARs must be brought down, separately, so that each > LPAR’s ‘sensitive’ volumes can be moved from another LPAR. > > IBM documents state: ‘JES3 considerations: In order to ensure that JES3 > system defined volumes will migrate (not required for a Point-In-Time > migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and > OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS and > therefore, will allow the swapping of volumes. Important: All systems sharing > devices where JES3 manages the devices must be involved in the TDMF session > running. This ensures that all JES3 internal tables are properly updated. > Failure to do so will cause unpredictable results. It is recommended that the > user check the UCB for the following bit prior to copying volumes in a JES3 > environment: UCBJ3DV - device is defined to JES3. If the bit is off, TDMF > will migrate the volume(s) with no errors. If the bit is on, TDMF will make > the appropriate calls to JES3 to notify JES3 of the volume redirection > needed.’ > > Since the DASD volumes at this installation are not managed by JES3, I don’t > think these APARs are an issue. However, to assuage my co-worker’s fears, I’d > like to see whether the corresponding PTFs have been applied. Unfortunately, > I cannot find the PTFs that correspond to any of them. > > Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457? > > Also, I’m not sure how to display the UCBs involved to verify that the > UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help you > can provide on would be appreciated, particularly on how to use either > UCBSCAN or UCBLOOK macros. > > > -- > 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: Assembler programmer wanted
On 2023-12-01 14:14 PM, Bob Bridges wrote: I think the rate is unusual Pure curiosity: unusually low or unusually high? -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler programmer wanted
Gotta be low... Mike Shaw MVS/QuickRef Support Chisoft On Fri, Dec 1, 2023, 3:23 PM Gord Tomlin wrote: > On 2023-12-01 14:14 PM, Bob Bridges wrote: > > I think the rate is unusual > > Pure curiosity: unusually low or unusually high? > > -- > > Regards, Gord Tomlin > Action Software International > (a division of Mazda Computer Corporation) > Tel: (905) 470-7113, Fax: (905) 470-6507 > Support: https://actionsoftware.com/support/ > > -- > 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: JES3plus & TDMF
We just created new paging volumes, PAGEAD them, updated IPL member, PAGEDEL the old volumes. On Fri, Dec 1, 2023 at 12:32 PM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > From the APAR numbers, they are ancient and most likely do not apply to > ans z/OS system (OS 390 or earlier perhaps). > That coed is undoubtedly in the JES3 and Jes3/Plus base. I would not worry > about them. > > One other thing. TDMF can move inactive page datasets. It will refuse to > touch an in-use page dataset. > > The last time I did a DASD migration, I defined temporary page datasets > and used pageadd/pagdel commands to move the paging activity. > After the original page datasets had been moved, I repeated the process to > go back to the original page datasets. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Michael Watkins > Sent: Friday, December 1, 2023 11:47 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: JES3plus & TDMF > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > Apologies for the double listing to anyone who's also seen this on the > JES3-L LISTSERV. > > The government agency that employs me has three z/OS LPARs (V2R5) running > on a z15 server. The lone mainframe storage subsystem is a non-replicated, > channel-attached DS8886. This has never been a JES2 installation and > Phoenix Software’s JES3plus is now installed. While the JES3 initialization > deck has DEVICE statements for all tape drives, it has not contained a > DEVICE statement for a DASD address in over a decade. In other words, DASD > allocation is not managed by JES3. > > The DS8886 will soon be replaced by a DS8950F. TDMF software will be used > to migrate the contents of the DS8886 to the DS8950F. I believe that TDMF > can move the JES3 SPOOL volumes, the SYSRES volumes, the page packs and the > DASD volumes where the coupling facility resides without issues. A > co-worker insists that all of the LPARs must be brought down, separately, > so that each LPAR’s ‘sensitive’ volumes can be moved from another LPAR. > > IBM documents state: ‘JES3 considerations: In order to ensure that JES3 > system defined volumes will migrate (not required for a Point-In-Time > migration) in a TDMF (or P/DAS) environment, APARs OW23271, OW28455, and > OW28457 must be applied. These APARs provides JES3 DDR support for P/DAS > and therefore, will allow the swapping of volumes. Important: All systems > sharing devices where JES3 manages the devices must be involved in the TDMF > session running. This ensures that all JES3 internal tables are properly > updated. Failure to do so will cause unpredictable results. It is > recommended that the user check the UCB for the following bit prior to > copying volumes in a JES3 environment: UCBJ3DV - device is defined to JES3. > If the bit is off, TDMF will migrate the volume(s) with no errors. If the > bit is on, TDMF will make the appropriate calls to JES3 to notify JES3 of > the volume redirection needed.’ > > Since the DASD volumes at this installation are not managed by JES3, I > don’t think these APARs are an issue. However, to assuage my co-worker’s > fears, I’d like to see whether the corresponding PTFs have been applied. > Unfortunately, I cannot find the PTFs that correspond to any of them. > > Question: What PTFs correspond to APARs OW23271, OW28455, and OW28457? > > Also, I’m not sure how to display the UCBs involved to verify that the > UCBJ3DV flag indicates that the volumes are not managed by JES3. Any help > you can provide on would be appreciated, particularly on how to use either > UCBSCAN or UCBLOOK macros. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this > email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, distribution and / or > publication of this message without the prior written consent of authorized > representative of HCL is strictly prohibited. If you have received
Re: IEF211I - DATA SET RESERVATION UNSUCCESSFUL on relative GDG
On 12/1/2023 9:26 AM, Scott Ballentine wrote: (When upgrading, waiting isn't allowed, so we can only upgrade it if we are the only shared holder of the resource, otherwise the request fails.) I just learned something here, Scott. I always assumed an upgrade would wait just the way an ordinary ENQ does. (Obviously, I never read the fine print... ) Any idea why this restriction exists? Were the original designers afraid -- because shared ENQ already held -- that it would lead to deadlock? -- Phoenix Software International Edward E. Jaffe Chief Technology Officer 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler programmer wanted
Agreed, very low. I asked for and received $125/hr back in 1999 for a complex assembler consulting job (BTAM/BDAM/multitasking/etc.). With inflation and time passing the starting rate for that kind of work has to go over $200/hr at the very least to attract anyone with the talent and experience. If it is a truly junior position though, say maintaining and perhaps documenting old single-function utility ASM subroutines, that might not be a terrible starting point to negotiate upwards. Anything more complicated than that, start the negotiation higher, or much higher depending on the actual work to be done. Peter From: IBM Mainframe Discussion List On Behalf Of Mike Shaw Sent: Friday, December 1, 2023 4:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler programmer wanted Gotta be low... Mike Shaw MVS/QuickRef Support Chisoft On Fri, Dec 1, 2023, 3:23 PM Gord Tomlin mailto:gt.ibm.li...@actionsoftware.com>> wrote: > On 2023-12-01 14:14 PM, Bob Bridges wrote: > > I think the rate is unusual > > Pure curiosity: unusually low or unusually high? > -- 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: JES3plus & TDMF
On 12/1/2023 9:46 AM, Michael Watkins wrote: Since the DASD volumes at this installation are not managed by JES3, I don’t think these APARs are an issue. However, to assuage my co-worker’s fears, I’d like to see whether the corresponding PTFs have been applied. Unfortunately, I cannot find the PTFs that correspond to any of them. If you scan the JES3 or JES3plus source code for those APAR numbers, you will find the code is there -- implemented way back in 1996 and 1997. But you're right, unless the DASD is JES3-managed, they do not apply. xxxMDSB: * OW23271 HJS6604 961030 PS0MC: OS 2.4.0 @WA23271 02400432 * OW28457 HJS6605 970828 PS0MC: OS 2.5.0 @WA28457 02400433 xxxIPSET: * OW28455 HJS6605 970902 PS0MC : OS 2.5.0 *@WA28455 01016003 -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler programmer wanted
On Fri, 1 Dec 2023 at 16:31, Farley, Peter < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > Agreed, very low. I asked for and received $125/hr back in 1999 for a > complex assembler consulting job (BTAM/BDAM/multitasking/etc.). With > inflation and time passing the starting rate for that kind of work has to > go over $200/hr at the very least to attract anyone with the talent and > experience. > I interpreted Bob's comment "...I think the rate is unusual; I'm guessing they don't think they can get one of their regulars to do it." as meaning he thought it (60-65 $/hr) was high. But I agree that finding someone with serious assembler chops for that price isn't going to be easy. $65/hour sounds much more like an all-in employee-with-benefits kind of rate back-calculated from a salary. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEF211I - DATA SET RESERVATION UNSUCCESSFUL on relative GDG
Look into ALOCxx parmlib option - "SDSN_WAIT WAITALLOC(YES)" Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html On Thu, 30 Nov 2023 23:17:48 +, Schmitt, Michael wrote: >JOB. If we were starting new we'd use STEP. > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Don Leahy >Sent: Thursday, November 30, 2023 5:12 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: IEF211I - DATA SET RESERVATION UNSUCCESSFUL on relative GDG > >[You don't often get email from don.le...@leacom.ca. Learn why this is >important at https://aka.ms/LearnAboutSenderIdentification ] > >Are you using GDGBIAS = STEP or GDGBIAS = JOB? > >On Thu, Nov 30, 2023 at 13:17 Mike Schwab wrote: > >> Can downgrade from Exclusive (NEW,MOD,OLD) to Shared (SHR) within a job. >> Cannot upgrade from Shared to Exclusive within a job.. >> Since the first job was SHR, another system / job / task may be browing the >> data, and prevents a Shared enque being upgraded to Exclusive enque. This >> is documented for within a job. >> I am guessing the Exclusive enque process requires no one be using the DSN >> at the time of the attempt, but that is not documented on >> https://www.ibm.com/docs/en/zos/3.1.0?topic=statement-disp-parameter >> >> >> On Thu, Nov 30, 2023 at 9:24 AM Schmitt, Michael >> wrote: >> >> > We had a production job enqueue failure on z/OS 2.4, that it seemed to me >> > should have worked. I've been in communication with IBM; they say it is >> as >> > expected. But I don't understand why this is normal. Does it make sense >> to >> > you? Has it always worked this way? >> > >> > Here's the scenario: >> > >> > We have a job where the first step has DD DSN=data.set.name(0),DISP=SHR. >> > The second step has the same data set, but as exclusive: DD DSN= >> > data.set.name(0),DISP=OLD. >> > >> > Someone was browsing the data set when the job started, so they were >> > holding a shared enqueue. >> > >> > The first step ran, and then the second step failed with the IEF211I - >> > DATA SET RESERVATION UNSUCCESSFUL error. >> > >> > >> > My understanding is that JES acquires the enqueues at the highest level >> > before starting the job, to prevent deadlocks. IBM says that because it >> is >> > a relative GDG, it is unable to acquire the enqueue on the *absolute* >> > generation before the job started. >> > >> > >> > Contrast it with this case: >> > 1st step: DD DSN=data.set.name(0),DISP=OLD >> > 2nd step: DD DSN=data.set.name(0),DISP=SHR >> > And again, a user is browsing the data set. >> > >> > In this case, the job waits until the user's enqueue is released. Which >> > means that JES tried to get the exclusive enqueue before starting the >> job, >> > so waits. Or it means that it stated the job, couldn't get the enqueue, >> but >> > waits instead of failing with the IEF211I error. >> > >> > So why is the second case different than the first? >> > >> > >> > >> > -- >> > 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 >> > >-- >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
