Re: REXX parse parens

2023-05-01 Thread Paul Gilmartin
On Mon, 1 May 2023 20:13:36 -0400, Phil Smith III  wrote:
>...
>parse var option keyword '(' value ')' +1 paren
>
ITYM:
 parse var option keyword '(' value ')' +0 paren +1 .
>
>if paren = ')' then /* It's nested! */
>...
>This can, of course, be made more iterative. It ain't that pretty, but it's 
>not too hard to do. I can even imagine a function that returns multiple nested 
>values, at least to the Rexx implementation limit (typically 250).
>
It's the curse of the TRT instruction.  It's a great hammer; performs great;
but everything has to look like a nail.  No good for recursive descent for
something such as:
trace I; say ((3+4)*5+6)*7

And I can't forgive that there's no way to escape the command separator, ";".
(That's largely bad layering in the design.  I will be told, "Just pick a 
character
you won't use!"  There is almost none such.  Sometimes I set it to "¾".
But it would be better to have it when I need it and quote it when I don't.

-- 
gil

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


Re: REXX parse parens

2023-05-01 Thread Seymour J Metz
PCRE is one option. There is also a package (XPARSE? XPROC?) that calls 
IKJPARSE.


From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Monday, May 1, 2023 7:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: REXX parse parens

The following is a simplified version of some code from IBM's CEEBLDTX, placed 
in to an EXEC I've named PARENS:

Parse Arg option
Parse Var option varOpt '(' valueOpt ')'
Say varOpt
Say valueOpt

This handles a simple dataset name, e.g.:

Test1:  PARENS COBOL(TEST):
Results1:
COBOL
TEST

But it doesn't work for a PDS member to following, also surrounded by 
parentheses:

Test2:  PARENS COBOL(TEST(MEMBER))
Results2:
COBOL
TEST(MEMBER

Any simple REXX parse option to handle this, or do I need to resort to more 
complex REXX?  Or do I just add a trailing paren if there is a leading one in 
valueOpt?  Perhaps that's the simples answer.

Frank


--
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: REXX parse parens

2023-05-01 Thread Phil Smith III
Frank Swarbrick wrote about trying to parse z/OS-style parameter lists, with 
nested parens, in Rexx.

This has been a challenge since Rexx leapt from VM (where its parsing fits the 
normal command syntax). In part, I'd say that IF you can make statements about 
how things MUST be specified, you can do OK. For example, is this valid:

Input: parens cobol(test)somethingelse(woof)
? If so, then it's harder. But I suspect that's not "normal" in z/OS-land, so 
if you say "Each entity must be space-delimited", then you can take something 
like:
Input: parens cobol(test(member)) somethingelse(woof)

And parse it:
arg args
do while args <> ''
parse var args option args
option = space(option, 0)
parse var option keyword '(' value ')' +1 paren
if paren = ')' then /* It's nested! */
...

This can, of course, be made more iterative. It ain't that pretty, but it's not 
too hard to do. I can even imagine a function that returns multiple nested 
values, at least to the Rexx implementation limit (typically 250).

Does this help?


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


Re: REXX parse parens

2023-05-01 Thread Paul Gilmartin
On Mon, 1 May 2023 23:30:51 +, Frank Swarbrick wrote:
>...
>But it doesn't work for a PDS member to following, also surrounded by 
>parentheses:
>
>Test2:  PARENS COBOL(TEST(MEMBER))
>Results2:
>COBOL
>TEST(MEMBER
>
>Any simple REXX parse option to handle this, or do I need to resort to more 
>complex REXX?  Or do I just add a trailing paren if there is a leading one in 
>valueOpt?  Perhaps that's the simples answer.
>
A tough one.  Can PCRE do this?  Does REXX support PCRE nowadays?  Maybe OoRexx?

In general, this is beyond regular expressions: a grammar allowing an arbitrary 
depth
of nested parentheses is not Chomsky Type 3; not recognizable by a finite state
machine.

Finite state machines can't count.

IIRC, SNOBOL4 has a BAL predicate for this.  It can probably handle parentheses
nested to any reasonable depth.

-- 
gil

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


REXX parse parens

2023-05-01 Thread Frank Swarbrick
The following is a simplified version of some code from IBM's CEEBLDTX, placed 
in to an EXEC I've named PARENS:

Parse Arg option
Parse Var option varOpt '(' valueOpt ')'
Say varOpt
Say valueOpt

This handles a simple dataset name, e.g.:

Test1:  PARENS COBOL(TEST):
Results1:
COBOL
TEST

But it doesn't work for a PDS member to following, also surrounded by 
parentheses:

Test2:  PARENS COBOL(TEST(MEMBER))
Results2:
COBOL
TEST(MEMBER

Any simple REXX parse option to handle this, or do I need to resort to more 
complex REXX?  Or do I just add a trailing paren if there is a leading one in 
valueOpt?  Perhaps that's the simples answer.

Frank


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


Re: XLC inline assembler question

2023-05-01 Thread Paul Gilmartin
On Mon, 1 May 2023 17:02:23 -0400, Phil Smith III wrote:
>(Cross-posted to IBM-MAIN and the assembler list)
>
>...; what isn't clear is whether there's any downside to it beyond the 
>unlikely case that you decide to have a function of your own named asm or 
>__asm or __asm__. Is there? 
> 
I believe the ANSI standard reserves names beginning with "__" for
the implementation.  However a FOSS provider whom I once scolded 
for using using such a name replied, "I *am* the implementation!"

-- 
gil

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


Re: XLC inline assembler question

2023-05-01 Thread Phil Smith III
Doh, I of course meant -qasm not -dasm. 

 

From: Phil Smith III  
Sent: Monday, May 1, 2023 5:02 PM
To: ibm-m...@bama.ua.edu; IBM Mainframe Assembler List 
(assembler-l...@listserv.uga.edu) 
Subject: XLC inline assembler question

 

(Cross-posted to IBM-MAIN and the assembler list)

When compiling C programs with XLC, you need to specify the -dasm flag to have 
inline assembler code recognized as such. I can see PoE arguments for requiring 
that option; what isn't clear is whether there's any downside to it beyond the 
unlikely case that you decide to have a function of your own named asm or __asm 
or __asm__. Is there? We'd rather just use it all the time, rather than trying 
to keep track of which modules have inline assembler and which don't, but not 
if it's going to cost significant performance at compile time or something.


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


Re: TLS - and HTTP download

2023-05-01 Thread Keith Gooding
Bill.

A AT-TLS rule consists of a number of tests and pointers to actions which are 
performed if all of the tests are true. One of the actions specifies if TLS is 
to be enabled or not.  You can test on  local and remote port numbers , local 
and remote IP addresses, connection direction (inbound or outbound) , local 
address space name etc. you may have a rule which says “if the remote port is 
443 (https ?) and direction is outbound then enable TLS”.  This would  enable 
TLS for an SMPE batch job connecting to an https server. To check you can 
either view the AT-TLS policy or,  to get a better formatted list, use the unix 
command “pasearch -t >  mylist.txt” and then view mylist.txt. See Comms Server 
IP diagnosis for details of pasearch and how to list a subset of the policy. If 
this is in fact the problem you  could add add another rule which says “if the 
remote IP address is the IBM https server then do not enable TLS“.

Keith
> On 1 May 2023, at 20:29, Michael Babcock  wrote:
> 
> Here's our simple DB2 Secure port definition in AT-TLS:
> 
> TTLSRule DBRTSecureServer# Secure DBRT
> {
>   LocalPortRange   4450# DBRT Secure Port
>   DirectionInbound # Inbound Only
>   Priority 1   # Lowest priority rule
>   TTLSGroupActionRef   grp_Production  # Uncomment once 
> debugging
>   TTLSEnvironmentActionRef DBRT_SecureServer_Action# DBRT Env Action
> }
> 
> TTLSEnvironmentAction DBRT_SecureServer_Action
> {
>   HandshakeRole   Server
>   TTLSKeyRingParmsRef DBRT_Keyring_Parms
>   TTLSCipherParmsRef  DB2_CipherParms
>   TTLSEnvironmentAdvancedParms
>   {
> ClientAuthTypePassThru
> SSLv2 Off
> SSLv3 Off
> TLSv1 Off
> TLSv1.1   Off
> TLSv1.2   On
>   }
> }
> 
> TTLSKeyRingParms  DBRT_Keyring_Parms
> {
>  Keyring  DBRT/DBRT.KEYRING
> }
>> 

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


XLC inline assembler question

2023-05-01 Thread Phil Smith III
(Cross-posted to IBM-MAIN and the assembler list)

When compiling C programs with XLC, you need to specify the -dasm flag to have 
inline assembler code recognized as such. I can see PoE arguments for requiring 
that option; what isn't clear is whether there's any downside to it beyond the 
unlikely case that you decide to have a function of your own named asm or __asm 
or __asm__. Is there? We'd rather just use it all the time, rather than trying 
to keep track of which modules have inline assembler and which don't, but not 
if it's going to cost significant performance at compile time or something.




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


Re: TLS - and HTTP download

2023-05-01 Thread Michael Babcock

Here's our simple DB2 Secure port definition in AT-TLS:

TTLSRule DBRTSecureServer    # Secure DBRT
{
  LocalPortRange   4450    # DBRT Secure Port
  Direction    Inbound     # Inbound Only
  Priority 1   # Lowest 
priority rule
  TTLSGroupActionRef   grp_Production  # Uncomment once 
debugging

  TTLSEnvironmentActionRef DBRT_SecureServer_Action    # DBRT Env Action
}

TTLSEnvironmentAction DBRT_SecureServer_Action
{
  HandshakeRole   Server
  TTLSKeyRingParmsRef DBRT_Keyring_Parms
  TTLSCipherParmsRef  DB2_CipherParms
  TTLSEnvironmentAdvancedParms
  {
    ClientAuthType    PassThru
    SSLv2 Off
    SSLv3 Off
    TLSv1 Off
    TLSv1.1   Off
    TLSv1.2   On
  }
}

TTLSKeyRingParms  DBRT_Keyring_Parms
{
 Keyring  DBRT/DBRT.KEYRING
}

On 5/1/2023 2:12 PM, Kurt J. Quackenbush wrote:

My understand is that ATTLS allows you to encrypt network traffic for 
clients/servers which do not implement TLS themselves.  It sounds like your Db2 
traffic was formerly not encrypted with TLS, but your ATTLS rule now encrypts 
that Db2 traffic without the client or server being any wiser.  Unfortunately 
that rule is also negatively affecting SMP/E and probably any other 
applications that use HTTPS.  SMP/E implements TLS itself, so it doesn't need 
ATTLS to do so on its behalf.

I am absolutely NOT an expert in defining ATTLS rules, but my guess is you need 
to define the rule more specifically to impact only the Db2 traffic and not all 
HTTPS traffic.  Hopefully some kind soul with may more experience in ATTLS can 
offer suggestions, sorry.

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.

--
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: TLS - and HTTP download

2023-05-01 Thread Kurt J. Quackenbush
My understand is that ATTLS allows you to encrypt network traffic for 
clients/servers which do not implement TLS themselves.  It sounds like your Db2 
traffic was formerly not encrypted with TLS, but your ATTLS rule now encrypts 
that Db2 traffic without the client or server being any wiser.  Unfortunately 
that rule is also negatively affecting SMP/E and probably any other 
applications that use HTTPS.  SMP/E implements TLS itself, so it doesn't need 
ATTLS to do so on its behalf.

I am absolutely NOT an expert in defining ATTLS rules, but my guess is you need 
to define the rule more specifically to impact only the Db2 traffic and not all 
HTTPS traffic.  Hopefully some kind soul with may more experience in ATTLS can 
offer suggestions, sorry.

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.

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


Re: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
Micro Focus.

But it appears I misread the Micro Focus COBOL documentation.

I already had a program that set the data set name dynamically. I thought there 
was syntax that would allow the "external" identifier (dd name) to be a data 
name, but that's not true.

So ironically, now I have an easy way to do what I want in z/OS COBOL but not 
in Micro Focus COBOL!


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Monday, May 1, 2023 12:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

Whose COBOL are you using on the PC side? If it is Fujitsu's, I
think SORT is built in. I'm not sure about the MicroFocus COBOL.
I don't have one of their systems.

Steve Thompson

On 5/1/2023 10:33 AM, Schmitt, Michael wrote:
> The data I'm trying to write is mixed up in an input file, so I don't know 
> which DDs I need to write to until I get there.
>
> I know that I could change the program to do an internal sort, but what I'm 
> trying to do is an *interim* solution for testing using the *PC* version of 
> the program, which *can* write to dynamic DD names.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Farley, Peter
> Sent: Friday, April 28, 2023 3:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL to dynamic DD name
>
> I don't think you can do that.  Unfortunately COBOL does not yet support 
> actual FILE-type variables.  COBOL files are essentially CONSTANTS in the 
> language definition.  I wish that we had PL/I's FILE variable capability, but 
> we don't.
>
> IMHO your best bet is to avoid multiple DD allocations entirely. Instead 
> start with a list of DSN's to be input (can be another separate input file) 
> and dynamically assign each DSN you wish to process to the "constant" COBOL 
> DD name in the ASSIGN clause, then FREE it (also using BPXWDYN) when you 
> finish processing each file and then start with the next DSN (if any left).
>
> You could also leave the DD names allocated as they already are and use an 
> assembler function to retrieve the JFCB (or BXWDYN) to get the DSN of each 
> assigned DD name and then use those to do a dynamic assign of each DSN to the 
> COBOL file DD name from the ASSIGN clause, but the you will have two DD names 
> assigned to the same file in the same step, which won't work unless DISP=SHR 
> for all of them.  And if any of them is a GDG (+1) from a prior step, you 
> have to mess around with getting the GDG suffix right in the dynamic allocate.
>
> I once tried to mess around with dynamically changing the DCB DD name field 
> of the closed COBOL file, but finding the DCB for a COBOL file is very 
> compiler-release dependent and is a reverse-engineering effort that can be 
> upset by IBM any time they decide to update COBOL implementation structures.  
> Messy and a maintenance nightmare, so I dropped that effort.
>
> HTH
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Schmitt, Michael
> Sent: Friday, April 28, 2023 3:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: COBOL to dynamic DD name
>
> I know how to have a COBOL program on z/OS use a data set name that isn't 
> determined until runtime, via an environment variable. My question is can you 
> use one file (i.e. one select/assign and one FD) to write to different DD 
> names, that were already allocated in the JCL?
>
> I can't find a way, and in the manual the syntax for the environment variable 
> method requires a DSN or PATH, no option for a DD name.
> --
>
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
>
> --
> 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

--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

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

Re: COBOL to dynamic DD name

2023-05-01 Thread Steve Thompson
Whose COBOL are you using on the PC side? If it is Fujitsu's, I 
think SORT is built in. I'm not sure about the MicroFocus COBOL. 
I don't have one of their systems.


Steve Thompson

On 5/1/2023 10:33 AM, Schmitt, Michael wrote:

The data I'm trying to write is mixed up in an input file, so I don't know 
which DDs I need to write to until I get there.

I know that I could change the program to do an internal sort, but what I'm 
trying to do is an *interim* solution for testing using the *PC* version of the 
program, which *can* write to dynamic DD names.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Friday, April 28, 2023 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

I don't think you can do that.  Unfortunately COBOL does not yet support actual 
FILE-type variables.  COBOL files are essentially CONSTANTS in the language 
definition.  I wish that we had PL/I's FILE variable capability, but we don't.

IMHO your best bet is to avoid multiple DD allocations entirely. Instead start with a 
list of DSN's to be input (can be another separate input file) and dynamically assign 
each DSN you wish to process to the "constant" COBOL DD name in the ASSIGN 
clause, then FREE it (also using BPXWDYN) when you finish processing each file and then 
start with the next DSN (if any left).

You could also leave the DD names allocated as they already are and use an 
assembler function to retrieve the JFCB (or BXWDYN) to get the DSN of each 
assigned DD name and then use those to do a dynamic assign of each DSN to the 
COBOL file DD name from the ASSIGN clause, but the you will have two DD names 
assigned to the same file in the same step, which won't work unless DISP=SHR 
for all of them.  And if any of them is a GDG (+1) from a prior step, you have 
to mess around with getting the GDG suffix right in the dynamic allocate.

I once tried to mess around with dynamically changing the DCB DD name field of 
the closed COBOL file, but finding the DCB for a COBOL file is very 
compiler-release dependent and is a reverse-engineering effort that can be 
upset by IBM any time they decide to update COBOL implementation structures.  
Messy and a maintenance nightmare, so I dropped that effort.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Friday, April 28, 2023 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL to dynamic DD name

I know how to have a COBOL program on z/OS use a data set name that isn't 
determined until runtime, via an environment variable. My question is can you 
use one file (i.e. one select/assign and one FD) to write to different DD 
names, that were already allocated in the JCL?

I can't find a way, and in the manual the syntax for the environment variable 
method requires a DSN or PATH, no option for a DD name.
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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


--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

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


Re: TLS - and HTTP download

2023-05-01 Thread Keith Gooding
Do you mean that you have an ATTLS rule which ‘converts’ your SMP/E job to an 
SSL client ?. Ie ATTLS acts as an SSL proxy, converting the data stream into 
and out of your SMP/E step to SSL ? But SMP/E implements SS itself so you must 
not convert that to SL using an AT-TLS rule. 

> On 1 May 2023, at 17:53, Bill Giannelli  wrote:
> 
> I am confused myself!
> we originally "reconfigured" TLS to provide for encrypted data transfer for 
> Db2 thru secured ports.
> part of that work (I do not know why) was specifying a rule for HTTPS.
> Now the only way we can download on this LPAR is when the HTTPS - TLS rule is 
> disabled.
> Does that make sense?
> thanks
> Bill  
>> On Mon, 1 May 2023 15:03:47 +, Kurt J. Quackenbush  
>> wrote:
>> 
>> I'm confused by your question.  Can you be more specific what you mean by 
>> "we have locked down HTTPS via TLS"?  Are you not allowing any HTTPS traffic 
>> at all?  That feels extreme.
>> 
>> Kurt Quackenbush
>> IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com
>> 
>> Chuck Norris never uses CHECK when he applies PTFs.
>> 
>> --
>> 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: TLS - and HTTP download

2023-05-01 Thread Bill Giannelli
I am confused myself!
we originally "reconfigured" TLS to provide for encrypted data transfer for Db2 
thru secured ports.
part of that work (I do not know why) was specifying a rule for HTTPS.
Now the only way we can download on this LPAR is when the HTTPS - TLS rule is 
disabled.
Does that make sense?
thanks
Bill  
On Mon, 1 May 2023 15:03:47 +, Kurt J. Quackenbush  wrote:

>I'm confused by your question.  Can you be more specific what you mean by "we 
>have locked down HTTPS via TLS"?  Are you not allowing any HTTPS traffic at 
>all?  That feels extreme.
>
>Kurt Quackenbush
>IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com
>
>Chuck Norris never uses CHECK when he applies PTFs.
>
>--
>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: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
This works, and is the winning solution!


All that is needed is to add a nested program:

identification division.
program-id. set_dd_name.

data division.
linkage section.
01  dcb-i.
05  fillerpic x(40).
05  dd-name-dcb-i pic x(8).

01  dd-name-i pic x(8).

procedure division using dcb-i
 dd-name-i.

move dd-name-i   to dd-name-dcb-i.
goback.

end program set_dd_name.


In the parent program the select/assign is to a dummy dd name:

select output-file assign to DUMMYDD

To use, while the file is closed, call set_dd_name with the file name (e.g. 
output-file) and the desired dd name.





-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Monday, May 1, 2023 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

That's an interesting idea: add a nested program, call it passing the file-name 
(so it passes the FD), and then within the nested program find the offset of 
the ddname in the passed data and change it.

But it assumes that when you then open the file, COBOL doesn't move the 
select/assign dd name to the DCB again.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Hardee
Sent: Friday, April 28, 2023 3:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

*I have not tried this*, but could you use SET FILE-VAR TO ADDRESS OF
FILE-NAME?
Does that make FILE-VAR point to the DCB?
If so, then, with the file closed, move in your DD name, open, write, close.
Rinse and repeat.

Like I said, I don't know if this will work, but it's worth a try.

Chuck


On Fri, Apr 28, 2023 at 2:38 PM Schmitt, Michael 
wrote:

> I know how to have a COBOL program on z/OS use a data set name that isn't
> determined until runtime, via an environment variable. My question is can
> you use one file (i.e. one select/assign and one FD) to write to different
> DD names, that were already allocated in the JCL?
>
> I can't find a way, and in the manual the syntax for the environment
> variable method requires a DSN or PATH, no option for a DD name.
>
> --
> 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: Unlike data sets concatenation - revised 3

2023-05-01 Thread Michael Stein
On Mon, May 01, 2023 at 08:26:42AM -0500, Pierre Fichaud wrote:
> I have provided the DCB in source and dumped it just before the OPEN.

> .  000183 INFILE   DCB   DDNAME=INFILE,   
>*00164000 .
>  .  000184DSORG=PS,   
> *00165000 .
>  .  000185EODAD=0,
> *00166000 .
>  .  000186MACRF=GL
>  00167000 .

>From previous emails it's known that the EODAD routine was getting
control so somewhere the DCB EODAD field must be being set as EODAD=0
isn't going to work...

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


Re: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
To all the repliers, thanks for your ideas.

I think the answer is that there's no *simple* way to do what I asked in COBOL. 
Most replies were to suggest other ways to do it, but they were not what I 
wanted.*

I've run a test of reading a file where the DD name is determined at runtime. 
This works:

1. The select/assign is to a dummy DD name.

2. The program does a DYNALLOC call to determine the DSN for the actual target 
DD name, i.e. it is finding how it was allocated in the JCL.

   I'm using a different DYNALLOC interface than BPXWDYN but the concept is the 
same.

3. The program uses the environment variable trick to assign the DSN determined 
in step #2 to the dummy DD name.

4. Open and read.

I think this will work for writing with a disp of MOD.


* the key here is I'm trying to do in z/OS what I can easily do in not-ZOS. So 
I don't want a different language, or 100 files in the program, or assembler 
assists, etc.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Friday, April 28, 2023 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL to dynamic DD name

I know how to have a COBOL program on z/OS use a data set name that isn't 
determined until runtime, via an environment variable. My question is can you 
use one file (i.e. one select/assign and one FD) to write to different DD 
names, that were already allocated in the JCL?

I can't find a way, and in the manual the syntax for the environment variable 
method requires a DSN or PATH, no option for a DD name.

--
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: COBOL to dynamic DD name

2023-05-01 Thread Sri h Kolusu
>> SORT would be tricky to only write the header record once per file, and to 
>> resequence the records.

Michael,

Not really. There are ways to get around it.  Here is a sample job of writing 
to 2 files. You can expand that to “n” number of files.

//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD *
FILE-HEADER-01
  DATA REC01
  DATA REC02
  DATA REC04
  DATA REC05
  DATA REC06
FILE-HEADER-02
  DATA REC01
  DATA REC02
  DATA REC03
FILE-HEADER-01
  DATA REC07
  DATA REC08
  DATA REC09
//OUT01DD SYSOUT=*
//OUT02DD SYSOUT=*
//SYSINDD *
  OPTION COPY
  INREC IFTHEN=(WHEN=GROUP,
   BEGIN=(01,11,CH,EQ,C'FILE-HEADER'),
PUSH=(81:13,02,01,80)),
IFTHEN=(WHEN=(01,11,CH,EQ,C'FILE-HEADER'),
 OVERLAY=(81:82X))

  OUTFIL FNAMES=OUT01,REMOVECC,
  INCLUDE=(81,02,CH,EQ,C'01'),
  BUILD=(01,80),
  HEADER1=(83,80)

  OUTFIL FNAMES=OUT02,REMOVECC,
  INCLUDE=(81,02,CH,EQ,C'02'),
  BUILD=(01,80),
  HEADER1=(83,80)
/*


OUT01 file will have the following data.

FILE-HEADER-01
  DATA REC01
  DATA REC02
  DATA REC04
  DATA REC05
  DATA REC06
  DATA REC07
  DATA REC08
  DATA REC09

OUT02 file will have the following data.

FILE-HEADER-02
  DATA REC01
  DATA REC02
  DATA REC03


Thanks,
Kolusu
DFSORT Development
IBM Corporation



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


Re: TLS - and HTTP download

2023-05-01 Thread Kurt J. Quackenbush
I'm confused by your question.  Can you be more specific what you mean by "we 
have locked down HTTPS via TLS"?  Are you not allowing any HTTPS traffic at 
all?  That feels extreme.

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.

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


Re: COBOL to dynamic DD name

2023-05-01 Thread Sri h Kolusu
>> The data I'm trying to write is mixed up in an input file, so I don't know 
>> which DDs I need to write to until I get there.

You Code for ALL the ddnames possible and open them and write to them based on 
the file indicator.

>> I know that I could change the program to do an internal sort, but what I'm 
>> trying to do is an *interim* solution for testing using the *PC* version of 
>> the program, which *can* write to dynamic DD names.

Not sure as to why you need to sort, but you don't have to.

Assuming  the data looks like this

file-header-01
  data rec-01
  data rec02
  data rec03
...
file-header-02
  data rec-01
  data rec02
  data rec03
...

again file-header-01
file-header-01
  data rec-01
  data rec02
  data rec03
...


If that is the case, you just read the header and write it that file if it is a 
data record and as soon as you hit the next header record you switch to writing 
to the new file.  If the header record is not needed you turn on a switch to 
say s-hdr-record-written = 'y' and you check to write the next time you 
encounter the header that you have already written to

Thanks,
Kolusu


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


Re: Unlike data sets concatenation - revised 3

2023-05-01 Thread Michael Stein
On Mon, May 01, 2023 at 08:26:42AM -0500, Pierre Fichaud wrote:
> I have provided the DCB in source and dumped it just before the OPEN.

> 1st data set in the concatenation :

>   The JCL has just the DSN and DISP.
>  .
> 
> .  000183 INFILE   DCB   DDNAME=INFILE,   
>*00164000 .
>  .  000184DSORG=PS,   
> *00165000 .
>  .  000185EODAD=0,
> *00166000 .
>  .  000186MACRF=GL
>  00167000 .

>  DCB before open
>  000224D8    
 0001 4000 0001
*... ..  *
>  000224F8 00010580 5000 C6C9D3C5 C1404040
0A004800 0001 00018240 03E8 <-- 03E8
*.   &...FILEA.  . b .. Y*
>  00022518  0001 0001 0001
00C8 -> 00C8 0001  0001
*... ... ... ...H... ... *

Which has BLKSIZE 1000 (x'03E8') and LRECL 200 (x'00C8') already set.

If they aren't set at assembly time who's setting them before open?

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


Re: COBOL to dynamic DD name

2023-05-01 Thread Jon Butler
SELECT specifies the COBOL FILE name to be ASSIGNED to a DDNAME.  The FILE name 
is then used in an FD to nominate the I/O area(s).  

There is no dynamic SELECT that I am aware of.  You have to use some form of 
SVC99.  BPXWDYN can be used for this purpose.

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


Re: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
SORT would be tricky to only write the header record once per file, and to 
resequence the records.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Friday, April 28, 2023 10:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

I've  seen several uses of sort to split a file into multiple output files.

On Fri, Apr 28, 2023 at 2:38 PM Schmitt, Michael
 wrote:
>
> I know how to have a COBOL program on z/OS use a data set name that isn't 
> determined until runtime, via an environment variable. My question is can you 
> use one file (i.e. one select/assign and one FD) to write to different DD 
> names, that were already allocated in the JCL?
>
> I can't find a way, and in the manual the syntax for the environment variable 
> method requires a DSN or PATH, no option for a DD name.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
Requirement is for COBOL; that's what the end-state program will be.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Andrew Rowley
Sent: Friday, April 28, 2023 8:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

On 29/04/2023 6:29 am, Schmitt, Michael wrote:
> I have an input file that contains thousands of records. They are in groups: 
> header record, then a bunch of segments all for one database name, then 
> another header, records for another database. But the same database can 
> appear more than once in the input.

Have you considered Java?

This is untested, and I don't know File Manager so I'm not 100% sure of
the logic or even the field definitions, but it should give you the
idea. Run under JZOS Batch Launcher so JCL DDs are available.

A complete Java program:

import java.io.*;
import java.util.*;
import com.ibm.jzos.*;
import com.ibm.jzos.fields.*;
import com.ibm.jzos.fields.daa.*;

public class App
{
 public static void main(String[] args) throws IOException
 {
 BinaryUnsignedIntField keyField = new BinaryUnsignedIntField(0, 2);
 BinaryUnsignedIntField countField = new
BinaryUnsignedIntField(4, 4);
 StringField ddField = new StringField(8, 8);

 byte[] nextHeader = null;

 Map outEntries = new HashMap<>();
 RecordReader in = null;
 try
 {
 in = RecordReader.newReaderForDD("INPUT");
 int bytesRead = 0;
 byte[] record = new byte[in.getLrecl()];
 while ((bytesRead = in.read(record)) >= 0)
 {
 if (keyField.getInt(record) == 0)
 {
 nextHeader = Arrays.copyOfRange(record, 0, bytesRead);
 }
 else
 {
 String ddname = ddField.getString(record);
 OutEntry out = outEntries.get(ddname);
 if (out == null)
 {
 out = new OutEntry(ddname);
 outEntries.put(ddname, out);
 out.writer.write(nextHeader);
 }
 out.count++;
 countField.putInt(out.count, record);
 out.writer.write(record, 0, bytesRead);
 }
 }
 }
 finally
 {
 if (in != null)
 in.close();
 for (OutEntry entry : outEntries.values())
 {
 entry.writer.close();
 }
 }
 }

 private static class OutEntry
 {
 OutEntry(String ddname) throws IOException
 {
 writer = RecordWriter.newWriterForDD(ddname);
 }
 int count = 0;
 RecordWriter writer;
 }
}

--
Andrew Rowley
Black Hill Software

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




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


Re: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
Requirement is for COBOL.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, April 28, 2023 5:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

How many different files does he have? An equivalent to the PL/I FILE keyword 
would be more flexible than hard-wiring the ddnames at compile time.


From: IBM Mainframe Discussion List  on behalf of Sri 
h Kolusu 
Sent: Friday, April 28, 2023 4:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

>> The OP isn't trying to retrieve the information; he's trying to open a file 
>> using a dynamic ddname. Put another way, he wants to open the same DCB 
>> multiple times, with a different DCBDDNAM each time.

SeyMour

>From the limited information that OP provided, IMHO he was planning on having 
>multiple open and close of files.  However, he doesn't really need to do that. 
>He can open all the files and then have the logic to write to specific file

Sample pseudo code

OPEN INPUT   file-input
 OUTPUT  fileout1
 fileout2
 fileout3
 fileout4
 ..
 fileoutn

MAIN-LOGIC


EVALUATE TRUE
WHEN WS-FILE-IND = 'f01'
 PERFORM WRITE-TO-FILE01
 PERFORM READ-INPUT-FILE
WHEN WS-FILE-IND = 'f02'
 PERFORM WRITE-TO-FILE02
 PERFORM READ-INPUT-FILE
WHEN WS-FILE-IND = 'f03'
 PERFORM WRITE-TO-FILE03
 PERFORM READ-INPUT-FILE
n... files
END-EVALUATE


CLOSE  file-input
   fileout1
   ..


Thanks,
Kolusu
DFSORT Development
IBM Corporation


--
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: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
I'm trying to avoid that because the end-state program won't be doing that, if 
I'm not in z/OS COBOL I can just have one file and dynamically switch the DD 
name.

At least I think I can; I haven't tested that exact syntax yet.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu
Sent: Friday, April 28, 2023 4:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

>> The OP isn't trying to retrieve the information; he's trying to open a file 
>> using a dynamic ddname. Put another way, he wants to open the same DCB 
>> multiple times, with a different DCBDDNAM each time.

SeyMour

>From the limited information that OP provided, IMHO he was planning on having 
>multiple open and close of files.  However, he doesn't really need to do that. 
>He can open all the files and then have the logic to write to specific file

Sample pseudo code

OPEN INPUT   file-input
 OUTPUT  fileout1
 fileout2
 fileout3
 fileout4
 ..
 fileoutn

MAIN-LOGIC


EVALUATE TRUE
WHEN WS-FILE-IND = 'f01'
 PERFORM WRITE-TO-FILE01
 PERFORM READ-INPUT-FILE
WHEN WS-FILE-IND = 'f02'
 PERFORM WRITE-TO-FILE02
 PERFORM READ-INPUT-FILE
WHEN WS-FILE-IND = 'f03'
 PERFORM WRITE-TO-FILE03
 PERFORM READ-INPUT-FILE
n... files
END-EVALUATE


CLOSE  file-input
   fileout1
   ..


Thanks,
Kolusu
DFSORT Development
IBM Corporation


--
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: Unlike data sets concatenation - revised 3

2023-05-01 Thread Hobart Spitz
I don't see a question, so I'm responding to what I think you want.

It has long been true that BUFSIZE defaults to the largest
available BLKSIZE  The requirement was written in the 1980s.  (It might
depend on your access method.)  So, I very much doubt the the BLISIZE
difference is the problem.

There is no equivalent default for LRECL, so I'm guessing that the first
LRECL being smaller than the second is your problem.  This is a long shot,
but it might work if you code LRECL=230 on the first DD.

Sorry I don't have anything better.


OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Mon, May 1, 2023 at 8:27 AM Pierre Fichaud  wrote:

> I have provided the DCB in source and dumped it just before the OPEN.
>
> 1st data set in the concatenation :
>
>  Data Set Name . . . . : PIERRE.VB200.
>  .
>   .
>  .  General Data   Current
> Allocation   .
>  .   Management class . . : **None**
> Allocated cylinders : 1 .
>  .   Storage class  . . . : **None**
> Allocated extents . : 1 .
>  .Volume serial . . . : DISK01
>   .
>  .Device type . . . . : 3390
>   .
>  .   Data class . . . . . : **None**
>   .
>  .Organization  . . . : PS Current
> Utilization  .
>  .Record format . . . : VB  Used
> cylinders  . . : 1 .
>  .Record length . . . : 200 Used
> extents  . . . : 1 .
>  .Block size  . . . . : 1000
>   .
>  .1st extent cylinders: 1
>  .
>  .Secondary cylinders : 1  Dates
>   .
>  .Data set name type  :
>  Creation date . . . : 2023/04/20.
>  .Data set encryption : NO
> Referenced date . . : 2023/05/01.
>  .
> Expiration date . . : ***None***.
>  .
>   .
>  .SMS Compressible  . : NO
>
> 2nd dataset :
>
>.  Data Set Name . . . . : PIERRE.VB230
> .
>  .
>   .
>  .  General Data   Current
> Allocation   .
>  .   Management class . . : **None**
> Allocated cylinders : 1 .
>  .   Storage class  . . . : **None**
> Allocated extents . : 1 .
>  .Volume serial . . . : DISK01
>   .
>  .Device type . . . . : 3390
>   .
>  .   Data class . . . . . : **None**
>   .
>  .Organization  . . . : PS Current
> Utilization  .
>  .Record format . . . : VB  Used
> cylinders  . . : 1 .
>  .Record length . . . : 230 Used
> extents  . . . : 1 .
>  .Block size  . . . . : 1150
>   .
>  .1st extent cylinders: 1
>  .
>  .Secondary cylinders : 1  Dates
>   .
>  .Data set name type  :
>  Creation date . . . : 2023/04/20.
>  .Data set encryption : NO
> Referenced date . . : 2023/05/01.
>  .
> Expiration date . . : ***None***.
>  .
>
>  .SMS Compressible  . : NO
>
>
>   The JCL has just the DSN and DISP.
>  .
>
> .  000183 INFILE   DCB   DDNAME=INFILE,
>   *00164000 .
>  .  000184DSORG=PS,
>   

Re: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
That's an interesting idea: add a nested program, call it passing the file-name 
(so it passes the FD), and then within the nested program find the offset of 
the ddname in the passed data and change it.

But it assumes that when you then open the file, COBOL doesn't move the 
select/assign dd name to the DCB again.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Hardee
Sent: Friday, April 28, 2023 3:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

*I have not tried this*, but could you use SET FILE-VAR TO ADDRESS OF
FILE-NAME?
Does that make FILE-VAR point to the DCB?
If so, then, with the file closed, move in your DD name, open, write, close.
Rinse and repeat.

Like I said, I don't know if this will work, but it's worth a try.

Chuck


On Fri, Apr 28, 2023 at 2:38 PM Schmitt, Michael 
wrote:

> I know how to have a COBOL program on z/OS use a data set name that isn't
> determined until runtime, via an environment variable. My question is can
> you use one file (i.e. one select/assign and one FD) to write to different
> DD names, that were already allocated in the JCL?
>
> I can't find a way, and in the manual the syntax for the environment
> variable method requires a DSN or PATH, no option for a DD name.
>
> --
> 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: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
Yeah, the File Manager solution is slick, but the end state won't be running on 
z/OS.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu
Sent: Friday, April 28, 2023 3:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

>> Now we're trying to replace the File Manager step. If it was possible to do 
>> this in z/OS COBOL we could use it, but it isn't worth a large effort 
>> because it would be an interim solution anyway.

Michael,

Not sure as to why you want to replace file manager step with a COBOL program, 
but DFSORT can easily be used to fulfil the requirement. Let me know the DCB 
properties(LRECL, RECFM) of the input file and I can show you way to split the 
records into multiple files.

Thanks,
Kolusu
DFSORT Development
IBM Corporation


--
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: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
I don't have a license for the PL/I compiler, and...

The ends state will be a program that runs on my PC, where it doesn't have the 
same limitation as z/OS COBOL. What I'm trying to do now is test that program 
logic in z/OS. So, I need it to be COBOL.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, April 28, 2023 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

Is PL/I an option at your shop?


From: IBM Mainframe Discussion List  on behalf of 
Schmitt, Michael 
Sent: Friday, April 28, 2023 4:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

I have an input file that contains thousands of records. They are in groups: 
header record, then a bunch of segments all for one database name, then another 
header, records for another database. But the same database can appear more 
than once in the input.

The step takes this input and creates one output file per database, with one 
header. And resequences the records so they go 1,2,3,4, for each output DD.

On z/OS this step is done using File Manager, with this code:

if fld(1,2,B) = 0 then do   /* if sort key is 0 then  */
   header_rec = inrec   /*save the header record  */
   return 'drop'/*get next record */
   end

dd_name = overlay('N', fld(9,8), 4) /* get DD name from DBD name  */

if recsout(dd_name) = 0 then do /* if 1st record for database */
   outrec.dd_name = header_rec
   write(dd_name)   /*write the header*/
   drop outrec.dd_name
   end

ovly_out(recsout(dd_name), 5,4,B)   /* resequence the records */
write(dd_name)  /* write the segment record   */
return 'drop'


That's the ENTIRE program!


On my PC I have a COBOL program, with a lot more logic, that does essentially 
the same thing. As it is reading the input, each time it gets to a different 
database name, it closes the file it has been writing to and opens the file for 
the appropriate DD name, extending it. So the program only needs to have one 
output file defined, even though it is writing to different DDs as it goes.


Now we're trying to replace the File Manager step. If it was possible to do 
this in z/OS COBOL we could use it, but it isn't worth a large effort because 
it would be an interim solution anyway.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Friday, April 28, 2023 3:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

I don't know any Cobol syntax that would change the DDNAME in a DCB, but you 
could call an assembler routine to change the DDNAME before OPEN. Why would you 
want to do that?

I'm a bit baffled. In z/OS and its ancestors, the data set name isn't 
determined until runtime, via JCL.

Perhaps if you describe the problem you are trying to solve.

--
Tom Marchant

On Fri, 28 Apr 2023 19:37:39 +, Schmitt, Michael  
wrote:

>I know how to have a COBOL program on z/OS use a data set name that isn't 
>determined until runtime, via an environment variable. My question is can you 
>use one file (i.e. one select/assign and one FD) to write to different DD 
>names, that were already allocated in the JCL?
>
>I can't find a way, and in the manual the syntax for the environment variable 
>method requires a DSN or PATH, no option for a DD name.

--
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: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
All are VB

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu
Sent: Friday, April 28, 2023 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

>> So use it to retrieve the data set name that is allocated in the JCL to the 
>> DD, then use the environment variable method to write to that same data set 
>> name? Hmmm.

Michael,

Not really,  once you get the Dataset name, you can open it in EXTENDED mode 
and write the output.  However, you are still limited by the LRECL and RECFM of 
the ddname.   Since you are splitting the records, I guess all of them have the 
same length

Thanks,
Kolusu
DFSORT Development
IBM Corporation

--
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: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
The data I'm trying to write is mixed up in an input file, so I don't know 
which DDs I need to write to until I get there.

I know that I could change the program to do an internal sort, but what I'm 
trying to do is an *interim* solution for testing using the *PC* version of the 
program, which *can* write to dynamic DD names.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Friday, April 28, 2023 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

I don't think you can do that.  Unfortunately COBOL does not yet support actual 
FILE-type variables.  COBOL files are essentially CONSTANTS in the language 
definition.  I wish that we had PL/I's FILE variable capability, but we don't.

IMHO your best bet is to avoid multiple DD allocations entirely. Instead start 
with a list of DSN's to be input (can be another separate input file) and 
dynamically assign each DSN you wish to process to the "constant" COBOL DD name 
in the ASSIGN clause, then FREE it (also using BPXWDYN) when you finish 
processing each file and then start with the next DSN (if any left).

You could also leave the DD names allocated as they already are and use an 
assembler function to retrieve the JFCB (or BXWDYN) to get the DSN of each 
assigned DD name and then use those to do a dynamic assign of each DSN to the 
COBOL file DD name from the ASSIGN clause, but the you will have two DD names 
assigned to the same file in the same step, which won't work unless DISP=SHR 
for all of them.  And if any of them is a GDG (+1) from a prior step, you have 
to mess around with getting the GDG suffix right in the dynamic allocate.

I once tried to mess around with dynamically changing the DCB DD name field of 
the closed COBOL file, but finding the DCB for a COBOL file is very 
compiler-release dependent and is a reverse-engineering effort that can be 
upset by IBM any time they decide to update COBOL implementation structures.  
Messy and a maintenance nightmare, so I dropped that effort.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Friday, April 28, 2023 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL to dynamic DD name

I know how to have a COBOL program on z/OS use a data set name that isn't 
determined until runtime, via an environment variable. My question is can you 
use one file (i.e. one select/assign and one FD) to write to different DD 
names, that were already allocated in the JCL?

I can't find a way, and in the manual the syntax for the environment variable 
method requires a DSN or PATH, no option for a DD name.
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
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: COBOL to dynamic DD name

2023-05-01 Thread Schmitt, Michael
The goal is to OPEN the DD name that is already allocated in the JCL, but with 
one select/assign and FD, in COBOL.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Friday, April 28, 2023 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

On Fri, 28 Apr 2023 19:37:39 +, Schmitt, Michael wrote:

>I know how to have a COBOL program on z/OS use a data set name that isn't 
>determined until runtime, via an environment variable. My question is can you 
>use one file (i.e. one select/assign and one FD) to write to different DD 
>names, that were already allocated in the JCL?
>
>I can't find a way, and in the manual the syntax for the environment variable 
>method requires a DSN or PATH, no option for a DD name.
>
Do you know the DSN or PATH?

Do you want to specify the DD name or let Dynalloc choose one?

Do BPXWDYN keys RTDDN and INFO help you?  BPXWDYN can be called with OS 
standard linkage.


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


TLS - and HTTP download

2023-05-01 Thread Bill Giannelli
we download IBM software maintenance via HTTPS.
Now, we have locked down HTTPS via TLS.
This prevents us from downloading.
One detail, we are going thru a proxy server.
How do we need to configure so we can still download using HTTPS with TLS 
locking it down?
thanks
Bill

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


Re: cyberark efforts

2023-05-01 Thread Bill Giannelli
Hi Bruce,
Thanks so much for your response!
Are the cyberark ids literally the same as the racf ids? 
Our cyberark team wants us to use separate group of "generic" cyberark ids 
different from our original RACF ids.
So one day you might "check out" cyberark id 123, another day you might "check 
out" cyberark id "abc".
thanks
Bill
On Sun, 30 Apr 2023 22:47:27 -0500, Bruce Hewson  
wrote:

>Hello Bill,
>
>CyberArk can do RACF and Top Secret USER administration,. at least for 
>PASSWORD change, and REVOKE/RELEASE processing.
>
>CyverArk will connect to Z/OS via ssh.  Certificates are used for the ssh 
>connection validation. The USER used by CybertArk must have suitable 
>administrative permissions to issue commands.
>
>For RACF systems, CyberArk can run a shell script to issue the ALTUSER 
>command. Pay attention to how the command string is quoted, as "$" can be used 
>in USERID and PASSWORD values, and shell processing could treat it as a 
>variable.
>
>Been using it for some years now.
>
>Regards
>Bruce Hewson
>
>
>On Mon, 24 Apr 2023 11:15:27 -0500, Bill Giannelli  
>wrote:
>
>>our company is pushing forward with cyberark for all platforms.
>>the statement was made that cyberark and the like are becoming the industry 
>>standard.
>>Is that true for z/OS systems?
>>thanks
>>Bill
>
>--
>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: COBOL to dynamic DD name

2023-05-01 Thread Jon Butler
As suggested, simply define four output files, open them, and then write to 
them based on the data in the input file record, perhaps using an EVALUATE 
statement.  Opening them all at the start of your program has another 
advantage: if you open only one output at a time and loop between them, it's 
possible that another job could open your target file when you have it closed 
and you will not be able to get ahold to write to it.

If you really must have only one output file open at a time, you can 
dynamically allocate and deallocate the DDNAME amongst multiple DSNs with 
BPXWDYN; ostensibly an OMVS routine designed for use with REXX, but I have used 
it with COBOL as well.  

call BPXWDYN using "alloc fi(ddanme) da(my.dataset.name) old" *> change the 
DISP as required

call BPXWDYN using "free fi(ddanme)"

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


Unlike data sets concatenation - revised 3

2023-05-01 Thread Pierre Fichaud
I have provided the DCB in source and dumped it just before the OPEN.

1st data set in the concatenation :

 Data Set Name . . . . : PIERRE.VB200.
 .  
.
 .  General Data   Current 
Allocation   .
 .   Management class . . : **None**Allocated 
cylinders : 1 .
 .   Storage class  . . . : **None**Allocated 
extents . : 1 .
 .Volume serial . . . : DISK01  
.
 .Device type . . . . : 3390
.
 .   Data class . . . . . : **None**
.
 .Organization  . . . : PS Current 
Utilization  .
 .Record format . . . : VB  Used 
cylinders  . . : 1 .
 .Record length . . . : 200 Used 
extents  . . . : 1 .
 .Block size  . . . . : 1000
.
 .1st extent cylinders: 1   
.
 .Secondary cylinders : 1  Dates
.
 .Data set name type  : Creation 
date . . . : 2023/04/20.
 .Data set encryption : NO  Referenced 
date . . : 2023/05/01.
 .  Expiration 
date . . : ***None***.
 .  
.
 .SMS Compressible  . : NO 

2nd dataset :

   .  Data Set Name . . . . : PIERRE.VB230  
  .
 .  
.
 .  General Data   Current 
Allocation   .
 .   Management class . . : **None**Allocated 
cylinders : 1 .
 .   Storage class  . . . : **None**Allocated 
extents . : 1 .
 .Volume serial . . . : DISK01  
.
 .Device type . . . . : 3390
.
 .   Data class . . . . . : **None**
.
 .Organization  . . . : PS Current 
Utilization  .
 .Record format . . . : VB  Used 
cylinders  . . : 1 .
 .Record length . . . : 230 Used 
extents  . . . : 1 .
 .Block size  . . . . : 1150
.
 .1st extent cylinders: 1   
.
 .Secondary cylinders : 1  Dates
.
 .Data set name type  : Creation 
date . . . : 2023/04/20.
 .Data set encryption : NO  Referenced 
date . . : 2023/05/01.
 .  Expiration 
date . . : ***None***.
 .  
 
 .SMS Compressible  . : NO 


  The JCL has just the DSN and DISP.
 .

.  000183 INFILE   DCB   DDNAME=INFILE, 
 *00164000 .
 .  000184DSORG=PS, 
  *00165000 .
 .  000185EODAD=0,  
  *00166000 .
 .  000186MACRF=GL  
   00167000 .


 DCB before open
 000224D8       0001 
4000 0001  *... ..  *
 000224F8  00010580 5000 C6C9D3C5 C1404040 0A004800 0001 
00018240 03E8  *.   &...FILEA.  . b .. Y*
 

Re: COBOL to dynamic DD name

2023-05-01 Thread Allan Staller
Classification: Confidential

Same answer as my previous post. Open/close/read/write as needed.
Nothing here need to be dynamic.

Am I missing something?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Friday, April 28, 2023 3:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I have an input file that contains thousands of records. They are in groups: 
header record, then a bunch of segments all for one database name, then another 
header, records for another database. But the same database can appear more 
than once in the input.

The step takes this input and creates one output file per database, with one 
header. And resequences the records so they go 1,2,3,4, for each output DD.

On z/OS this step is done using File Manager, with this code:

if fld(1,2,B) = 0 then do   /* if sort key is 0 then  */
   header_rec = inrec   /*save the header record  */
   return 'drop'/*get next record */
   end

dd_name = overlay('N', fld(9,8), 4) /* get DD name from DBD name  */

if recsout(dd_name) = 0 then do /* if 1st record for database */
   outrec.dd_name = header_rec
   write(dd_name)   /*write the header*/
   drop outrec.dd_name
   end

ovly_out(recsout(dd_name), 5,4,B)   /* resequence the records */
write(dd_name)  /* write the segment record   */
return 'drop'


That's the ENTIRE program!


On my PC I have a COBOL program, with a lot more logic, that does essentially 
the same thing. As it is reading the input, each time it gets to a different 
database name, it closes the file it has been writing to and opens the file for 
the appropriate DD name, extending it. So the program only needs to have one 
output file defined, even though it is writing to different DDs as it goes.


Now we're trying to replace the File Manager step. If it was possible to do 
this in z/OS COBOL we could use it, but it isn't worth a large effort because 
it would be an interim solution anyway.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Friday, April 28, 2023 3:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL to dynamic DD name

I don't know any Cobol syntax that would change the DDNAME in a DCB, but you 
could call an assembler routine to change the DDNAME before OPEN. Why would you 
want to do that?

I'm a bit baffled. In z/OS and its ancestors, the data set name isn't 
determined until runtime, via JCL.

Perhaps if you describe the problem you are trying to solve.

--
Tom Marchant

On Fri, 28 Apr 2023 19:37:39 +, Schmitt, Michael  
wrote:

>I know how to have a COBOL program on z/OS use a data set name that isn't 
>determined until runtime, via an environment variable. My question is can you 
>use one file (i.e. one select/assign and one FD) to write to different DD 
>names, that were already allocated in the JCL?
>
>I can't find a way, and in the manual the syntax for the environment variable 
>method requires a DSN or PATH, no option for a DD name.

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


--
For IBM-MAIN subscribe / signoff 

Re: COBOL to dynamic DD name

2023-05-01 Thread Allan Staller
Classification: Confidential

If the JCL has all of the DD's defined. Just open/close the requested file(s) 
as needed. No need for dynamic ddname.

>> I'm not trying to allocate the files. The JCL for the step has all the DDs. 
>> I just need to be able open, extend, and close the select/assign to 
>> different DDs where which ones I use and which order is not known until I'm 
>> working through an input file.

::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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


Re: CBU Woes

2023-05-01 Thread Jousma, David
This is what we do as well, as in defining the extra processors as reserves, 
and then just config them on when needed during the envent.




From: IBM Mainframe Discussion List  on behalf of 
Mike Shorkend 
Date: Saturday, April 29, 2023 at 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: CBU Woes
Hi Ed, There are two ways you could do this. The first one is by assigning 
reserve processors in the image profile. After the LPAR is up and running you 
can config the extra CPUs online. You could automate this pretty easily. You 
don't have
ZjQcmQRYFpfptBannerStart

ZjQcmQRYFpfptBannerEnd

Hi Ed,

There are two ways you could do this. The first one is by assigning reserve

processors in the image profile. After the LPAR  is up and running you can

config the extra CPUs online.

You could automate this pretty easily. You don't have to make any changes

going back and forward with/without CBU.



The other way is to create a new image profile with the added CPUs defined.

After you add the CBU, you will need to mark this new profile for

activation and then activate the LPAR.

I guess that you could use BCPii to script this but I am not sure that

BCPii has access to all these controls.You would have to do the reverse

when you withdraw the CBU.



I prefer the first method . Much less hassle.





Mike



On Sat, 29 Apr 2023, 20:43 Ed Jaffe,  wrote:



> Esteemed Sysprogs,

>

> We use CBU to activate additional engines and capacity twice a year.

>

> The image profiles on the HMC match the LPAR names and there seems to be

> no way to associate alternate image profiles to be used while CBU is

> active. Therefore, we have been manually updating the image profiles to

> add the additional engines during the CBU and then manually changing

> them back when the CBU is over.

>

> Is there a better way? Can alternate image profiles be used? If not, can

> these changes be easily scripted?

>

> Thanks,

>

> --

> Phoenix Software International

> Edward E. Jaffe

> 831 Parkview Drive North

> El Segundo, CA 90245

> https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!MwwqYLOC6b6whF7V!ljwlOQMOTrouY0378viK3LLitLzAen0tXgtX2Uw64GxoYekutjvY1TGYftxOg3yJFljakLkujxiJU48nlJdCbC5c$

>

>

>

> 

> This e-mail message, including any attachments, appended messages and the

> information contained therein, is for the sole use of the intended

> recipient(s). If you are not an intended recipient or have otherwise

> received this email message in error, any use, dissemination, distribution,

> review, storage or copying of this e-mail message and the information

> contained therein is strictly prohibited. If you are not an intended

> recipient, please contact the sender by reply e-mail and destroy all copies

> of this email message and do not otherwise utilize or retain this email

> message or any or all of the information contained therein. Although this

> email message and any attachments or appended messages are believed to be

> free of any virus or other defect that might affect any computer system

> into

> which it is received and opened, it is the responsibility of the recipient

> to ensure that it is virus free and no responsibility is accepted by the

> sender for any loss or damage arising in any way from its opening or use.

>

> --

> For IBM-MAIN subscribe / signoff / archive access instructions,

> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

>



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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: CBU Woes

2023-05-01 Thread Tom Mathias
Edward,

As you stated, the name of the image profile must match the name of the LPAR 
and so there can only be one image profile per LPAR.

However, if you need to have different versions of the image profile, such as 
when CBU is active and when it is not, then you do have some option.

First, the Export/Import Activation Profiles task does let you export and 
import the entire set of activation profiles.  In addition to letting you 
export/import using media, an HMC (or SE) can hold a set of activation profiles 
for a given system.  Up to 8 different sets can be saved and each one can have 
a name.  You could update the activation profiles and export the set and give 
it a name of "CBU" for example and then  update the activation profiles again 
and export the set with a name of "Normal" and then you can use the task to 
quickly change the set of activation profiles on an SE between "CBU" and 
"regular", for example.   The only drawback is that the entire set of 
activation profiles must be exported or imported.

Another option is that the HMC offers both SNMP and WS APIs that can be used to 
query and to update image profiles. You could write scripts that run on your 
favorite server and that used SNMP or WS APIs to update the image profiles.  In 
addition, GDPS/BCPii and z/OS BCPii offer z/OS based APIs that in turn use the 
SNMP APIs (sometimes referred to as BCPii v1) or the WS APIs (sometimes 
referred to as BCPii v2).  This can be more work than just exporting or 
importing a full set of activation profiles but the big advantage is that you 
can use the APIs (either directly or thru z/OS) to update just one image 
profile and even just one image profile property of one image profile.  And if 
you are already using z/OS and BCPii to do things like activating LPARs or 
IPLing LPARs, then it shouldn't be too difficult to create scripts to update 
image profiles.  

Tom Mathias

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