Re: Python 3.11 on z/OS - UTF-8 errors
On 13/07/2023 2:00 pm, kekronbekron wrote: Andrew - could you please explain what you mean by "checkout in git as UTF8". I mean setting the zos-working-tree-encoding for the file to UTF-8. I don't actually do this but it appears to be possible. Git encodings are quite confusing. I find it frustrating that it seems to require you to tag every file added on z/OS, even if you have defined the encoding in .gitattributes. I did briefly try Maven on z/OS but I think I had the same problem as you. I quickly decided I didn't need to do that and haven't investigated any further. -- 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
Re: Python 3.11 on z/OS - UTF-8 errors
On 13/07/2023 1:59 pm, Seymour J Metz wrote: UTF-8 is just an encoding of Unicode; not a character set. All of ISO-8859-1 is part of Unicode. Yes, but the code is stored in git as UTF-8 and defined as UTF-8 when working on other platforms. You can specify the zos-working-tree-encoding is ISO-8859-1... it seems like this conversion could cause problems. Alternatively, zos-working-tree-encoding of UTF-8 presumably transfers the data without conversion, but it sounds like some programs have problems using it? Normally, I think I want IBM-1047 which has the same potential conversion issues to/from git... you just have to be careful editing on other platforms. -- 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
Re: A question about CPU usage on z/OS
A task can only use one CPU at a time, but MVS has never limited an address space to a single CPU except for the case of CPU affinity, which I have never seen used. However, many batch jobs do not exploit multitasking and thus cannot exploit multiple CPUs. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jason Cai [ibmm...@foxmail.com] Sent: Wednesday, July 12, 2023 6:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: A question about CPU usage on z/OS 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: Python 3.11 on z/OS - UTF-8 errors
Andrew - could you please explain what you mean by "checkout in git as UTF8". I can't remember which project I saw this in, but it mentioned needing to use UTF8. So, similar to what Andrew has shown below, I suspect. If all files on host are tagged ISO8859-1 then, and even if a project has build.sourceEnconding UTF8, will that be fine as long as there aren't any "special" chars? I tried following this for getting Maven to work on zOS, but it doesn't work - https://github.com/HeinekenBilly/Maven-zOS mvn -v shows gibberish. If I don't set "MAVEN_OPTS=-Dfile.encoding=UTF-8", without messing with iconv, then it works with IBM-1047, zOS-native. - KB --- Original Message --- On Thursday, July 13th, 2023 at 4:50 AM, Andrew Rowley wrote: > On 13/07/2023 9:02 am, David Crayford wrote: > > > I'd like to understand your reasons for wanting to encode your Java source > > files in UTF-8. It's important to note that the default encoding on z/OS is > > IBM-1047 (EBCDIC). We typically use ISO8859-1 and have to specify the > > "-encoding iso8859-1" option when using the javac compiler. As mentioned > > earlier, tagging files as UTF-8 can lead to unexpected issues, which is why > > it's not commonly done. > > > I commonly see > UTF-8 > > specified for Java projects. > > I have wondered how this works if you try to compile on z/OS. The > obvious but possibly wrong answer would be to checkout in git as UTF8 > and tag the files. > > If you encode as ISO8859-1, what happens to e.g. literals with > characters not in ISO8859-1? An obvious one would be the Euro character, > but I'm sure there are more. > > -- > 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: Python 3.11 on z/OS - UTF-8 errors
UTF-8 is just an encoding of Unicode; not a character set. All of ISO-8859-1 is part of Unicode. Of course, the encoding of characters between U+80 and U+FF requires two octets in UTF-8. And, yes, UTF-8 is clearly the way forward, although there may be some bumps in the road. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Andrew Rowley [and...@blackhillsoftware.com] Sent: Wednesday, July 12, 2023 9:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Python 3.11 on z/OS - UTF-8 errors On 13/07/2023 10:01 am, David Crayford wrote: > We specify > UTF-8 in > our Maven builds as most of the time we are building off host on > machines with UTF8 locales. However, we tag our files ISO8859-1 on z/OS ... > If we cared about the euro sign we could change it to ISO8859-15 which > is still an 8-bit character set. It’s those pesky codes above 0x7F in > UTF-8 that cause the issues. Euro was just an example, there are plenty of other UTF-8 characters. If you convert to an 8 bit character set, does it mean that any literals with codes above 0x7F are silently broken? Or does git fail to checkout? Either way, sourceEncoding=UTF8 seems like a good answer to why you might want to actually have the files encoded in UTF8. Anything else would seem to be courting unpredictable errors. -- 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: A question about IXGLOGR and RRS CPU usage
Jason, You may wish to download the Redbook SG24-6898-01, Systems Programmer's Guide to z/IS System Logger. Even though it has not been updated since 2012, the information may still be relevant. In particular, chapter 8 is performance and tuning. That chapter mentions the IXGRPT1 report as well as a SORT job that may be more readable. That chapter also mentions several RMF reports of interest. Allan On Wed, Jul 12, 2023 at 6:53 PM Jason Cai wrote: > Dear all, > > I have a question about IXGLOGR and RRS CPU usage that I hope you can help > me with. > > Due to a large number of transactions that update DB2 and query DB2 (query > transactions from DRDA), the IXGLOGR usage has increased significantly, and > the RRS allocate logstream offline datasets have also increased > significantly, but the RRS CPU usage is not high. Is this normal? I would > like to know how to reduce the IXGLOGR CPU usage. Any suggestions are > greatly appreciated. > > Thank you for your time and attention. I look forward to hearing from you > soon. > > Sincerely, > > 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: [EXTERNAL] A question about CPU usage on z/OS
IXGLOGR has had multiple TCBs for more than a decade now, with over 256 TCBs possible for high load scenarios. Of course each task has specific functions, so the processor speed for a single task can affect that part of the logger. You can define your logstreams to be separated between TEST and PROD in order to avoid degrading PROD work. In general z/OS has evolved to efficiently process larger sets of resources and eliminate bottlenecks ... the logger is potentially a huge bottleneck affecting all sorts of applications, and z/OS has done a great job to make it faster. On Thu, Jul 13, 2023 at 11:28 AM Pommier, Rex wrote: > Yes, typically a task runs as a single TCB, and a TCB can only be > dispatched on a single processor. I don't know if the logger spawns > subtasks that could run on additional CPUs or not. > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Jason Cai > Sent: Wednesday, July 12, 2023 5:27 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] A question about CPU usage on z/OS > > 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 > > -- > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] A question about CPU usage on z/OS
Yes, typically a task runs as a single TCB, and a TCB can only be dispatched on a single processor. I don't know if the logger spawns subtasks that could run on additional CPUs or not. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jason Cai Sent: Wednesday, July 12, 2023 5:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] A question about CPU usage on z/OS 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 -- 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: Python 3.11 on z/OS - UTF-8 errors
On 13/07/2023 10:01 am, David Crayford wrote: We specify UTF-8 in our Maven builds as most of the time we are building off host on machines with UTF8 locales. However, we tag our files ISO8859-1 on z/OS ... If we cared about the euro sign we could change it to ISO8859-15 which is still an 8-bit character set. It’s those pesky codes above 0x7F in UTF-8 that cause the issues. Euro was just an example, there are plenty of other UTF-8 characters. If you convert to an 8 bit character set, does it mean that any literals with codes above 0x7F are silently broken? Or does git fail to checkout? Either way, sourceEncoding=UTF8 seems like a good answer to why you might want to actually have the files encoded in UTF8. Anything else would seem to be courting unpredictable errors. -- 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
Re: "National" characters
The particularly perverse one was France, code page 297, with à for @ "at," reasonable enough; £ for # "pound" but the wrong kind; and $ for $ because there was no special sign for the franc (not even a ligature of Fr). When the euro was introduced, that was really the end of trying to maintain a code point meaning "national currency unit." The new code pages kept the old national characters as is, and instead replaced the *universal* currency sign ¤ with the euro sign. ¬R On Tue, 11 Jul 2023 16:50:55 +, Gibney, Dave wrote: >US/Europe centered attitude >$ Currency - Dollar ># Weight - Pound >@ per item - at -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Python 3.11 on z/OS - UTF-8 errors
> On 13 Jul 2023, at 7:20 am, Andrew Rowley > wrote: > > On 13/07/2023 9:02 am, David Crayford wrote: >> I'd like to understand your reasons for wanting to encode your Java source >> files in UTF-8. It's important to note that the default encoding on z/OS is >> IBM-1047 (EBCDIC). We typically use ISO8859-1 and have to specify the >> "-encoding iso8859-1" option when using the javac compiler. As mentioned >> earlier, tagging files as UTF-8 can lead to unexpected issues, which is why >> it's not commonly done. > > I commonly see > UTF-8 specified > for Java projects. We specify UTF-8 in our Maven builds as most of the time we are building off host on machines with UTF8 locales. However, we tag our files ISO8859-1 on z/OS other then some YAML docs that must be tagged UTF-8 or else SnakeYaml barfs when reading it from the class path which doesn’t support tags :). The server runs with file.encoding=ISO8859-1 as well. If we cared about the euro sign we could change it to ISO8859-15 which is still an 8-bit character set. It’s those pesky codes above 0x7F in UTF-8 that cause the issues. > > I have wondered how this works if you try to compile on z/OS. The obvious but > possibly wrong answer would be to checkout in git as UTF8 and tag the files. > > If you encode as ISO8859-1, what happens to e.g. literals with characters not > in ISO8859-1? An obvious one would be the Euro character, but I'm sure there > are more. > > -- > 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: Python 3.11 on z/OS - UTF-8 errors
On 13/07/2023 9:02 am, David Crayford wrote: I'd like to understand your reasons for wanting to encode your Java source files in UTF-8. It's important to note that the default encoding on z/OS is IBM-1047 (EBCDIC). We typically use ISO8859-1 and have to specify the "-encoding iso8859-1" option when using the javac compiler. As mentioned earlier, tagging files as UTF-8 can lead to unexpected issues, which is why it's not commonly done. I commonly see UTF-8 specified for Java projects. I have wondered how this works if you try to compile on z/OS. The obvious but possibly wrong answer would be to checkout in git as UTF8 and tag the files. If you encode as ISO8859-1, what happens to e.g. literals with characters not in ISO8859-1? An obvious one would be the Euro character, but I'm sure there are more. -- 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
Re: Python 3.11 on z/OS - UTF-8 errors
> On 11 Jul 2023, at 10:41 am, kekronbekron
> <02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
>
> Hi David,
>
> A quick question -
> Will the same chtag command work for, say, Java packages/projects?
Yes
> Or, would I have to use chtag -R -tc UTF-8 if a project expects to things to
> be in UTF8?
I'd like to understand your reasons for wanting to encode your Java source
files in UTF-8. It's important to note that the default encoding on z/OS is
IBM-1047 (EBCDIC). We typically use ISO8859-1 and have to specify the
"-encoding iso8859-1" option when using the javac compiler. As mentioned
earlier, tagging files as UTF-8 can lead to unexpected issues, which is why
it's not commonly done. If you examine the file attributes of modern languages
like Python, Node.js, Go, etc., you'll notice that their source files are
tagged as ISO8859-1.
A while ago, one of our ported tools developers provided me with a detailed
explanation regarding the challenges associated with UTF-8 for ported tools.
Although I don't recall all the specifics, it had something to do with double
conversions. Therefore, the general rule of thumb is to avoid using UTF-8
unless it is necessary, such as when embedding a YAML document into a Java JAR
file.
>
>
> - KB
>
> --- Original Message ---
> On Tuesday, July 11th, 2023 at 3:34 AM, David Crayford
> wrote:
>
>
>> It’s difficult to use modern tools when the systems you work on are air
>> gapped.
>>
>> I can’t recreate your problem but I used a different method. I downloaded a
>> zip file from Github, uploaded it to z/OS and followed these steps:
>>
>> jar xf psutill-master.zip
>> cd psutil-master
>> chtag -R -tc iso8859-1 .
>> python3 setup.py
>>
>>> platform zos is not supported
>>
>>
>> Like I said, it’s a heavy lift to port this package to z/OS.
>>
>>> On 9 Jul 2023, at 11:08 pm, Frank Allan Rasmussen f...@nal-net.dk wrote:
>>>
>>> Hi
>>>
>>> I'm doing this on the company sandbox so I can not make a git clone.
>>>
>>> And trying 8859-1 (cp 819) does not change anything:
>>>
>>> /home/bc6608/psutil:chtag -p setup.py
>>> t ISO8859-1 T=on setup.py
>>>
>>> PYTHONWARNINGS=all python3 setup.py build_ext -i `python3 -c "import sys,
>>> os; py36 = sys.version_info[:2] >= (3, 6); cpus = os.cpu_count() or 1 if
>>> py36 else 1; print('--parallel %s' % cpus if cpus > 1 else '')"`
>>> Traceback (most recent call last):
>>> File "/home/bc6608/psutil/setup.py", line 47, in
>>> from _common import AIX # NOQA
>>> ^^^
>>> UnicodeDecodeError: 'utf-8' codec can't decode byte 0x97 in position 2:
>>> invalid start byte
>>>
>>> I'm know that getting to run and move it back to github will be
>>> clumbersome, but if I do not try I do not learn.
>>>
>>> BR
>>> Frank Allan Rasmussen
>>>
>>> --
>>> 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
A question about IXGLOGR and RRS CPU usage
Dear all, I have a question about IXGLOGR and RRS CPU usage that I hope you can help me with. Due to a large number of transactions that update DB2 and query DB2 (query transactions from DRDA), the IXGLOGR usage has increased significantly, and the RRS allocate logstream offline datasets have also increased significantly, but the RRS CPU usage is not high. Is this normal? I would like to know how to reduce the IXGLOGR CPU usage. Any suggestions are greatly appreciated. Thank you for your time and attention. I look forward to hearing from you soon. Sincerely, Jason Cai -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
A question about CPU usage on z/OS
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
DFSMS Advanced Customization Guide
All, Can anyone give me an idea of the quantity/number of updates in the newer version of the 2023 version of this manual versus the 2013 version? Bill Hitefield -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Latches?
Latches (e.g., ISGLOBT and ISGLREL) were introduced in MVS/ESA SP4.3.0. 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: [EXT] Re: Invoke Java from Assembler
Hi Robert, IMS uses the CEEPIPI approach to make the JVM persistent, but thats actually only needed if multiple modules are serially executed and (speaking with COBOL) end with a GOBACK. The GOBACK of the first module called would terminate the LE enclave (and as such the JVM) so CEEPIPI is used to allow the next program to work the same way without tiering down the JVM. The COBOL (and C JNI) work like this, you start a program e.g. with JCL PGM=PROG1. Enterprise COBOL initializes the JVM (CreateJavaVM and AttachCurrentThread JNI calls under the covers if I remember correctly, in C and e.g. PL/I you do that by yourself and the environment for the JVM is pointed to by _CEE_ENVFILE) and with that JVM pointer you can do any number of JNI calls (e.g. call Java methods) and after each call the calling program is returned control. The JNIEnvPtr will be valid as long as the JVM or the LE enclave stay up.You can do the same thing in assembler, but you need an LE enclave with POSIX(ON) and XPLINK(ON) since the JVM on z/OS is written in C and requires those settings (in addition that up to Java 8 the 31bit version of Java needs to be used). But if the inital assembler uses CEEENTRY and CEETERM it will be quite easy to achieve, because it would create the LE enclave and remain until the initial assembler ends. From that first module you can call any non LE assembler as you like.The JVM can be ended by using JNI call DestroyJavaVM to make sure any unfinished work on the Java side is ended (as opposed to just end the first module and terminate the JVM together with the LE enclave and the address space). One question is, why would you need to make the JVM persistent with CEEPIPI in batch?You can do PROG1 call anything then return, PROG1 call Java then return as long and as many times as you want without the need of CEEPIPI and reusing the JVM - since its not terminated after return from Java. But to make it more complicated, since Java 11 for z/OS there is no 31bit JVM anymore and the JVM will be in a secondary 64bit LE enclave. There is a libjvm31.so shared library which can be used to make the JNI calls work, with the difference that most references require 64bit parameters. (Under the covers CEL4RO64 service is used)https://www.ibm.com/support/pages/enhancement-coboljni-interface For now, I think the easiest way to do it, is in COBOL. Hope that helps,Denis. On Wednesday, July 12, 2023 at 02:40:08 PM GMT+2, Crawford Robert C (Contractor) <04e08f385650-dmarc-requ...@listserv.ua.edu> wrote: Thanks, Allan. Back in the 90's I used CEEPIPI to create a persistent C enclave I could call from Assembler because building the environment is expensive. Unfortunately, CEEPIPI documentation is kind of scarce. What we do find doesn't give us very many clues for how to get to Java. Robert Crawford Abstract Evolutions LLC (210) 913-3822 -Original Message- From: IBM Mainframe Discussion List On Behalf Of allan winston Sent: Tuesday, July 11, 2023 5:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXT] Re: Invoke Java from Assembler Robert, This reminds me of a situation I ran into 25 years ago involving assembler and COBOL. Granted, COBOL and Java are different environments, but there may be enough similarity in the issues to be relevant. We had an assembler main program that called a COBOL subroutine repeatedly. It was chugging along just fine until LE maintenance showed a large spike in CPU time within LE library routines, as shown by Strobe. It seemed as though the LE environment was constantly being created and torn down. I did look into solutions, such as using CEEPIPI, but this program was a major CPU consumer in this shop and we needed a quick solution. The solution I proposed and was implemented was to create a new main program, written in COBOL, that called the former assembler main program. That way the new main program established the LE environment that persisted until the program terminated. So, ALC calling COBOL changed to COBOL calling ALC calling COBOL. In your case: Java calling COBOL changed to COBOL calling Java calling COBOL. I have never used Java, so this is somewhat a shot in the dark. I should have created an ETR on IBMLINK about the increased CPU overhead, but did not bother since we had a circumvention. Allan On Tue, Jul 11, 2023 at 5:58 PM Crawford Robert C (Contractor) < 04e08f385650-dmarc-requ...@listserv.ua.edu> wrote: > We're interested in invoking Java from assembler in batch. > Specifically, we'd like to create a persistent Java environment we can > call repeatedly and terminate when we're through. > > Has anyone done this? Is the LE pre-initialization module CEEPIPI > worth exploring? > > Thanks. > > Robert Crawford > Abstract Evolutions LLC > (210) 913-3822 > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions,
Re: OSA-ICC question
I think he was asking about the hosting company. They will always have access via the HMC. In addition, since their network will be used to access the OSA-ICC port, they will have access via that method. Joe On Wed, Jul 12, 2023 at 8:01 AM Tom Longfellow < 03e29b607131-dmarc-requ...@listserv.ua.edu> wrote: > I am confused about which 'access' is at question. > > There is access to the card and access to the lpars using the card. > Basically the wires in and out of the physical OSA-ICC card. > > ANYONE that has connectivity to the Ethernet port on the OSA is > 'accessing' the OSA. > The 'OSA Specific Utilities' under HMC control then controls what LPARS > the people who 'access' the OSA can see within your mainframe.. > The LPARS must also be told about the OSA-ICC. > > None of this will give them 'Access' to your operating systems or > applications. In other words, they will still have to authenticate and > login just like any users of the systems. > > It boils down to the trust you have in your outsourcer.They are the > fox in charge of this hen house.IF they are sharing the physical OSA > across all customers, then the OSA-ICC configuration becomes your > gatekeeper/firewall to keep everyone isolated. > > Makes me wonder what the concerns are and what 'accesses' are being > question. Also, what access? physically, to the applications and data? > etc. > > -- > 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: [EXT] Re: Invoke Java from Assembler
A few years back I ran up an assembler program that used CELQPIPI(64-bit PIPI) to do this, but the assembler program called C routines via PIPI to do the real work; the C routines contained Java JNI code. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Crawford Robert C (Contractor) Sent: Wednesday, July 12, 2023 1:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXT] Re: Invoke Java from Assembler Thanks, Allan. Back in the 90's I used CEEPIPI to create a persistent C enclave I could call from Assembler because building the environment is expensive. Unfortunately, CEEPIPI documentation is kind of scarce. What we do find doesn't give us very many clues for how to get to Java. Robert Crawford Abstract Evolutions LLC (210) 913-3822 -Original Message- From: IBM Mainframe Discussion List On Behalf Of allan winston Sent: Tuesday, July 11, 2023 5:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXT] Re: Invoke Java from Assembler Robert, This reminds me of a situation I ran into 25 years ago involving assembler and COBOL. Granted, COBOL and Java are different environments, but there may be enough similarity in the issues to be relevant. We had an assembler main program that called a COBOL subroutine repeatedly. It was chugging along just fine until LE maintenance showed a large spike in CPU time within LE library routines, as shown by Strobe. It seemed as though the LE environment was constantly being created and torn down. I did look into solutions, such as using CEEPIPI, but this program was a major CPU consumer in this shop and we needed a quick solution. The solution I proposed and was implemented was to create a new main program, written in COBOL, that called the former assembler main program. That way the new main program established the LE environment that persisted until the program terminated. So, ALC calling COBOL changed to COBOL calling ALC calling COBOL. In your case: Java calling COBOL changed to COBOL calling Java calling COBOL. I have never used Java, so this is somewhat a shot in the dark. I should have created an ETR on IBMLINK about the increased CPU overhead, but did not bother since we had a circumvention. Allan On Tue, Jul 11, 2023 at 5:58 PM Crawford Robert C (Contractor) < 04e08f385650-dmarc-requ...@listserv.ua.edu> wrote: > We're interested in invoking Java from assembler in batch. > Specifically, we'd like to create a persistent Java environment we can > call repeatedly and terminate when we're through. > > Has anyone done this? Is the LE pre-initialization module CEEPIPI > worth exploring? > > Thanks. > > Robert Crawford > Abstract Evolutions LLC > (210) 913-3822 > > > -- > 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 -- 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: Cobol question
Rex, at this link you'll find an interesting thread: https://groups.google.com/g/bit.listserv.ibm-main/c/B04G-HasOd4 As somebody (who is at least 30K light years beyond me) probably the right way is to use TIMEUSED macro. It depends on how much you need to rely the info. I recently wrote an assembler interface to do the needed using the new instructions (without too many checks to be honest). It seems the new way (ECT=YES) invocation costs very less than before. Best regards. Max Il giorno mar 11 lug 2023 alle ore 23:44 Joe Monk ha scritto: > You can always map the TCB and reference field TCBTTIME to get the > accumulated CPU time for the task - I think its offset 316 decimal. > > Joe > > On Tue, Jul 11, 2023 at 4:22 PM Pommier, Rex > wrote: > > > Hey all, > > > > I just got this tossed at me by an application developer. Cobol 6.3. Is > > there some built-in function or something that they can put into a > program > > to report out the amount of CPU (TCB) time the program has consumed thus > > far in execution of the program? We have a program that processes > > accounts, and at the beginning of every account it prints the account > > number and wall clock timestamp. The developers would like to also > report > > out how much CPU the program has consumed at the same time as the wall > > clock. I don't know of any but if somebody has an idea off the top of > > their head, I'll listen. > > > > TIA, > > > > Rex > > > > -- > > 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 > > > > -- > 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: OSA-ICC question
I am confused about which 'access' is at question. There is access to the card and access to the lpars using the card. Basically the wires in and out of the physical OSA-ICC card. ANYONE that has connectivity to the Ethernet port on the OSA is 'accessing' the OSA. The 'OSA Specific Utilities' under HMC control then controls what LPARS the people who 'access' the OSA can see within your mainframe.. The LPARS must also be told about the OSA-ICC. None of this will give them 'Access' to your operating systems or applications. In other words, they will still have to authenticate and login just like any users of the systems. It boils down to the trust you have in your outsourcer.They are the fox in charge of this hen house.IF they are sharing the physical OSA across all customers, then the OSA-ICC configuration becomes your gatekeeper/firewall to keep everyone isolated. Makes me wonder what the concerns are and what 'accesses' are being question. Also, what access? physically, to the applications and data? etc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Re: Invoke Java from Assembler
Thanks, Allan. Back in the 90's I used CEEPIPI to create a persistent C enclave I could call from Assembler because building the environment is expensive. Unfortunately, CEEPIPI documentation is kind of scarce. What we do find doesn't give us very many clues for how to get to Java. Robert Crawford Abstract Evolutions LLC (210) 913-3822 -Original Message- From: IBM Mainframe Discussion List On Behalf Of allan winston Sent: Tuesday, July 11, 2023 5:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXT] Re: Invoke Java from Assembler Robert, This reminds me of a situation I ran into 25 years ago involving assembler and COBOL. Granted, COBOL and Java are different environments, but there may be enough similarity in the issues to be relevant. We had an assembler main program that called a COBOL subroutine repeatedly. It was chugging along just fine until LE maintenance showed a large spike in CPU time within LE library routines, as shown by Strobe. It seemed as though the LE environment was constantly being created and torn down. I did look into solutions, such as using CEEPIPI, but this program was a major CPU consumer in this shop and we needed a quick solution. The solution I proposed and was implemented was to create a new main program, written in COBOL, that called the former assembler main program. That way the new main program established the LE environment that persisted until the program terminated. So, ALC calling COBOL changed to COBOL calling ALC calling COBOL. In your case: Java calling COBOL changed to COBOL calling Java calling COBOL. I have never used Java, so this is somewhat a shot in the dark. I should have created an ETR on IBMLINK about the increased CPU overhead, but did not bother since we had a circumvention. Allan On Tue, Jul 11, 2023 at 5:58 PM Crawford Robert C (Contractor) < 04e08f385650-dmarc-requ...@listserv.ua.edu> wrote: > We're interested in invoking Java from assembler in batch. > Specifically, we'd like to create a persistent Java environment we can > call repeatedly and terminate when we're through. > > Has anyone done this? Is the LE pre-initialization module CEEPIPI > worth exploring? > > Thanks. > > Robert Crawford > Abstract Evolutions LLC > (210) 913-3822 > > > -- > 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: "National" characters
If you've ever looked at an IMS FORMAT library, you'd see all manner of unprintable member names.So I'd confirm that STOW accepts anything. Cheers,Andrew Original message From: Michael Stein Date: 12/07/2023 08:46 (GMT+00:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "National" characters On Tue, Jul 11, 2023 at 02:37:04PM -0500, Paul Gilmartin wrote:> On Tue, 11 Jul 2023 18:35:14 +, Seymour J Metz wrote:> > >That's a definite maybe. You can certainly have a null in a quoted DSN, but you can't catalog it, which makes it pretty useless. > >> I bet STOW allows them. Probably BLDL, LINK, ...My old site used to name modules as: MODULE$ - new version MODULE# - current version MODUEL@ - old versionThe new module was linked in to the library as MODULE$ then to install a few renames (interactive or batch): MODULE# -> MODULE@ MODULE$ -> MODULE#and restart the effected process.backing it out was the reverse...--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: OSA-ICC question
Basically, as long you have access to the IP subnet, you have connectivity to the defined OSA-ICC. Joe On Tue, Jul 11, 2023 at 10:53 PM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > For our benefit here, could you please share what the conclusion is? > > > - KB > > --- Original Message --- > On Wednesday, July 12th, 2023 at 9:17 AM, Laurence Chiu > wrote: > > > > Thanks. I thought as much as Googled for this but this link didn't pop > up. > > That is pretty conclusive. > > > > On Wed, Jul 12, 2023 at 12:11 PM Joe Monk joemon...@gmail.com wrote: > > > > > Page 129 > > > > > > https://www.redbooks.ibm.com/redbooks/pdfs/sg245444.pdf > > > > > > Joe > > > > > > On Tue, Jul 11, 2023 at 5:12 PM Laurence Chiu lch...@gmail.com wrote: > > > > > > > We are having a LPAR being stood up on an outsourcing company's > host. It > > > > will be for our use but they will manage it via the HMC's and > possibly > > > > the > > > > OSA-ICC port. All regular access to the LPAR will be via 3270 and > using > > > > our accounts. But a question was asked, what about OSA-ICC access. My > > > > understanding is if the OSA Express cards have been defined in IOCD > and > > > > assigned to the LPAR, and a port(s) configured as OSA-ICC then the > > > > outsourcer can access it so long as they have IP connectivity to > that IP > > > > address. And Z/OS Communications Manager does not need to be started. > > > > > > > > Is that correct? This is not my area of expertise but one of my > > > > colleagues > > > > said the OSA Express cards are assigned to the hardware and not to > the > > > > LPAR > > > > which of course makes no sense to me at all. After all you can share > OSA > > > > Express cards across the LPARs on a CEC. > > > > > > > > > -- > > > > 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: "National" characters
On Tue, Jul 11, 2023 at 02:37:04PM -0500, Paul Gilmartin wrote: > On Tue, 11 Jul 2023 18:35:14 +, Seymour J Metz wrote: > > >That's a definite maybe. You can certainly have a null in a quoted DSN, but > >you can't catalog it, which makes it pretty useless. > > > I bet STOW allows them. Probably BLDL, LINK, ... My old site used to name modules as: MODULE$ - new version MODULE# - current version MODUEL@ - old version The new module was linked in to the library as MODULE$ then to install a few renames (interactive or batch): MODULE# -> MODULE@ MODULE$ -> MODULE# and restart the effected process. backing it out was the reverse... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
