Re: REXX vs other languages -- EXECIO intuitiveness

[Jon Perryman]

On Mon, 22 Apr 2024 18:14:50 +, Farley, Peter  
wrote:

>From the testing I have done so far,
> My suspicion (untested) is that the Rexx script itself is automagically 
> converted to EBCDIC as the interpreter
> is reading it, so that the interpreter only sees EBCDIC text.

Default REXX input routines would include support for UNIX files which are 
encoded. It makes sense they would make this generic and support multiple 
character sets. Why force it to only support the default encoding?

> the z/OS Unix Rexx interpreter SAY command only writes in EBCDIC.  

On other Unix variants, STDOUT does not perform encoding and it is typically 
performed by the application (language support). Imagine the difficulty in 
translating characters but skipping terminal commands without understanding the 
intentions of the app.  I would expect z/OS Unix to be the same and It would 
make sense that it is EBCDIC.

SAY is often environment specific. Rexx provides exits that are user 
replaceable allowing common functionality to be environment specific.

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

Re: REXX vs other languages WAS: Rexx numeric digits and scientific notation question

[Jon Perryman]

On Mon, 22 Apr 2024 14:01:23 +, Seymour J Metz  wrote:

>delete foo
>rather than
>'DELETE' foo
>is a simple example. In practise I often need multiple upper case constants in 
>a single expression.

This isn't a valid example because 'delete' will also work. As Andrew said, 
rarely will you find a real need for REXX to uppercase an undefined REXX 
variable name. All parsers handle uppercase as needed. In this case, you're 
ignoring the TSO parser. Consider "alloc dsn('my.dataset') 
path('/my/unix/file')" where everything is specified in lowercase. Lowercase 
TSO commands, command option names, DSN and more are not valid. In this 
example, everthing except '/my/unix/file' will be automatically uppercased 
instead of failing the command because of lowercase.

Truthfully, REXX uppercasing rarely provides real advantages for most z/OS 
environments and is a problem for z/OS Unix where lowercase is the norm.

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

Re: REXX vs other languages WAS: Rexx numeric digits and scientific notation question

[Jon Perryman]

On Mon, 22 Apr 2024 01:41:21 +, Seymour J Metz  wrote:

>I was referring to 'I once found CMS ISPF to reauire "address isredit 'isredit 
>'".
>Otherwise the command went to ISPEXEC.', which clearly is b0rk3n.

This seems very unlikely given that IBM does good QA and this would have caused 
a HYPER to fix it. This would have broken a lot of existing customer code. My 
gut tells me that ISREDIT was set causing it not to be "ISREDIT".

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

Re: REXX vs other languages -- EXECIO intuitiveness

[Jon Perryman]

On Sun, 21 Apr 2024 22:54:15 +, Seymour J Metz  wrote:

>>Wait, what?  Are you saying TSO-REXXhaas LINEIN, CHAROUT and so on?

>Only in a EUnix environment. I don't know if syscalls is enough or if you 
>actually have t be running under the shell.

Syscalls does not setup a full z/OS Unix environment and in environments like 
TSO would only cause dubbing.

I've never tried it but a shell should not be required to automatically 
integrate REXX & UNIX as long as you start REXX using z/OS Unix facilities in a 
Unix address space. Technically, shells are not required by Unix but I doubt 
that it has been tested much for obscure requirements.

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

Re: S0c4 creation

[Jon Perryman]

>>Is there any sample Jobs or I can enforce a s0c4 abend in a Started task ?
>>I am trying to teach SLIP trap to a rookie..Is there any other efficient
>>way to do this?

> 0c4 is 7BAD and this explicit value is used on purpose by some products 
> to catch unintended or unwanted reference.

This is too funny. The system is littered with suppressed S0C4 abends. Set a 
generic SLIP SOC4 for any highly active STC and it should catch within a couple 
of minutes. The chances of you capturing your S0C4 is less than 50%. If you 
need your S0c4, then ask IBM for their S0C4 suppression slips. Be sure to use 
LIMIT=1 for your slip otherwise you may get more dumps than wanted. I once 
forgot to send those to a customer who saw that my slip caught the wrong S0C4 
and decided to increase the limit. Let's just say it was not pretty and I never 
made that mistake again.

If you create your own S0C4 program, you can easily run it in your automation 
product (e.g. Netview) without jumping thru hoops. Just write a REXX to call it 
and you can set the slip just before you call your program thus increasing the 
chances you S0C4 is captured.

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

REXX vs other languages WAS: Rexx numeric digits and scientific notation question

[Jon Perryman]

>Java's not perfect, but it is powerful and it is pretty much universally
>available on z/OS.

People don't understand the ingenuity behind REXX and don't understand the real 
problems it solves. From a language standpoint, REXX is just another language 
but it's real strength is it's environment integration. Instead of the caller 
maintaining libraries, the environment automatically integrates with REXX. For 
instance, REXX in the TSO environment, gives you access to TSO commands 
(address TSO) and z/OS programs (address linkmvs). Start ISPF and address 
ISPEXEC is available. ISPF option 2 gives you address ISREDIT. SYSCALLS ON 
gives you address syscalls.

For product developers, REXX is simple to integrate environments as witnessed 
by the plethora of integrated environments on z/VM, z/OS and probably z/VSE 
(e.g. some addressable environments: automation, CICS, CMS, CP, TSO, UNIX, 
SYSCALLS and more) 

OOREXX is not REXX because it does not have the automatic environment 
integration and as you say, using JAVA instead of OOREXX would be preferable. 
REXX on the other hand is preferable over JAVA in many IBM environments. For 
instance, why would you use JAVA as your system automation environment language?

The complication of using OOP REXX is rarely beneficial for most environments. 
Generally, you are not building complicated applications. For instance, system 
automation will be the most complex but managing events under objects would be 
complicated and unmanageable given the current automation environment design.

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

Re: What is IEANTRTR in Authorized Assembler Services Reference?

[Jon Perryman]

On Sun, 14 Apr 2024 00:11:28 +0300, Binyamin Dissen 
 wrote:

>I was looking to see if this was supported in 2.4, but didn't find it

IBM guarantees upward compatibility but not backward. You must always assemble 
your product with your lowest supported libraries (e.g. 2.4 AMACLIB, AMODGEN, 
MACLIB, MODGEN) otherwise the generated code may not be compatible with lower 
releases.

I believe I used name tokens in z/OS 1.8 but your minimum release libraries are 
you guide to which macro's are supported..

>This macro does not need any authorization.

Some macros in the authorized assembler macro book don't require running 
authorized but are affected if you are running authorized. Name tokens is one 
of those. Name tokens are useful in all environments (including unauthorized) 
but when used in an authorized environment, you will want them secured 
otherwise you may have a security exposure.

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

Re: Nanosecond resolution timestamps for HLL's?

[Jon Perryman]

On Sat, 24 Feb 2024 19:50:32 +, Jim Mulder  wrote:

>STCK, which inserts a processor related value in the low order bits to meet 
>the "unique with a partition" requirement. 

If there's not a simple answer, I'll take your word this is monotonic, Out of 
curiosity, what is the precision of STCK and how does it guarantee monotonic 
time? In other words, how does STCK distinguish between 10 STCK's on the same 
CPU in the same partition within 49 microseconds? Multiply 244 picoseconds (TOD 
bit 63) by 200 CPU IDs, STCK precision is 49 microseconds. With a 5Ghz Telum 
processor, single cycle instructions take 191 picoseconds which means a single 
CPU can potentially execute 256 instructions during that 49 microsecond 
timeframe.

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

Re: SDWAEC1

[Jon Perryman]

On Mon, 26 Feb 2024 20:24:09 -0500, Joseph Reichman  
wrote:

> Thanks and I apologize if sone of my posts made it seem like I wasn’t 
> listening to what you were telling me 

Joseph, you missed Peter's point. Clearly you don't understand this is not 
about "seems like". By ignoring several clarification requests, you caused lots 
of confusing posts because you forced false speculation that would have been 
avoided by the clarifications. Everyone is wasting their time reading 
irrelevant posts (not just the poster) because you couldn't be bothered to 
respond. Do you not consider this rude?

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

Re: Nanosecond resolution timestamps for HLL's?

[Jon Perryman]

On Tue, 20 Feb 2024 22:58:42 +, Farley, Peter  
wrote:

>the monotonically increasing real-time clock to be the “tie breaker” value.  

Real-time clocks are not monotonical. Regardless of vendor, there is 1 
real-time clock shared by all CPU cores. 

> I guess COBOL programmers aren’t supposed to be that “sophisticated”.

Cobol flawlessly implement security, flawlessly optimize programs that need to 
be optimized, flawlessly implement NOSQL, flawlessly implement private cloud 
applications and more. Cobol programmers are more likely to educate themselves 
more on their line of business.

>Or maybe the real issue is the lack of existing support in COBOL for data 
>structures 
>like heaps, queues, lists, maps and sets that are so common else where 
>in the programming language universe.  

Why implement these concepts when there are robust z/OS alternatives that 
achieve the same results?

>  if the “keys” for the heap to be attached were guaranteed by the application 
> design 
> and implementation not to have any of the keys in the heap to which it is 
> being attached,
> just keeping the highest counter value would be sufficient. 

Why bother with unique keys if all you want is LIFO or FIFO access by key. Do 
you have a problem with using duplicate keys in the heap and access using min 
or max? I'm guessing you are writing the heap logic. You can read from the left 
branch and write to the right branch.  

>In the more general case, how do we get away from needing to use assembler to 
>write COBOL?  
>Using CS, CDS, CDSG, PLO, ENQ, etc. to maintain a consistent non-timer counter 
>value would
> all need to be invoked from assembler (or possibly MetalC using 
> “builtins.h”).  

Under CICS, Cobol has direct access to ENQ and STORAGE OBTAIN. Single threaded 
COBOL does not need serialization (e.g. ENQ). Someone familiar with COBOL and 
the environment you will be using can tell you if storage obtain, 
multi-threaded and serialization is available / how to use it.

>Mind you, I am far from one to shy away from assembler, I am very comfortable 
>with it.

Trivial assembler programs should be acceptable. STORAGE OBTAIN / RELEASE is 
trivial. CSDG for serialization update of a counter is trivial. Metal C could 
probably achieve the same functionality.

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

Re: Nanosecond resolution timestamps for HLL's?

[Jon Perryman]

On Mon, 19 Feb 2024 21:54:56 -0600, Charles Mills  wrote:

> has recently issued an STCK and your program must spin, consuming CPU cycles, 
> until a unique STCK value is available.

This is being made far more difficult than needed. The vast majority use nano 
seconds for monotonic code rather than serving a real purpose. System z is 
already at 1,000 instructions per nano second (200 cores times 5 Ghz) and 
sysplex apps can boost that up to 32,000 instructions per nano second. Anyone 
using this strategy is not Quantum ready where nano seconds become irrelevant. 
Why bother with the clock at all? Why bother with spin?

The simple solution is a counter that is incremented. Using PLO, CS, CSD, CSDG 
or ENQ to serialize updates to the counter, you can easily handle a counter 
larger than the TOD. E.g. CSDG serializes 128 bytes.
 

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

Re: Nanosecond resolution timestamps for HLL's?

[Jon Perryman]

On Mon, 19 Feb 2024 23:21:49 -0600, Peter Farley  
wrote:

>The only drawback is that if I ever need to meld two heaps 
>the meld logic would have to pick the largest heap counter 
>as the result counter value in the merged heap. 

Merging heaps would require that you maintain a single counter because multiple 
separate counters are not coordinated sequencing. In other words, you don't 
know if 7 on heap 1 is before / after in time of 5 on heap 2.

Depending on your needs, you could serialize the single counter between all 
heaps using CS, CSD, PLO, ENQ, coupling facility or something I haven't 
mentioned. Instead of the counter being in the heap definition, you would each 
one point to a common shared counter.  

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

Re: Nanosecond resolution timestamps for HLL's?

[Jon Perryman]

On Tue, 20 Feb 2024 00:30:43 +, Farley, Peter  
wrote:

>My initial purpose is actually part of implementing COBOL-compatible 
>min-heap priority queue functions that return equal-priority nodes 
>in FIFO insert order when popped.  A timestamp or some other monotonically 
>increasing integer tie-breaker

For those that mentioned DB2, I believe the GENERATE_UNIQUE() function produces 
a timestamp that is unique across the SYSPLEX.

As for implementing a heap, you say you don't care if it's a timestamp. Since 
heaps require single thread or a locking mechanism when elements are added / 
removed, why not just have a counter associated with the heap. Each time you 
add an element, you increment (or decrement) the counter and append it to the 
key (in your case priority). Alternatively if you prefer timestamp, then 
maintain the timestamp as the first part of the counter and increment it with 
matching timestamps or replace count with new timestamp & 0.

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

Re: SDSF PS Command column

[Jon Perryman]

On Sun, 4 Feb 2024 10:04:05 -0600, Paul Gilmartin  wrote:

>On Sat, 3 Feb 2024 21:47:56 -0600, Mark Zelden wrote:
>>Agree to disagree.  I haven't checked the doc and maybe it isn't documented 
>>that that field or
>>any field is limited to 40 characters, but it is not a bug to be fixed.  
>> 
>I shall disagree.  For example, suppose there were an option to display
>a data set name in that 4-character field.  

You can disagree all you want but these are WADs. Right or wrong, IBM makes a 
design choice that turned out to be annoying that requires an RFE. If it's 
small enough and enough of an impact, IBM sometimes chooses to fix it as a 
defect in this release. 

This doesn't appear to be causing you any pain. Some enhancements and defects 
aren't worth fixing with limited resources. 

>There are multiple ways it could have been done right:
>o The caller could provide a variable-length reply buffer.
>o The service could return a pointer to a string.

These are solutions to some problem in your mind. IBM's design choices would 
determine if these would meet their requirements. Could it be that there are 
more requirements such as security, MLWTO, MPF, automation, SSI, TSO commands 
or requirements we simply did not consider.

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

Re: SDSF PS Command column

[Jon Perryman]

On Sat, 3 Feb 2024 09:24:07 +, Rob Scott  wrote:

>SDSF calls the BPXEKDA service returns truncated command information. 

Since BPXEKDA doesn't need the OMVS segment for the first 40 bytes of the 
command, why does it need it for the rest of the command? Isn't it just a null 
terminated field that can be fully copied?

>We have an existing RFE to provide more information.

My guess is that the RFE includes more than just the command which probably 
need dubbing. I would think you could just as easily copy 100 bytes as 40 bytes.

> When the PS command was originally written OMVS segments 
> were not commonplace and the design goal was to provide the data without 
> being dubbed

In the past, dubbing caused some conflicts in some OEM products. For example, I 
was a developer for an automation product that included multi-tasking & 
multi-user TSO in the address space (also TCP tasks). You might introduce 
similar problems in the console address space so you will need more than simple 
testing. 

>BPXEKDA is used by the operator command responses which probably explains the 
>truncation length.

I suspect the truncation is by choice. One possibility for the limitation is 
MLWTO secondary messages having a max length of 80. Another possibility is 
security.where the user does not have an OMVS segment to restrict access to 
processes. A third possibility would be TSO CONSOLE & OPER commands where 
output flooding. Fourth, it might introduce problems with MPF processing & 
message suppression. It might also be an issue with syslog. It could also 
introduce bad habits in automation products.

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

Re: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Jon Perryman]

On Wed, 31 Jan 2024 13:36:56 -0600, Charles Mills  wrote:

> the ACEEUNAM seems to be a supported programming interface and should be safe.

All documented control blocks have a supported (or unsupported) programming 
interface section. ACEEUNAM is not excluded in the ACEE so the assumption is 
that it is supported.

https://www.ibm.com/docs/en/zos/2.4.0?topic=areas-acee-accessor-environment-element#d82132e41

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

Re: SDSF PS Command column

[Jon Perryman]

On Fri, 2 Feb 2024 13:53:54 -0600, Lionel B. Dyck  wrote:

>Perhaps someone who knows the internals could help out here.

It's unlikely someone here will know the internals to PS command in SDSF 
because it's designed for those who avoid UNIX. 40 bytes for a UNIX command can 
be very small when it can be up to 512 bytes.

Since "/" did not get you the full line command, try the "D" line command.

If that doesn't work, REXX exec can be run from the command line. Maybe someone 
has a REXX that extracts the information that you want. 

Maybe a D OMVS command gives you the information that you want.

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

Re: ISPF edit - clone a column

[Jon Perryman]

On Fri, 2 Feb 2024 16:02:05 +0100, Radoslaw Skorupka  
wrote:

>Sometimes I need clone text column.:

The BOUNDS edit command can be useful. For instance, maybe you only want to 
clone columns 20 to 29 (BOUNDS 20 29 will not copy data outside those columns). 
Maybe you want to remove the columns 20 to 29 (BOUNDS 20 * and use shift line 
command <<10). Don't forget to restore bounds. 

Maybe you need to clear columns 20 to 29, CHANGE P'^' ' ' 20 29 ALL.

As a reminder about overlay, remember that blanks do not overlay. You may need 
to clear the overlay area using the previous change command.   

Alternatively, you could write a simple REXX edit macro

/* rexx */
address ISREDIT
"MACRO"
do cnt = 1
   "LINE (data) =" cnt
   if rc <> 0 then exit /* last line */
   parse var data col1 11 col2 21 col3 31 col4
   newdata = col1 || col3 || col2 || col4
   "LINE" cnt "= (newdata)"
end

If you are using ISPF EDIT simply because you want to create the data in TSO, 
remember, the utilities you mentioned can run in TSO instead of using edit. 
REXX EXECIO can also be used to avoid ISPF EDIT. 

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

Re: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Jon Perryman]

>
>You can get it from ACEEUNAM.
>
>
>The intended interface is likely one of the RACROUTE variants (EXTRACT?).

Also keep in mind multi-user address spaces and that you are referencing the 
correct ACEE. MUSAS can occur in unexpected places. E.g. Just because your TSO 
address space is single user does not mean embedded TSO in my products address 
space is single user.

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

Re: Regarding RBINTCOD

[Jon Perryman]

On Tue, 30 Jan 2024 20:05:50 +0200, Binyamin Dissen 
 wrote:

>:>Jon P did write what I meant. Answer: no, it just makes it a lot more likely 
>that the storage obtain for the SDWA will succeed.
>
>Sad.

I believe abend recovery R0=12 is virtually unheard of when SDWA is above the 
line. Realize that REGION=2048M is not valid and 2047M is the max. I suspect 
that IBM reserves this last 1M for situations like this. Additionally, running 
out of 2GB of storage is very rarely from <1K storage obtains. SDWA is small 
and enough storage should be available. 

Far more concerning would be S878 abend recovery. Does abend recovery 
automatically bypass storage limits during S878 abend recovery? If not, is 
there a mechanism to bypass it temporarily? I've used STORAGE OBTAIN,COND=YES 
and when it fails, percolate it to IBM recovery. For common recovery in product 
environments, this is not the best solution but it works most of the time.

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

Re: Regarding RBINTCOD

[Jon Perryman]

On Mon, 29 Jan 2024 15:40:04 +0200, Binyamin Dissen 
 wrote:

>Are you implying that an ESTAE(X) routine with SSWALOC=31 is guaranteed an
>SDWA and there is no reason to check R0 for 12 and alternate code paths?

Obviously Peter is not making that guarantee but how many jobs run with 
REGION=0M or 0K. If I remember correctly, SDWA allocation ignores REGION 
limits, which essentially ensures SDWA will always exist unless you have 
serious system problems. Above the line storage may not be guaranteed but the 
odds would be astronomical.

Coding REGION= >16M is far more common. With all the advancements, filling 
below the line storage should never happen but it is conceivable.

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

Re: Any Recovery for RMODE64

[Jon Perryman]

On Fri, 26 Jan 2024 08:30:54 -0500, Joseph Reichman  
wrote:

>For Estae says amode 24 or 31 

ESTAEX supports SYSSTATE AMODE=64

>Regardless if I established a recovery in 31 but storage and then branched to 
>64 bit storage 
>Under the same RB 
>
>I assume the recovery routine would cover me 

It does not make sense what you are asking. If your recovery routine switches 
from AMODE31 to AMODE64, why would it need to branch to 64 bit storage? 

If you're talking about the SETRP, then you would need to set the SDWA to retry 
using the 64 bit registers in SDWARC4.

>For sdwaec2 I would have to find it in the linkage stack 

Since you are searching the linkage stack in reverse, you might want to keep in 
mind that percolation could have destroyed the relevant linkage stack entry. 

>How would I know I have the right entry maybe by comparing the lower half of 
>the registers 

Will a SDWAEC2 ever be above the bar? If I remember correctly, above the bar 
storage is obtained in large chunks (MB's). Rarely will a non-LE programming 
language create load modules large enough that makes above the bar a 
consideration. I suspect it's a safe bet that SDWAEC2 won't be above the bar 
but you could warn users of your diagnositc routines that you make this 
assumption and how you handle it.

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

Re: RACF Automation (Cross Posted)

[Jon Perryman]

On Thu, 25 Jan 2024 17:51:46 -0500, Bob Bridges  wrote:

>Back when my client in Ohio installed it, we called it "Sam-Jupiter". 

It appears that Beta Systems acquired the product and call it Beta-Access. 
https://www.betasystems.com/en/products/beta-access/

It also appears they removed everything except for RACF support.

> The client seemed content with their choice, although it was 
> really designed to work with RACF and this is an ACF2 client.

RACF had groups which made implementing role-based administration easier. ACF2 
and Top-Secret have a different architecture which some customer 
implementations were burdensome to implement within SAM. It also had 
performance implications. However, it had the benefit for customers acquiring 
other companies where they could use the same SAF logic regardless of the SAF 
products being used. It also allowed conversion between SAF products.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Automation (Cross Posted)

[Jon Perryman]

On Thu, 25 Jan 2024 10:15:57 -0600, Steve Beaver  wrote:

>I don't even know if the product still exists. -- The closest IVP that I know 
>of is OKTA.

See if SAM (Security Administration Manager) still exists (possibly rebranded). 
The company no longer exists but I found 
https://dl.acm.org/doi/pdf/10.1145/266741.266758 which described the product. 

>The down side of ROLLING your own you have to administer and maintain it
>And no one wants to spend the couple hundred thousand to write and watch 
>people retire.

You haven't defined the customer's expectation of "Automate RACF". To say 
"couple hundred thousand $" is meaningless because at this point you don't know 
the customers problem.. Maybe the customer simply needs standards that simplify 
and consolidate the process. Products like AutoOperator may simplify 
distribution of security definitions to a few simple execs.

What is the problem that the customer trying to solve? Maybe the customer will 
find an 80% solution written in 2 weeks is acceptable. 

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

Re: RACF Automation (Cross Posted)

[Jon Perryman]

On Tue, 23 Jan 2024 12:39:47 -0600, Steve Beaver  wrote:

>I have a customer that would like to AUTOMATE RACF. 

Did you solve your problem?

You need to clarify what AUTOMATE RACF means to the customer. What is the 
problem the customer is trying to solve because they can't mean automate. 
Security definitions requires someone to fill in the blanks. Are they looking 
to simplify the process and streamline it with a company's security strategy.

I worked on a product that centralized security thru a single interface (RACF, 
TopSecret, ACF2, Unix, Windows and others. It's been many years and I don't 
even know if the product still exists.

If you can describe the problem, then we might have some suggestions to solve 
your problem.

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

Re: IPCS - CBFORMAT

[Jon Perryman]

This looks correct and essentially the same as mine. I never ran into the 
truncated error. I'm guessing the problem must lie somewhere else.

Since ACRONYM= is working, it's unlikely that a spurious blank is causing the 
problem. Maybe compare the assembler listings to see if there is a difference. 

I think I accessed my IPCS modules thru BLSLLIB or possibly TSOLIB to eliminate 
problems associated with linklst. I don't think this is your problem..

I would look at the link listing and verify the entry point and module name is 
correct. I don't think this is the problem because HEADER= is working correctly.

Although you didn't include the full source, It appears the CSECT is setup 
correctly and nothing spurious seems to be included but maybe you can check the 
listing for something unexpected.

I don't think using CBLEN=20 will fix the problem but you could try it. 

Sorry I can't be of help but your problem doesn't appear to be with the 
definitions. 

On Tue, 23 Jan 2024 14:26:20 -0600, Bill Yeager  wrote:

>OPRM  DSECT 
>OPRMEYEC DSCL4EYECATCHER ('OPRM') @E120
>OPRMIFUN DSCL4I/O FUNCTION TO BE PERFORMED 
>OPRMCFUN DSCL4COMM FUNCTION TO BE PERFORMED
>
> BLSQMDEF BASELBL=OPRM,CBLEN=12,PREFIX=4,HEADER=OPRM,  X
>   ACRONYM=OPRM,ACROLBL=OPRMEYEC
> BLSQMFLD NAME=OPRMEYEC,DTYPE=EBCDIC
> BLSQMFLD NAME=OPRMIFUN,DTYPE=EBCDIC
> BLSQMFLD NAME=OPRMCFUN,DTYPE=EBCDIC 
> BLSQMDEF END
>
>2B79E814  D6D7D9D4   E6D9E3C5   D9D9C5D8   | OPRMWRTERREQ |
>2B79E820   E6D9E3C5   D9C5C1C4         | WRTEREAD |
>
>Command: CBF 2B79E814. STRUCTURE(OPRM)
>
>OPRM: 2B79E814  
>   +  EYEC. OPRM
>Control block is truncated  
>
>--
>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: IPCS - CBFORMAT

[Jon Perryman]

On Tue, 23 Jan 2024 13:11:27 -0600, Bill Yeager  wrote:

> I get “Control block is truncated”

TSO PROFILE MSGID will turn on message ID. You can then look up the message to 
find the causes and solutions for this message. You can TSO PROFILE NOMSGID to 
eliminate message ids from TSO. I personally leave it on because message id's 
can be useful.

Use IP LIST xxx LEN(##) to display the area and verify the full area actually 
exists. Verify the acronym matches and (I think) it has trailing blanks instead 
of X'00'. Look at the fields with formatting and ensure they are compatible 
with the formatting.

If the problem is not something obvious, then include the definition and 
storage here so that we aren't guessing.

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

Re: Custom ISPF command

[Jon Perryman]

>Create a site ISPF command table and add your commands to that.

An alternative to creating a site ISPF command table is to dynamically add ISPF 
commands. Command tables are ISPF tables that can be updated using TBADD, TBDEL 
and TBUPD. ISPCMDS is always open (probably ISRCMDS too). When you start ISPF, 
you can specify a REXX to be run that TBADD's your commands and they will 
remain in effect while ISPF is running. I never experimented with NEWAPPL 
commands so I can't tell you if that command table is automatically closed or 
remains open until ISPF is terminated.

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

Re: sdwagrsv not equal rbgrsave

[Jon Perryman]

On Thu, 18 Jan 2024 05:08:17 +, Peter Relson  wrote:

>
>I chain backward as its  the only way to do it wrapping around tcbrbp and next 
>rb had the registers in the prefix it had SVC 12 maybe SVC 42 issued that
>
>
>"Wrapping around tcbrbp" is a strange way to do much of anything.

Hi Peter,

Joseph is updating the abend recovery provided on the CBT available for public 
consumption. IBM abend does not always display abend module with offset. He is 
going to great lengths to obtain this information when not provided or when 
SDWAEC2 is different from SDWAEC1.

I doubt that any vendor would do this because of possible risks. Having worked 
on critical software, the benefit never justified the risk of crippling a 
customer's system.

I only mention this because you may have some tips for him. For instance, 
Wrapping around TCBRBP is his method for locating the module. Are there 
situations where the overhead could be problematic or worse yet a true 
multi-active task environment encountering problems such as an RB being 
removed. UNIX, CICS and OEM products.

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

Re: How can I keep JES2 from being SYSPLEXed?

[Jon Perryman]

> $HASP843 MASDEF  OWNMEMB=S0W3,COLDVRSN=z/OS 2.5,
>   $HASP843 ENFSCOPE=SYSPLEX,SHARED=NOCHECK,
>   $HASP843 XCFGRPNM=JES2,ESUBSYS=HASP
>
> $HASP843 MASDEF  OWNMEMB=S0W1,COLDVRSN=z/OS 3.1,
> $HASP843 ENFSCOPE=SYSPLEX,SHARED=NOCHECK,
> $HASP843 XCFGRPNM=JES2,ESUBSYS=HASP

Have you verified that compatibility PTF's are installed between z/OS 2.5 & 3.1?

Have you verified event notication (ENFSCOPE) is acceptable?

Are you sure that you will never need both JES2 MAS running on the same LPAR at 
the same time? You might want to consider ESUBSYS.

> $HASP792 JES2 HAS JOINED XCF GROUP JES2 THAT INCLUDES ACTIVE MEMBERS
>   THAT ARE NOT PART OF THIS MAS
>   MEMBER=JES2$S0W3,REASON=DIFFERENT COLD START TIME

Message $HASP729 told you that each JES2 MAS requires a unique XCFGROUP.

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

Re: Masking SMF data internally

[Jon Perryman]

>You can mask any character or external decimal field by using translate

As an alternative, you should run those programs on your systems and provide 
them with the reports that you review for sensitive information.

.

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

Re: SSH tunneling for unattended process.

[Jon Perryman]

On Thu, 11 Jan 2024 09:47:45 -0600, Kirk Wolf  wrote:

>Did I say anything about using passwords for ssh?   
>Again, this has nothing to do with your assertion that 
>using tn3270 over a ssh tunnel would expose the userid and password.

This thread is specifically about using ssh tunnel to provide SSL for non-SSL 
TCP apps. TN3270 (without enabling SSL) is being used for context that everyone 
in this group understands. 

You ask how I would get your TSO userid / password when you run TN3270 thru an 
ssh tunnel. Very simply, the userid & password would likely be the same for 
both. Assuming you automated ssh with userid & password exposed, I just look at 
your script.

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

Re: Gtf trace

[Jon Perryman]

On Thu, 11 Jan 2024 16:29:06 +, Ken Bloom  wrote:

>Does anyone know the format of the parm to set the number of bytes recorded to 
>64?

You need to be more specific about what you are tracing. Are you tracing VTAM, 
TCP, RACF or something else? Most likely you will specify size when you tell a 
component to start it's trace.

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

Re: SSH tunneling for unattended process.

[Jon Perryman]

On Thu, 11 Jan 2024 13:03:07 +1100, Filip Palian  wrote:

>Passing secret material in the command line for long-running and daemon
>processes is never a good idea [;

I'm not condoning this an as you say, this isn't a good idea but my point was 
it's a common practice in the UNIX and Windows environment. There are decent 
solutions but unlike z/OS programmers, UNIX programmers are jack of all trades 
(security, performance and ???) who make their own decisions.  

I only brought this up because of the use cases for SSH -R option is not 
obvious.

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

Re: How to configure using PDS members in JCL.

[Jon Perryman]

On Wed, 10 Jan 2024 08:47:38 -0600, Paul Gilmartin  wrote:

>On Wed, 10 Jan 2024 11:41:16 +, Colin Paice wrote:
>
>>I think all products should use this technique, instead of asking users to
>>make the same changes to multiple files as part of configuration.
>>
>It's regrettable that there's no clean way to provide defaults.  Perhapsis onl
>another JCLLIB member.

I would think that most product developers would create professional installer 
instead of using a quick and dirty solution. z/OS has many tools. ISPF Panels, 
models. Clists, REXX, TSO, IRXJCL, ISPF edit and more. It doesn't take much to 
use ISPF panels, validate user input and set defaults. Having customers modify 
JCL set statements is only useful for very simple products.

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

Re: SSH tunneling for unattended process.

[Jon Perryman]

On Wed, 10 Jan 2024 11:37:11 -0600, Kirk Wolf  wrote:

>   ssh -L 623:127.0.0.1:623  zoshost
>How EXACTLY is your userid and password exposed?

You example ignores using a script to automate SSH login. There are various 
implementations. e.g.sshpass -p !4u2tryhack ssh usern...@host.example.com

Even IBM tells you how you can use sshpass: 
https://www.redhat.com/sysadmin/ssh-automation-sshpass

Realize that it's not just sysadmins using it. 

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

Re: SSH tunneling for unattended process.

[Jon Perryman]

On Tue, 9 Jan 2024 20:18:42 -0600, Kirk Wolf  wrote:

>On Tue, Jan 9, 2024, at 5:18 PM, Jon Perryman wrote:
\>> You may wonder why you might need -R. The SSH command exposes 
identification (e.g. userid & password).
>> -L exposes a z/OS userid & password on each TN3270 computer which is not 
>> easily protected. 
>
>Exposes how? Do you mean that traffic on one socket across the loopback adapter

Amazingly the hack is much simpler. Scan thru github for userid's / passwords. 
There are opensource utilities that will find the most common occurrences. 

Consider DB2 connect in z/OS using shared RACF, ACEE and trust for every 
machine within the SYSPLEX. No userid / password (or some other identification 
method is not allowed)

DB2 connect client for Linux, Windows and ??? is completely different. For 
instance, the DB2_CONNECT for PHP is documented as follows:

db2_connect(
string $database,
?string $username,
?string $password,
array $options = []
): resource|false
Creates a new connection to an IBM DB2 Universal Database, IBM Cloudscape, or 
Apache Derby database.

This is a common Unix practice (not necessarily a best practice). People tend 
to follow the documentation.

Surprisingly, some people do not sanitize their code before uploading to github 
(or other open source repositories).  

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

Re: Netview, REXX and assembler interfaces for variable access

[Jon Perryman]

On Tue, 9 Jan 2024 10:26:54 -0600, Willy Jensen  
wrote:

> IRXSAY returns with return code 28 'A language processor environment could 
> not be located'. 

You have a coding error. Does R0 point to the ENVBLOCk? IRXSAY works in Netview 
otherwise the REXX SAY command would not work.

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

Re: EDIT MACRO REQUEST

[Jon Perryman]

On Tue, 9 Jan 2024 22:41:50 +, Steely.Mark  wrote:

>  ISPSTART CMD(%EDITREXX XX.TSS.CTM.DATA(PADM3) EMPTREXX)
>  ISPSTART CMD(%EDITREXX XX.TSS.CTM.DATA(PPCT3) EMPTREXX)

You don't want to start and stop ISPF for each member (ISPSTART). There are far 
better methods to process specific members or all members

>I would like to check each member of a PDS and if it is empty (0 Lines)
> I would like to add a line with the text of *NONE*.

I don't have access to a system and I'm doing this from memory, so this might 
not be quite right

ADDRESS ISREDIT
"MACRO (PARM1,PARM2,...)"
"(LINES) = LINENUM .ZLAST"
if lines = 0 then do
   "LINE_AFTER .ZFIRST = 'NONE'"
   "SAVE"
end
"END" 

>I would like to do this in batch using this format:

There are many ways to skin this cat. Your job would work but you might not 
have considered some alternatives. such as 

LMMLIST to get member list

Interactive ISPF 3.4 using E /(*) MACRO(EMPTREXX) 

Interactive ISPF 3.4 using M for member list. First use E line command 
MACRO(EMPTREXX). Subsequent members use = to repeat. If ISPF stats exist, then 
you can sort on lines and issue command for those with 0 lines.

Forget ISPF and use REXX. Certainly better than stopping and starting ISPF for 
each member. SYSOUTTRAP LISTDS MEMBERS to get the member list. For each desired 
member, ALLOC, EXECIO DISKR, EXECIO DISKW. FREE.

I'm sure there are more.  

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

Re: SSH tunneling for unattended process.

[Jon Perryman]

On Tue, 9 Jan 2024 11:41:45 -0600, Grant Taylor  
wrote:

>This is important to keep in mind when you are considering which way the
>port forwarded traffic will go in relation to which end is the SSH client.

Tunnels are bidirectional so it does not matter which way traffic is forwarded. 
What is important is the system with the listener port (often referred to as 
server). 

>N.B. the -L and -R are reference to the ssh /client/.

This is very simple. You are moving the listener port from one computer to 
another computer. Consider TN3270 connecting to your z/OS system. You specify 
an IP address and port on TN3270 which means you want to connect to the 
listener port on z/OS.  -R means you are issuing the SSH tunnel command from 
z/OS (listener port/server machine) whereas -L means you're means you are 
issuing the SSH tunnel command from the TN3270 computer (client). Regardless of 
-R or -L, you now have the listener port on the computer where you issue the 
TN3270 command.

You may wonder why you might need -R. The SSH command exposes identification 
(e.g. userid & password). -L exposes a z/OS userid & password on each TN3270 
computer which is not easily protected. -R exposes Unix/Windows userid/password 
on z/OS where you can fully protect them in 1 location and easily restrict 
access.

I used TN3270 as an example that is familiar to everyone in this group. But 
this holds true for all TCP connections. Some exceptions may apply but it's 
unlikely most people will be in those situations.

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

Re: ISPF setup macro

[Jon Perryman]

On Sun, 7 Jan 2024 00:31:30 +, Seymour J Metz  wrote:

>ALLOC DSN(userid.USER.ISPM) INRTDNN(MYDD) SHR
>
>So why -24 instead of -23?
>
>Changing the *3rd* key to RTDDN fixed the problem.

The word KEY is ambiguous and may not mean KEYWORD.

Total guess but considering this syntax is not UNIX compatible, maybe their 
logic is:
21  ALLOC 
22  DSN(
23  userid.USER.ISPM) 
24  INRTDNN(
25  MYDD) 
26  SHR

It should be easy enough to test by changing MYDD to MYDD56789. .

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

Re: Why do I have IEE159E MESSAGE WAITING

[Jon Perryman]

> I think that he's not getting a "flooding" condition at all, he probably just 
> hit enter on his emulator,
> IEE163I MODE= HELD IEE159E MESSAGE WAITING

The OP showed the IEE163I which showed MODE=RD with the IEE159E. It's possible 
he intentionally used hold mode and caused the message backup.

The OP needs to understand RTME=. Even when messages remain for 1 second on the 
console, a backlog can occur for various reasons.

Most consider the term "message flooding" an unexpected situation and bad. The 
reality is that each console has a purpose and the console operator wants to 
see those messages. 

"MODE=R" should never be used to clear a console because action messages will 
not be held on the console screen.

The OP specified ROUTCDE=ALL which means every syslog message will be displayed 
on this console. Obviously the OP should be using syslog instead of a console. 

The OP defaulted MSCOPE which directs messages from all systems in the SYSPLEX 
will be directed to this console. The OP said he only runs a monoplex so this 
is not a problem.

Is there anyone who actually uses RTME=1,ROUTCDE=ALL,MSCOPE=ALL and find that 
console useful with normal activity?

Understanding RTME tells the OP how the console removes messages from the 
console. Understanding ROUTCDE shows the OP the primary method to eliminate 
irrelevant messages from the console. There are many tools available to make a 
console relevant for a specific use.

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

Re: OPERLOG contention

[Jon Perryman]

On Thu, 4 Jan 2024 18:16:49 +0100, Radoslaw Skorupka  
wrote:

>Sometimes I observe IXG251I and IXG284I
>ISG251I informs the dataset is in use by another sysplex member
>IXG284I says the dataset is PENDING DELETE.

Use the DISPLAY LOGGER CONNECTIONS command to see if something unexpected is 
connecting. I always used syslog. If you only use OPERLOG, maybe SDSF or ??? is 
connected causing the delay.

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

Re: SYSPLEX JES2 SYSLOG processing

[Jon Perryman]

On Thu, 4 Jan 2024 12:31:36 -0600, Paul Gorlinsky  
wrote:

>On a z/OS 2.5 system using z System Automation V4.3, >
>The event needs to issue a 'W L' then locate the SYSLOG output for that 
>specific LPAR,

There are many ways to solve this problem and various considerations. 

>Where STC08984 is the result of parsing a JES2 $DS'SYSLOG' command 
>
>LPR1  2024002  02:01:00:45  STC08984   $HASP890 JOB(SYSLOG)
> 
>   $HASP890 JOB(SYSLOG)
> STATUS=(EXECUTING/LPR1),CLASS=STC,   
>   $HASP890
> PRIORITY=15,SYSAFF=(LPR1),HOLD=(NONE)
>LPR1  2024002  02:01:00:45  STC09720   $HASP890 JOB(SYSLOG)
> 
>   $HASP890 JOB(SYSLOG)
> STATUS=(EXECUTING/LPR2),CLASS=STC,   
>   $HASP890
> PRIORITY=15,SYSAFF=(LPR2),HOLD=(NONE)
>
>I have tried using a PIPE command without success...

You never show the PIPE command nor how or why it failed. I can only guess as 
to why it failed.

Possibility 1: Notice the indentation of the $DS output. This shows $DS writes 
multiple MLWTO's. Does PIPE only return the first MLWTO? Personally, I would 
issue D A,SYSLOG to get the jobid and forget using $DS.

Possibility 2: You issue "W L" before the $DS. Maybe SYSLOG is one of the 
products that changes it's JOBID to free JES resources. The $DS picks up the 
wrong JOBID. Solution would be to issue $DS first.

Possibility 3: "W L" does not complete before XWTR is started. 

> start an XWTR with job selection for class and JOBID...
>
>For example, 
>'S XWTR.XWTR,END=IEF176I'
>'F XWTR.XWTR,CLASS=L,JOBID=STC08984'

I suspect that "W L" command issues messages. XWTR should not be started before 
it completes. Is the JOBID available from those messages?

You might consider TRAP & WAIT. Maybe an MPF exit for the messages. Maybe you 
could use a different class for each system and omit the jobid.

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

Re: Netview, REXX and assembler interfaces for variable access

[Jon Perryman]

On Fri, 5 Jan 2024 08:10:52 -0600, Willy Jensen  
wrote:

>When running in Netview it doesn't abend, but it doesn't do anything either,
> except that the return value is valid. It returns 0, which indicates success.

Saying "returns 0" tells us nothing. 

>The function in question reads. lists and writes variables, it uses IRXEXCOM 
>for variable access, 
> IRXSTK for stack access and IRXSAY for terminal output.

There's too much going on for us to be of any help. Start with IRXEXCOM that 
creates a REXX variable with a known value and a REXX that calls this program 
and displays it. 

The ENVBLOCK should be correct and this is the simplest method to verify you 
have R0 and 2 parmlist fields pointing to it. 

Once you have this working, then you can proceed to other functions.

> r0 points to an ENVBLOCK 

Make sure you pass it correctly to IRXEXCOM (R0 and 2 parmlist fields). In 
theory, these can be 0, but why make REXX search for it when you have it in R0.

> field ENVBLOCK_IRXEXTE points to a valid IRXEXTE,
> but the fields IRXEXCOM, IRXSTK and IRXSAY in there points to the TSO 
> modules. 

REXX was first ported to TSO and those modules were coded generically. It could 
also be that a TSO environment is built into Netview. I know it's built into 
another automation product.

>I verified this by running the program under TSO.

TSO REXX is more forgiving than other environments. 

>I did look at the sample Netview program CNMS8002, but that didn't help.

I don't have access to z/OS so I can't comment on this program and the 
requirements to setup a valid REXX environment for Netview. Later, it might be 
useful to compare with your program but for now, it's not helpful.

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

Re: allowed characters in member name

[Jon Perryman]

On Fri, 5 Jan 2024 20:40:00 +, Nash, Jonathan S.  
wrote:

>We have a PDSE with member names starting with a
>left paren which were created with some old software.

Did IBM fix this with JCL DSN= using quoted dataset and member name? My guess 
is no. DSN and member name validation can be different for every interface. For 
instance, JCL DSN validation is different when the DSN= is quoted. I've used 
superzap more than once because someone quoted a DSN with lower case letters. 
I'm guessing that including blanks, special characters and omitting periods is 
acceptable for quoted datasets.

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

Re: ISPF setup macro

[Jon Perryman]

On Fri, 5 Jan 2024 17:41:45 +, Seymour J Metz  wrote:

>I've been using BPXWDYN for allocation and concatenation, but I had a problem 
>with an error code -24. 

UNIX standards provide error codes versus z/OS typically provide an error code 
and error message. There's a learning curve for diagnosing various errors. 

As for ISPF setup exec's, almost everyone has one that usually includes 
personal and group datasets. Ask for one, and I suspect someone would be 
willing to provide one.

Don't forget to specify a BLKSIZE on the alloc. The default is the first DSN's 
BLKSIZE which is used for buffer size allocation which may be too small for all 
concatenated datasets.

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

Re: LISTDSI - hardcoded dsn vs. read in from file

[Jon Perryman]

On Sat, 6 Jan 2024 04:06:59 -0600, Willy Jensen  
wrote:

>"PROF NOPREFIX works but can leave you that setting when you don't want it on 
>termination."

PROF NOPREFIX should never be used especially if you can't figure out quoting. 
You are potentially creating problems for others working on your code. More 
important, millions of programmers mastered quoting (e.g. HTML with 
JavaScript). 

Others told you to TRACE I your REXX. This should make your quoting problem 
obvious when seeing the resulting line. Without you posting this trace output, 
we can only guess at your problem.

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

Re: Why do I have IEE159E MESSAGE WAITING

[Jon Perryman]

On Tue, 2 Jan 2024 12:55:37 -0500, David Spiegel  
wrote:

>There are ways to flood the console other than ROUTCODE(ALL).

What is your point? Clearly, the OP doesn't understand console flooding 
otherwise he would not have ROUTCDE(ALL).
I gave the OP what he needs to learn to understand why he is getting the 
IEE159E.

ROUTCDE(ALL) is never used by tape drive operator consoles nor the main 
operator console. What hardware console finds ROUTCDE(ALL) useful. Starting an 
STC can generate 1,000 messages which take more than 1 minute to automatically 
clear from a ROUTCDE(ALL) console causing IEE159E  to be on the console for 1 
minute because of RTME(1). 

For someone to be bothered by IEE159 caused by ROUTCDE(ALL), they are using it 
for something unusual. In this case, my guess is that he's testing generic 
abend recovery but instead of using SDSF SYSLOG, he's using a hardware console.

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

Re: Help Trying to determine where abend occurred

[Jon Perryman]

On Mon, 1 Jan 2024 12:00:15 -0500, Joseph Reichman  
wrote:

>I am thinking the doc says I can issue CSVQUERY in AR mode I might try to put 
>SDWAPRIM on my DU-AL 
>
>And and maybe get the name of the PC routine 

Since this is about updating the CBT generic abend recovery example file 
instead of creating an actual application, what is the purpose of demonstrating 
bad programming practices.

First, the ESTAE may be running non-authorized and not have access to the 
DU-AL. A lesser experienced programmer may not understand the implications.

Second, Good PC routines have abend recovery code that gracefully recovers. The 
example should be about that rather than including all possible variations. For 
example, is there method to percolate the SDWA in such a way that the ARR can 
update important information in the ESTAE SDWA.

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

Re: Why do I have IEE159E MESSAGE WAITING

[Jon Perryman]

On Tue, 2 Jan 2024 11:36:34 -0500, Joseph Reichman  
wrote:

>I have CON(N) and DEL(RD). Wondering why this happening

The most likely cause is ROUTCODE(ALL) and RTME(1). How you solve this problem 
depends on why you need all messages to that console.

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

Re: PLIST8=NO?

[Jon Perryman]

On Sat, 30 Dec 2023 14:34:16 -0600, Paul Gilmartin  wrote:

>In  

>I see no MF=L.  What are the reentrancy concerns?

Scroll to the next sections to see the execute and list forms of the CALL macro.

>But can PLIST8=YES and PLIST8=NO be specified together?

HLASM ignores all but the last one I believe (or maybe it's the first). I never 
code args twice so I can't tell you which or if HLASM now rejects it.

>default is:
>If running AMODE 64, PLIST8=YES
>If not running AMODE 64, PLIST4=YES

This is incorrect because macro's don't understand run time. This actually 
refers to the AMODE statement in your source code. 

More important is the program being called. Does it expect PLIST4 or PLIST8. 
The assumption is that if you specify AMODE 64, then you are calling programs 
that expect PLIST8=YES.

>Register Contents
>1 Address of the parameter list, if present
>
>Are the contents unpredictable if the parameter list is absent?

Test it. It's simple enough to see if R1 is zeroed. IBM's philosophy is not to 
change an undesired behavior that may adversely affect existing code. 

>If //  EXEC PGM= refers to an AMODE 64 program, does the initiator
>provide an AMODE 64 plist?

This would be my expectation but it's easy enough to test.

>Are the semantics of PLIST8=NO and PLIST4=YES identical?

Only a bad coder would specify PLIST8=NO instead of PLIST4=YES. Make it easy 
for others to understand your intentions because PLIST8=NO is not clear.

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

Re: Question about IEAMSCHD

[Jon Perryman]

On Sat, 30 Dec 2023 19:52:42 GMT, esst...@juno.com  wrote:

>Binyamin wrote
>>What is a "non-authorized" address space?
>Key 8 Problem state job/started task 

He's telling you there is no such thing as a "non-authorized" job/STC. A 
job/stc does not have a key or state. Running authorized is different from the 
key and state. An RB (e.g. PRB or IRB) running unauthorized cannot change it's 
key and state whereas an RB (e.g. PRB or SRB) running authorized can switch key 
and state.

Nothing stops an authorized RB (e.g. SRB or PRB) switching to & from key 8 
problem state. 

>If you want to run code that should not be in supervisor state, have the SRB
>create an IRB.
>.
>Can You elaborate on this ?
>Did You mean SRB Routine ?
>How does the SRB create an IRB ?  I must have missed something.

If you have code that must run unauthorized key 8 problem state, then you can 
use the SCHEDIRB macro that runs an RB called IRB. Chances are this is overkill 
and switching your SRB to key 8 problem state is probably sufficient.

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

Re: Checking status of multiple datasets in CLIST and REXX

[Jon Perryman]

On Sat, 30 Dec 2023 19:33:34 +0200, Binyamin Dissen 
 wrote:

>On Fri, 29 Dec 2023 14:47:29 + Seymour J Metz  wrote:
>
>:>I need to check whether any of a list of datasets exists and whether any of 
>a list of ddnames is allocated. I'd rather not trap and parse the output of 
>LISTALC and LISTCAT, and I'd rather not call LISTDSI for each one. Is there a 
>simple way to do that in REXX, or would it be better to write a small service 
>routine in assembler?
>
>:>I don't have a requirement to handle XTIOT.
>
>The elephant in the room - why?

The OP has never told us what problem he was solving although the last messages 
hint at it. The original messages implied he was developing an ISPF 
application. We now know that he doesn't have SYSPROG access and he wants to 
setup the ISPF environment. The elephant in the room is now  mixed dataset 
attributes for concatenated DD's. E.g. ISPPLIB is by default RECFM=FB,LRECL=80 
but he needs concatenated datasets with attributes like RECFM=VB,LRECL=180.

> As you are worried about performance, it appears to be something that will
> need to run quite often. How will you use this information?

The OP has never stated this is about performance. The LISTDSI requirement 
being a performance issue has become unclear with the last few messages. He 
implies it will only be used at ISPF initialization. He's said that this is 
about setting up the ISPF user environment rather that ISPF application 
environment setup.

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

Re: Question about IEAMSCHD

[Jon Perryman]

On Sat, 30 Dec 2023 15:36:44 GMT, esst...@juno.com  wrote:

>I would like to schedule an SRB using IEAMSCHD to a non-authorized 
>Address Space - I would prefer not to place the target SRB routine in common 
>storage.

It's important to tell us about the problem you need to solve because you only 
told us SRB is how you will solve that problem. Maybe XMEM, PC routine or ??? 
is a better solution. SRB routines are required to be in common but maybe your 
problem requires the SRB routine be in common. Do you actually need an SRB 
because it must execute in that address space?  

You schedule an SRB to a TCB so I'm guessing you meant an unauthorized TCB. 
This is irrelevant unless you have code that must run unauthorized as opposed 
to running the SRB in problem state. 

If your SRB routine is not in common, then you most likely use XMEM (some 
obscure exceptions) where you most likely use primary, secondary, home (again 
some obscure exceptions). Learn how to use primary, secondary and home. Most 
important, be consistent about how you use it otherwise you could have a mess 
on your hands.

>Can someone please clarify this statement regarding IEAMSCHD -
>.
>"To run an SRB routine in a different address space from the 
>scheduling code, the SRB routine must be either in a different 
>program that is accessible from the target address space, or 
>in the common storage together with the scheduling code."
>.
>The above was taken from Example 7 of IEAMSCHD -
>https://www.ibm.com/docs/en/zos/2.4.0?topic=ixg-ieamschd-schedule-srb

Example 7 specifies ENV=STOKEN which potentially involves a third address space 
where the SRB routine must be addressable. The routine cannot be included with 
the IEAMSCHD because it's not addressable by the SRB.  

>It makes no reference to the authorization of the target srb routine. 

SRB's are authorized but that does not prevent your SRB from switching to / 
from problem state.

>I suspect its implied this is an integrity issue; as the target SRB Routine 
>would be loaded by the Non Authorized Address Space, AND the Target
>SRB Routine is entered in supervisor state.

This is not an integrity issue because IEAMSCHD specifies the address of the 
SRB routine and it is your responsibility to ensure this address is for code 
that does not create an authorization exposure. This is a requirement for 
running authorized and has nothing to do with SRB. You never allow unauthorized 
programs to pass an executable address to your program running authorized 
regardless of the environment you are running..

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

Re: SSH tunneling for unattended process.

[Jon Perryman]

On Sat, 30 Dec 2023 04:02:22 +, kekronbekron  
wrote:

>So SSH is used for auth and encryption, 

SSH has multiple features. Understand that SSH primary feature is "Secure 
SHell" where you can issue UNIX commands on a remote UNIX system thru an 
encrypted connection. You must login to that remote system thru SSH using one 
of the implemented methods (e.g. userid / password). SSH is delivered on most 
UNIX systems although it may require some configuration.

> and mainly just as a tunnel (as the first mail mentioned).

Port tunneling is a second feature which I believe disables shell commands 
(never bothered to try it). There's plenty of documentation on the internet 
(e.g. https://linuxize.com/post/how-to-setup-ssh-tunneling/).

An unencrypted 3270 connection:
tn3270 -host MVSsystem.com -port 3270 

Encrypted 3270 connection
ssh -L localhost:100:MVSsystem.com:3270 unix_use...@mvssystem.com
TN3270 -host localhost -port 100

Specifying localhost is important because it limits access to his specific 
machine. 0.0.0.0 would allow other machines to access MVSsystem.com thru this 
machine.

The server and client can be on either side but I always used the client app on 
the machine issuing the SSH with the server on the other machine. 

>The traffic that's tunnelled may be any protocol or a TCP socket.

In theory, yes but I've only used it with TCP.

> and the goal is to just use SSH's ubiquity (say port 22) to make life easier 
> w.r.t firewalls and all that.

The goal is encryption which is provided by SSH instead of building it into the 
application. As for firewalls, I don't see how it changes anything. Firewall 
implements NAT, filtering, proxy servers and ???. I would think that 
implementing SSL into the client / server would be more secure.

>I wonder if spiped fits the bill - https://www.tarsnap.com/spiped.html

 I'm not familiar with SPIPED but from that documentation, it appears it could 
be used for this purpose. The drawback is that you must install the client.

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

Re: Checking status of multiple datasets in CLIST and REXX

[Jon Perryman]

On Fri, 29 Dec 2023 12:15:31 -0600, Paul Gilmartin  wrote:

>Does that show DSNs that are ENQed but not allocated?

What ENQ are you referring? QNAME SYSVSAM as opposed to SYSDSN? You would need 
to include those QNAMEs in your query.

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

Re: Checking status of multiple datasets in CLIST and REXX

[Jon Perryman]

On Fri, 29 Dec 2023 12:35:58 -0600, Jon Perryman  wrote:

>QUERYENQ documents that it is "SYSTEM" enq level but datasets are "SYSTEMS". 

Sorry, my bad. I just saw a ZENSCOPE variable which implies bot SYSTEM and 
SYSTEMS are returned. STEP does not appear as a possible value.

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

Re: Checking status of multiple datasets in CLIST and REXX

[Jon Perryman]

On Fri, 29 Dec 2023 18:10:08 +, Seymour J Metz  wrote:

>I should be able to use any BPXW... service that doesn't require dubbing.

I doubt that BPXWDYN requires dubbing but Some minimal dubbing should be 
available because of TCP requirements.

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

Re: Checking status of multiple datasets in CLIST and REXX

[Jon Perryman]

On Fri, 29 Dec 2023 18:01:19 +, Sri h Kolusu  wrote:

>>> Does CLIST or REXX provide an interface to ENQ?
>
>Via ISPF service named QUERYENQ
>
>https://www.ibm.com/docs/en/zos/2.5.0?topic=services-queryenqquery-system-enq-data

QUERYENQ documents that it is "SYSTEM" enq level but datasets are "SYSTEMS". 
They are very different things. The XSYS=YES option is unclear about whether it 
switches to "SYSTEMS" enq but mentions high overhead. Since SYSTEMS enqueues 
are propogated throughout the SYSPLEX, I'm guessing that it queries each GRS in 
the SYSPLEX for SYSTEM enqueues because of this overhead

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

Re: Checking status of multiple datasets in CLIST and REXX

[Jon Perryman]

On Fri, 29 Dec 2023 11:36:38 -0600, Paul Gilmartin  wrote:

>On Fri, 29 Dec 2023 11:13:18 -0600, Jon Perryman  wrote:

>>REXX function SYSDSN( ) will determine if a dataset exists without the 
>>overhead of LISTDSI.
>> 
>Does it report allocated status as the OP requested?

The OP had 2 requests. I believe BPXWDYN INFO only tells you about allocated 
datasets. It does not tell you if a dataset exists which is solved by using 
SYSDSN( ). You could BPXWDYN ALLOC to determine if it exists but SYSDSN( ) 
would be a better solution.

>in 
><https://www.ibm.com/docs/en/zos/3.1.0?topic=functions-using-sysdsn-function> 
>i see:
>PROTECTED DATASET
>UNAVAILABLE DATASET

These are documented at https://www.ibm.com/docs/sr/zos/2.1.0?topic=tef-sysdsn

Protected dataset requires member name be specified and means you don't have 
SAF access to the dataset.

Unavailable dataset means someone has exclusive enq for the dataset.

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

Re: Checking status of multiple datasets in CLIST and REXX

[Jon Perryman]

On Fri, 29 Dec 2023 17:00:37 +, Sri h Kolusu  wrote:

>How about issuing ENQ in loop for all the datasets in the list?  
>Once you hit a dataset that is already allocated you can quit the search.

ENQ is not appropriate for this type of problem. Dataset allocations are 
SYSTEMS ENQ which means the dataset is allocated somewhere in the SYSPLEX. 
While you could query the jobs enqueues, why not query the allocations.

My gut tells me that this question stemmed from the ISPF allocations question. 
The solution in that case would be to use BPXWDYN CONCAT if it exists or use 
the CONCAT command from the CBT tapes.

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

Re: ISPF setup macro

[Jon Perryman]

On Fri, 29 Dec 2023 13:10:27 +, Seymour J Metz  wrote:

>I'm not trying to setuup an ISPF application environment.; I'm trying to set 
>up a TSO user environment. 

TSO user environment limits your options. LIBDEF is not suitable because it is 
lost or replaced at various times. ISPxUSR is not suitable because it is 
searched first and requires LIBDEF.

>At other shops I've done it by reallocating the standard concatenations when 
>the user libraries existed; I want an alternative to that.

I believe BPXWDYN has a CONCAT function. I believe it's a reallocation under 
the covers but won't swear to that.

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

Re: Checking status of multiple datasets in CLIST and REXX

[Jon Perryman]

On Fri, 29 Dec 2023 09:40:33 -0600, Paul Gilmartin  wrote:

>On Fri, 29 Dec 2023 14:47:29 +, Seymour J Metz wrote:
>>I need to check whether any of a list of datasets exists and whether any of a 
>>list of ddnames is allocated.
>> 
>How useful would BPXWDYN(INFO ,,,) be?
>

REXX function SYSDSN( ) will determine if a dataset exists without the overhead 
of LISTDSI.

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

Re: ISPF setup macro

[Jon Perryman]

On Thu, 28 Dec 2023 02:01:54 +, Seymour J Metz  wrote:

>I'm trying to use LIBDEF as an alternative to freeing and reallocating the 
>standard ISPF concatenations.

LIBDEF is commonly used to eliminate the need for reallocating standard ISPF 
DDs. There are situations where ISPxUSR is useful but I suspect most don't use 
it. I'm sure CBTTAPE.ORG has multiple examples of setting up the ISPF 
application environment.

>Yes, typo for ISPxUSR. The allocation is before starting ISPF. The 
>documentation shows 
> those ddnames as being picked up automatically only for the DATASET keyword.

If you are developing an application, then I suggest avoiding ISPxUSR unless 
your requirements need it. Using LIBDEF for products means the datasets are 
freed when not in use.
 
>I'm aware of the contingent that advocates NOVALUE, but I don't agree with 
>that perspective.

ISPF works as designed and everyone must follow these rules or request they be 
changed.

>To clarify, my logon panel calls userid.AD.CLIST, which does allocations, 
>ALTLIB and TSOLIB before calling ISPF. 

A requirement for products that I've worked on is that everything is contained 
within the REXX and nothing needs to be modified in TSO other than making the 
REXX available to the users who need it. 

> I want to add, e.g., user panels, in a form that will persist across START 
> (ISPSTRT).

Persistence is typically achieved through REXX using the appropriate LIBDEFs. 
You would still need a REXX with permanent DD's because you should have a 
different ISPF ZAPPLID for your application.

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

Re: ISPF setup macro

[Jon Perryman]

On Wed, 27 Dec 2023 19:59:26 +, Seymour J Metz  wrote:

What you are asking does not make any sense.

>Do the LIBDEFs with DATASET pick up SPPxUSR if there is no ID keyword? 

I assume SSPxUSR actually means ISPxUSR. I can only comment from what I've read 
because ISPxUSR does not solve my problems.

ISPxUSR is an actual DDName that must be allocated prior to starting ISPF which 
makes it valid for all applications with active LIBDEF. The documentation tells 
you the search sequence. If I remember correctly, only specifying the library 
name disables the LIBDEF. A quick test of specifying DATASET without the ID 
will tell you it's behavior. Remember that ISPxUSR does not change during the 
ISPF session. Remember you must avoid LIBDEF and ISPxUSR member collisions if 
other applications are needed.

>address TSO ALTLIB ACTIVATE 'USER(EXEC)'

To avoid REXX variable substitution, you should quote the entire ALTLIB 
command. Some could inadvertently code altlib="badcmd" in the REXX.

ALTLIB is valid with and without ISPF. Executing the command prior to starting 
ISPF may affect its behavior.

You will need to find the method that best suits ISPxUSR behavior.  

>address ISPEXEC ISPSTRT 'PARM LIBDEFARM(3.4)'

I don't think you mean "ISPSTRT". There is an ISPF command called "START" which 
starts another logical ISPF screen but I don't think that is what you are 
attempting.

I think you actually mean the TSO command ISPSTART which I believe is an alias 
for ISPF and PDF commands that start ISPF. Realize that ADDRESS ISPEXEC is not 
available until you start ISPF.

>I want to write a REXX script to initialize an ISPF session, 

Session and initialize are not clear. I assume "session" refers to starting 
ISPF instead of splitting the logical screen. You mentioned ISPxUSR so you 
probably only need to LIBDEF the appropriate libraries. My guess is that you 
want "ISPF CMD(%MYREXX)" If I remember correctly, the syntax is similar to 
ISPEXEC SELECT.  

> assuming that another script has already allocated the necessary user data 
> sets and issue TSOLIB. 

Since you mentioned ISPxUSR, maybe ISPLUSR would be more appropriate than 
TSOLIB.

>Tentatively I assume that I need
>address ISPEXEC LIBDEF ISPPLIB DATASET
>address ISPEXEC ...
>address ISPEXEC ISPSTRT 'PARM LIBDEFARM(3.4)'

"ISPEXEC ISPSTRT" doesn't look right. I would expect some form of "ISPEXEC 
SELECT".

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

Re: RETRY - was ARR and CSVQUERY

[Jon Perryman]

Hi Tom,

I think Peter misinterpreted your question because you provided too much 
information.

> Peter Relson wrote:
> I'm now thinking you just meant that you were surprised that the recovery 
> routine did not complete successfully.

I think you are asking the academic question if there is a time when RTM is 
disabled or inactive. Or if you can encounter a situation where RTM is disabled 
or inactive. Maybe you can form your question in terms of RTM behavior that you 
want to understand.

To clarify LPAR DISABLED WAIT state, I believe it's part of RTM. While it's a 
drastic form of recovery, the LPAR should never be left running random 
instructions. My point was that I believe that RTM always provides some sort of 
recovery even if the recovery is not actual recovery.

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

Re: RETRY - was ARR and CSVQUERY

[Jon Perryman]

On Sat, 23 Dec 2023 21:02:18 +0200, Binyamin Dissen 
 wrote:

>On Fri, 22 Dec 2023 15:07:33 -0800 Tom Brennan 
>wrote:
>
>:>So are you implying that in z/OS there are environments where I can run
>:>a program without any built-in basic recovery?
>
>Yes. Most batch jobs run that way.

Recovery in batch jobs is not obvious. Consider step termination (e.g. 
DISP=(NEW,CATLG,DELETE), free user storage, in-flight database transactions and 
probably more),

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

Re: RETRY - was ARR and CSVQUERY

[Jon Perryman]

On Sat, 23 Dec 2023 15:54:38 +, Peter Relson  wrote:

>I view their being two main reasons for recovery (and not necessarily in the 
>order I show):

Everyone ignores the third main reason which is stopping abends from becoming 
catastrophic. IBM knows this is ignored and plans accordingly. IBM uses 
multiple techniques that are not obvious. 

For instance, consider how IBM handles the most dangerous z/OS user exit which 
is the last one anyone thinks. It's not allocation, job, interpreter nor any 
other exits that people think.

It's the message user exit. To stop people from doing something dumb, IBM 
requires a user exit for a specific message id (see SETPROG). IBM knows a 
single message user exit would invite catastrophic situations because it's far 
too complicated and most people won't understand the recovery requirements. You 
can code specific IOS, JES, z/OS and more message exits but the concept is that 
recovery only affects a small portion of the system.

IBM allows messages thru the SSI but few people venture onto the SSI because of 
the complexity. The expectation is that anyone using the SSI will use advanced 
techniques for messages that can be issued from almost any environment. SSI 
programmers must understand how and when to handle locks, FRR, ESTAE, running 
disabled and everything else that can affect SSI code.

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

Re: RETRY - was ARR and CSVQUERY

[Jon Perryman]

On Fri, 22 Dec 2023 18:35:52 -0800, Tom Brennan  
wrote:
>Never mind, my question wasn't clear and I don't know how to better explain it.
>>
>>> So are you implying that in z/OS there are environments where I can run
>>> a program without any built-in basic recovery?

Sorry I misunderstood that you are asking if there is a user exit that is 
called when all abend recovery is disabled.

What I intended to say was "IBM supplying useful recovery". For instance, 
recovery can range from causing machine wait states to fully recoverable 
environments like dynamic exits which rarely cause disruptions.

I suspect that all user exits run when PSA PROGRAM CHECK PSW is enabled so some 
type of recovery should be active although it may not be useful. If you want to 
know this, then you'll need to ask Peter Relson.



 

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

Re: RETRY - was ARR and CSVQUERY

[Jon Perryman]

On Fri, 22 Dec 2023 15:07:33 -0800, Tom Brennan  
wrote:

>So are you implying that in z/OS there are environments where I can run
>a program without any built-in basic recovery?

I don't condone omitting recovery but CBTTAPE.ORG has many exits that do not 
include any recovery. The vast majority of exit points have built-in recovery 
which does a great recovery job. Someone mentioned JES exits but even those 
even those exits mostly ask (not require) you simply set a return code.  IBM 
avoids detrimental situations by disabling an exit if it has abended too often.

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

Re: RETRY - was ARR and CSVQUERY

[Jon Perryman]

On Fri, 22 Dec 2023 10:26:41 -0800, Tom Brennan  
wrote:

>But I think it's overkill for a recovery routine to have it's own
>recovery routine (if that's even possible in a JES2 exit environment).

z/OS exits have built in recovery, diagnostics and recursive abend handling. 
Since IBM did the work for you in exits, there's no need to duplicate that part 
of recovery.

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

Re: RETRY - was ARR and CSVQUERY

[Jon Perryman]

On Thu, 21 Dec 2023 13:37:21 +, Peter Relson  wrote:

>>Jon P wrote
>>The SDWA can be referenced by alet 0 or alet 2.

>if this was meant to indicate that you could choose either, that wouldn't be 
>true for an ESTAEX or ARR or IEAARR established for primary <> home.

Hi Peter,

You missed my point where I was trying to get the OP to understand some 
fundamental mistakes made with ARR's and PC routines. Maybe you can help 
clarify what I did not make clear. My comment about SDWA and alet 2 (HOME) was 
prefaced with the code provided. It was not to say alet 2 should be used to 
reference SDWA but to point out duplication of alets.

The OP's objective is to enhance CBTTAPE csect GRECOV which is recommended as a 
one size fits all recovery routine (e.g. ARR, FRR, ESTAEX, SRB and more). I 
would hope we could give him a little guidance to avoid confusing unsuspecting 
soles who decide to use this as their recovery concept. At the moment, GRECOV 
simply displays a few diagnostic messages. He's being secretive as you've noted 
but he's mentioned CSVQUERY, PRIMARY, SECONDARY, HOME and a few SDWA fields.

Problem 1: He believes primary, secondary and home are predictable to GRECOV 
without understanding the specific PC definition. For GRECOV, secondary and 
home should not be used because they are completely unpredictable (PC 
definable). Primary is somewhat predictable where executable code, SDWA and PC 
storage obtain can be referenced. 

For example, the op mentioned SDWARBAD which is a pointer to the RB address. 
This address requires GRECOV analyze the PC definition to determine which (if 
any) ALET has access to the RB address.  

Possible problem 2: Does an abend in the PC routine percolate outside the PC 
routine? E.g. an ESTAE prior to the PC call. Either way, it requires special 
handling by the users of GRECOV.

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

Re: RETRY - was ARR and CSVQUERY

[Jon Perryman]

On Wed, 20 Dec 2023 00:56:14 -0500, Tony Harminc  wrote:

>On Wed, 20 Dec 2023 at 00:48, Jon Perryman  wrote:
>> I locate the base reg and verify the branch around the module eyecatcher

>The trick is to not abend when you try looking at the eyecatcher. 
> A wild branch can easily destroy what you think is the base

There is no trick. All recovery risks secondary abends and at the very least 
must issue a message that recovery failed. This just adds one more use case 
that you can easily add to your secondary recovery. Secondary abends are very 
rare but you must always plan for them. For ARR and SETFRR routines, it's a 
little more complicated than ESTAEX but none the less you must plan how they 
will be handled.

>Where do you get the base reg?

You design according to what you know (e.g. abends, base regs, module 
eyecatchers and more). 

1. My product has a unique savearea (R13) eyecatcher. If it matches, the base 
reg is a known register. My code is what people call baseless but I chose to 
place the constants (including program eyecatcher with PTF) before the 
executable code. This makes it very IPCS friendly. There are other options you 
can use for baseless code which can also provide eyecatcher with offset but I 
won't delve into that here.

2. Base reg is always less than the abend address.

3. Base reg is always within a reasonable offset for assembler (e.g. 3 regs on 
using is 12K). 

4. More but I can't be bothered to list them here.

All the products I've worked on use this method because creating simple / 
useful diagnostics because it greatly simplifies problem solving for the 
customer and vendor. Consider when CSVQUERY.works giving you an offset into a 
LOAD MODULE name. You need to map the load module, find the CSECT at the module 
offset, subtract that offset to determine the CSECT offset and look up the PTF 
level for the CSECT. When CSVQUERY fails, I need you to send a dump to get this 
information. It's far easier for customers to simply cut and paste the 
diagnostics messages which has the CSECT and offset. 

This process is the same for user programs but realize when you get annoyed 
with this process, you are the one to blame.

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

Re: RETRY - was ARR and CSVQUERY

[Jon Perryman]

On Tue, 19 Dec 2023 21:20:29 -0500, Joseph Reichman  
wrote:

>It seems to me that SDWA has values from the home address space such as 
>SDWARBAD 

For the CBT recovery example, the PC definition has PRIMARY (alet 0) and HOME 
(alet 2) point to the PC owner ASID. Secondary (alet 1) is the PC caller 
address space. The SDWA can be referenced by alet 0 or alet 2. SDWARBAD is in 
the PC caller address space which must use alet 1 which is not HOME.

All this can change depending upon the PC def or if it's called from another 
PC. Referencing each of the SDWA fields is dependent upon the environment.
  
>If you are looking for entry point modname if primary CSVQUERY would give you 
>that 

CSVQUERY will not always work which is why IBM diagnostic messages do not 
include the load module name and entry point. This is why I locate the base reg 
and verify the branch around the module eyecatcher (including length). I use 
this same standard in my modules to be compatible.  

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

Re: RETRY - was ARR and CSVQUERY

[Jon Perryman]

On Tue, 19 Dec 2023 23:13:46 GMT, esst...@juno.com  wrote:
.   
>I have been following the thread on ARR and CSVQUERY, and started   
>thinking about a retry routine.

The discussion is about a CBT file that has been referred to as "generic 
recovery". I took a 2 minute look at it. It does not do any type of recovery 
and I spotted multiple bugs. It only displays some diagnostic data which is not 
the hard part. 
If you are doing this for a specific project, then you should ask questions and 
describe what you want to accomplish. There are many approaches to solving 
recovery problems.

>When I hear the words "retry", I interpret that as: re-execute the  
>failing instruction.

Completely false interpretation. RETRY is a word that IBM chose because there 
was not a better word that describes the true functionality.  

Retry is the address where you want to continue. Consider IBM's use of abend 
recovery. For example, S0C4 abend is used to verify the existence of an 
address. 

In my case with a product, I close the current unit of work and then dispatch 
the next unit of work.
 
>Whether it's an ARR or ESTAE, it is my understanding that a Recovery
>Routine may be capable of retrying a failed instruction. 

You can choose to retry the failed instruction but remember the definition of 
insanity is trying the same thing over and over again while expecting different 
results. 
 
>Dose anyone have any experience in developing a ESTAEX or ARR
>where they actually retry the failing instruction ?  

Simply retrying the failed instruction serves no useful purpose.

> How should a recovery routine determine which register or data area is 
> invalid ?

You design your code to specifically handle this situation. In IBM's S0C4 case, 
they know the failing register or they look at the failing instruction. 
 
  
>How many times should a recovery routine try to re-execute the same
>failing instruction ? 

Your design dictates how many times you should retry.

>I guess I'm looking for a strategy for correcting the failing instruction. 
> 

It's very rare that you need to retry a failed instruction. Why don't you use a 
strategy that doesn't need to retry the failing instruction?

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

Re: Z/OS Survey - Unusuall system commands

[Jon Perryman]

On Tue, 19 Dec 2023 16:23:30 +0200, Itschak Mugzach 
 wrote:

>Was it ROUTE command? ;-) Don't tell them. We fill our refrigerator using
>these weaknesses...

I always hated when auditors bashed us for non-issues but then again, these 
were often simple to show we took some sort of futile action. ROUTE is limited 
to the sysplex and console is normally the same people in control of the entire 
sysplex. Even if you include the programming test systems in the sysplex, they 
use SDSF and never need to issue a console commands. Automation is more likely 
to be an exposure than the ROUTE command.

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

Re: Z/OS Survey - Unusuall system commands

[Jon Perryman]

On Tue, 19 Dec 2023 10:12:21 +0200, ITschak Mugzach  wrote:

>There are some MVS commands that are hard to understand how and why they
>were created.

You mean "console commands" because MVS is only 1 product that implements 
console commands. Each subsystem on the SSI can optionally receive commands 
(e.g. VTAM v net and d net). Additionally, other products like TCP don't need 
the SSI and implement the modify command.
 
> What bothers me is the fact that the input of the commands
>that modify MVS behavior allows input from private dataset. 
> I wonder why IBM allows such a scenario.

There are various benefits to specifying datasets. The most important is to 
avoid an outage (e.g. IPL or restarting a product to correct a problem), 
Another benefit is the change is temporary to a non-production dataset.

>How frequent do you use these commands (if ever).

As a product developer dealing with customers, I've dealt with customers 
production environments ranging from very secure to very flexible. It's rare 
that these commands are needed. A few customers don't want to touch production 
datasets and prefer to make temporary changes. 

Does a company consider temporary changes thru the use of a temporary dataset 
any more risky than modifying production datasets or using tools like Omegamon 
to make those temporary changes without the use of a dataset?

>*SETLOAD* allows on-the-fly change of parmlib concatenation using a dataset

I would expect specifying a dataset on SETLOAD would be extremely rare and only 
needed if multiple members are affected. For instance, you have an OEM product 
that uses PARMLIB for configuration options that you need implemented outside 
the regular maint window.

>TCPCIP *OBEY* command allows specification of TCPIP configuration from a 
>private library

TCP configuration files can be datasets, PDS members or UNIX files. For those 
customers that use sequential datasets, specifying a DSN is the best option 
because you're dealing with a lesser experienced customer who hasn't planned 
for backup and changing TCP config.

> and how do you identify the use 

Identifying console commands that allow specifying datasets requires you review 
all products that support console commands. Job scheduling software may allow 
specifying a dataset on the demand request. Automation by local sysprogs can 
intercept commands, modify them or process the command. System monitors can 
sometimes allow DSN. Identifying where DSN is allowed requires you put in the 
effort because there won't be a single document telling you where DSN is 
allowed.

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

Re: SMP/E question of the day

[Jon Perryman]

On Mon, 18 Dec 2023 08:12:33 -0600, Paul Gilmartin  wrote:

>In ,
>the entire description of the MAME parameter syntax is:name
>There is no mention of a limit of length.  You're making that up.

The SMP/e programming API tells you 
https://www.ibm.com/docs/en/zos/3.1.0?topic=command-valid-subentry-types about 
all the CSI entries.

First, ++ZAP does not create an SMP/e entry. The NAME specified references an 
entry that already exists. In this case, a MOD entry. 

Second, the MOD ENAME length is 8. In fact, look at each entry type and you 
will see all ENAMEs are 8 (or less) in length. 

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

Re: SMP/E question of the day

[Jon Perryman]

On Sun, 17 Dec 2023 14:10:51 -0600, Paul Gilmartin  wrote:

>On Sun, 17 Dec 2023 12:52:49 -0600, Jon Perryman wrote:
>>
>>++ZAP does not document limitations already described in ++MOD and ++JCLIN.
>>
>And yet it says: 
><https://www.ibm.com/docs/en/zos/3.1.0?topic=statements-zap-mcs>
>
>name
>... The name can contain any alphanumeric characters and $, #, @, or hex 
> C0.
>
>Is that documenting limitations already described, introducing further 
>limitations,
>or fully describing the lexical syntax.  The reader should be told.

Clearly this sentence is not necessary and as you say somewhat confusing why it 
is mentioned. In fact, "name" documentation should be rewritten. NAME must 
specify a valid SMP/e MOD entry. To say module member is outside the context of 
SMP/e if it does not reference an SMP/e object.

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

Re: SMP/E question of the day

[Jon Perryman]

On Sun, 17 Dec 2023 11:01:23 -0600, Paul Gilmartin  wrote:

>The CSECT() option of the ++MOD MCS should clarify this.  But it's optional,
>and I don't know that it's verified, even if present.

CSECT defaults to ++MOD name which generates BINDER REPLACE statements. 
Specifying additional CSECT names allows one ++MOD to contain multiple CSECTs. 
I suspect that this is important for packaging LE programs.

>Fiendish case: a CSECT in one ++MOD is identical to the name of a different 
>++MOD.

Having the same CSECT name in different ++MODs is not a problem. A problem only 
occurs if both MODs are included into the same LMOD.

>Why are TALIAS and DALIAS mutually exclusive?

++MOD have a dist library DDN but do not have a target library DDN. DALIAS has 
an obvious implementation. TALIAS on the other hand is used for something that 
is not obvious because the MOD does not physically exist as a member in a 
target library. What and where are you going to attach an alias name. I suspect 
that TALIAS has a meaning in both target and dist that conflicts with DALIAS.

>SMP/E doesn't understand its own alias names.  Once, as an experiment I created
>an alias.  In standalone JCL SYSLIN "INCLUDE alias" worked.  Failed in SMP/E.
>Went to SR.  Got WAD.

An alias is not a SMP/e object so JCLiN cannot process an alias. All SMP/e 
objects are unique but the same alias can be used for many objects. SMP/e 
cannot identify the SMP/e object which affected.

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

Re: SMP/E question of the day

[Jon Perryman]

On Sun, 17 Dec 2023 15:12:59 +, Seymour J Metz  wrote:

>Given that a csect may be included in multiple program objects (is there a 
>generic term for LM & PO),
> I don't see whwre you would need an lmod parameter on the NAME statement.

It's rare but a ++ZAP circumvents a problem that the customer is experiencing. 
If the workaround is for a very specific situation, restricting the change to a 
specific LMOD may be necessary. 

>Does the 8 character limitation apply to alias names? PDSE limits main names 
>too 8.

I suspect that alias names are limited to 8 because IBM added SYMLINK for long 
name support needed by UNIX.

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

Re: SMP/E question of the day

[Jon Perryman]

On Sun, 17 Dec 2023 09:02:37 -0600, Paul Gilmartin  wrote:

>On Thu, 14 Dec 2023 22:22:51 +, Kurt Quackenbush wrote:
>
>>> NAME ABCDITSK ABCPROC#C C_CODE
>>I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and 
>>CLASS names 
> specified on the IMASPZAP NAME statement.  CSECT name ABCPROC#C is 9 
> characters.
>> 
>You're making that up.  The SMP/E Ref. for ++ZAP mentions no such maximum.

He's not making it up the 8 char limit. ++MOD and ++JCLIN create those SMP/e 
entries. ++ZAP does not document limitations already described in ++MOD and 
++JCLIN.

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

Re: SMP/E question of the day

[Jon Perryman]

On Thu, 14 Dec 2023 11:54:28 -0500, Phil Smith III  wrote: 

>++VER(Z038) FMID(VABC840) .
>++ZAP(ABCDITSK) .
>NAME ABCDITSK ABCPROC#C C_CODE
>--NAME ABCDITSK ABCPROC#C C_CODE. 
>GIM23101E ** THERE IS A SYNTAX ERROR IN A ZAP CONTROL STATEMENT FOR MODULE
> ABCDITSK IN SYSMOD ABC8401.

Like ++JCLIN, ++ZAP contains pseudo statements instead of actual superzap 
statements. SMP/E processes these pseudo statements which are sometimes 
incompatible with the real functionality. This is an SMP/e error message (not 
superzap). SMP/e may or may not support certain features. You will need to 
determine how SMP/e handles the various NAME statement options.

Consider a simple ++ZAP where in superzap where you specify NAME MYLMOD 
MYCSECT. Your first problem is that you don't zap an SMP/e LMOD. Instead, you 
would ++ZAP (MYCSECT) and use NAME MYCSECT. I think you can specify the LMOD if 
you only want to affect a single load module instead of all load modules with 
that csect name.

Verify that ABCDITSK is an SMP/e LMOD. ABCPROC#C is too long for an SMP/e MOD 
name so I'm guessing that you omitted an optional superzap NAME that SMP/e is 
relying upon. Look at the superzap NAME statement.

LE programs complicate the situation a little. I've never packaged them so I 
can only suggest how I would approach this. I'm guessing that SMP/e either 
requires a superzap NAME option specifying module name or requires ABCPROC#C be 
renamed to a valid ++MOD name which can be specified in the ++ZAP name. I'm 
guessing by this time, superzap with PDS/e now supports "NAME load-module 
module csect". 

Remember that SMP/e may not have implemented all of the superzap NAME options. 
I suspect the C_CODE option is supported but it's possible that it's 
automatically determined in SMP/e and should not be specified as a NAME option. 



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

Re: RACROUTE REQUEST=AUTH problem

[Jon Perryman]

The one thing no one has mentioned is MUSASS configuration (Multi-User address 
spaces). Has the customer configured MUSASS changes like naming table, exits or 
???. For instance, is the STC jobname being appended to distinguish between 
production and test? Maybe a RACF trace would show the real resource name and 
results.

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

Re: Abend producing SDWARBAD

[Jon Perryman]

On Tue, 28 Nov 2023 20:14:36 -0500, Joseph Reichman  
wrote:

>You can always determine if it’s a CSECT whitin many by seeing if it’s a
>minor CDE

When did IBM start creating minor CDE's for each csect in a load module? 
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Abend producing SDWARBAD

[Jon Perryman]

Hi Joseph,

Just so everyone is clear, you're upgrading CBT192 (generic abend diagnostics / 
recovery - ESTAEX, FRR, ARR, ...) to include new diagnostic information. You're 
charged with mapping the abending address to a load module and the offset into 
that load module which will be displayed as part of the abend diagnostics. Ask 
yourself if this is useful except in the most basic scenarios.

There are flaws in using RB's (PRB, SVRB, IRB, ...)  to determine the load 
module.  It doesn't work for PC routine abends captured by a PRB ESTAE.  It 
assumes that all load modules are executed using (LINK, XCTL, ...) which 
creates an RB (PRB, SVRB, IRB, ...). It ignores the common practice of using 
LOAD with branch tables. What about RBs that have terminated with the abend 
percolated into the next RB? I'm sure there are more.

I suggest that you code macros for new diagnostics you add. This simplifies 
users' ability to choose, customize, replace and eliminate functionality 
instead of having a single large module. In this case, I suggest giving them a 
few options.

Always ask yourself, where you could be exposing a normal sysprog to some grief 
and how you should warn them of potential dangers. In my opinion, everyone 
ignores the danger in the single most dangerous z/OS exit, The WTO exit can be 
exposed to every possible z/OS restriction. Messages from RSM, IOS and others 
can be issued from problematic states. For example, device allocation because a 
disk volser is misspelled.   

You were asked specifically to display load module name and offset. I 
personally find this useless because without a dump, you cannot identify the 
CSECT with offset. You have an abend at some unknown CSECT name that is linked 
in the load module. SMP/e complicates this further because it does not do a 
complete link. Instead, it replaces modules (CSECTs) that have been changed 
which changes the CSECT sequence. While you could provide this as an option, 
the question is why? You can't determine the cause in any way except that it 
was in a specific load module.

I personally would provide a second option that can determine CSECT name and 
offset using saveareas (possibly linkage stack).and base reg. You would need to 
document how to be compatible with what people call baseless code where a 
register points to literals. I don't know about how others implement it. My 
personal implementation starts the csect with a SAVE (14,12),,'module info' 
that never gets executed followed by the program constants. To avoid loading 
constants to the instruction buffer, I have an ENTRY statement where the 
executable code starts, followed by a SAVE (14,12) and LARL Rxx,csect_name. 
This eliminates the need to calculate offsets into the program.

From a diagnostic standpoint, it looks like a standard program where a J or B 
is followed by a length & eyecatcher. My recovery diagnostics find the reg (R12 
for my programs) that is within 12K of the failing address and verify there is 
a J or B. 

A third option is to give sample code that requires user mods in the case they 
don't follow standard conventions.

You should ask the group because I suspect that others will have 
recommendations and preferences. Maybe ask the assembler group too.

On Tue, 28 Nov 2023 12:41:21 -0500, Joseph Reichman  
wrote:

>Sam asked me to update file 192 in cbttape 
>
>Its a generic recovery 
>
>I’m making two 
>
>Updates 
>
>1) when the error PSW isn’t in the program storage so I’m finding out if the 
>abend happened in a RB and then at what offset the user called that rb
>2) displaying 128 bit PSW and 64 bit gpr 
>If then abend occurred while the user was in amode 64 
> 
>That’s it

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

Re: Abend producing SDWARBAD

[Jon Perryman]

On Tue, 28 Nov 2023 08:48:23 -0500, Joseph Reichman  
wrote:

>Let then be specific
>
>The first thing I do is get the low and high address of the program The
>program name is being passed as a parm to the Estae routine

Hi Joseph,

Peter asked you what is the problem you are trying to solve (not the details 
about how you are trying to solve that problem). Are you performing recovery 
where having the RB is somehow important? Are you printing diagnostic 
information where the RB contains something you think might be important? Is 
this an exercise to create an updated CBT192.

I'm guessing that your company wants better diagnostic information for some 
code that your company has written. You're going after control blocks that 
don't seem to be useful and seem to be trying to handle every possible 
situation. Can you tell us what you want to accomplish instead of how you are 
trying to accomplish it?

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

Re: UNIX REXX LINKMVS TASKLIB?

[Jon Perryman]

On Fri, 24 Nov 2023 09:07:54 -0600, Paul Gilmartin  wrote:

>On Fri, 24 Nov 2023 00:29:34 -0600, Jon Perryman  wrote:
>>For temporary datasets, when is there ever a need for VOL=REF unless you are 
>>working with a volume?
>>
>It's needed when allocating the same the same temp data set to two different
>ddnames within s single job step, regardless of volume.

Are you saying that DD DDNAME= doesn't work without VOL=REF? Are you saying 
that DSN=&TEMP on both DD requires one to have a VOL=REF? If allocation is 
causing a problem, doesn't an IEFBR14 step solve that problem?

You can get VOL=REF to work for temporary datasets but is it the right 
solution? The only times I used VOL=REF was for datasets that needed to be on 
the same volume.

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

Re: Page Datasets in User Catalog

[Jon Perryman]

On Fri, 24 Nov 2023 01:42:08 +, Mark Jacobs  
wrote:

>I tried a pageadd of a newly defined page dataset that was cataloged in a user 
>catalog. It didn't work. 

I suspected it would not work but was unsure. Pageadd remains in effect until 
the next CLPA so it would make sense it would fail.

Prior to shared MCAT, I think we recataloged the emergency page dataset to each 
master catalog so it could be used from any system. It's been so long that I 
can't remember for sure and I wasn't responsible for setting it up. I just had 
to know about it in case of emergency.

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

Re: UNIX REXX LINKMVS TASKLIB?

[Jon Perryman]

On Thu, 23 Nov 2023 18:21:28 -0600, Paul Gilmartin  wrote:

>>On Fri, 24 Nov 2023 00:10:18 +, Seymour J Metz wrote:
>>If you insist on using VOL=SER=foo for a temporary, it will work.
>>
>I use VOL=REF=ddfoo only when it's required.

For true temporary datasets, a normal user will never code VOL=SER unless they 
screwed up. For sysprogs, there are a couple of disk utilities but these are 
exceptions that are used to identify a volume instead of containing actual 
temporary data.. 

For temporary datasets, when is there ever a need for VOL=REF unless you are 
working with a volume?

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

Re: Page Datasets in User Catalog

[Jon Perryman]

On Fri, 24 Nov 2023 00:12:34 +, Seymour J Metz  wrote:

>Are you saying that PAGEADD will work with alias entries and that the added 
>datasets will be retained across IPL?

Sorry, I worded it incorrectly. I didn't mean to imply I had experience using 
pageadd in that respect. 

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

Re: UNIX REXX LINKMVS TASKLIB?

[Jon Perryman]

On Fri, 24 Nov 2023 00:10:18 +, Seymour J Metz  wrote:

>if you insist on using VOL=SER=foo for a temporary, it will work. 

Cleanup of the public volumes is unpredictable. Normal users should never learn 
about VOL=SER especially for temporary datasets.

> IMHO, it's best to let SMS do its thing.

Unless things have changed, SMS does not control temporary datasets. The system 
places them on volumes mounted public or storage bypassing the need for SMS.

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

Re: DSS dump and migrated datasets

[Jon Perryman]

On Thu, 23 Nov 2023 22:47:59 +0100, Radoslaw Skorupka  
wrote:

>Well, Keith metioned *a switch*. 

Turning on the switch implies that everyone agreed that the feature benefits 
are more important than the risks. This is acceptable because IBM warned you 
and your company accepted the risks.

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

Re: DSS dump and migrated datasets

[Jon Perryman]

On Thu, 23 Nov 2023 19:47:24 +, Keith Gooding  wrote:

>I certainly would like the option to tell dss to recall datasets

I feel your pain but I personally agree with IBM's decision. Realize this is 
z/OS with specialists instead UNIX with its jack of all trades. DASD sysprog, 
performance sysprog, scheduler and more should be involved in how this should 
occur because they have access to important knowledge, For instance, the DASD 
sysprog can tell you the importance of using HRECALL instead of ADRDSSU doing 
the recall. Very simply, HRECALL can group recalls by recall volume with fewer 
tape mounts and they can easily cancel the request if people are being 
impacted. The scheduler can schedule this non-time sensitive work when it won't 
impact others.

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

Re: Page Datasets in User Catalog

[Jon Perryman]

On Wed, 22 Nov 2023 22:35:13 +, Seymour J Metz  wrote:

>I suspect that there was a game of telegraph, whereby crucial details got lost.
>
>It is normal to allocate page datasets in a user catalog that will eventually 
>be used as a master catalog.
> I'm suspicious of the claim that z/OS can use  a page dataset that is not in 
> its own master catalog, but I can't rule it out.

There are definitely crucial details lost. Page and swap are special datasets. 
For instance, a page dataset can be in multiple catalogs (I think using 
recatalog). Only page datasets specified in PARMLIB must be in the master 
catalog. Without details, we're only guessing how it's being used. 

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

Re: Performance i/o problem

[Jon Perryman]

It sounds like the OP is sharing a volume between 2 different sysplexes. If 
that's the case, then hardware reserves may also be a problem that should be 
investigated.

On Thu, 23 Nov 2023 11:37:29 -0600, Steve Estle  wrote:

>Assuming you are running ZOS in native mode (not as guest under ZVM) where 
>your dump/restores are occurring, I would definitely look at RMF reports - my 
>first place to look is RMF Monitor III online - if not active, turn on with 
>the recording VSAM files - typically "F RMF, S III" - this should show what is 
>delaying / impeding the restore job.  One other question - are you restoring 
>from tape or disk - what is the source device type you are recovering from.  
>We recently activated ZEDC on our LPAR's and found out dumping / restoring in 
>DFDSS compressed mode speeds up our backups substantially (like by factor 3:1) 
>if you have that option?  You have to specify the proper "ZCOMPRESS" option on 
>the ADRDSSU dump statement to take advantage if you have that feature /  
>option active for your system / processor - we are running on Z15 hardware.
>
>Steve Estle
>ZOS Systems Programmer
>
>--
>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: DSS dump and migrated datasets

[Jon Perryman]

On Thu, 23 Nov 2023 18:18:23 +, Keith Gooding  wrote:

>I do not know why IBM do not have an option for adrdssu to go the recall 
>automatically - there have been some requests on IBM ideas. 

The last thing you want is for ADRDSSU to become long running waiting on 
multiple recalls from multiple tapes. There's also the problem that someone 
inadvertently runs a backup that includes archived datasets. You have limited 
disk space and unwitting users can potentially defeat the purposes of HSM 
archiving.

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

Re: DSS dump and migrated datasets

[Jon Perryman]

On Thu, 23 Nov 2023 17:57:53 +0100, Radoslaw Skorupka  
wrote:

>I need to dump a lot of small dataset with HLQ=user_to_be_deleted.
>Since the user is no longer active, most of. datasets are migrated to ML1
>and ML2.

Do you really need another backup since HSM already backed them up? If HRECALL 
generics don't meet your needs, then you could write a REXX to be more granular.

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

Re: UNIX REXX LINKMVS TASKLIB?

[Jon Perryman]

On Thu, 23 Nov 2023 01:47:18 -0600, Paul Gilmartin  wrote:
>>On Thu, 23 Nov 2023 04:18:05 +, Farley, Peter wrote:

>>In this day and age, why in the world would you evec contemplate using a 
>>non-cataloged library? 
>>
>In parallel with the JCL Ref. mentioning use of temporary data sets as link 
>libraries:
>
>Use the PGM parameter ..., or a temporary library.

Temporary datasets never use VOL=SER=. They are accessed through a DD that 
optionally exists for the life of the job (DDNAME= or DSN=&XXX). 
Technically they are uncatalogued but the word uncatalogued implies use of 
VOL=SER=,  

>>Performance was admirable and acceptable but this usage was obviously not a 
>>high-volume commercial application, so YMMV.
>>
>I was just taking to heart the advice in
>
>... To improve performance of the z/OS® shell, avoid propagating STEPLIBs 
> ...

Think of this in terms of z/OS. USS STEPLIB variable is actually an attach 
tasklib (not a true step). The problem occurs when you FORK() a process which 
must allocate a new unique DDN, open it and read the directories during ATTACH. 
Much of UNIX is built around FORKing is cheap. For instance consider MAKE 
(compile) which could potentially do a 100,000 FORKs in a short amount of time.

Performance is in the eye of the beholder. Performance is more than one thing 
that runs extremely fast. z/OS can run at 100% busy without impacting users. If 
I run MAKE to compile in LINUX, it is treated the same as if I'm using edit.  
Performance must be measured in overall impact which can vary greatly by 
environment.

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