Re: ISPF: How to remove highlighting of a FIND/SEEK result in an EDIT MACRO

[Gary Freestone]

This macro works fine.   I ran it on itself and the cursor was left at the
start of the first occurrence of macro but macro was not highlighted.

/* REXX */
Address isredit
"macro"
"seek 'macro' "
"resert find"

Regards,
Gary

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Bob Bridges
Sent: Sunday, 1 January 2023 11:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF: How to remove highlighting of a FIND/SEEK result in an
EDIT MACRO

I don't think I've ever run across this.  The Edit Macro manual says this
about RESET FIND:

"Turns off highlighting of FIND strings until the next FIND, RFIND, CHANGE,
or RCHANGE command. However, SEEK and EXCLUDE do not return the highlighting
of FIND strings in this manner.

"RESET with no operands has the same effect on highlighted FIND strings as
RESET FIND."

I think it's saying "you can't get there from here".  Maybe there's a
workaround, but I don't see it here.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Do you know what constitutes a "hate crime"?  Put your thinking caps on.
What tools do we need to determine whether a crime was motivated by hate or
prejudice?  Answer: We need thought police.  -from "See, I Told You So" by
Rush Limbaugh */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Binyamin Dissen
Sent: Saturday, December 31, 2022 17:50

I have an EDIT MACRO that is doing a SEEK (but the same results with FIND).

There does not seem to be an obvious way to reset the high-lit result.

I tried RESET FIND and RESET with no luck.

What obvious command am I missing?

--
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 - Interpret or Value - Which is better?

[Gary Freestone]

A few years back I switched from INTERPRET to VALUE due to concerns I had from 
a security perspective.  

Value only performs an evaluation and assigns it to a variable.  Interpret lets 
you do any thing. 

Say for example in your sample code.  If I could hijack you code and adding a 
single line to the REXX I could issue a JES2 command.  The line is

def=';x=isfcalls(on);address sdsf "isfexec /$DI";istr="DEF";say "DEF" '

Sure this case its just a harmless $DI but it could be anything.  The only 
difference in the output is an example blank line. 

That’s why I’ve switched.

Gary Freestone
Kyndryl Australia   
 

Sent from Mail for Windows

From: Lionel B. Dyck
Sent: Monday, 13 September 2021 9:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: REXX - Interpret or Value - Which is better?

>From a programming standpoint which is (a) more efficient, and (b) easier to
understand - Interpret or Value.

Examples:

/* rexx */
/* setup our defaults to start with */
istr = 'abc'  
vstr = istr   
  
/* value examples */  
newvar = value(vstr,'def')
say newvar
say vstr value(vstr)  
newvar = value(vstr''1,'second')  
say newvar
say vstr''1 value(vstr''1)
  
/* interpret examples */  
interpret 'istr = def'
interpret 'say' istr 'istr'   
interpret 'istr'1 '= second'  
interpret 'say' istr''1 'istr'1   

The main differences that I can see is that with interpret the new values
are uppercase, and with value the return contains the new variable name.

Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

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

--
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: ICSF and z/OS 2.3

[Gary Freestone]

This was announced by IBM last August.

“With the PTFs for APAR OA55437, customers on z/OS V2.2 and V2.3 can now 
generate true random numbers via /dev/random when running on the IBM z14™ 
family of servers, without needing to set up the Integrated Cryptographic 
Service Facility (ICSF). This new support is significant for users of OpenSSH, 
who may now use functions such as sftp and ssh without needing to set up ICSF, 
especially when using the new function introduced last year in APAR OA54299 
(also for z/OS V2.2 and V2.3) allowing OpenSSH to use the CPACF instructions, 
when present, directly for certain ciphers and MACs

Regards, Gary


Sent from Mail for Windows 10

From: Kirk Wolf
Sent: Saturday, 19 January 2019 10:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ICSF and z/OS 2.3

ICSF is currently required if you want to use the Unix /dev/random and
/dev/urandom devices.
These might be required by Unix apps (or jobs/stcs that use z/OS Unix
System services).

For exampe:  IBM OpenSSH server will not work without ICSF and /dev/random
available.

On Fri, Jan 18, 2019 at 5:24 PM Greg Boyd 
wrote:

> ICSF is only required if you want to use the ICSF APIs, so it depends on
> what, if anything in your shop might be using the APIs.  System SSL (TLS)
> will certainly leverage the APIs if you have Crypto Express cards available
> and that might provide some CPU relief.  The Guardium Database Encryption
> Tool requires it if you want to encrypt IMS segments or DB2 tables at the
> row level.
>
> Pervasive is getting a lot of attention and if you're going that route, I
> would highly recommend that ICSF be active everywhere.  You don't want one
> system writing ciphertext to a file and another system thinking that the
> file is cleartext.  IBM is also recommending that ICSF be 'always up'.
> They have made a number of changes to the component so that it will come up
> earlier in the IPL and it should be one of the last tasks running.
>
> Given the growth in crypto workload, I take 'always up' to also mean
> 'running everywhere'.  There are simply more things that can leverage ICSF,
> some optionally and some require it.
>
> I'm not sure why DFSMShsm would need ICSF active, unless they were using
> the Encryption Facility for z/OS with the DFSMSdss feature.
>
> Greg Boyd
> Mainframe Crypto
> www.mainframecrypto.com
>
>
>
> On Fri, 18 Jan 2019 18:16:37 +, Mary Kay Tubello 
> wrote:
>
> >Hello all,
> >
> >Does anyone know if z/os 2.3 requires ICSF to be installed on each LPAR?
> >
> >Thanks,
> >Mary Kay
> >
> >Large Systems Engineering
> >IT Infrastructure
> >Humana
> >123 E. Main St. 40202  (CT6)
> >502-476-2772
> >mtube...@humana.com
> >
> >
> >
> >
> >--
> >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

BPXWDYN - Bug or no bug ?

[Gary Freestone]

These days we are opting for BPXWDYN in our REXXs instead of TSO ALLOC.  One
of the main reason for the switch is BPXWDYN's ability to return the DDNAME
it allocated via the RTDDN parameter.

 

Chasing down a bug in my code lead me to discover an idiosyncrasy with
BPXWDYN that I think is a bug, but maybe not. So I'm seeking your opinions. 

 

If I have the following

 

 

Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"

Say 'DDname allocated is 'dd

Call bpxwdyn "Free fi("dd")"

Running this exec gives something like "DDname allocated is SYS00746"

However, if any.dataset.name is already allocated to an alternate DDNAME
that is not in concatenation then, instead of allocating a new DDname it
just returns the DDNAME of the existing allocation. 

You can see this with this code

Address tso "alloc fi(abug) da('any.dataset.name') shr resue"

Call bpxwdyn "Alloc rtddn(dd) da('any.dataset.name') shr reuse"

Say 'DDname allocated is 'dd

Call bpxwdyn "Free fi("dd")"

And you will get "DDname allocated is ABUG"

Problem is because I'm not getting a new allocation my FREE is freeing up a
DDNAME allocated by a totally different process.  In my case causing an
abend sometime later because a DDname that should be allocated is not.

This doesn't seem right to me.  An "ALLOC" should do a new allocation every
time.   

 

Comments 

 

 

Gary Freestone   

 


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