Re: Question on use of LPARNAME, SYSNAME and SMFID
On 2/13/2023 7:23 PM, Al Sherkow wrote: I don’t think this happens anymore, but also long ago a machine could be significantly changed and keep the same serial number to make software licensing simpler. (For example, replacing a 3033 with a 3090). Keeping the CPUTYPE and the serial number handled that condition. If you order an MES upgrade on a supported path, you can keep your serial number when going from one CPC type to another. You cannot keep the CPC type. That is an inherent attribute of both the new machine and the older one you're replacing... -- 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: Question on use of LPARNAME, SYSNAME and SMFID
The 4-char SMFID has been around a very long time. This field is in the header of SMF records at offset=14 (SMF70SID), SMF0SID, etc.). SYSNAME and SYSPLEX were added to many SMF records with MVS/ESA 5.1.0 (as documented in MXG with change 12.034 on Feb 14, 1994). LPARNAME was added in 1988 with PRSM. I think the OS was ESA/390 on 3090 hardware. For some expert witness work I did in the early 90s I began identifying MVS images with the 4-char SMFID from offset 14, the CPUTYPE (SMF70MOD) and the serial number (SMF70SER). I don’t think this happens anymore, but also long ago a machine could be significantly changed and keep the same serial number to make software licensing simpler. (For example, replacing a 3033 with a 3090). Keeping the CPUTYPE and the serial number handled that condition. This worked well, and I implemented the same image tracking when I wrote LCS (https://www.sherkow.com/lcs/) to help sites audit SCRT in 2002. One customer eventually showed me that more information was required. They had two 4-char SMFIDs ‘ASYS’ on the same machine in different LPARs simultaneously! That totally broke my software. I called Bob Rogers at IBM to ask what was happening and what didn’t I understand. He said “they must have different 8-char SYSNAMEs, as that is how Parallel Sysplex keeps those two ‘ASYS’ separate.” Eye opening for me… I had to add SYSPLEX and SYSNAME to completely identify images. I was auditing SCRT, so I determined I needed to add LPARNAME also. A particular 4-char SMFID, SYSNAME, SYSPLEX could be in two different LPARs on a machine during the month (not simultaneously) and I needed to keep them separate. (Later recognized they needed LPARNAME to properly merge SMF70 and SMF89 and in 2007 APAR OA20314 added the LPARNAME to the SMF89 record.) Most of my licensees have 4-char SMFID=SYSNAME. I have a few customers where they are different. As others have written some sites have found interesting uses for the extra four characters in SYSNAME. Al Sherkow, I/S Management Strategies, Ltd. +1 414 332-3062 www.sherkow.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Irish data centers....an opportunity?
On 13/2/23 02:34, Hobart Spitz wrote: IMHO, the fault lies in the character stream orientation of UNIX, C, HTML etc. The shorted-sighted design was motivated by the limited budgets and underpowered systems of many early UNIX users. On record oriented systems, (z/OS and z/VM) common operations are faster, because the needed information is not embedded in the data. For example: - Read/skip-to the next record. - Find/check the length of a string. Can you please provide evidence to support that assumption? On byte stream oriented systems, every single character, including the otherwise uninteresting ones, must go through the CPU for such operations. Record oriented systems can efficiently add the record length to the current record address, or compare a target character position to the length of the record to avoid string overflow (e.g). What are you talking about? Writing a UNIX program that reads/writes length-prefixed records to a file is a simple task. Do you mean to say that all I/O performed on LUW systems involves line-delimited text files? Anyone who understands that global warming and climate change are existential threats and that it may be too late to avoid catastrophic impacts would be well advised to keep their record oriented systems and move away from UNIX, Linux, and Windows where feasible. Arm servers outperform all competition in terms of performance per watt. One can buy an Ampere server with 128 cores per socket, consuming an impressively low 250W of power. A few years ago, I came across an excellent article regarding the IBM z196, written in collaboration with IBM. The article stated that, " "Even when aggressively cooled, the ~250W z196 dissipates over 70W of leakage, which is more than the total power budget for many commodity server processors." Mainframes are designed to operate at maximum capacity with redundancy integrated into a single platform, which requires a significant amount of power. [1] https://www.realworldtech.com/z196-mainframe/8/ Just my "buck three eighty", or two cents if you prefer. OREXXMan Q: What do you call the residence of the ungulate with the largest antlers? A: A moose pad. :-D Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. REXX is the new C. On Sat, Feb 11, 2023 at 8:37 PM Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: Correct. I copied the article from the NYT & then reposted the paragraph in the article which discussed the study. Heh - I don't think those are rankings - just (former) links from the article in whatever publication Bill copied from. ... The largest cloud data centers, sometimes the size of football fields, are owned and operated by big tech companies like Google, Microsoft, Amazon and Facebook. ... Over the years, data center electricity consumption has been a story of economic incentives and technology advances combining to tackle a problem. Do they use: o IBM z? o IBM supercomputers? o Others, such as overseas-sourced (specify)? At one time Facebook published detailed specs for its homegrown PC servers, in contrast to the likes of Google, Amazon, and Microsoft, for whom it's all trade secrets. I've no idea if they've kept the specs current. Lynn Wheeler wrote about this stuff a number of times when he was active on IBM-MAIN, though mostly from an available-compute-power perspective rather than a power efficiency one. Tony H. -- 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: Question on use of LPARNAME, SYSNAME and SMFID
>I think the SMFID is older than SYSNAME. I think SYSNAME dates from the late >80s or 90s, whereas SMFID was in the early versions of MVS. System symbols are only 30 years old, but system name (via CVTSNAME) has existed since at least MVS/SP1.3 (no later than 1977). SMF ID (SMCASID) appears to predate even that. It remains the case that, of the three items in the subject, only is defined as a system symbol by z/OS. 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: Hsm for system dump volume
Yes, auto migration will suffice. Use the HSM ADDVOL command to have HSM manage a nonSMS volume. You'll define it as a PRIMARY volume. You can specify the days to keep the data sets on the volume before they are migrated with the MIGRATE(days) keyword. You should also specify the THRESHOLD command to indicate high and low thresholds. Backup only applies if you want to additionally create a backup copy of the data sets. Backup doesn't delete the data sets after the backup, so you'll essentially have 2 copies. Glenn Wilcock DFSMS Chief Product Owner -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to get MetalC "INLINE" report
I said in the pmap, i.e. the section of the listing produced by the LIST compiler option. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Andrew Rowley Sent: Friday, February 10, 2023 5:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to get MetalC "INLINE" report On 11/02/2023 7:42 am, Farley, Peter wrote: > I'd consider this to be a bug in the compiler. The listing pmap should show > all source statements, at the place where they are executed. If they are > inlined twice, they should be listed twice. That sounds like it would ultimately be confusing. An inlined piece of code might be inlined in hundreds of places. In general, my expectation of optimization is that it happens behind the scenes and doesn't change visible behavior. A huge growth in the compiler listing is probably not what people want. Also, once a piece of code is inlined, other optimizations are opened to the compiler. - The compiler might know some input parameters, so parts of the code are redundant and can be removed, loops can be unrolled etc. - Statements can be reordered - parts of the inlined code might be moved outside loops in the calling code - The compiler might even swap the order of inner/outer loops, so that part of the calling code ends up inside a loop in the inlined section of code These would be very difficult to reflect in a compiler listing (and are the reasons debugging optimized code is problematic). -- Andrew Rowley Black Hill Software -- 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: Are JNI required to be re-entrant and/or re-usable?
Yes you are correct, and the assembler program would need to be added to the program class. I had had hoped to find documentation to confirm what I've seen and maybe find a way around it, but no luck so far. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, February 13, 2023 2:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Are JNI required to be re-entrant and/or re-usable? If it's not reusable then you might as well use a LINK[X]. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Austin [steve.aus...@macro4.com] Sent: Monday, February 13, 2023 9:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Are JNI required to be re-entrant and/or re-usable? I'm pretty sure I could do that, even if it meant retaining the address using name/token services. However, the assembler program is not re-usable, so I need a fresh copy for each call. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, February 13, 2023 1:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Are JNI required to be re-entrant and/or re-usable? Does the Java runtime allow loading and stashing the address of the routine he first time you need it and serializing access to it? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Austin [steve.aus...@macro4.com] Sent: Monday, February 13, 2023 8:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Are JNI required to be re-entrant and/or re-usable? I have a Java JNI routine written in C and used as a wrapper to a venerable assembler program. The assembler program is neither re-entrant or reusable and to reflect this the JNI routine is linked RENT=NO and REUS=NO. However, the RENT=NO and REUS=NO does not appear to be being honoured, as the 1st call works and subsequent calls fail in the assembler routine. I imagine I could use LINK/LINKX to get around this, but I'd like to understand any JNI restrictions on z/OS. Thanks Steve -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Are JNI required to be re-entrant and/or re-usable?
If it's not reusable then you might as well use a LINK[X]. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Austin [steve.aus...@macro4.com] Sent: Monday, February 13, 2023 9:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Are JNI required to be re-entrant and/or re-usable? I'm pretty sure I could do that, even if it meant retaining the address using name/token services. However, the assembler program is not re-usable, so I need a fresh copy for each call. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, February 13, 2023 1:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Are JNI required to be re-entrant and/or re-usable? Does the Java runtime allow loading and stashing the address of the routine he first time you need it and serializing access to it? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Austin [steve.aus...@macro4.com] Sent: Monday, February 13, 2023 8:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Are JNI required to be re-entrant and/or re-usable? I have a Java JNI routine written in C and used as a wrapper to a venerable assembler program. The assembler program is neither re-entrant or reusable and to reflect this the JNI routine is linked RENT=NO and REUS=NO. However, the RENT=NO and REUS=NO does not appear to be being honoured, as the 1st call works and subsequent calls fail in the assembler routine. I imagine I could use LINK/LINKX to get around this, but I'd like to understand any JNI restrictions on z/OS. Thanks Steve -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- 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: Are JNI required to be re-entrant and/or re-usable?
I'm pretty sure I could do that, even if it meant retaining the address using name/token services. However, the assembler program is not re-usable, so I need a fresh copy for each call. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, February 13, 2023 1:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Are JNI required to be re-entrant and/or re-usable? Does the Java runtime allow loading and stashing the address of the routine he first time you need it and serializing access to it? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Austin [steve.aus...@macro4.com] Sent: Monday, February 13, 2023 8:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Are JNI required to be re-entrant and/or re-usable? I have a Java JNI routine written in C and used as a wrapper to a venerable assembler program. The assembler program is neither re-entrant or reusable and to reflect this the JNI routine is linked RENT=NO and REUS=NO. However, the RENT=NO and REUS=NO does not appear to be being honoured, as the 1st call works and subsequent calls fail in the assembler routine. I imagine I could use LINK/LINKX to get around this, but I'd like to understand any JNI restrictions on z/OS. Thanks Steve -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Are JNI required to be re-entrant and/or re-usable?
Does the Java runtime allow loading and stashing the address of the routine he first time you need it and serializing access to it? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Austin [steve.aus...@macro4.com] Sent: Monday, February 13, 2023 8:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Are JNI required to be re-entrant and/or re-usable? I have a Java JNI routine written in C and used as a wrapper to a venerable assembler program. The assembler program is neither re-entrant or reusable and to reflect this the JNI routine is linked RENT=NO and REUS=NO. However, the RENT=NO and REUS=NO does not appear to be being honoured, as the 1st call works and subsequent calls fail in the assembler routine. I imagine I could use LINK/LINKX to get around this, but I’d like to understand any JNI restrictions on z/OS. Thanks Steve -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- 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
Are JNI required to be re-entrant and/or re-usable?
I have a Java JNI routine written in C and used as a wrapper to a venerable assembler program. The assembler program is neither re-entrant or reusable and to reflect this the JNI routine is linked RENT=NO and REUS=NO. However, the RENT=NO and REUS=NO does not appear to be being honoured, as the 1st call works and subsequent calls fail in the assembler routine. I imagine I could use LINK/LINKX to get around this, but I’d like to understand any JNI restrictions on z/OS. Thanks Steve -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
