Re: A question about CPU usage on z/OS
While each cpu in the 504 is slower than a 701 cpu, running 4 batch jobs at the same time should reduce run time because each batch job expect reduced wait because there is reduced competition for the CPU. However, you could be correct if the 4 batch jobs are experiencing heavy I/O wait. On Friday, July 14, 2023 at 06:05:24 PM PDT, Tom Brennan wrote: On 7/14/2023 3:01 PM, Jon Perryman wrote: > As for batch running slower at night after you went from 1 CPU to 4, that doesn't make sense unless other things changed. I'm thinking it could be as simple as say, going from a 701 to a 504. The overall MIPS are bumped up, multi-task address spaces are happier, but single threaded work can be left in the dust. -- 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: A question about CPU usage on z/OS
Every address space has multiple TCB. Only TCBs that are not in a wait (dispatchable) are eligible to run on separate CPUs. You are correct but all TCBs in a wait are not eligible to run. On Friday, July 14, 2023 at 05:56:58 PM PDT, Brian Westerman wrote: I'm pretty sure that each TCP of a task can run on a separate CPU. Brian -- 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: How to set a SLIP to catch S0C4 in OMVS separate AS
On Sat, 15 Jul 2023 00:16:23 +, Farley, Peter wrote: >... >Any and all assistance to help us catch this abend and generate the SVCDUMP >that the ibmdb team have requested to help solve the root cause would be much >appreciated. > No assistance, but an observation that SLIP has appeared to have been specified before fork() came to MVS. It would be a good Idea to enhance SLIP to recognize all the progeny of a job step. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A question about CPU usage on z/OS
On 7/14/2023 3:01 PM, Jon Perryman wrote: > As for batch running slower at night after you went from 1 CPU to 4, that doesn't make sense unless other things changed. I'm thinking it could be as simple as say, going from a 701 to a 504. The overall MIPS are bumped up, multi-task address spaces are happier, but single threaded work can be left in the dust. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A question about CPU usage on z/OS
I'm pretty sure that each TCP of a task can run on a separate CPU. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How to set a SLIP to catch S0C4 in OMVS separate AS
Hi All, I am trying to help the python ibmdb team help me solve an S0C4 abend issue with (we think maybe) their code on the IBM Zxplore LPAR by generating an SVCDUMP that the ibmdb team could analyze. The admins at Zxplore have tried a couple of times to set a SLIP to catch the S0C4 abend that I am getting when using one of the ibmdb functions, but it keeps missing catching the abend. Here is the "usual" setup to duplicate the abend: 1. USS logon from ssh on a Windows box at my home into the Zxplore system. Zxplore runs the bash shell as your default shell. 2. Execute "python3 db_fetch_both_err-2.py" 3. This reliably generates a S0C4 abend deep inside the python runtime code in something named TOROLABA the first time the python script tries to use the ibmdb function "fetch_both(...)". I can supply both a copy of the python script and the exact text of the abend messages if it helps you to help me, but the real question we have is how should a SLIP trap be set up to catch a S0C4 abend in a forked USS address space? The only dump that seems to be generated is a CEEDUMP in my $HOME directory on Zxplore. I have also tried a JCL executing BPXBATCH to run the exact same python script, and that also does not trigger the SLIP they recently set to match the JOB name of that JCL. SHAREAS=MUST does not work with the bash shell, so the python process is (I believe) being forked to a new AS by BPXBATCH. Any and all assistance to help us catch this abend and generate the SVCDUMP that the ibmdb team have requested to help solve the root cause would be much appreciated. Peter 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: A question about CPU usage on z/OS
I've never looked at IXGLOGR address space but my guess is that IXGLOGR would have multiple tasks (TCB's) running at the same time if there are multiple logs active. As for batch running slower at night after you went from 1 CPU to 4, that doesn't make sense unless other things changed. SRM dispatching? More workload? Competition for resources such as disk usage? LPARs and LPAR configurations? CPUs dedicated to an LPAR versus shared CPUs. As for 20 years later, an address space has always been able to support multiple dispatchable tasks. I've worked on address spaces with over a hundred tasks with over 10 dispatchable tasks at one time. All could be active as long as enough CPUs are available.On Wednesday, July 12, 2023 at 03:27:32 PM PDT, Jason Cai wrote: Dear all, I have a question about CPU usage on z/OS that I hope you can help me with. Many years ago, we increased the CPU of a mainframe from one to four, but the batch jobs at night became slower. The explanation at that time was that a batch job could only use one CPU, and the single CPU performance decreased because of the increase to four CPUs. I accepted that explanation at that time. Now, twenty years later, is z/OS still the same that an address space like IXGLOGR can only use one CPU at most? Thank you for your time and attention. I look forward to hearing from you soon. Jason Cai -- 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: Userid schemes
Nah, that's an old myth that (I think) sprang up only in my lifetime. "Man" has always applied, in English, to humans and also to adult males, depending on context. I'm still unembarrassed to use the term "man-hours". At about the same time sprang up the myth that "my" indicates ownership, and as far as I can tell it was presented by the same people and for the same reason. "My wife" doesn't mean "I own" any more than does "my career", "my god" or "my favorite food". --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* God blesses or afflicts us with people according to our needs. -Bob Mumford */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Friday, July 14, 2023 09:46 Just remarking that "man number" is conspicuously gender-specific. >> --- On Thu, 13 Jul 2023 21:56:55 -0400, David Spiegel wrote: >>> When I worked at IBM Canada full time (1994-2002), our TSO Userids >>> were XXn, where n was a person's "man number" (aka employee number). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Change how LE allocates storage (subpool,key)
I don't know if this ancient history will be of any use in your case Binyamin: In the early 1990s, I was working on IBM Prolog for 370 (MVS). I was asked to help the VM group migrate their code to MVS and they explained their issues with Stack/Heap. We discussed storage keys and what they were using and why. So it was decided to use KEY9 and I think we also used KEY15 (long time ago, and I have forgotten some details). I wrote the SVC for PROLOG and was in the middle of testing when we were informed that CICS was going to use KEY9 and a system change (forgot the name of this) was being done for them. So I had to find another key. Just thought you might need to make sure you will not create or incur some problem in using Key9 with CICS (and since the changes to CSA, this may well be obsolete). Regards, Steve Thompson On 7/14/2023 10:41 AM, Farley, Peter wrote: Binyamin, Is this desire perhaps for use in a CICS "threadsafe" or "open" TCB? If so, doesn't CICS itself provide some CICS-unique storage facilities to LE programs, and are those not sufficient to your needs? As many others have mentioned, the LE Vendor Interfaces manual has information on heap routine replacement. I suspect you are SOL for redirecting STACK storage though. The LE start and stop macro generated code doesn't look to me to be very amenable to replacing the stack allocation/free subroutines, unless maybe after setting up an enclave with CEEPIPI you change storage routine addresses in the CAA (and possibly elsewhere?), but that sounds like a heavy lift to test for RAS integrity. Peter From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen Sent: Thursday, July 13, 2023 6:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Change how LE allocates storage (subpool,key) I would like to have LE use SP=132 KEY=9 for its STACK and HEAP. I obviously could screw with CEEINT, but I don't know if that will affect other storage requests. Is there some explicit getmain routine that I can play with? -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A question about CPU usage on z/OS
CPU Affinity has not been supported for many years. I don't remember if it ever was on an address-space basis as opposed to begin on a work-unit basis (I know that you could identify CPU affinity for a scheduled SRB, for example). The "multiprocessor effect" (or perhaps it's the "multiprocessing effect") comes into play when multiple processors are in play. That's why, for example, a 4 CPU system is not deemed 4 times as fast as a 1 CPU system. The CPU capacity is not effected, but the effective result is. Processor cache, cross-processor communication and other things factor in. 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
SYSREXX - Max number of tasks (TSO=NO)
Hi: from IBM documentation (z/OS 2.4): << There can be up to 64 REXX worker tasks running TSO=NO execs and up to 8 TSO server address spaces running TSO=YES execs.>> On the other hand, in System Rexx configuration member AXRxx, you have the parameter MAXWORKERTASKS, whose maximum value is 32. MAXWORKERTASKS is described as:<> I am confused. What is the maximum number of concurrent SYSREXX execs (with TSO=NO)? 32 or 64? Thanks in advance, Juan Mautalen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
I believe that it's because a single id is easier to audit. Apparently easy audits are more important than actual security. From: IBM Mainframe Discussion List on behalf of Bob Bridges Sent: Friday, July 14, 2023 9:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Userid schemes I fully agree with the general principle that one ID must have no more than one owner. (I'll admit to exceptional cases, but I'll argue about them first.) I've never understood the reverse principle that every user must have only one ID. I think the folks who make a rule like that are simply extending the previous rule without thinking about why. ...Unless maybe they're thinking about reducing workload for the admins, who then may have to create extra IDs for each user. That doesn't apply in Mr Paice's situation. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Never cut what you can untie. -Joseph Joubert (1754-1824) */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Colin Paice Sent: Friday, July 14, 2023 07:58 At one point some of us had two userids. SYSPROG1 ... for sysprog stuff, and a personal ID. When anyone moved on they just reallocated SYSPROG1 to a new user, and all the accesses continued to work. If you use a personal ID, you had to connect it to a lot of groups to get the access, and remove the retiree from the same groups. Role based userids are much better and less work -- 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: Userid schemes
For testing authorized code, it helps to have a userid with minimal privileges. From: IBM Mainframe Discussion List on behalf of Tom Brennan Sent: Friday, July 14, 2023 10:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Userid schemes I had 3 id's on each system, but all had the same sysprog capability. Mainly it was to avoid the embarrassment of having to go to another sysprog to fix my #1 id after I messed it up testing or changing something. But they also came in handy for testing things like enqueues and multiple tasks. For DR testing we tried 3 new role-based id's to be used for OS, CICS, and DB2 recovery, but that plan kept failing due to lack of authority over time. The main sysprogs for each always kept their own access up-to-date, so we ended up using a 'stub' DR id with SPECIAL access that could change passwords and use their personal ids. That worked fine and the stub userid access was handled by an off-mainframe security system. The whole idea of course, was for anyone with the printed instructions to be able to do the DR recovery - no sysprogs needed. Turns out almost every test we needed a sysprog anyway, but at least we had that goal. > At one point some of us had two userids. SYSPROG1 ... for sysprog stuff, > and a personal ID. > When anyone moved on they just reallocated SYSPROG1 to a new user, and all > the accesses continued to work. > If you use a personal ID, you had to connect it to a lot of groups to get > the access, and remove the retiree from the same groups. > Role based userids are much better and less work > > Colin -- 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: Userid schemes
English has many nouns that have both gender neutral and gender specific uses; demanding that we stop using terms that are in no way derogatory is linguistic fascism. OTOH, there are words that really derogatory, and we should refrain from using those. From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Friday, July 14, 2023 9:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Userid schemes On Fri, 14 Jul 2023 06:43:49 -0400, David Spiegel wrote: > >EEOC is an American thing. In Canada, we have an equivalent. > Just remarking that "man number" is conspicuously gender-specific. >Please explain: "... Five digits isn't enough. ..." Enough for what? > IBM has over 300,000 employees. Are the numbers required to be unique? >(I think you're confusing employee number with SIN (equivalent to >American SSN). >On 2023-07-13 22:53, Paul Gilmartin wrote: >> On Thu, 13 Jul 2023 21:56:55 -0400, David Spiegel wrote: >>> When I worked at IBM Canada full time (1994-2002), our TSO Userids were >>> XXn, where n was a person's "man number" (aka employee number). -- 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: Userid schemes
I had 3 id's on each system, but all had the same sysprog capability. Mainly it was to avoid the embarrassment of having to go to another sysprog to fix my #1 id after I messed it up testing or changing something. But they also came in handy for testing things like enqueues and multiple tasks. For DR testing we tried 3 new role-based id's to be used for OS, CICS, and DB2 recovery, but that plan kept failing due to lack of authority over time. The main sysprogs for each always kept their own access up-to-date, so we ended up using a 'stub' DR id with SPECIAL access that could change passwords and use their personal ids. That worked fine and the stub userid access was handled by an off-mainframe security system. The whole idea of course, was for anyone with the printed instructions to be able to do the DR recovery - no sysprogs needed. Turns out almost every test we needed a sysprog anyway, but at least we had that goal. At one point some of us had two userids. SYSPROG1 ... for sysprog stuff, and a personal ID. When anyone moved on they just reallocated SYSPROG1 to a new user, and all the accesses continued to work. If you use a personal ID, you had to connect it to a lot of groups to get the access, and remove the retiree from the same groups. Role based userids are much better and less work Colin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
Being a RACF geek and a contractor for roughly half my career I've seen most of the conventions people have shared here in this thread. The best laugh I get talking with other mainframe geeks though was from a large bank where the algorithm went: First 5 letters of SURNAME + first initial of first name + first initial of middle name. Either of the last two single character fields could be cycled upwards alphabetically (starting from 'A') until a unique string was obtained in case the generated one was already allocated to someone. So my middle name is Francis and my userid became CAIRNCF - Cairns was a not uncommon surname in these parts, and thus I didn't get my forename in position 6, but did get my middle initial in position 7. The unfortunate fellow who's name is indelibly burned into my mind (and no doubt he has never heard this story) was Keith Allen Mumford - who the algorithm spat out as MUMFOKA... We decided to simply revoke that userid and roll the dice again. Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
I can verify that CA would adjust the userid if the resulting userid was 'inappropriate'. One of my coworkers was such a case. Unfortunately, its been too long ago and I can't remember the specifics. When CA bought our company and told us the new rules, one guy just busted out laughing and it took us a minute to figure it out. Mine was THITO01 and from that point on, everyone just called me Thito. (Tee-tow) Tony Thigpen Phil Smith III wrote on 7/13/23 5:37 PM: Jay Maynard wrote: The one I use was formed by taking the first four non-vowels of the last name and then the first and second initials. So I'd be SMTHPH? Ick. I know, I'd get used to it, but. That SMIPH03 really was my ID at CA after Sterling bought them. I didn't mind, the 03 was perfect! Highest number we had was BERMA16, which I assume got run up by all the Mark and Marie Bergmanns and Bergdorfs and the like out there on Lon Guyland. Ain't no perfect scheme, of course. We have someone here whose name is quite uncommon-but there's another one of him in the company, so he's got a 2 in his ID (yeah, I guess they go right to 2, so my PSMITH1 example was bogus, or at least would be bogus here; of course if they were C programmers, the one after PSMITH would be PSMITH0). -- 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: Change how LE allocates storage (subpool,key)
Binyamin, Is this desire perhaps for use in a CICS "threadsafe" or "open" TCB? If so, doesn't CICS itself provide some CICS-unique storage facilities to LE programs, and are those not sufficient to your needs? As many others have mentioned, the LE Vendor Interfaces manual has information on heap routine replacement. I suspect you are SOL for redirecting STACK storage though. The LE start and stop macro generated code doesn't look to me to be very amenable to replacing the stack allocation/free subroutines, unless maybe after setting up an enclave with CEEPIPI you change storage routine addresses in the CAA (and possibly elsewhere?), but that sounds like a heavy lift to test for RAS integrity. Peter From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen Sent: Thursday, July 13, 2023 6:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Change how LE allocates storage (subpool,key) I would like to have LE use SP=132 KEY=9 for its STACK and HEAP. I obviously could screw with CEEINT, but I don't know if that will affect other storage requests. Is there some explicit getmain routine that I can play with? -- 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: Userid schemes
Maybe it wasn't a "man number" as in "male human being", but rather a "machine automation number number"? /s (but ya gotta admit, it DOES sound like something IBM would have, complete with redundancy!) On Fri, Jul 14, 2023 at 9:59 AM David Spiegel < 0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > Hi Paul, > You said: "...Just remarking that "man number" is conspicuously > gender-specific. ..." > True, but, you have to remember the historical context for it. > > You said: "...IBM has over 300,000 employees. Are the numbers required > to be unique? ..." > AFAIK, my number was unique in Canada. > My Retain ID had to be changed because someone else (probably an > American) already was using my Man Number to LOGON. > > Regards, > David > > On 2023-07-14 09:45, Paul Gilmartin wrote: > > On Fri, 14 Jul 2023 06:43:49 -0400, David Spiegel wrote: > >> EEOC is an American thing. In Canada, we have an equivalent. > >> > > Just remarking that "man number" is conspicuously gender-specific. > > > >> Please explain: "... Five digits isn't enough. ..." Enough for what? > >> > > IBM has over 300,000 employees. Are the numbers required to be unique? > > > >> (I think you're confusing employee number with SIN (equivalent to > >> American SSN). > > > >> On 2023-07-13 22:53, Paul Gilmartin wrote: > >>> On Thu, 13 Jul 2023 21:56:55 -0400, David Spiegel wrote: > When I worked at IBM Canada full time (1994-2002), our TSO Userids > were > XXn, where n was a person's "man number" (aka employee > number). > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- zMan -- "I've got a mainframe and I'm not afraid to use it" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
Paul Gilmartin wrote, in part: >IBM has over 300,000 employees. While it's not relevant to the point you were making, I suspect that number is much smaller these days. I'd heard that IBM was down to fewer than 25,000 U.S. employees several years ago, before the Kyndryl spinoff and several more WFRs. Very sad. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
Hi Paul, You said: "...Just remarking that "man number" is conspicuously gender-specific. ..." True, but, you have to remember the historical context for it. You said: "...IBM has over 300,000 employees. Are the numbers required to be unique? ..." AFAIK, my number was unique in Canada. My Retain ID had to be changed because someone else (probably an American) already was using my Man Number to LOGON. Regards, David On 2023-07-14 09:45, Paul Gilmartin wrote: On Fri, 14 Jul 2023 06:43:49 -0400, David Spiegel wrote: EEOC is an American thing. In Canada, we have an equivalent. Just remarking that "man number" is conspicuously gender-specific. Please explain: "... Five digits isn't enough. ..." Enough for what? IBM has over 300,000 employees. Are the numbers required to be unique? (I think you're confusing employee number with SIN (equivalent to American SSN). On 2023-07-13 22:53, Paul Gilmartin wrote: On Thu, 13 Jul 2023 21:56:55 -0400, David Spiegel wrote: When I worked at IBM Canada full time (1994-2002), our TSO Userids were XXn, where n was a person's "man number" (aka employee number). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
On Fri, 14 Jul 2023 06:43:49 -0400, David Spiegel wrote: > >EEOC is an American thing. In Canada, we have an equivalent. > Just remarking that "man number" is conspicuously gender-specific. >Please explain: "... Five digits isn't enough. ..." Enough for what? > IBM has over 300,000 employees. Are the numbers required to be unique? >(I think you're confusing employee number with SIN (equivalent to >American SSN). >On 2023-07-13 22:53, Paul Gilmartin wrote: >> On Thu, 13 Jul 2023 21:56:55 -0400, David Spiegel wrote: >>> When I worked at IBM Canada full time (1994-2002), our TSO Userids were >>> XXn, where n was a person's "man number" (aka employee number). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Change how LE allocates storage (subpool,key)
I did RTFM before asking. I was surprised that it wasn't an obvious thing in the vendors guide. On Fri, 14 Jul 2023 15:11:07 +0200 Tony Harminc wrote: :>On Fri, 14 Jul 2023 at 14:33, Binyamin Dissen :> wrote: :>> :>> I also want STACK storage. :> :>OK - I'm not an expert in LE interfaces. I just saw that there's a :>documented heap manager interface that you can supply services to. :>Maybe there's something similar for stacks. Maybe stacks are allocated :>from heap storage. I'm just suggesting that "there is no replaceable :>routine" seems a bit premature wihout having RTFM in detail. :> :>Tony H. :> :>> On Fri, 14 Jul 2023 13:15:10 +0200 Tony Harminc wrote: :>> :>> :>On Fri, 14 Jul 2023 at 12:57, Binyamin Dissen :>> :> wrote: :>> :>> :>> :>> No replaceable routine. :>> :>> :>> :>> Got it. :>> :> :>> :>I'm a bit surprised... The LE Vendor Interfaces book has all kinds of :>> :>talk about providing your own heap storage manager. Maybe this :>> :>interface isn't available in your environment, or has too many :>> :>restrictions or something, but it certainly exists. :>> :> :>> :>Jump in at https://www.ibm.com/docs/en/zos/2.2.0?topic=management-vendor-heap-manager-interface :>> :> :>> :>Tony H. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
Radek, I can't read the mind of Canadian legislators, but I would guess it has to do with fraud. I'm told that one can go through someone's trash, find old bills (telephone, power etc) and use that information to convince someone at the power company that I'm the householder because I have the bill, know the account number etc. Thence to defrauding the company and possibly the rightful owner. I'm guessing the Canadian thought is that the same sort of thing can happen with employee number. I've worked at one company, as I wrote earlier in this thread, that used emp# for proof of identity when getting a password fixed over the phone. I don't think much of that scheme, and maybe that's why I go to that thought when guessing about the Canadians' motives. I have less sympathy for the user ID; seems to me that's necessarily a known quantity, at least internally, sort of like an IP address. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* There's remarkable overlap between conservative and liberal complaints about the culture. But when traditionalists talk the language of decency and morality, the left hears bigotry and theocracy. And when liberals talk about sensitivity and white privilege, the right hears something totalitarian. The result is that the two sides hold separate conversations. -Jonah Goldberg, 2007-04-17 */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Friday, July 14, 2023 05:39 I would like to know the explanation of such statement. IMHO employee# is as internal as userid. It is NOT SSN or other government number. --- W dniu 14.07.2023 o 02:32, Paul Gilmartin pisze: > Many years ago someone reported here that in Canada it was illegal to use > an employee# as a UID because it's considered privileged HR information. > I'd guess the same applies to user IDs. > --- On Thu, 13 Jul 2023 20:17:38 -0400, Matt Hogstrom wrote: >> A place I worked used initials followed by a 5 digit employee ID. >> xxn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
I fully agree with the general principle that one ID must have no more than one owner. (I'll admit to exceptional cases, but I'll argue about them first.) I've never understood the reverse principle that every user must have only one ID. I think the folks who make a rule like that are simply extending the previous rule without thinking about why. ...Unless maybe they're thinking about reducing workload for the admins, who then may have to create extra IDs for each user. That doesn't apply in Mr Paice's situation. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Never cut what you can untie. -Joseph Joubert (1754-1824) */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Colin Paice Sent: Friday, July 14, 2023 07:58 At one point some of us had two userids. SYSPROG1 ... for sysprog stuff, and a personal ID. When anyone moved on they just reallocated SYSPROG1 to a new user, and all the accesses continued to work. If you use a personal ID, you had to connect it to a lot of groups to get the access, and remove the retiree from the same groups. Role based userids are much better and less work -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
You could connect them all to a dummy group with no privileges. From: IBM Mainframe Discussion List on behalf of Bob Bridges Sent: Friday, July 14, 2023 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Userid schemes I like the part about service IDs. One of the challenges at most installations I've worked at is being able to identify non-human IDs; they're easy enough to spot by eye (because of the name attached to it), but I need some sort of indicator when writing a program. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Normal people believe "if it ain't broke, don't fix it". Engineers believe that if it ain't broke, it doesn't have enough features yet. -from _The Dilbert Principal_ by Scott Adams */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jack Zukt Sent: Friday, July 14, 2023 03:30 First position for the company first letter and six digits with the employee number. For external people, "EX" and five digits for a sequence number. "Y" for service userids with up to seven letters taken from the product name (as these do not logon to TSO, eight positions could be used) Regards Jack -- 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: Userid schemes
I hope that they're not, e.g., defense, financial, health. From: IBM Mainframe Discussion List on behalf of Matt Hogstrom Sent: Friday, July 14, 2023 9:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Userid schemes I think it’s not having multiple ID inasmuch as the implied sharing. Oddly enough, I’ve run into a situation where some customers want to map multiple distributed IDs to a shared mainframe ID for a given function in an application to avoid creating hundreds of IDs for the application support personnel. I guess quantity has a quality all its own. Matt Hogstrom “It may be cognitive, but, it ain’t intuitive." — Hogstrom > On Jul 14, 2023, at 9:15 AM, David Spiegel > <0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > > Hi R'Shmuel AMV"SH, > You said: "...Auditors don't like multiple user ids..." > It's not the first time auditors have had illogical ideas. > > OTOH, 2 or more people sharing a Userid is BAD. > > Regards, > David > > On 2023-07-14 08:38, Seymour J Metz wrote: >> Auditors don't like multiple user ids, but sysprogs are usually in multiple >> roles, with different authority requirements. >> >> >> From: IBM Mainframe Discussion List on behalf of >> Colin Paice >> Sent: Friday, July 14, 2023 7:57 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Userid schemes >> >> Some of the UK banks use your D.O.B as an account number - such as >> 601225JC12 ! which exposes sensitive information. >> >> At one point some of us had two userids. SYSPROG1 ... for sysprog stuff, >> and a personal ID. >> When anyone moved on they just reallocated SYSPROG1 to a new user, and all >> the accesses continued to work. >> If you use a personal ID, you had to connect it to a lot of groups to get >> the access, and remove the retiree from the same groups. >> Role based userids are much better and less work >> >> Colin >> >> >> >> On Fri, 14 Jul 2023 at 10:39, Radoslaw Skorupka < >> 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: >> >>> W dniu 14.07.2023 o 02:32, Paul Gilmartin pisze: On Thu, 13 Jul 2023 20:17:38 -0400, Matt Hogstrom wrote: > A place I worked used initials followed by a 5 digit employee ID. >>> xxn Many years ago someone reported here that in Canada it was illegal to use an employee# as a UID because it's considered privileged HR >>> information. I'd guess the same applies to user IDs. >>> >>> I would like to know the explanation of such statement. IMHO employee# >>> is as internal as userid. >>> It is NOT SSN or other government number. >>> >>> -- >>> 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 >>> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
I like the part about service IDs. One of the challenges at most installations I've worked at is being able to identify non-human IDs; they're easy enough to spot by eye (because of the name attached to it), but I need some sort of indicator when writing a program. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Normal people believe "if it ain't broke, don't fix it". Engineers believe that if it ain't broke, it doesn't have enough features yet. -from _The Dilbert Principal_ by Scott Adams */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jack Zukt Sent: Friday, July 14, 2023 03:30 First position for the company first letter and six digits with the employee number. For external people, "EX" and five digits for a sequence number. "Y" for service userids with up to seven letters taken from the product name (as these do not logon to TSO, eight positions could be used) Regards Jack -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
I think it’s not having multiple ID inasmuch as the implied sharing. Oddly enough, I’ve run into a situation where some customers want to map multiple distributed IDs to a shared mainframe ID for a given function in an application to avoid creating hundreds of IDs for the application support personnel. I guess quantity has a quality all its own. Matt Hogstrom “It may be cognitive, but, it ain’t intuitive." — Hogstrom > On Jul 14, 2023, at 9:15 AM, David Spiegel > <0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > > Hi R'Shmuel AMV"SH, > You said: "...Auditors don't like multiple user ids..." > It's not the first time auditors have had illogical ideas. > > OTOH, 2 or more people sharing a Userid is BAD. > > Regards, > David > > On 2023-07-14 08:38, Seymour J Metz wrote: >> Auditors don't like multiple user ids, but sysprogs are usually in multiple >> roles, with different authority requirements. >> >> >> From: IBM Mainframe Discussion List on behalf of >> Colin Paice >> Sent: Friday, July 14, 2023 7:57 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Userid schemes >> >> Some of the UK banks use your D.O.B as an account number - such as >> 601225JC12 ! which exposes sensitive information. >> >> At one point some of us had two userids. SYSPROG1 ... for sysprog stuff, >> and a personal ID. >> When anyone moved on they just reallocated SYSPROG1 to a new user, and all >> the accesses continued to work. >> If you use a personal ID, you had to connect it to a lot of groups to get >> the access, and remove the retiree from the same groups. >> Role based userids are much better and less work >> >> Colin >> >> >> >> On Fri, 14 Jul 2023 at 10:39, Radoslaw Skorupka < >> 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: >> >>> W dniu 14.07.2023 o 02:32, Paul Gilmartin pisze: On Thu, 13 Jul 2023 20:17:38 -0400, Matt Hogstrom wrote: > A place I worked used initials followed by a 5 digit employee ID. >>> xxn Many years ago someone reported here that in Canada it was illegal to use an employee# as a UID because it's considered privileged HR >>> information. I'd guess the same applies to user IDs. >>> >>> I would like to know the explanation of such statement. IMHO employee# >>> is as internal as userid. >>> It is NOT SSN or other government number. >>> >>> -- >>> 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 >>> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
Hi R'Shmuel AMV"SH, You said: "...Auditors don't like multiple user ids..." It's not the first time auditors have had illogical ideas. OTOH, 2 or more people sharing a Userid is BAD. Regards, David On 2023-07-14 08:38, Seymour J Metz wrote: Auditors don't like multiple user ids, but sysprogs are usually in multiple roles, with different authority requirements. From: IBM Mainframe Discussion List on behalf of Colin Paice Sent: Friday, July 14, 2023 7:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Userid schemes Some of the UK banks use your D.O.B as an account number - such as 601225JC12 ! which exposes sensitive information. At one point some of us had two userids. SYSPROG1 ... for sysprog stuff, and a personal ID. When anyone moved on they just reallocated SYSPROG1 to a new user, and all the accesses continued to work. If you use a personal ID, you had to connect it to a lot of groups to get the access, and remove the retiree from the same groups. Role based userids are much better and less work Colin On Fri, 14 Jul 2023 at 10:39, Radoslaw Skorupka < 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: W dniu 14.07.2023 o 02:32, Paul Gilmartin pisze: On Thu, 13 Jul 2023 20:17:38 -0400, Matt Hogstrom wrote: A place I worked used initials followed by a 5 digit employee ID. xxn Many years ago someone reported here that in Canada it was illegal to use an employee# as a UID because it's considered privileged HR information. I'd guess the same applies to user IDs. I would like to know the explanation of such statement. IMHO employee# is as internal as userid. It is NOT SSN or other government number. -- 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 -- 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: Change how LE allocates storage (subpool,key)
On Fri, 14 Jul 2023 at 14:33, Binyamin Dissen wrote: > > I also want STACK storage. OK - I'm not an expert in LE interfaces. I just saw that there's a documented heap manager interface that you can supply services to. Maybe there's something similar for stacks. Maybe stacks are allocated from heap storage. I'm just suggesting that "there is no replaceable routine" seems a bit premature wihout having RTFM in detail. Tony H. > On Fri, 14 Jul 2023 13:15:10 +0200 Tony Harminc wrote: > > :>On Fri, 14 Jul 2023 at 12:57, Binyamin Dissen > :> wrote: > :>> > :>> No replaceable routine. > :>> > :>> Got it. > :> > :>I'm a bit surprised... The LE Vendor Interfaces book has all kinds of > :>talk about providing your own heap storage manager. Maybe this > :>interface isn't available in your environment, or has too many > :>restrictions or something, but it certainly exists. > :> > :>Jump in at > https://www.ibm.com/docs/en/zos/2.2.0?topic=management-vendor-heap-manager-interface > :> > :>Tony H. > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > -- > 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: Basic VM/CMS question (GENMOD)
You'll get plenty of help over in the IBMVM mailing list. When you issue the LOAD prior to the GENMOD, be sure to include the RLDSAVE option. This ensures that your program can be loaded anywhere in memory, and CMS will not overlay the current program. In fact, the first MODULE can invoke another MODULE without worrying about overlays. That code you have to read the module header isn't needed. This functionality was introduced into CMS around 1985 (VM/SP Release 4). In general, VM/370 is not a good place to develop applications that you intend to run on z/VM. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where does the IHASLMSG mapping macro live?
IHASLMSG is not distributed. It is not a programming interface. The DataAreas book contains the information for that macro, as has been mentioned. 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: Userid schemes
Auditors don't like multiple user ids, but sysprogs are usually in multiple roles, with different authority requirements. From: IBM Mainframe Discussion List on behalf of Colin Paice Sent: Friday, July 14, 2023 7:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Userid schemes Some of the UK banks use your D.O.B as an account number - such as 601225JC12 ! which exposes sensitive information. At one point some of us had two userids. SYSPROG1 ... for sysprog stuff, and a personal ID. When anyone moved on they just reallocated SYSPROG1 to a new user, and all the accesses continued to work. If you use a personal ID, you had to connect it to a lot of groups to get the access, and remove the retiree from the same groups. Role based userids are much better and less work Colin On Fri, 14 Jul 2023 at 10:39, Radoslaw Skorupka < 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > W dniu 14.07.2023 o 02:32, Paul Gilmartin pisze: > > On Thu, 13 Jul 2023 20:17:38 -0400, Matt Hogstrom wrote: > > > >> A place I worked used initials followed by a 5 digit employee ID. > xxn > >> > > Many years ago someone reported here that in Canada it was illegal to > > use an employee# as a UID because it's considered privileged HR > information. > > I'd guess the same applies to user IDs. > > > I would like to know the explanation of such statement. IMHO employee# > is as internal as userid. > It is NOT SSN or other government number. > > -- > 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 > -- 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: Change how LE allocates storage (subpool,key)
I also want STACK storage. On Fri, 14 Jul 2023 13:15:10 +0200 Tony Harminc wrote: :>On Fri, 14 Jul 2023 at 12:57, Binyamin Dissen :> wrote: :>> :>> No replaceable routine. :>> :>> Got it. :> :>I'm a bit surprised... The LE Vendor Interfaces book has all kinds of :>talk about providing your own heap storage manager. Maybe this :>interface isn't available in your environment, or has too many :>restrictions or something, but it certainly exists. :> :>Jump in at https://www.ibm.com/docs/en/zos/2.2.0?topic=management-vendor-heap-manager-interface :> :>Tony H. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Userid schemes
We still have remnants of IDs from M activities. Some of them are a 2 character department followed by 3 random digits, the other is EMP. Not sure if they used CON for contractors or some other combination of letters for non-employees. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Matt Hogstrom Sent: Thursday, July 13, 2023 7:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Userid schemes A place I worked used initials followed by a 5 digit employee ID. xxn Matt Hogstrom “It may be cognitive, but, it ain’t intuitive." — Hogstrom > On Jul 13, 2023, at 8:09 PM, David Spiegel > <0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > >> "N" was for Number and "xxx" was a numeric value starting with 1 and >> being incremented for the next userid. Since he was first in the shop, and >> he knew RACF, he set himself up as N001, I was the next person hired, >> and I got N002. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
Some of the UK banks use your D.O.B as an account number - such as 601225JC12 ! which exposes sensitive information. At one point some of us had two userids. SYSPROG1 ... for sysprog stuff, and a personal ID. When anyone moved on they just reallocated SYSPROG1 to a new user, and all the accesses continued to work. If you use a personal ID, you had to connect it to a lot of groups to get the access, and remove the retiree from the same groups. Role based userids are much better and less work Colin On Fri, 14 Jul 2023 at 10:39, Radoslaw Skorupka < 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > W dniu 14.07.2023 o 02:32, Paul Gilmartin pisze: > > On Thu, 13 Jul 2023 20:17:38 -0400, Matt Hogstrom wrote: > > > >> A place I worked used initials followed by a 5 digit employee ID. > xxn > >> > > Many years ago someone reported here that in Canada it was illegal to > > use an employee# as a UID because it's considered privileged HR > information. > > I'd guess the same applies to user IDs. > > > I would like to know the explanation of such statement. IMHO employee# > is as internal as userid. > It is NOT SSN or other government number. > > -- > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Change how LE allocates storage (subpool,key)
On Fri, 14 Jul 2023 at 12:57, Binyamin Dissen wrote: > > No replaceable routine. > > Got it. I'm a bit surprised... The LE Vendor Interfaces book has all kinds of talk about providing your own heap storage manager. Maybe this interface isn't available in your environment, or has too many restrictions or something, but it certainly exists. Jump in at https://www.ibm.com/docs/en/zos/2.2.0?topic=management-vendor-heap-manager-interface Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Change how LE allocates storage (subpool,key)
No replaceable routine. Got it. On Fri, 14 Jul 2023 01:55:39 +0200 Bernd Oppolzer wrote: :>If there is no explicit LE option to override the standard subpools :>(which are 1 and 2, AFAIK), :>then I would try to use the LE option which allows to have an alternate :>heap handler :>and use a modified version of the standard LE handler. I don't recall :>the names of the runtime options, :>but I used them in the past to have LE heap checks enables; that's an :>alternate LE heap handler :>which writes messages about allocated and not freed storage areas ... I :>used that when looking :>for memory leaks with certain C++ applications. :> :>If you don't know what I'm talking about, I can search my archives and :>maybe find the names :>of these options and some sort of presentation (IBM's or my own) on the :>topic. :> :>But: that's only for heap storage, not for stack. Why do you want to :>have the STACK allocated :>in another subpool? Normally stack allocation is not a problem; heap is :>where the problems are. :> :>Look here: http://bernd-oppolzer.de/stackheap.pdf :> :>HTH, kind regards :> :>Bernd :> :> :>Am 14.07.2023 um 00:11 schrieb Binyamin Dissen: :>> I would like to have LE use SP=132 KEY=9 for its STACK and HEAP. :>> :>> I obviously could screw with CEEINT, but I don't know if that will affect :>> other storage requests. :>> :>> Is there some explicit getmain routine that I can play with? :>> :>> -- :>> Binyamin Dissen :>> http://www.dissensoftware.com :>> :>> Director, Dissen Software, Bar & Grill - Israel :>> :>> -- :>> 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 -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
Hi Paul, EEOC is an American thing. In Canada, we have an equivalent. Please explain: "... Five digits isn't enough. ..." Enough for what? (I think you're confusing employee number with SIN (equivalent to American SSN). Regards, David On 2023-07-13 22:53, Paul Gilmartin wrote: On Thu, 13 Jul 2023 21:56:55 -0400, David Spiegel wrote: When I worked at IBM Canada full time (1994-2002), our TSO Userids were XXn, where n was a person's "man number" (aka employee number). No EEOC. Five digits isn't enough. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
W dniu 14.07.2023 o 02:32, Paul Gilmartin pisze: On Thu, 13 Jul 2023 20:17:38 -0400, Matt Hogstrom wrote: A place I worked used initials followed by a 5 digit employee ID. xxn Many years ago someone reported here that in Canada it was illegal to use an employee# as a UID because it's considered privileged HR information. I'd guess the same applies to user IDs. I would like to know the explanation of such statement. IMHO employee# is as internal as userid. It is NOT SSN or other government number. -- 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: Userid schemes
My favourite (admittedly on a sandbox) was an IMS guy with the right initials who snagged DL1. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userid schemes
First position for the company first letter and six digits with the employee number. For external people, "EX" and five digits for a sequence number. "Y" for service userids with up to seven letters taken from the product name (as these do not logon to TSO, eight positions could be used) Regards Jack On Fri, 14 Jul 2023 at 03:53, Paul Gilmartin < 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > On Thu, 13 Jul 2023 21:56:55 -0400, David Spiegel wrote: > > > >When I worked at IBM Canada full time (1994-2002), our TSO Userids were > >XXn, where n was a person's "man number" (aka employee number). > > > No EEOC. > > Five digits isn't enough. > > -- > 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: DFSORT - adding up on a field
Thank you very much Kolusu. That did the trick Best wishes Jack On Thu, 13 Jul 2023 at 17:40, Sri h Kolusu wrote: > Jack, > > If your intention is to count the number of Storage group and DASD Model, > then you can init with a counter of 1 and then sum it up. > > Here are the updated control cards. I added a new symbol TMP-STGCNTR and > initialized it with 1 using INREC and then sum that field. > > > // DD * > TMP-DCVVLCAP,*,8,BI > TMP-DCVVLCAP1,=,4,BI > TMP-DCVVLCAP2,*,4,BI > TMP-DCVALLOC,*,8,BI > TMP-DCVALLOC1,=,4,BI > TMP-DCVALLOC2,*,4,BI > TMP-STGCNTR,*,2,BI > /* > //SYSINDD * > OPTION VLSHRT,VLSCMP,DYNALLOC=(,4) > INCLUDE COND=(DCURCTYP,EQ,DCUVULUT) > * > INREC OVERLAY=(TMP-DCVVLCAP:8Z, > TMP-DCVVLCAP2:DCVVLCAP, * DASD CAPACITY > TMP-DCVALLOC:8Z, > TMP-DCVALLOC2:DCVALLOC, > TMP-STGCNTR:+1,BI,LENGTH=2) > * > SORT FIELDS=(DCVSGTCL,A,DCVVLCAP,D) * SORT BY SRGRP NAME > * > SUM FIELDS=(TMP-DCVVLCAP,* SUM DASD CAPACITY > TMP-DCVALLOC,* SUM DASD ALLOCATED SPACE > TMP-STGCNTR) * SUM DASD MODEL COUNT > * > OUTFIL FNAMES=SORT01, > BUILD=(1,4, >DCVSGTCL, >CHANGE=(30,C'',C'NON SMS'), >NOMATCH=(DCVSGTCL), >X, >SEQNUM,4,ZD,START=1,INCR=1,RESTART=(DCVSGTCL), >X, >TMP-STGCNTR,M10,LENGTH=5, >X, >DCVVLCAP, >CHANGE=(7,X'000E18B9',C'3390-01', > X'002A4A2C',C'3390-03', > X'007EDE85',C'3390-09', > X'019EEB0F',C'3390-27', > X'033DD61F',C'3390-54'), >NOMATCH=(C'NMODEL'), >X, >TMP-DCVVLCAP,EDIT=(III.III.III.IIT), >X, >TMP-DCVALLOC,EDIT=(III.III.III.IIT)) > /* > > > -- > 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: Userid schemes
When I worked at IBM it was first letter of surname plus personnel number (5 numerics). Another site used a role based ID such as SNRDBA for Senior DBA. On Fri, Jul 14, 2023 at 10:31 AM Bob Bridges wrote: > One place I worked used the employee number as proof of identify when the > help desk proposed to help him with his password. The employee ID was > printed on the photo ID we carried around. As a security jock I never > thought much of that scheme; no better than SSN, in my opinion. > > (The best scheme for that, at least that I've run into so far, is the > policy of a company I worked for a long time: Any department that had at > least 25 people in it was required to have someone there scoped to update > the passwords for folks in that department. So no need to prove my > identity through some hackable means: I just walked up to Anna's desk and > say "Anna, please fix my password". Since Anna knows me (or knows my voice > over the phone), no issue. I've been a fan of decentralized (but > monitored) security ever since.) > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* It is hard enough, even with the best will in the world, to be just. > It is hard, under the pressure of haste, uneasiness, ill-temper, > self-complacency, and conceit, even to continue intending justice. Power > corrupts; the "insolence of office" will creep in. We see it so clearly in > our superiors; is it unlikely that our inferiors see it in us? How many of > those who have been over us did not sometimes (perhaps often) need our > forgiveness? Be sure that we likewise need the forgiveness of those that > are under us. -C S Lewis, "The Psalms" */ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Matt Hogstrom > Sent: Thursday, July 13, 2023 20:18 > > A place I worked used initials followed by a 5 digit employee ID. xxn > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
