Re: AUTHPGM in IKJTSOxx
On Tue, 26 Nov 2019 00:20:12 +, Jesse 1 Robinson wrote: >I'm having trouble imagining a scenario where an EBCDIC representation of an >address would be useful. The problem is, in a job step situation, how would >you figure out an address to pass? > >//STEP1 EXEC PGM=my-pgm,PARM=??? > >How would I figure out what address to pass? > Rexx x2c(), for example. Enter that value with ISPF Edit hex option. Don't underestimate the determination of hackers. >If instead my-pgm is called from another program, then I would not use the JCL >parm format being discussed. In that case, I would pass the address directly >without the EBCDIC conversion game. > I believe when Walt raveled this fiber of the thread he posited assembler CALL macro or JCL PARM format (they're the same.) >-Original Message- >From: Paul Gilmartin >Sent: Monday, November 25, 2019 3:51 PM > >>Why can't the character string contain eg the eight character hex >>representation of a 4-byte address, which the program converts back to >>binary and tries to pass control to? >> >In fact, that character string could be any four octets comprising a >legitimate AMODE 31 address. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDENTIFYING 3270 GDDM USERS
On Thursday, November 21, 2019, 12:36:17 PM PST, Seymour J Metz wrote: > As ITschak Mugzach wrote, "Try get who enqueues ADMSYMBL dataset, >or any other commonly (but centrally) used dataset which is outside the >linklist > or lpalist." Just remember that there may be users of GDDM who are not using > it when you look at the ENQs. Enqueues not work for CICS and IMS users of GDDM. If usage pricing for GDDM is supported, then maybe their tool will give you this information or tell you how to extract this information. Another possibility is to look at the GDDM customization manual and diagnostics manual. Maybe there is an exit, trace or diagnostic tool to get this information. I believe that graphical terminals require a special VTAM logmode. If so, maybe you could use Omegamon VTAM to get connected terminals with those log modes. Jon. I believe that GDDM has exits. You could look at implementing one of them to keep count. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AUTHPGM in IKJTSOxx
The point is to pass an address to an authorised program so that it can call back the unauthorised program (at a different entry point in (for example) supervisor state. So you are saying you can design code which bypasses system integrity. If you had a program which took that characterised hex address and then passed control to it in supervisor state, then that is NOT a suitable program for AUTHPGM or AUTHCMD or AUTHTSF. There are many ways to design programs to subvert z/OS integrity. The more difficult and worthwhile thing to do, is achieving what you need without bypassing z/OS integrity. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: 26 November 2019 00:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] AUTHPGM in IKJTSOxx I'm having trouble imagining a scenario where an EBCDIC representation of an address would be useful. The problem is, in a job step situation, how would you figure out an address to pass? //STEP1 EXEC PGM=my-pgm,PARM=??? How would I figure out what address to pass? If instead my-pgm is called from another program, then I would not use the JCL parm format being discussed. In that case, I would pass the address directly without the EBCDIC conversion game. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Monday, November 25, 2019 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: AUTHPGM in IKJTSOxx On Mon, 25 Nov 2019 23:26:32 +, Jeremy Nicoll wrote: >On Mon, 18 Nov 2019, at 19:35, Seymour J Metz wrote: >> A program designed to run as a jobstep expects a parameter list whose >> first word points to a halfword length field followed by a character >> string of that length. The Initiator will always flag the first word >> with an end-of-list bit. So if the program follows normal rules, you >> can't pass it an address that way. > >Why can't the character string contain eg the eight character hex >representation of a 4-byte address, which the program converts back to >binary and tries to pass control to? > In fact, that character string could be any four octets comprising a legitimate AMODE 31 address. -- 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: IARST64 OWNER SECONDARY ?
On Monday, November 25, 2019, 05:13:35 AM PST, Joseph Reichman wrote: > Where in 31 bit mode you are able to get 31 bit ( private ) storage in a > other address space > via the ALET parameter on the STORAGE macro this is > not true for 64 bit storage OWNER= is only valid with COMMON=YES (not private). There does not seem to be an IARST64 parm to specify a foreign address space. IARV64 seems to give you some flexibility by allowing you HOME and PRIMARY which seems suitable for PC routines. You need to explain what you are trying to do. Are you running in a PC routine? Are you trying to share memory with specific address spaces? Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AUTHPGM in IKJTSOxx
I'm having trouble imagining a scenario where an EBCDIC representation of an address would be useful. The problem is, in a job step situation, how would you figure out an address to pass? //STEP1 EXEC PGM=my-pgm,PARM=??? How would I figure out what address to pass? If instead my-pgm is called from another program, then I would not use the JCL parm format being discussed. In that case, I would pass the address directly without the EBCDIC conversion game. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Monday, November 25, 2019 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: AUTHPGM in IKJTSOxx On Mon, 25 Nov 2019 23:26:32 +, Jeremy Nicoll wrote: >On Mon, 18 Nov 2019, at 19:35, Seymour J Metz wrote: >> A program designed to run as a jobstep expects a parameter list whose >> first word points to a halfword length field followed by a character >> string of that length. The Initiator will always flag the first word >> with an end-of-list bit. So if the program follows normal rules, you >> can't pass it an address that way. > >Why can't the character string contain eg the eight character hex >representation of a 4-byte address, which the program converts back to >binary and tries to pass control to? > In fact, that character string could be any four octets comprising a legitimate AMODE 31 address. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AUTHPGM in IKJTSOxx
On Mon, 25 Nov 2019 23:26:32 +, Jeremy Nicoll wrote: >On Mon, 18 Nov 2019, at 19:35, Seymour J Metz wrote: >> A program designed to run as a jobstep expects a parameter list whose >> first word points to a halfword length field followed by a character >> string of that length. The Initiator will always flag the first word >> with an end-of-list bit. So if the program follows normal rules, you >> can't pass it an address that way. > >Why can't the character string contain eg the eight character hex >representation of a 4-byte address, which the program converts back >to binary and tries to pass control to? > In fact, that character string could be any four octets comprising a legitimate AMODE 31 address. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AUTHPGM in IKJTSOxx
On Mon, 18 Nov 2019, at 19:35, Seymour J Metz wrote: > A program designed to run as a jobstep expects a parameter list whose > first word points to a halfword length field followed by a character > string of that length. The Initiator will always flag the first word > with an end-of-list bit. So if the program follows normal rules, you > can't pass it an address that way. Why can't the character string contain eg the eight character hex representation of a 4-byte address, which the program converts back to binary and tries to pass control to? -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Great I will look On Mon, Nov 25, 2019 at 5:38 PM Jon Perryman wrote: > > > On Monday, November 18, 2019, 05:56:09 AM PST, scott Ford < > idfli...@gmail.com> wrote: > > > My chief complaint is samples. > > I spend a lot of time digging for examples. > > > Working examples which I can refer to and understand > > > (prototype) before I start writing code. > > CBTTAPE.ORG has tons of real world code. There is probably a variation on > your request there but you will need to think creatively to find it. Since > you wanted an exit that issues a WTO then look at IEFACTRT. This > implementation will not work in every exit. > > Samples need to be generic with very little risk. A sample WTO in an exit > could easily be misconstrued or unfit for your intended use. > > > When to use the execute form of the macro vs list, > > MF= is common and rarely deviates from the accepted standard. MF=(E,label) > creates the executable code and belongs in your code where you want to > execute the functionality. Think of it as the instruction. > > MF=L is the problem. Think of this as a DC instruction to reserve storage. > Using MF=L in your CSECT makes your program non-reentrant. Using MF=L in > your workarea DSECT makes your program reentrant but loses the constant > initializer (initializes with X'00'). To be reentrant, it must occur in > your CSECT and workarea DSECT. You must copy from the CSECT to the workarea > DSECT and make sure the alignment is correct. You must also ensure the > pointers are correct. Some programs skip the copy from CSECT to DSECT but > they are at risk. > > Jon. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IARST64 OWNER SECONDARY ?
On Monday, November 25, 2019, 05:13:35 AM PST, Joseph Reichman wrote: > Where in 31 bit mode you are able to get 31 bit ( private ) storage in a > other address space via the ALET parameter on the STORAGE macro this is not > true for 64 bit storage -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
On Monday, November 18, 2019, 05:56:09 AM PST, scott Ford wrote: > My chief complaint is samples. > I spend a lot of time digging for examples. > Working examples which I can refer to and understand > (prototype) before I start writing code. CBTTAPE.ORG has tons of real world code. There is probably a variation on your request there but you will need to think creatively to find it. Since you wanted an exit that issues a WTO then look at IEFACTRT. This implementation will not work in every exit. Samples need to be generic with very little risk. A sample WTO in an exit could easily be misconstrued or unfit for your intended use. > When to use the execute form of the macro vs list, MF= is common and rarely deviates from the accepted standard. MF=(E,label) creates the executable code and belongs in your code where you want to execute the functionality. Think of it as the instruction. MF=L is the problem. Think of this as a DC instruction to reserve storage. Using MF=L in your CSECT makes your program non-reentrant. Using MF=L in your workarea DSECT makes your program reentrant but loses the constant initializer (initializes with X'00'). To be reentrant, it must occur in your CSECT and workarea DSECT. You must copy from the CSECT to the workarea DSECT and make sure the alignment is correct. You must also ensure the pointers are correct. Some programs skip the copy from CSECT to DSECT but they are at risk. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Charles, Yes we do, IBM , provided us an entry in the ECVT ... Scott On Mon, Nov 25, 2019 at 4:33 PM Charles Mills wrote: > Do you have an anchor, a place you could store one 32-bit word? If so, a > lower overhead than GETMAIN is a cell pool. It takes a little work to set > it up initially, but after that you can get 'n' bytes of reentrant storage > very quickly. > > Write me off-line (if you wish) Scott if you want more details. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of scott Ford > Sent: Monday, November 25, 2019 7:46 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WTO > > David, > > It’s the way CA calls the exit. There is a workarea dsect and notes from > CA peppered through the exit and doc saying there is a 100 byte limitation. > > Scott > > On Mon, Nov 25, 2019 at 4:20 AM David Crayford > wrote: > > > That's interesting! You said the exit was re-entrant so how is it > > obtaining the working storage. If it's doing a GETMAIN why don't you > > just increase the size > > of the storage. Why do you have a constraint of 100 bytes? > > > > On 2019-11-25 1:11 AM, scott Ford wrote: > > > David, > > > > > > True, sorry misread his reply. David my issue is I have limited storage > > for > > > variables, 100 bytes , like being back writing BAL on a 360/20. I > haven’t > > > had this experience on a piece of re-entrant code with this limitation. > > > This was one of the main reasons I asked the question of my colleagues > > here > > > on the Listserv. > > > > > > The exit is Top-secrets exit. > > > > > > Scott > > > > > > On Sun, Nov 24, 2019 at 7:07 AM David Crayford > > wrote: > > > > > >> On 2019-11-23 7:07 AM, scott Ford wrote: > > >>> Henri, > > >>> > > >>> That’s what ended up doing , thank you, I appreciate any help. > > >> Maybe a bit of a misunderstanding here. I think what Henri was > > >> suggesting was using a UNIX shell that pipes messages to /dev/console > > >> which writes WTOs using the syslogd daemon. > > >> > > >> echo "hello" > /dev/console > > >> > > >> I think your problem was related to writing assembler code with WTO > > macros? > > >> > > >> > > >>> Scott > > >>> > > >>> On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper < > henrikui...@zdevops.com> > > >>> wrote: > > >>> > > Maybe a bit late. But a plain WTO via an echo to /dev/console not an > > option? > > > > Sent from my wireless iPhone > > > > > On 19 Nov 2019, at 18:52, scott Ford wrote: > > > > > > Bruce, Peter, all: > > > > > > A big thanks . its much appreciated by this older t-rex. > > > > > > Scott > > > > > >> On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < > > >> bruce_hew...@hotmail.com> > > >> wrote: > > >> > > >> Hello Scott, > > >> > > >> How I do it. > > >> > > >> in CSECT copy list form from CONSTANTs section to DSECT working > > >> section > > >> Update message text > > >> run WTO execute form > > >> > > >> in DSECT > > >> WTO list form map > > >> > > >> in Constants > > >> WTO_text WTO list form with text > > >> WTO_length = * - WTO_text > > >> > > >> DESCT maps onto your own STORAGE area, thus copying the constant > > LIST > > form > > >> over the DSECT map makes the code reentrant. > > >> > > >> > > >> > > >> > > >> > > >>> On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford < > idfli...@gmail.com > > > > > wrote: > > >>> Peter, > > >>> > > >> > > >>> I have to add displays ( WTOs ). I dont have complaints again > IBM, > > rarely, > > >>> best people I ever worked with, my issue is howtos. Working > > examples > > which > > >>> I can refer to and understand > > >>> (prototype) before I start writing code. When to use the execute > > form > > of > > >>> the macro vs list, also let me add I was never an applications > > program, i > > >> > > >> > > >> > > >> Regards > > >> Bruce > > >> > > >> > > -- > > >> For IBM-MAIN subscribe / signoff / archive access instructions, > > >> send email to lists...@listserv.ua.edu with the message: INFO > > >> IBM-MAIN > > > -- > > > > > > > > > > > > *IDMWORKS * > > > > > > Scott Ford > > > > > > z/OS Dev. > > > > > > > > > > > > > > > “By elevating a friend or Collegue you elevate yourself, by > > demeaning a > > > friend or collegue you demean yourself” > > > > > > > > > > > > www.idmworks.com > > > > > > scott.f...@idmworks.com > > > > > > Blog: www.idmworks.com/blog > > > > > > > > > > > > > > > > > > *The information contained in this email message and any attachment > > may > > be > > > privileged, confidential, proprietary or otherwise
Re: WTO
Do you have an anchor, a place you could store one 32-bit word? If so, a lower overhead than GETMAIN is a cell pool. It takes a little work to set it up initially, but after that you can get 'n' bytes of reentrant storage very quickly. Write me off-line (if you wish) Scott if you want more details. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of scott Ford Sent: Monday, November 25, 2019 7:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO David, It’s the way CA calls the exit. There is a workarea dsect and notes from CA peppered through the exit and doc saying there is a 100 byte limitation. Scott On Mon, Nov 25, 2019 at 4:20 AM David Crayford wrote: > That's interesting! You said the exit was re-entrant so how is it > obtaining the working storage. If it's doing a GETMAIN why don't you > just increase the size > of the storage. Why do you have a constraint of 100 bytes? > > On 2019-11-25 1:11 AM, scott Ford wrote: > > David, > > > > True, sorry misread his reply. David my issue is I have limited storage > for > > variables, 100 bytes , like being back writing BAL on a 360/20. I haven’t > > had this experience on a piece of re-entrant code with this limitation. > > This was one of the main reasons I asked the question of my colleagues > here > > on the Listserv. > > > > The exit is Top-secrets exit. > > > > Scott > > > > On Sun, Nov 24, 2019 at 7:07 AM David Crayford > wrote: > > > >> On 2019-11-23 7:07 AM, scott Ford wrote: > >>> Henri, > >>> > >>> That’s what ended up doing , thank you, I appreciate any help. > >> Maybe a bit of a misunderstanding here. I think what Henri was > >> suggesting was using a UNIX shell that pipes messages to /dev/console > >> which writes WTOs using the syslogd daemon. > >> > >> echo "hello" > /dev/console > >> > >> I think your problem was related to writing assembler code with WTO > macros? > >> > >> > >>> Scott > >>> > >>> On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper > >>> wrote: > >>> > Maybe a bit late. But a plain WTO via an echo to /dev/console not an > option? > > Sent from my wireless iPhone > > > On 19 Nov 2019, at 18:52, scott Ford wrote: > > > > Bruce, Peter, all: > > > > A big thanks . its much appreciated by this older t-rex. > > > > Scott > > > >> On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < > >> bruce_hew...@hotmail.com> > >> wrote: > >> > >> Hello Scott, > >> > >> How I do it. > >> > >> in CSECT copy list form from CONSTANTs section to DSECT working > >> section > >> Update message text > >> run WTO execute form > >> > >> in DSECT > >> WTO list form map > >> > >> in Constants > >> WTO_text WTO list form with text > >> WTO_length = * - WTO_text > >> > >> DESCT maps onto your own STORAGE area, thus copying the constant > LIST > form > >> over the DSECT map makes the code reentrant. > >> > >> > >> > >> > >> > >>> On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford > > wrote: > >>> Peter, > >>> > >> > >>> I have to add displays ( WTOs ). I dont have complaints again IBM, > rarely, > >>> best people I ever worked with, my issue is howtos. Working > examples > which > >>> I can refer to and understand > >>> (prototype) before I start writing code. When to use the execute > form > of > >>> the macro vs list, also let me add I was never an applications > program, i > >> > >> > >> > >> Regards > >> Bruce > >> > >> > -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO > >> IBM-MAIN > > -- > > > > > > > > *IDMWORKS * > > > > Scott Ford > > > > z/OS Dev. > > > > > > > > > > “By elevating a friend or Collegue you elevate yourself, by > demeaning a > > friend or collegue you demean yourself” > > > > > > > > www.idmworks.com > > > > scott.f...@idmworks.com > > > > Blog: www.idmworks.com/blog > > > > > > > > > > > > *The information contained in this email message and any attachment > may > be > > privileged, confidential, proprietary or otherwise protected from > > disclosure. If the reader of this message is not the intended > >> recipient, > > you are hereby notified that any dissemination, distribution, copying > >> or > > use of this message and any attachment is strictly prohibited. If you > have > > received this message in error, please notify us immediately by > >> replying > to > > the message and permanently delete it from your computer and destroy > >> any > > printout thereof.* > > > > >
Re: WTO
The OP wants to issue a WTO for diagnostic purposes. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Monday, November 25, 2019 1:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO I suspect it is the TSS Installation exit. It gets called a lot, has a 100 byte work area, and I suspect you probably don’t want to be doing getmains, etc or anything else that will cause performance issues. It does execute in KEY 0, supervisor state. Although, I don’t know what WTO's have to do with this exit. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of scott Ford Sent: Monday, November 25, 2019 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Jon, Absolutely agree, this is the first time I have seen this but not surprising. Scott On Mon, Nov 25, 2019 at 12:52 PM Jon Perryman wrote: > > >> On Monday, November 25, 2019, 01:19:47 AM PST, David Crayford < > dcrayf...@gmail.com> wrote: > > > That's interesting! You said the exit was re-entrant so how is it > > > obtaining the working storage. If it's doing a GETMAIN why don't you > > just increase the size > > > of the storage. Why do you have a constraint of 100 bytes? > > > Some high volume exits are provided with a pre-allocated work area to > avoid a storage obtain in the exit when possible. This does not > prevent you from allocating more storage if needed. If you allocate > more storage, be sure to consider the impact (e.g. cpu or linkage=), > > Jon. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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 - UUID Approach for Mainframes in Japan
UUID letters as generated are all lower case, so you could translate them to
upper case without losing any information.
Anything that accepts UUIDs must be prepared to accept upper case, so you would
be good to go.
-- https://tools.ietf.org/html/rfc4122#section-3
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cameron Conacher
Sent: Monday, November 25, 2019 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question - UUID Approach for Mainframes in Japan
Hello folks,
I am here with another question today.
We are a large international company with a market presence in Japan.
We store our mainframe EBCDIC data for these markets in EBCDIC CodePage 930.
This CodePage has no support for lower case English letters.
If I were a distributed platform and I generated a UTF-8 encoded UUID
value, and sent this value to the mainframe, it would be then transformed
into EBCDIC CodePage 930.
If the UUID were to be generated with any lower case English values ("a",
"b", "c", "d", "e", or "f") I would expect to encounter some issue at
conversion/transformation time, since the underlying EBCDIC CodePage cannot
support the value.
However, if upper case values were sent instead ("A", "B", "C", "D", "E",
or "F"), everything would flow and transform politely.
So, my question is whether in the Japan world, mainframe application expect
Consumers to send only upper cased values, or if an intermediate step prior
to message transformation occurs close to the mainframe side of things to
force upper casing of the UUID.
Or some other technique?
Similarly, if a UUID were to be sent from the mainframe to the middle tier
somewhere, should I expect that the mainframe would only pas along upper
cased values in the UUID area?
I believe I can handle things on the mainframe side by transforming the
entire message to UTF-16BE, and then upper casing the UUID, and then
transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
Not sure if this is a "good" way, but it would work.
Any thoughts?
Thanks
...Cameron
--
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 - UUID Approach for Mainframes in Japan
Hello Cameron!
I see all lowercase letters on
http://demo.icu-project.org/icu-bin/convexp?conv=ibm-930.
Why do you say there is no support?
Regards,
Leo
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cameron Conacher
Sent: Monday, November 25, 2019 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question - UUID Approach for Mainframes in Japan
Hello folks,
I am here with another question today.
We are a large international company with a market presence in Japan.
We store our mainframe EBCDIC data for these markets in EBCDIC CodePage 930.
This CodePage has no support for lower case English letters.
If I were a distributed platform and I generated a UTF-8 encoded UUID
value, and sent this value to the mainframe, it would be then transformed
into EBCDIC CodePage 930.
If the UUID were to be generated with any lower case English values ("a",
"b", "c", "d", "e", or "f") I would expect to encounter some issue at
conversion/transformation time, since the underlying EBCDIC CodePage cannot
support the value.
However, if upper case values were sent instead ("A", "B", "C", "D", "E",
or "F"), everything would flow and transform politely.
So, my question is whether in the Japan world, mainframe application expect
Consumers to send only upper cased values, or if an intermediate step prior
to message transformation occurs close to the mainframe side of things to
force upper casing of the UUID.
Or some other technique?
Similarly, if a UUID were to be sent from the mainframe to the middle tier
somewhere, should I expect that the mainframe would only pas along upper
cased values in the UUID area?
I believe I can handle things on the mainframe side by transforming the
entire message to UTF-16BE, and then upper casing the UUID, and then
transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
Not sure if this is a "good" way, but it would work.
Any thoughts?
Thanks
...Cameron
--
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
Question - UUID Approach for Mainframes in Japan
Hello folks,
I am here with another question today.
We are a large international company with a market presence in Japan.
We store our mainframe EBCDIC data for these markets in EBCDIC CodePage 930.
This CodePage has no support for lower case English letters.
If I were a distributed platform and I generated a UTF-8 encoded UUID
value, and sent this value to the mainframe, it would be then transformed
into EBCDIC CodePage 930.
If the UUID were to be generated with any lower case English values ("a",
"b", "c", "d", "e", or "f") I would expect to encounter some issue at
conversion/transformation time, since the underlying EBCDIC CodePage cannot
support the value.
However, if upper case values were sent instead ("A", "B", "C", "D", "E",
or "F"), everything would flow and transform politely.
So, my question is whether in the Japan world, mainframe application expect
Consumers to send only upper cased values, or if an intermediate step prior
to message transformation occurs close to the mainframe side of things to
force upper casing of the UUID.
Or some other technique?
Similarly, if a UUID were to be sent from the mainframe to the middle tier
somewhere, should I expect that the mainframe would only pas along upper
cased values in the UUID area?
I believe I can handle things on the mainframe side by transforming the
entire message to UTF-16BE, and then upper casing the UUID, and then
transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
Not sure if this is a "good" way, but it would work.
Any thoughts?
Thanks
...Cameron
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
WTO has a lot more overhead than one GETMAIN; if it's legitimate to issue the WTO in the exit, then it's legitimate to issue the GETMAIN or STORAGE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> Sent: Monday, November 25, 2019 1:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO I suspect it is the TSS Installation exit. It gets called a lot, has a 100 byte work area, and I suspect you probably don’t want to be doing getmains, etc or anything else that will cause performance issues. It does execute in KEY 0, supervisor state. Although, I don’t know what WTO's have to do with this exit. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of scott Ford Sent: Monday, November 25, 2019 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Jon, Absolutely agree, this is the first time I have seen this but not surprising. Scott On Mon, Nov 25, 2019 at 12:52 PM Jon Perryman wrote: > > >> On Monday, November 25, 2019, 01:19:47 AM PST, David Crayford < > dcrayf...@gmail.com> wrote: > > > That's interesting! You said the exit was re-entrant so how is it > > > obtaining the working storage. If it's doing a GETMAIN why don't you > > just increase the size > > > of the storage. Why do you have a constraint of 100 bytes? > > > Some high volume exits are provided with a pre-allocated work area to > avoid a storage obtain in the exit when possible. This does not > prevent you from allocating more storage if needed. If you allocate > more storage, be sure to consider the impact (e.g. cpu or linkage=), > > Jon. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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: WTO
I suspect it is the TSS Installation exit. It gets called a lot, has a 100 byte work area, and I suspect you probably don’t want to be doing getmains, etc or anything else that will cause performance issues. It does execute in KEY 0, supervisor state. Although, I don’t know what WTO's have to do with this exit. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of scott Ford Sent: Monday, November 25, 2019 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Jon, Absolutely agree, this is the first time I have seen this but not surprising. Scott On Mon, Nov 25, 2019 at 12:52 PM Jon Perryman wrote: > > >> On Monday, November 25, 2019, 01:19:47 AM PST, David Crayford < > dcrayf...@gmail.com> wrote: > > > That's interesting! You said the exit was re-entrant so how is it > > > obtaining the working storage. If it's doing a GETMAIN why don't you > > just increase the size > > > of the storage. Why do you have a constraint of 100 bytes? > > > Some high volume exits are provided with a pre-allocated work area to > avoid a storage obtain in the exit when possible. This does not > prevent you from allocating more storage if needed. If you allocate > more storage, be sure to consider the impact (e.g. cpu or linkage=), > > Jon. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Jon, Absolutely agree, this is the first time I have seen this but not surprising. Scott On Mon, Nov 25, 2019 at 12:52 PM Jon Perryman wrote: > > >> On Monday, November 25, 2019, 01:19:47 AM PST, David Crayford < > dcrayf...@gmail.com> wrote: > > > That's interesting! You said the exit was re-entrant so how is it > > > obtaining the working storage. If it's doing a GETMAIN why don't you > > just increase the size > > > of the storage. Why do you have a constraint of 100 bytes? > > > Some high volume exits are provided with a pre-allocated work area to > avoid a storage obtain in the exit when possible. This does not prevent you > from allocating more storage if needed. If you allocate more storage, be > sure to consider the impact (e.g. cpu or linkage=), > > Jon. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.3 installation
The Devil is in the details. The more information you include, the more likely someone is to spot the problem. This could be something wrong in your USS definition, your logmode definition, your TCP/IP definition or the logon command you used, none of which you provided. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of saurabh khandelwal Sent: Monday, November 25, 2019 12:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.3 installation Dear Group, We are in processing of z/OS 2.3 installation and during our first IPL, as soon as we login to TSO using APPLID, system throwing us back and session terminated message i am getting on TN3270 screen. I dont see any other message on z/OS console. Can anybody faced this issue before . -- Thanks & Regards Saurabh Khandelwal -- 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: Zosmf error with IZUSRV1
ObNit That's domin name, not DNS name. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mike Wawiorko <014ab5cdfb21-dmarc-requ...@listserv.ua.edu> Sent: Monday, November 25, 2019 5:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zosmf error with IZUSRV1 is it possible to have an IP address to use ? Pretty unlikely if you are talking about the web interface to zOSMF and trying to access it from a browser. Modern browsers understandably impose security rules to protect us all. You'll need: · A server certificate · It must be signed by a CA trusted in your network · You must use a DNS name in the browser (not an IP address) · That DNS name MUST be included in the server certificate list of subject alternate names Anything less than this and most browsers will warn that the site is not to be trusted and may even completely deny access to it. Mike Wawiorko This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Execution Services Limited provides support and administrative services across Barclays group. Barclays Execution Services Limited is an appointed representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Clydesdale Financial Services Limited is authorised and regulated by the Financial Conduct Authority. -- 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: WTO
> On Monday, November 25, 2019, 01:19:47 AM PST, David Crayford wrote: > That's interesting! You said the exit was re-entrant so how is it > obtaining the working storage. If it's doing a GETMAIN why don't you > just increase the size > of the storage. Why do you have a constraint of 100 bytes? Some high volume exits are provided with a pre-allocated work area to avoid a storage obtain in the exit when possible. This does not prevent you from allocating more storage if needed. If you allocate more storage, be sure to consider the impact (e.g. cpu or linkage=), Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.3 installation
Are you on a z14? If so, does your LPAR have at least 8G assigned? z/OS 2.3 will complain otherwise (but not sure if it will prevent login). On Sun, Nov 24, 2019 at 11:37 PM saurabh khandelwal < sourabhkhandelwal...@gmail.com> wrote: > Dear Group, > > We are in processing of z/OS 2.3 installation and during our first IPL, as > soon as we login to TSO using APPLID, system throwing us back and session > terminated message i am getting on TN3270 screen. I dont see any other > message on z/OS console. > > Can anybody faced this issue before . > > > > > > -- > Thanks & Regards > Saurabh Khandelwal > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zosmf error with IZUSRV1
Look up that error in Google and you’ll see some workarounds for this. Make sure you have the latest PTFs on top as there was a PTF to fix the duplicate entries in one of the files. You also need to make sure the proper ID/Group owns the files. On Mon, Nov 25, 2019 at 5:25 AM Peter wrote: > There is only error message under STDERR i see > > CWWKS4108E: The system cannot create the LTPA key. > > > > On Mon, 25 Nov, 2019, 3:10 PM Mike Wawiorko, < > 014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote: > > > D TCPIP,stack_name,N,CON,CLI=IZU* > > stack_name may be null if you've only one IP stack. > > > > Do you see it listening? > > > > If not, look again at your configuration and messages from IZUSRV1. > > Some messages may be in Unix log files rather than JES output or syslog. > > I'm not sure about this. > > > > Mike Wawiorko > > > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of Peter > > Sent: 25 November 2019 11:01 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Zosmf error with IZUSRV1 > > > > > > This message originated from outside our organisation and is from web > > based email - dbajava...@gmail.com > > > > I was able the fix this will the TCPIP host file but still not seeing > > IZUSRV1 listening on the port coded in IZUPRMXX parmlib member. > > > > > > > > On Mon, 25 Nov, 2019, 2:57 PM Mike Wawiorko, < > > 014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote: > > > > > is it possible to have an IP address to use ? > > > > > > > > > > > > Pretty unlikely if you are talking about the web interface to zOSMF > > > and trying to access it from a browser. > > > > > > > > > > > > Modern browsers understandably impose security rules to protect us all. > > > You'll need: > > > > > > > > > > > > · A server certificate > > > > > > · It must be signed by a CA trusted in your network > > > > > > · You must use a DNS name in the browser (not an IP address) > > > > > > · That DNS name MUST be included in the server certificate list > > of > > > subject alternate names > > > > > > > > > > > > Anything less than this and most browsers will warn that the site is > > > not to be trusted and may even completely deny access to it. > > > > > > > > > > > > Mike Wawiorko > > > > > > > > > > > > This e-mail and any attachments are confidential and intended solely > > > for the addressee and may also be privileged or exempt from disclosure > > > under applicable law. If you are not the addressee, or have received > > > this e-mail in error, please notify the sender immediately, delete it > > > from your system and do not copy, disclose or otherwise act upon any > > > part of this e-mail or its attachments. > > > Internet communications are not guaranteed to be secure or virus-free. > > > The Barclays Group does not accept responsibility for any loss arising > > > from unauthorised access to, or interference with, any Internet > > > communications by any third party, or from the transmission of any > > > viruses. Replies to this e-mail may be monitored by the Barclays Group > > > for operational or business reasons. > > > Any opinion or other information in this e-mail or its attachments > > > that does not relate to the business of the Barclays Group is personal > > > to the sender and is not given or endorsed by the Barclays Group. > > > Barclays Execution Services Limited provides support and > > > administrative services across Barclays group. Barclays Execution > > > Services Limited is an appointed representative of Barclays Bank UK > > > plc, Barclays Bank plc and Clydesdale Financial Services Limited. > > > Barclays Bank UK plc and Barclays Bank plc are authorised by the > > > Prudential Regulation Authority and regulated by the Financial Conduct > > > Authority and the Prudential Regulation Authority. Clydesdale > > > Financial Services Limited is authorised and regulated by the Financial > > Conduct Authority. > > > > > > -- > > > 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 and any attachments are confidential and intended solely for > > the addressee and may also be privileged or exempt from disclosure under > > applicable law. If you are not the addressee, or have received this > e-mail > > in error, please notify the sender immediately, delete it from your > system > > and do not copy, disclose or otherwise act upon any part of this e-mail > or > > its attachments. > > Internet communications are not guaranteed to be secure or virus-free. > The > > Barclays Group does not accept responsibility for any loss arising from >
Re: WTO
I would like to see the exit doco! On 2019-11-25 8:46 PM, scott Ford wrote: David, It’s the way CA calls the exit. There is a workarea dsect and notes from CA peppered through the exit and doc saying there is a 100 byte limitation. Scott On Mon, Nov 25, 2019 at 4:20 AM David Crayford wrote: That's interesting! You said the exit was re-entrant so how is it obtaining the working storage. If it's doing a GETMAIN why don't you just increase the size of the storage. Why do you have a constraint of 100 bytes? On 2019-11-25 1:11 AM, scott Ford wrote: David, True, sorry misread his reply. David my issue is I have limited storage for variables, 100 bytes , like being back writing BAL on a 360/20. I haven’t had this experience on a piece of re-entrant code with this limitation. This was one of the main reasons I asked the question of my colleagues here on the Listserv. The exit is Top-secrets exit. Scott On Sun, Nov 24, 2019 at 7:07 AM David Crayford wrote: On 2019-11-23 7:07 AM, scott Ford wrote: Henri, That’s what ended up doing , thank you, I appreciate any help. Maybe a bit of a misunderstanding here. I think what Henri was suggesting was using a UNIX shell that pipes messages to /dev/console which writes WTOs using the syslogd daemon. echo "hello" > /dev/console I think your problem was related to writing assembler code with WTO macros? Scott On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper wrote: Maybe a bit late. But a plain WTO via an echo to /dev/console not an option? Sent from my wireless iPhone On 19 Nov 2019, at 18:52, scott Ford wrote: Bruce, Peter, all: A big thanks . its much appreciated by this older t-rex. Scott On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < bruce_hew...@hotmail.com> wrote: Hello Scott, How I do it. in CSECT copy list form from CONSTANTs section to DSECT working section Update message text run WTO execute form in DSECT WTO list form map in Constants WTO_text WTO list form with text WTO_length = * - WTO_text DESCT maps onto your own STORAGE area, thus copying the constant LIST form over the DSECT map makes the code reentrant. On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford wrote: Peter, I have to add displays ( WTOs ). I dont have complaints again IBM, rarely, best people I ever worked with, my issue is howtos. Working examples which I can refer to and understand (prototype) before I start writing code. When to use the execute form of the macro vs list, also let me add I was never an applications program, i Regards Bruce -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- 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
[SUSPECTED SPAM] Re: Mainframe DEVOPS
On Thu, 21 Nov 2019, at 20:00, Seymour J Metz wrote: > Tritus SPF; it is, alas, abandon-ware, but it is able to run ISPF > dialogs that do not depend on TSO commands or TSO function packages. It > has regexen, but the syntax is not the same as either ISPF or the major > PC languages. I would happily pay for an upgrade if the developers > would revive it, but as I understand it there are legal issues that > make it unlikely. Ah, Tritus...I should have remembered that. If one Googles for it there's several hits but only on iffy sites that look as if they want people to pay to download something, eg https://pserritirou.tk/family/tritus-spf.php I also stumbled across "Capable Worthy Text Editor" http://cwtexteditor.sourceforge.net/index.html which I don't think I've heard of before - open source - apparently works under both Windows & Linux/Unix etc via X⋅Window (X11). It looks like it has an editor and a files-list/dir / ispf 3.4 utility, but I saw no sign of any REXX or dialog support. There's also uni-SPF etc as described at: http://www.wrkgrp.com/index.html but I see the website page-footer copyright date is 2013.I downloaded some manuals but their production dates are 2002. Goodness knows if the products still exist. -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Mainframe PL/1 code for VSE with DBCS characters
Hi List, I'm looking for samples of PL/1 code for VSE with DBCS characters using graphical and mixed DBCS strings and whatever that may be in use in Japan. I'm also looking for the compiler options required to compile it on a z/VSE 6.1 environment. Thank in advance. Best Regards. Mauri. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IARST64 OWNER SECONDARY ?
Where in 31 bit mode you are able to get 31 bit ( private ) storage in a other address space via the ALET parameter on the STORAGE macro this is not true for 64 bit storage Thanks On Nov 25, 2019, at 8:07 AM, Peter Relson wrote: > > > There doesn't seem to be any documentation on what this parm means. > > Sure there is, as Michael Stein pointed out. And "owner" is the same for > getmain, storage obtain, IARV64, IARCP64. > > Seems like I would have to do a SSAR to point to the secondary asid > and I am > guessing the storage would reside in that asid and reference it with AR > value of 1 ? > > > In all of the obtaining storage cases, owner applies to common storage > obtains (as the documentation indicates), and SECONDARY applies to the > current secondary ASN when the request is made. Since common storage is > never freed by the system upon some work unit's (or address space's) > termination, owner does not relate to when the storage might automatically > be freed. For these obtaining storage cases, for the most part, owner > refers to how the storage is tracked by the system so that in a diagnostic > situation you might be able to ascertain who is responsible for obtaining > a particular area or who is responsible for using up "so much" common > storage. Look up the DIAGxx parmlib member TRAP statement with the CSA > and/or SQA options (although that does not apply to the high virtual that > IARST64 deals with). Look up IPCS subcommand VERBEXIT VSMDATA OWNCOMM > (similarly, I think not for high virtual). > > The most common usage might be in a space-switch PC target where you want > to get common storage that is to be tagged as owned by the PC issuer > (which usually is identified by your current secondary ASN). > > If ever considering SSAR, you need to factor in the authorization > requirements, the non-swappability requirements with respect to the target > space, and the possibility of needing to use SSAIR instead. > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IARST64 OWNER SECONDARY ?
There doesn't seem to be any documentation on what this parm means. Sure there is, as Michael Stein pointed out. And "owner" is the same for getmain, storage obtain, IARV64, IARCP64. Seems like I would have to do a SSAR to point to the secondary asid and I am guessing the storage would reside in that asid and reference it with AR value of 1 ? In all of the obtaining storage cases, owner applies to common storage obtains (as the documentation indicates), and SECONDARY applies to the current secondary ASN when the request is made. Since common storage is never freed by the system upon some work unit's (or address space's) termination, owner does not relate to when the storage might automatically be freed. For these obtaining storage cases, for the most part, owner refers to how the storage is tracked by the system so that in a diagnostic situation you might be able to ascertain who is responsible for obtaining a particular area or who is responsible for using up "so much" common storage. Look up the DIAGxx parmlib member TRAP statement with the CSA and/or SQA options (although that does not apply to the high virtual that IARST64 deals with). Look up IPCS subcommand VERBEXIT VSMDATA OWNCOMM (similarly, I think not for high virtual). The most common usage might be in a space-switch PC target where you want to get common storage that is to be tagged as owned by the PC issuer (which usually is identified by your current secondary ASN). If ever considering SSAR, you need to factor in the authorization requirements, the non-swappability requirements with respect to the target space, and the possibility of needing to use SSAIR instead. 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: WTO
Got any doc for that exit? On 2019-11-25 8:46 PM, scott Ford wrote: David, It’s the way CA calls the exit. There is a workarea dsect and notes from CA peppered through the exit and doc saying there is a 100 byte limitation. Scott On Mon, Nov 25, 2019 at 4:20 AM David Crayford wrote: That's interesting! You said the exit was re-entrant so how is it obtaining the working storage. If it's doing a GETMAIN why don't you just increase the size of the storage. Why do you have a constraint of 100 bytes? On 2019-11-25 1:11 AM, scott Ford wrote: David, True, sorry misread his reply. David my issue is I have limited storage for variables, 100 bytes , like being back writing BAL on a 360/20. I haven’t had this experience on a piece of re-entrant code with this limitation. This was one of the main reasons I asked the question of my colleagues here on the Listserv. The exit is Top-secrets exit. Scott On Sun, Nov 24, 2019 at 7:07 AM David Crayford wrote: On 2019-11-23 7:07 AM, scott Ford wrote: Henri, That’s what ended up doing , thank you, I appreciate any help. Maybe a bit of a misunderstanding here. I think what Henri was suggesting was using a UNIX shell that pipes messages to /dev/console which writes WTOs using the syslogd daemon. echo "hello" > /dev/console I think your problem was related to writing assembler code with WTO macros? Scott On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper wrote: Maybe a bit late. But a plain WTO via an echo to /dev/console not an option? Sent from my wireless iPhone On 19 Nov 2019, at 18:52, scott Ford wrote: Bruce, Peter, all: A big thanks . its much appreciated by this older t-rex. Scott On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < bruce_hew...@hotmail.com> wrote: Hello Scott, How I do it. in CSECT copy list form from CONSTANTs section to DSECT working section Update message text run WTO execute form in DSECT WTO list form map in Constants WTO_text WTO list form with text WTO_length = * - WTO_text DESCT maps onto your own STORAGE area, thus copying the constant LIST form over the DSECT map makes the code reentrant. On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford wrote: Peter, I have to add displays ( WTOs ). I dont have complaints again IBM, rarely, best people I ever worked with, my issue is howtos. Working examples which I can refer to and understand (prototype) before I start writing code. When to use the execute form of the macro vs list, also let me add I was never an applications program, i Regards Bruce -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- 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: WTO
David, It’s the way CA calls the exit. There is a workarea dsect and notes from CA peppered through the exit and doc saying there is a 100 byte limitation. Scott On Mon, Nov 25, 2019 at 4:20 AM David Crayford wrote: > That's interesting! You said the exit was re-entrant so how is it > obtaining the working storage. If it's doing a GETMAIN why don't you > just increase the size > of the storage. Why do you have a constraint of 100 bytes? > > On 2019-11-25 1:11 AM, scott Ford wrote: > > David, > > > > True, sorry misread his reply. David my issue is I have limited storage > for > > variables, 100 bytes , like being back writing BAL on a 360/20. I haven’t > > had this experience on a piece of re-entrant code with this limitation. > > This was one of the main reasons I asked the question of my colleagues > here > > on the Listserv. > > > > The exit is Top-secrets exit. > > > > Scott > > > > On Sun, Nov 24, 2019 at 7:07 AM David Crayford > wrote: > > > >> On 2019-11-23 7:07 AM, scott Ford wrote: > >>> Henri, > >>> > >>> That’s what ended up doing , thank you, I appreciate any help. > >> Maybe a bit of a misunderstanding here. I think what Henri was > >> suggesting was using a UNIX shell that pipes messages to /dev/console > >> which writes WTOs using the syslogd daemon. > >> > >> echo "hello" > /dev/console > >> > >> I think your problem was related to writing assembler code with WTO > macros? > >> > >> > >>> Scott > >>> > >>> On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper > >>> wrote: > >>> > Maybe a bit late. But a plain WTO via an echo to /dev/console not an > option? > > Sent from my wireless iPhone > > > On 19 Nov 2019, at 18:52, scott Ford wrote: > > > > Bruce, Peter, all: > > > > A big thanks . its much appreciated by this older t-rex. > > > > Scott > > > >> On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < > >> bruce_hew...@hotmail.com> > >> wrote: > >> > >> Hello Scott, > >> > >> How I do it. > >> > >> in CSECT copy list form from CONSTANTs section to DSECT working > >> section > >> Update message text > >> run WTO execute form > >> > >> in DSECT > >> WTO list form map > >> > >> in Constants > >> WTO_text WTO list form with text > >> WTO_length = * - WTO_text > >> > >> DESCT maps onto your own STORAGE area, thus copying the constant > LIST > form > >> over the DSECT map makes the code reentrant. > >> > >> > >> > >> > >> > >>> On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford > > wrote: > >>> Peter, > >>> > >> > >>> I have to add displays ( WTOs ). I dont have complaints again IBM, > rarely, > >>> best people I ever worked with, my issue is howtos. Working > examples > which > >>> I can refer to and understand > >>> (prototype) before I start writing code. When to use the execute > form > of > >>> the macro vs list, also let me add I was never an applications > program, i > >> > >> > >> > >> Regards > >> Bruce > >> > >> > -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO > >> IBM-MAIN > > -- > > > > > > > > *IDMWORKS * > > > > Scott Ford > > > > z/OS Dev. > > > > > > > > > > “By elevating a friend or Collegue you elevate yourself, by > demeaning a > > friend or collegue you demean yourself” > > > > > > > > www.idmworks.com > > > > scott.f...@idmworks.com > > > > Blog: www.idmworks.com/blog > > > > > > > > > > > > *The information contained in this email message and any attachment > may > be > > privileged, confidential, proprietary or otherwise protected from > > disclosure. If the reader of this message is not the intended > >> recipient, > > you are hereby notified that any dissemination, distribution, copying > >> or > > use of this message and any attachment is strictly prohibited. If you > have > > received this message in error, please notify us immediately by > >> replying > to > > the message and permanently delete it from your computer and destroy > >> any > > printout thereof.* > > > > > -- > > 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: Zosmf error with IZUSRV1
There is only error message under STDERR i see CWWKS4108E: The system cannot create the LTPA key. On Mon, 25 Nov, 2019, 3:10 PM Mike Wawiorko, < 014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote: > D TCPIP,stack_name,N,CON,CLI=IZU* > stack_name may be null if you've only one IP stack. > > Do you see it listening? > > If not, look again at your configuration and messages from IZUSRV1. > Some messages may be in Unix log files rather than JES output or syslog. > I'm not sure about this. > > Mike Wawiorko > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Peter > Sent: 25 November 2019 11:01 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Zosmf error with IZUSRV1 > > > This message originated from outside our organisation and is from web > based email - dbajava...@gmail.com > > I was able the fix this will the TCPIP host file but still not seeing > IZUSRV1 listening on the port coded in IZUPRMXX parmlib member. > > > > On Mon, 25 Nov, 2019, 2:57 PM Mike Wawiorko, < > 014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote: > > > is it possible to have an IP address to use ? > > > > > > > > Pretty unlikely if you are talking about the web interface to zOSMF > > and trying to access it from a browser. > > > > > > > > Modern browsers understandably impose security rules to protect us all. > > You'll need: > > > > > > > > · A server certificate > > > > · It must be signed by a CA trusted in your network > > > > · You must use a DNS name in the browser (not an IP address) > > > > · That DNS name MUST be included in the server certificate list > of > > subject alternate names > > > > > > > > Anything less than this and most browsers will warn that the site is > > not to be trusted and may even completely deny access to it. > > > > > > > > Mike Wawiorko > > > > > > > > This e-mail and any attachments are confidential and intended solely > > for the addressee and may also be privileged or exempt from disclosure > > under applicable law. If you are not the addressee, or have received > > this e-mail in error, please notify the sender immediately, delete it > > from your system and do not copy, disclose or otherwise act upon any > > part of this e-mail or its attachments. > > Internet communications are not guaranteed to be secure or virus-free. > > The Barclays Group does not accept responsibility for any loss arising > > from unauthorised access to, or interference with, any Internet > > communications by any third party, or from the transmission of any > > viruses. Replies to this e-mail may be monitored by the Barclays Group > > for operational or business reasons. > > Any opinion or other information in this e-mail or its attachments > > that does not relate to the business of the Barclays Group is personal > > to the sender and is not given or endorsed by the Barclays Group. > > Barclays Execution Services Limited provides support and > > administrative services across Barclays group. Barclays Execution > > Services Limited is an appointed representative of Barclays Bank UK > > plc, Barclays Bank plc and Clydesdale Financial Services Limited. > > Barclays Bank UK plc and Barclays Bank plc are authorised by the > > Prudential Regulation Authority and regulated by the Financial Conduct > > Authority and the Prudential Regulation Authority. Clydesdale > > Financial Services Limited is authorised and regulated by the Financial > Conduct Authority. > > > > -- > > 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 and any attachments are confidential and intended solely for > the addressee and may also be privileged or exempt from disclosure under > applicable law. If you are not the addressee, or have received this e-mail > in error, please notify the sender immediately, delete it from your system > and do not copy, disclose or otherwise act upon any part of this e-mail or > its attachments. > Internet communications are not guaranteed to be secure or virus-free. The > Barclays Group does not accept responsibility for any loss arising from > unauthorised access to, or interference with, any Internet communications > by any third party, or from the transmission of any viruses. Replies to > this e-mail may be monitored by the Barclays Group for operational or > business reasons. > Any opinion or other information in this e-mail or its attachments that > does not relate to the business of the Barclays Group is personal to the > sender and is not given or endorsed by the Barclays Group. > Barclays Execution Services Limited provides support and administrative >
Re: Zosmf error with IZUSRV1
D TCPIP,stack_name,N,CON,CLI=IZU* stack_name may be null if you've only one IP stack. Do you see it listening? If not, look again at your configuration and messages from IZUSRV1. Some messages may be in Unix log files rather than JES output or syslog. I'm not sure about this. Mike Wawiorko -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: 25 November 2019 11:01 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zosmf error with IZUSRV1 This message originated from outside our organisation and is from web based email - dbajava...@gmail.com I was able the fix this will the TCPIP host file but still not seeing IZUSRV1 listening on the port coded in IZUPRMXX parmlib member. On Mon, 25 Nov, 2019, 2:57 PM Mike Wawiorko, < 014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote: > is it possible to have an IP address to use ? > > > > Pretty unlikely if you are talking about the web interface to zOSMF > and trying to access it from a browser. > > > > Modern browsers understandably impose security rules to protect us all. > You'll need: > > > > · A server certificate > > · It must be signed by a CA trusted in your network > > · You must use a DNS name in the browser (not an IP address) > > · That DNS name MUST be included in the server certificate list of > subject alternate names > > > > Anything less than this and most browsers will warn that the site is > not to be trusted and may even completely deny access to it. > > > > Mike Wawiorko > > > > This e-mail and any attachments are confidential and intended solely > for the addressee and may also be privileged or exempt from disclosure > under applicable law. If you are not the addressee, or have received > this e-mail in error, please notify the sender immediately, delete it > from your system and do not copy, disclose or otherwise act upon any > part of this e-mail or its attachments. > Internet communications are not guaranteed to be secure or virus-free. > The Barclays Group does not accept responsibility for any loss arising > from unauthorised access to, or interference with, any Internet > communications by any third party, or from the transmission of any > viruses. Replies to this e-mail may be monitored by the Barclays Group > for operational or business reasons. > Any opinion or other information in this e-mail or its attachments > that does not relate to the business of the Barclays Group is personal > to the sender and is not given or endorsed by the Barclays Group. > Barclays Execution Services Limited provides support and > administrative services across Barclays group. Barclays Execution > Services Limited is an appointed representative of Barclays Bank UK > plc, Barclays Bank plc and Clydesdale Financial Services Limited. > Barclays Bank UK plc and Barclays Bank plc are authorised by the > Prudential Regulation Authority and regulated by the Financial Conduct > Authority and the Prudential Regulation Authority. Clydesdale > Financial Services Limited is authorised and regulated by the Financial > Conduct Authority. > > -- > 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 and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Execution Services Limited provides support and administrative services across Barclays group. Barclays Execution Services Limited is an appointed representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.
Re: Zosmf error with IZUSRV1
I was able the fix this will the TCPIP host file but still not seeing IZUSRV1 listening on the port coded in IZUPRMXX parmlib member. On Mon, 25 Nov, 2019, 2:57 PM Mike Wawiorko, < 014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote: > is it possible to have an IP address to use ? > > > > Pretty unlikely if you are talking about the web interface to zOSMF and > trying to access it from a browser. > > > > Modern browsers understandably impose security rules to protect us all. > You'll need: > > > > · A server certificate > > · It must be signed by a CA trusted in your network > > · You must use a DNS name in the browser (not an IP address) > > · That DNS name MUST be included in the server certificate list of > subject alternate names > > > > Anything less than this and most browsers will warn that the site is not > to be trusted and may even completely deny access to it. > > > > Mike Wawiorko > > > > This e-mail and any attachments are confidential and intended solely for > the addressee and may also be privileged or exempt from disclosure under > applicable law. If you are not the addressee, or have received this e-mail > in error, please notify the sender immediately, delete it from your system > and do not copy, disclose or otherwise act upon any part of this e-mail or > its attachments. > Internet communications are not guaranteed to be secure or virus-free. The > Barclays Group does not accept responsibility for any loss arising from > unauthorised access to, or interference with, any Internet communications > by any third party, or from the transmission of any viruses. Replies to > this e-mail may be monitored by the Barclays Group for operational or > business reasons. > Any opinion or other information in this e-mail or its attachments that > does not relate to the business of the Barclays Group is personal to the > sender and is not given or endorsed by the Barclays Group. > Barclays Execution Services Limited provides support and administrative > services across Barclays group. Barclays Execution Services Limited is an > appointed representative of Barclays Bank UK plc, Barclays Bank plc and > Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays > Bank plc are authorised by the Prudential Regulation Authority and > regulated by the Financial Conduct Authority and the Prudential Regulation > Authority. Clydesdale Financial Services Limited is authorised and > regulated by the Financial Conduct Authority. > > -- > 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: Zosmf error with IZUSRV1
is it possible to have an IP address to use ? Pretty unlikely if you are talking about the web interface to zOSMF and trying to access it from a browser. Modern browsers understandably impose security rules to protect us all. You'll need: · A server certificate · It must be signed by a CA trusted in your network · You must use a DNS name in the browser (not an IP address) · That DNS name MUST be included in the server certificate list of subject alternate names Anything less than this and most browsers will warn that the site is not to be trusted and may even completely deny access to it. Mike Wawiorko This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Execution Services Limited provides support and administrative services across Barclays group. Barclays Execution Services Limited is an appointed representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Clydesdale Financial Services Limited is authorised and regulated by the Financial Conduct Authority. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
That's interesting! You said the exit was re-entrant so how is it obtaining the working storage. If it's doing a GETMAIN why don't you just increase the size of the storage. Why do you have a constraint of 100 bytes? On 2019-11-25 1:11 AM, scott Ford wrote: David, True, sorry misread his reply. David my issue is I have limited storage for variables, 100 bytes , like being back writing BAL on a 360/20. I haven’t had this experience on a piece of re-entrant code with this limitation. This was one of the main reasons I asked the question of my colleagues here on the Listserv. The exit is Top-secrets exit. Scott On Sun, Nov 24, 2019 at 7:07 AM David Crayford wrote: On 2019-11-23 7:07 AM, scott Ford wrote: Henri, That’s what ended up doing , thank you, I appreciate any help. Maybe a bit of a misunderstanding here. I think what Henri was suggesting was using a UNIX shell that pipes messages to /dev/console which writes WTOs using the syslogd daemon. echo "hello" > /dev/console I think your problem was related to writing assembler code with WTO macros? Scott On Fri, Nov 22, 2019 at 3:38 PM Henri Kuiper wrote: Maybe a bit late. But a plain WTO via an echo to /dev/console not an option? Sent from my wireless iPhone On 19 Nov 2019, at 18:52, scott Ford wrote: Bruce, Peter, all: A big thanks . its much appreciated by this older t-rex. Scott On Tue, Nov 19, 2019 at 3:10 AM Bruce Hewson < bruce_hew...@hotmail.com> wrote: Hello Scott, How I do it. in CSECT copy list form from CONSTANTs section to DSECT working section Update message text run WTO execute form in DSECT WTO list form map in Constants WTO_text WTO list form with text WTO_length = * - WTO_text DESCT maps onto your own STORAGE area, thus copying the constant LIST form over the DSECT map makes the code reentrant. On Mon, 18 Nov 2019 08:55:45 -0500, scott Ford wrote: Peter, I have to add displays ( WTOs ). I dont have complaints again IBM, rarely, best people I ever worked with, my issue is howtos. Working examples which I can refer to and understand (prototype) before I start writing code. When to use the execute form of the macro vs list, also let me add I was never an applications program, i Regards Bruce -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- 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
