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 hand

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 wit

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 a

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 p

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 co

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

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.U

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

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 Se

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

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