Re: AUTHPGM in IKJTSOxx

[Michael Stein]

On Tue, Nov 26, 2019 at 07:13:47PM +, Seymour J Metz wrote:
> If you have update access to APF authorized libraries then you could
> certainly write such a program, although a competent auditor would read
> you the riot act if he found out. Exploiting a program that follows the
> rules is harder.

Figuring out the "rules" is hard.  Following them is harder.

It's very easy to get an authorized function to usually work.  Writing the
code so that it works and fails correctly and is secure is much harder..

For security it's usually best to let the hardware provide the security
boundaries whereever possible (address space and protect keys).

Write access to an APF library on a personal test system is really useful
for education, development, and trying out system services.

A non-shared test system doesn't have system stability or security issues
to be concerned about.  But be very careful NEVER to run that type of
code on shared systems.

I once traced instruction counts for a path of "hit enter once" type
action.  This involved turning on instruction fetch PER and disabled
DAT off code to update a counter for each asid/instruction address.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMFPRMFxx SYS SUBSYS and EXITs question

[Charles Mills]

It is a very confusing bit of business.

I find it clearer to work from D SMF,O rather than the raw parmlib member.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Nick Varley
Sent: Tuesday, November 26, 2019 7:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMFPRMFxx SYS SUBSYS and EXITs question

In an SMFPRMxx member if you have this:

...
SYS(NOTYPE(4,5,20,34,35,40)
EXITS(IEFU83,IEFU84,IEFU85,IEFACTRT,IEFUJV,IEFUSI,
   IEFUJP,IEFUSO,IEFUJI,IEFUTL))
SUBSYS(STC,EXITS(IEFUJP,IEFUSO))
...

then why would the IEFU83/84/85 exits not fire for SMF records coming from
STCs?
Documentation seems to imply that the SYS settings are the default/back-stop
for all things.

We needed to make the last line read like this to make it work:

...
 SUBSYS(STC,EXITS(IEFU83,IEFU84,IEFU85,IEFUJP,IEFUSO))
...

The question:
  Does the list of exits in the SUBSYS specification overwrite all those in
SYS, that is, in this case, it reduces the list of exits from the ten in the
SYS specification to just the two that are explicitly listed?

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

[Charles Mills]

Yeah, sorry, I fully admit I have zero real-world experience with UUIDs on Z -- 
Japanese or otherwise. And relatively little elsewhere: I have used them for 
version signing on Visual Studio -- that's it.

I would certainly think (hope!) that any reasonable code would be using the 
underlying 128-bit binary value, and whether you used abc, ABC or some mixture 
would be irrelevant.

I think the standard is pretty clear: the 128-bit binary value *is* the UUI, 
the character string is just a representation thereof, and upper-case hex 
values are acceptable.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cameron Conacher
Sent: Tuesday, November 26, 2019 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question - UUID Approach for Mainframes in Japan

Thanks Charles,
I was hoping someone with a Japan background would weigh in to say
something along the lines of "have the Consumers upper case the UUID BEFORE
they send it to you" or, "we use DATAPOWER to force upper case on all UUIDs
BEFORE the strings arrive in the mainframe". or something else.

If a Consumer were to send me a UUID in Lower Case and I return a reply
with the UUID Upper Cased, does this cause some inconsistency on the
Consumer's side of the fence?
I mean, functionally, the UUIDs are the same, but the actual string values
are different.
Does this create issues?


On Mon, Nov 25, 2019 at 4:30 PM Charles Mills  wrote:

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

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

[Attila Fogarasi]

The UUID specification requires accepting both lowercase and uppercase
letters as input, so changing lowercase to uppercase does not change the
value of the UUID.
That same specification specifies that only lowercase is allowed for output
(to make it more human readable), however many implementations in the past
have generated mixed case.
This behaviour is sensible as the UUID is actually a 128 bit hex number
being represented as hex letters (0-9, a-f) and only used as the 128-bit
number internally.
Bottom line is there is no issue for Japan for any codepage that you might
be using (or if the codepage is changed).

On Wed, Nov 27, 2019 at 1:01 AM Cameron Conacher  wrote:

> Thanks Charles,
> I was hoping someone with a Japan background would weigh in to say
> something along the lines of "have the Consumers upper case the UUID BEFORE
> they send it to you" or, "we use DATAPOWER to force upper case on all UUIDs
> BEFORE the strings arrive in the mainframe". or something else.
>
> If a Consumer were to send me a UUID in Lower Case and I return a reply
> with the UUID Upper Cased, does this cause some inconsistency on the
> Consumer's side of the fence?
> I mean, functionally, the UUIDs are the same, but the actual string values
> are different.
> Does this create issues?
>
>
> On Mon, Nov 25, 2019 at 4:30 PM Charles Mills  wrote:
>
> > 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
> >
>
> --
> 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

[Seymour J Metz]

Of course it was reentrant, but was it good form? I prefer to protect code 
against wild stores by marking it as r/o.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Tuesday, November 26, 2019 3:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO

On Tue, Nov 26, 2019 at 1:21 PM Seymour J Metz  wrote:

> What makes your program non-reentrant is failing to serialize shared data.
> Long ago in a galaxy far away IBM actually shipped reentrant code that
> modified itself; AFAIK they have cleaned up that abomination.
>

I agree that it's an abomination. But I have done it for a shared
subroutine in a multitasking system. It was reentrant. What was modified
was a 4 byte address. The code looked to see if the area was zero. If it
was, I would do a GETMAIN. I would then update the address area using a CS
to serialize the update. If the CS "succeeded", I would build a R/O table
in that area. If the CS "failed", I would do a FREEMAIN of the storage.
After this, I picked up the address and used it. This is reentrant
according to the defination in Wikipedia:
https://secure-web.cisco.com/1jsyGkFIj1WTeQ3KJFFZTdshHzHkTsH523_JLLN5q0_8zRvH5fDyxv6HpWDuG1ujz5M7NbyZLHHNNeBOxGyv06V0sdWDShL1sPaXH1ydr99wn9PTrvn8mQ371WstVbYW9PCG2qbfELdMura-qgBInB-IB-0MFntpaaeNNl-bzxuM984GbqsE_ddL1YhbrCgWQubkAMTjEccRf7KB7Q2KwjegMWw1XXJHCrcm4TL_cAMn8vn05YH1ziUeI57MUUZdjlabjreLj_0JG6nWfx-ye-qofzxhB_F3FgEQ-XjO56fQK_SzyF2LiKwEX4wsyo5ysZCu_vh7YWV2-N1K5ebEWMB0I9HfucI47A7MuIAZ005t8G7XOzjLBJl-nGalQLYL-Wc-_7_HKVqSJmz9v6fmKpmTWX7RL5TQyHeMbKnZe5NoKnIcLsmyhUUHUeWo7pX9B/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FReentrancy_%28computing%29


In computing 
,
 a computer program

 or subroutine

 is called *reentrant* if
multiple invocations can safely run concurrently. The concept applies even
on a single processor system, where a reentrant procedure can be
interrupted in the middle of its execution and then safely be called again
("re-entered") before its previous invocations complete execution. The
interruption could be caused by an internal action such as a jump or call,
or by an external action such as an interrupt

 or signal
.
 The previous
invocations may resume correct execution before the reentered invocation

Re: WTO

[John McKown]

On Tue, Nov 26, 2019 at 1:21 PM Seymour J Metz  wrote:

> What makes your program non-reentrant is failing to serialize shared data.
> Long ago in a galaxy far away IBM actually shipped reentrant code that
> modified itself; AFAIK they have cleaned up that abomination.
>

I agree that it's an abomination. But I have done it for a shared
subroutine in a multitasking system. It was reentrant. What was modified
was a 4 byte address. The code looked to see if the area was zero. If it
was, I would do a GETMAIN. I would then update the address area using a CS
to serialize the update. If the CS "succeeded", I would build a R/O table
in that area. If the CS "failed", I would do a FREEMAIN of the storage.
After this, I picked up the address and used it. This is reentrant
according to the defination in Wikipedia:
https://en.wikipedia.org/wiki/Reentrancy_(computing)


In computing , a computer program
 or subroutine
 is called *reentrant* if
multiple invocations can safely run concurrently. The concept applies even
on a single processor system, where a reentrant procedure can be
interrupted in the middle of its execution and then safely be called again
("re-entered") before its previous invocations complete execution. The
interruption could be caused by an internal action such as a jump or call,
or by an external action such as an interrupt
 or signal
. The previous
invocations may resume correct execution before the reentered invocation
completes, unlike recursion
, where the
previous invocations may only resume correct execution once the reentered
invocation completes.



Of course, in the latest z/OS code marked RENT (or is it REFR?) I think is
loaded into key 0 storage and my code will fail, just like it does if it's
loaded into LPA. I know of vendors in the past who demanded that their code
be loaded into MLPA to avoid the "no store here". I have seen other code
actually go key 0, change the protection on an LPA page to R/W, updated it,
then change the protection back to R/O.

All of the above is poor coding in today's environment. Today, I would use
some some of Name/Token to "anchor" a data area.



>
> In the case of WTO, use of MF=L in the CSECT does not keep the code from
> being reentrant if, as you describe later, the only use made of it is to
> initialize dynamic storage. Used that way there are no shared data, hence
> no need serialize.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

JES3 to JES2 migration experience

[Mark Wilson]

Varun,

We have lots of migration experience. If you would like to discuss the gotcha’s 
for such a migration, drop me an email to 
ma...@rsmpartners.com

Mark

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Mainframe Sysprog
Sent: 26 November 2019 14:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] JES3 to JES2 migration experience

Hi List,

I know this topic has been discussed multiple times, and with the recent SOD on 
JES3, I am looking for some hands-on tips or experiences from anyone who has 
had the chance of converting from JES3 to JES2.

Can anyone share their experience on what are the most troublesome areas to be 
considered for such a migration and how were these handled in your case?

Any gotchas, or areas that get overlooked?

I am reviewing the excellent Redbook from IBM, but would want to supplement 
that with some real world experiences.

Thanks
Varun


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: WTO

[Seymour J Metz]

What makes your program non-reentrant is failing to serialize shared data. Long 
ago in a galaxy far away IBM actually shipped reentrant code that modified 
itself; AFAIK they have cleaned up that abomination.

In the case of WTO, use of MF=L in the CSECT does not keep the code from being 
reentrant if, as you describe later, the only use made of it is to initialize 
dynamic storage. Used that way there are no shared data, hence no need 
serialize.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Monday, November 25, 2019 5:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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

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

[Seymour J Metz]

If you have update access to APF authorized libraries then you could certainly 
write such a program, although a competent auditor would read you the riot act 
if he found out. Exploiting a program that follows the rules is harder.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Jeremy Nicoll 
Sent: Monday, November 25, 2019 6:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

RES: JES3 to JES2 migration experience

[ITURIEL DO NASCIMENTO NETO]

Hi,

There is an IBM Redbook about this subject.
We have converted from JES3 to JES2 in 2005 when there was nothing documented 
and, AFAIR, the main points were:

1) ISV products in general and Automation package specifically.
2) We have to code some JES2 exits to cover funtionalities that were present in 
JES3, but not in JES2.
3) Aplications that issue JES3 commands
4) Training

Atenciosamente / Regards / Saludos

Ituriel do Nascimento Neto
4250/DITI Engenharia de Software
Tel: +55 11 3684-9602 Canal de voz 23-1404
E-mail: ituriel.nascime...@bradesco.com.br
BANCO BRADESCO S.A.
Cidade de Deus, Osasco, Prédio Vermelho




-Mensagem original-
De: IBM Mainframe Discussion List  Em nome de 
Mainframe Sysprog
Enviada em: terça-feira, 26 de novembro de 2019 11:28
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: JES3 to JES2 migration experience

Hi List,

I know this topic has been discussed multiple times, and with the recent SOD on 
JES3, I am looking for some hands-on tips or experiences from anyone who has 
had the chance of converting from JES3 to JES2.

Can anyone share their experience on what are the most troublesome areas to be 
considered for such a migration and how were these handled in your case?

Any gotchas, or areas that get overlooked?

I am reviewing the excellent Redbook from IBM, but would want to supplement 
that with some real world experiences.

Thanks
Varun

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) 
a quem é dirigida, podendo conter informação confidencial e/ou legalmente 
privilegiada. Se você não for destinatário desta mensagem, desde já fica 
notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de 
qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. 
Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este 
E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de 
dados, registros ou sistema de controle. Fica desprovida de eficácia e validade 
a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha 
poderes de representação. 
LEGAL ADVICE...This message is exclusively destined for the people to whom 
it is directed, and it can bear private and/or legally exceptional information. 
If you are not addressee of this message, since now you are advised to not 
release, copy, distribute, check or, otherwise, use the information contained 
in this message, because it is illegal. If you received this message by 
mistake, we ask you to return this email, making possible, as soon as possible, 
the elimination of its contents of your database, registrations or controls 
system. The message that bears any mandatory links, issued by someone who has 
no representation powers, shall be null or void.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JES3 to JES2 migration experience

[Lionel B Dyck]

I found this presentation with more information that may help

 

http://conferences.gse.org.uk/2019/presentations/BQ.pdf

 

For pricing on slide 27

1.  JES3plus is fully supported, has a road map for enhancements, and can 
be implemented by existing IBM JES3 customers through a trivial migration and 
at no additional cost.
2.  Initial contract cost will closely match what customers are currently 
paying for IBM JES3
3.  Any subsequent price increases will be in line with the percentage 
price increases implemented by IBM
4.  Annual licensing in place of MLC

 

 

 

Lionel B. Dyck <

Website: http://www.lbdsoftware.com

 

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mainframe Sysprog
Sent: Tuesday, November 26, 2019 9:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES3 to JES2 migration experience

 

Thanks, Lionel for your comment (year end bonus would be great :)

 

I have also read the announcement from Phoenix software, and the mail from 
Edward on this list. That is definitely being considered as an option. It would 
be interesting to see a cost comparison for JES3 being supported from Phoenix - 
is there any information available in that regard?

 

But since, I am not involved in the final decision w.r.t. the cost of keeping 
JES3 (through Phoenix), I am trying to compile this list more from a technical 
standpoint on the common pitfalls, duration of migration, post migration issues 
etc for the management to take an informed decision before we get too far down 
the road.

 

Regards

Varun

 

On Tue, Nov 26, 2019 at 8:16 PM Lionel B Dyck <  
lbd...@gmail.com> wrote:

 

> Save your company the time and resources and stay with JES3 now that 

> it will be supported by Phoenix Software

> 

> Check it out at   
> https://phoenixsoftware.com/jes3plus.htm

> 

> This is a very promising development for the JES3 community and will 

> save those considering the migration the time and expense of the 

> migration, funds that be better used elsewhere in the company (such as 

> year end bonuses to the systems staff)  while eliminating the risks of a 
> migration.

> 

> Disclaimer: I know several of the team at Phoenix but I do not work 

> for them or have stock in them.

> 

> 

> Lionel B. Dyck <

> Website:   http://www.lbdsoftware.com

> 

> "Worry more about your character than your reputation.  Character is 

> what you are, reputation merely what others think you are." - John 

> Wooden

> 

> -Original Message-

> From: IBM Mainframe Discussion List <  
> IBM-MAIN@LISTSERV.UA.EDU> On 

> Behalf Of Mainframe Sysprog

> Sent: Tuesday, November 26, 2019 8:28 AM

> To:   IBM-MAIN@LISTSERV.UA.EDU

> Subject: JES3 to JES2 migration experience

> 

> Hi List,

> 

> I know this topic has been discussed multiple times, and with the 

> recent SOD on JES3, I am looking for some hands-on tips or experiences 

> from anyone who has had the chance of converting from JES3 to JES2.

> 

> Can anyone share their experience on what are the most troublesome 

> areas to be considered for such a migration and how were these handled 

> in your case?

> 

> Any gotchas, or areas that get overlooked?

> 

> I am reviewing the excellent Redbook from IBM, but would want to 

> supplement that with some real world experiences.

> 

> Thanks

> Varun

> 

> --

> 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: JES3 to JES2 migration experience

[Mainframe Sysprog]

Thanks, Lionel for your comment (year end bonus would be great :)

I have also read the announcement from Phoenix software, and the mail from
Edward on this list. That is definitely being considered as an option. It
would be interesting to see a cost comparison for JES3 being supported from
Phoenix - is there any information available in that regard?

But since, I am not involved in the final decision w.r.t. the cost of
keeping JES3 (through Phoenix), I am trying to compile this list more from
a technical standpoint on the common pitfalls, duration of migration, post
migration issues etc for the management to take an informed decision before
we get too far down the road.

Regards
Varun

On Tue, Nov 26, 2019 at 8:16 PM Lionel B Dyck  wrote:

> Save your company the time and resources and stay with JES3 now that it
> will be supported by Phoenix Software
>
> Check it out at https://phoenixsoftware.com/jes3plus.htm
>
> This is a very promising development for the JES3 community and will save
> those considering the migration the time and expense of the migration,
> funds that be better used elsewhere in the company (such as year end
> bonuses to the systems staff)  while eliminating the risks of a migration.
>
> Disclaimer: I know several of the team at Phoenix but I do not work for
> them or have stock in them.
>
>
> Lionel B. Dyck <
> Website: http://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Mainframe Sysprog
> Sent: Tuesday, November 26, 2019 8:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JES3 to JES2 migration experience
>
> Hi List,
>
> I know this topic has been discussed multiple times, and with the recent
> SOD on JES3, I am looking for some hands-on tips or experiences from anyone
> who has had the chance of converting from JES3 to JES2.
>
> Can anyone share their experience on what are the most troublesome areas
> to be considered for such a migration and how were these handled in your
> case?
>
> Any gotchas, or areas that get overlooked?
>
> I am reviewing the excellent Redbook from IBM, but would want to
> supplement that with some real world experiences.
>
> Thanks
> Varun
>
> --
> 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: AUTHPGM in IKJTSOxx

[scott Ford]

Not if the resources are protected by a ESM..of some sort, i.e.; RACF...

On Tue, Nov 26, 2019 at 6:35 AM Jeremy Nicoll 
wrote:

> On Tue, 26 Nov 2019, at 00:20, 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 exec somewhere else runs control blocks, finds address of something
> critical, builds & submits the JCL.
>
> --
> 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
>
-- 
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: JES3 to JES2 migration experience

[Lionel B Dyck]

Save your company the time and resources and stay with JES3 now that it will be 
supported by Phoenix Software

Check it out at https://phoenixsoftware.com/jes3plus.htm

This is a very promising development for the JES3 community and will save those 
considering the migration the time and expense of the migration, funds that be 
better used elsewhere in the company (such as year end bonuses to the systems 
staff)  while eliminating the risks of a migration.

Disclaimer: I know several of the team at Phoenix but I do not work for them or 
have stock in them.


Lionel B. Dyck <
Website: http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mainframe Sysprog
Sent: Tuesday, November 26, 2019 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES3 to JES2 migration experience

Hi List,

I know this topic has been discussed multiple times, and with the recent SOD on 
JES3, I am looking for some hands-on tips or experiences from anyone who has 
had the chance of converting from JES3 to JES2.

Can anyone share their experience on what are the most troublesome areas to be 
considered for such a migration and how were these handled in your case?

Any gotchas, or areas that get overlooked?

I am reviewing the excellent Redbook from IBM, but would want to supplement 
that with some real world experiences.

Thanks
Varun

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

JES3 to JES2 migration experience

[Mainframe Sysprog]

Hi List,

I know this topic has been discussed multiple times, and with the recent
SOD on JES3, I am looking for some hands-on tips or experiences from anyone
who has had the chance of converting from JES3 to JES2.

Can anyone share their experience on what are the most troublesome areas to
be considered for such a migration and how were these handled in your case?

Any gotchas, or areas that get overlooked?

I am reviewing the excellent Redbook from IBM, but would want to supplement
that with some real world experiences.

Thanks
Varun

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

[Peter Relson]

I believe when Walt raveled this fiber of the thread he posited assembler
CALL macro or JCL PARM format (they're the same.)


I think of those two as not the same when both the parameter list and the 
parameter are considered.
If you pass a single parameter via CALL, then the parameter list consists 
of a single word (optionally with the high bit on) which has the address 
of the parameter, and the parameter is the parameter.
If you pass  a parameter in "JCL PARM format", the parameter list is the 
same as above, but the parameter is the halfword length followed by the 
data.

Granted, for the CALL you could have set up the parameter to be a halfword 
length followed by data. For that case, I agree that the two approaches 
end up being the same.

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: Question - UUID Approach for Mainframes in Japan

[Cameron Conacher]

Thanks Charles,
I was hoping someone with a Japan background would weigh in to say
something along the lines of "have the Consumers upper case the UUID BEFORE
they send it to you" or, "we use DATAPOWER to force upper case on all UUIDs
BEFORE the strings arrive in the mainframe". or something else.

If a Consumer were to send me a UUID in Lower Case and I return a reply
with the UUID Upper Cased, does this cause some inconsistency on the
Consumer's side of the fence?
I mean, functionally, the UUIDs are the same, but the actual string values
are different.
Does this create issues?


On Mon, Nov 25, 2019 at 4:30 PM Charles Mills  wrote:

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMFPRMFxx SYS SUBSYS and EXITs question

[retired mainframer]

>From Init & Tuning Ref:

You can specify exits on the SYS and SUBSYS statements of SMFPRMxx.
Your choice of SYS or SUBSYS depends on the scope of work you want to
influence (system-wide or subsystem-wide), as follows:

 On the SYS parameter, specify the exits that are to affect work
throughout
the system, regardless of the subsystem that processes the work.

 On the SUBSYS parameter, specify the exits that are to affect work
processed by a particular SMF-defined subsystem (JES2, JES3, STC, ASCH,
or TSO) and no other subsystem specific exit points will be taken.

The SUBSYS specification overrides the SYS specification. Use SUBSYS to
make exceptions to your SYS specification for particular subsystems.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Nick Varley
> Sent: Tuesday, November 26, 2019 4:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMFPRMFxx SYS SUBSYS and EXITs question
> 
> In an SMFPRMxx member if you have this:
> 
> ...
> SYS(NOTYPE(4,5,20,34,35,40)
> EXITS(IEFU83,IEFU84,IEFU85,IEFACTRT,IEFUJV,IEFUSI,
>IEFUJP,IEFUSO,IEFUJI,IEFUTL))
> SUBSYS(STC,EXITS(IEFUJP,IEFUSO))
> ...
> 
> then why would the IEFU83/84/85 exits not fire for SMF records coming from
STCs?
> Documentation seems to imply that the SYS settings are the
default/back-stop for all
> things.
> 
> We needed to make the last line read like this to make it work:
> 
> ...
>  SUBSYS(STC,EXITS(IEFU83,IEFU84,IEFU85,IEFUJP,IEFUSO))
> ...
> 
> The question:
>   Does the list of exits in the SUBSYS specification overwrite all those
in SYS, that is,
> in this case, it reduces the list of exits from the ten in the SYS
specification to just the
> two that are explicitly listed?
> 
> Any pointers would be welcome!
> 
> Thanks,
> Nick.
> 
> Nick Varley
> Director, Customer Support
> p +44 (0) 1823 226012 | m +44 (0) 7766 806780
> nick.var...@syncsort.com
> 
> We organise data everywhere,
> to keep the world working
> Syncsort Limited
> 2 Tangier Central
> Castle Street
> Taunton
> TA1 4AS
> UK
>
www.syncsort.com
-
> -
> ATTENTION: --
> Syncsort Limited is a limited company registered in England and Wales.
Registered
> number: 01373158. Registered office: 3rd Floor, The Pinnacle, 20 Tudor
Road,
> Reading, RG1 1NH. VAT: GB295525177
> The information contained in this message (including any files transmitted
with this
> message) may contain proprietary, trade secret or other confidential
and/or legally
> privileged information. Any pricing information contained in this message
or in any
> files transmitted with this message is always confidential and cannot be
shared with
> any third parties without prior written approval from Syncsort. This
message is
> intended to be read only by the individual or entity to whom it is
addressed or by their
> designee. If the reader of this message is not the intended recipient, you
are on notice
> that any use, disclosure, copying or distribution of this message, in any
form, is strictly
> prohibited. If you have received this message in error, please immediately
notify the
> sender and/or Syncsort and destroy all copies of this message in your
possession,
> custody or control.
> 
> --
> 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: SMFPRMFxx SYS SUBSYS and EXITs question

[Vernooij, Kees (ITOP NM) - KLM]

Check:
Initialization and Tuning Guide
SMFPRMxx description
Statements and parameters for SMFPRMxx
the SUBSYS parameter 

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nick Varley
Sent: 26 November 2019 13:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMFPRMFxx SYS SUBSYS and EXITs question

In an SMFPRMxx member if you have this:

...
SYS(NOTYPE(4,5,20,34,35,40)
EXITS(IEFU83,IEFU84,IEFU85,IEFACTRT,IEFUJV,IEFUSI,
   IEFUJP,IEFUSO,IEFUJI,IEFUTL))
SUBSYS(STC,EXITS(IEFUJP,IEFUSO))
...

then why would the IEFU83/84/85 exits not fire for SMF records coming from STCs?
Documentation seems to imply that the SYS settings are the default/back-stop 
for all things.

We needed to make the last line read like this to make it work:

...
 SUBSYS(STC,EXITS(IEFU83,IEFU84,IEFU85,IEFUJP,IEFUSO))
...

The question:
  Does the list of exits in the SUBSYS specification overwrite all those in 
SYS, that is, in this case, it reduces the list of exits from the ten in the 
SYS specification to just the two that are explicitly listed?

Any pointers would be welcome!

Thanks,
Nick.

Nick Varley
Director, Customer Support
p +44 (0) 1823 226012 | m +44 (0) 7766 806780 nick.var...@syncsort.com

We organise data everywhere,
to keep the world working
Syncsort Limited
2 Tangier Central
Castle Street
Taunton
TA1 4AS
UK
www.syncsort.com--
ATTENTION: --
Syncsort Limited is a limited company registered in England and Wales. 
Registered number: 01373158. Registered office: 3rd Floor, The Pinnacle, 20 
Tudor Road, Reading, RG1 1NH. VAT: GB295525177 The information contained in 
this message (including any files transmitted with this message) may contain 
proprietary, trade secret or other confidential and/or legally privileged 
information. Any pricing information contained in this message or in any files 
transmitted with this message is always confidential and cannot be shared with 
any third parties without prior written approval from Syncsort. This message is 
intended to be read only by the individual or entity to whom it is addressed or 
by their designee. If the reader of this message is not the intended recipient, 
you are on notice that any use, disclosure, copying or distribution of this 
message, in any form, is strictly prohibited. If you have received this message 
in error, please immediately notify the sender and/or Syncsort and destroy all 
copies of this message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMFPRMFxx SYS SUBSYS and EXITs question

[Jousma, David]

Not sure if you did an actual cut/paste of your member, but there is a comma 
missing at the end of the SYS line.

SYS(NOTYPE(4,5,20,34,35,40)
EXITS(IEFU83,IEFU84,IEFU85,IEFACTRT,IEFUJV,IEFUSI,
   IEFUJP,IEFUSO,IEFUJI,IEFUTL))

But in my SMFPRMxx there are comma's

SYS(NOTYPE(4,5,20,34,35,40),
EXITS(IEFU83,IEFU84,IEFU85,IEFACTRT,IEFUJV,IEFUSI,
   IEFUJP,IEFUSO,IEFUJI,IEFUTL))

_
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 
Nick Varley
Sent: Tuesday, November 26, 2019 7:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMFPRMFxx SYS SUBSYS and EXITs question

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

In an SMFPRMxx member if you have this:

...
SYS(NOTYPE(4,5,20,34,35,40)
EXITS(IEFU83,IEFU84,IEFU85,IEFACTRT,IEFUJV,IEFUSI,
   IEFUJP,IEFUSO,IEFUJI,IEFUTL))
SUBSYS(STC,EXITS(IEFUJP,IEFUSO))
...

then why would the IEFU83/84/85 exits not fire for SMF records coming from STCs?
Documentation seems to imply that the SYS settings are the default/back-stop 
for all things.

We needed to make the last line read like this to make it work:

...
 SUBSYS(STC,EXITS(IEFU83,IEFU84,IEFU85,IEFUJP,IEFUSO))
...

The question:
  Does the list of exits in the SUBSYS specification overwrite all those in 
SYS, that is, in this case, it reduces the list of exits from the ten in the 
SYS specification to just the two that are explicitly listed?

Any pointers would be welcome!

Thanks,
Nick.

Nick Varley
Director, Customer Support
p +44 (0) 1823 226012 | m +44 (0) 7766 806780 nick.var...@syncsort.com

We organise data everywhere,
to keep the world working
Syncsort Limited
2 Tangier Central
Castle Street
Taunton
TA1 4AS
UK
www.syncsort.com--
ATTENTION: --
Syncsort Limited is a limited company registered in England and Wales. 
Registered number: 01373158. Registered office: 3rd Floor, The Pinnacle, 20 
Tudor Road, Reading, RG1 1NH. VAT: GB295525177 The information contained in 
this message (including any files transmitted with this message) may contain 
proprietary, trade secret or other confidential and/or legally privileged 
information. Any pricing information contained in this message or in any files 
transmitted with this message is always confidential and cannot be shared with 
any third parties without prior written approval from Syncsort. This message is 
intended to be read only by the individual or entity to whom it is addressed or 
by their designee. If the reader of this message is not the intended recipient, 
you are on notice that any use, disclosure, copying or distribution of this 
message, in any form, is strictly prohibited. If you have received this message 
in error, please immediately notify the sender and/or Syncsort and destroy all 
copies of this message in your possession, custody or control.

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

SMFPRMFxx SYS SUBSYS and EXITs question

[Nick Varley]

In an SMFPRMxx member if you have this:

...
SYS(NOTYPE(4,5,20,34,35,40)
EXITS(IEFU83,IEFU84,IEFU85,IEFACTRT,IEFUJV,IEFUSI,
   IEFUJP,IEFUSO,IEFUJI,IEFUTL))
SUBSYS(STC,EXITS(IEFUJP,IEFUSO))
...

then why would the IEFU83/84/85 exits not fire for SMF records coming from STCs?
Documentation seems to imply that the SYS settings are the default/back-stop 
for all things.

We needed to make the last line read like this to make it work:

...
 SUBSYS(STC,EXITS(IEFU83,IEFU84,IEFU85,IEFUJP,IEFUSO))
...

The question:
  Does the list of exits in the SUBSYS specification overwrite all those in 
SYS, that is, in this case, it reduces the list of exits from the ten in the 
SYS specification to just the two that are explicitly listed?

Any pointers would be welcome!

Thanks,
Nick.

Nick Varley
Director, Customer Support
p +44 (0) 1823 226012 | m +44 (0) 7766 806780
nick.var...@syncsort.com
  
We organise data everywhere,
to keep the world working
Syncsort Limited
2 Tangier Central
Castle Street
Taunton
TA1 4AS
UK
www.syncsort.com--
ATTENTION: --
Syncsort Limited is a limited company registered in England and Wales. 
Registered number: 01373158. Registered office: 3rd Floor, The Pinnacle, 20 
Tudor Road, Reading, RG1 1NH. VAT: GB295525177
The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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

[Jeremy Nicoll]

On Tue, 26 Nov 2019, at 00:20, 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 exec somewhere else runs control blocks, finds address of something
critical, builds & submits the JCL.

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