Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News

[Jon Perryman]

On Wed, 3 Jul 2024 17:32:20 +, Seymour J Metz  wrote:

>In what way is OS/2 remotely similar to Unix?

The design concepts are very similar. The leap from OS/2 to Unix is fairly 
simple. Filesystem, threads, processes, commands, multi-tasking to name a few. 
z/OS on the other hand has a radically different design philosopjhy.

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

Re: What's at a comma?

[Jon Perryman]

On Thu, 4 Jul 2024 06:10:16 +0100, Rupert Reynolds  wrote:

>Also, I'm told that some installations restrict access to low storage
>(using storage keys?) and I wonder if Rexx storage() or whatever simply
>returns zeros rather than 0c4?

I won't swear to this but if I remember correctly, I think we typically ran KEY 
8 PROB mode when accessing PSA.

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

Re: As a long-time Rexx programmer

[Jon Perryman]

On Wed, 3 Jul 2024 19:36:52 +, Seymour J Metz  wrote:

Sorry, it submitted before I finished.

>> Instead, an ADDRESS environment is created but even that is not a 
>> requirement.
>It isiff you want the application to be scriptable. Otherwise, not.

An application does not require you to initialize REXX. TSO %MYREXX will 
automatically initialize REXX for all programs executed from MYREXX exec. No 
need to create an ADDRESS environment. 

>
>> Again, having a knowledge of REXX would be useful but by no means shouldn't 
>> stop anyone from using the API to create variables.
>You seem to be conflating "knowledge ff REXX" with "knowledge of REXX syntax". 
>Knowledge of the API is what the developer needs.

Knowledge of REXX nor knowledge of REXX syntax is needed. The developer only 
needs to learn the specific API's needed and write a very basic test of that 
functionality. There is no requirement to even use one REXX API call to be REXX 
compatible. Write a TSO command processor and the command output is 
automatically available to REXX using outtrap.

>> Again, having a knolledge of REXX would be useful but by no means shouldn't 
>> stop anyone from using the API to create variables.
>If they don't have knowledge of vthe API then they will have a hard time using 
>it. That said, some things can be done with the TSO API.

The knowledge is available in the REXX documentation for using API.

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

Re: As a long-time Rexx programmer

[Jon Perryman]

On Wed, 3 Jul 2024 19:36:52 +, Seymour J Metz  wrote:

>> No one said tech writes got it wrong nor consistently wrong.
>Demonstrably false.

I quote "It reads like it was written by someone who doesn't quite understand". 
This was not a claim the doc was wrong. People were using it for decades 
without calling IBM support. 

>> The SDSF syntax is self evident 
>Repeating a false claim doesn't make it true.

Have you ever used REXX? The string past "address sdsf" is passed to SDSF. 
Creating that string using REXX has nothing to do with the SDSF command syntax. 
Often you can use the SDSF screen command but If you need something more 
complex, then it's the same as can understand batch SDSF command syntax, then 
you'll 
>
>> While I wouldn't recommend it, you don't need to understand the REXX 
>> language to write a REXX function.
>
>Nor did I claim that you do.
>
>> Instead, an ADDRESS environment is created but even that is not a 
>> requirement.
>
>It isiff you want the application to be scriptable. Otherwise, not.
>
>> Again, having a knowledge of REXX would be useful but by no means shouldn't 
>> stop anyone from using the API to create variables.
>
>You seem to be conflating "knowledge ff REXX" with "knowledge of REXX syntax". 
>Knowledge of the API is what the developer needs.
>
>> Again, having a knolledge of REXX would be useful but by no means shouldn't 
>> stop anyone from using the API to create variables.
>
>If they don't have knowledge of vthe API then they will have a hard time using 
>it. That said, some things can be done with the TSO API.
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>עַם יִשְׂרָאֵל חַי
>נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Jon Perryman 
>Sent: Wednesday, July 3, 2024 2:46 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: As a long-time Rexx programmer
>
>On Wed, 3 Jul 2024 16:07:21 +, Seymour J Metz  wrote:
>
>>> The syntax is self-evident
>>Alas, no; if it were hee tech writers wouldn't consistently get it wrong.
>
>No one said tech writes got it wrong nor consistently wrong. The original 
>complaint was about unusual and incomplete. REXX quoting, concatenation, 
>address SDSF ISFEXEC DA & more. Why have a repeat where SDSF & ISFEXEC 
>identify the environment.
>
>The SDSF syntax is self evident which is a string as used in the SDSF batch 
>interface. ADDRESS SDSF and quoting is a REXX paradigm documented in REXX. The 
>documentation doesn't require explanation of these because they are fully 
>documented in REXX. It would certainly be helpful knowing REXX but it is not a 
>requirement.
>
>>> IBMddesigned REXX to completely avoid the need for product developers to 
>>> understand REXX.
>>In some cases, but if you want to defnne functions
>
>While I wouldn't recommend it, you don't need to understand the REXX language 
>to write a REXX function.
>
>That being said, most products rarel ccreate REXX functions because of 
>possible naming conflicts.  Instead, an ADDRESS environment is created but 
>even that is not a requirement. E.g. when running in TSO skip creating an 
>ADDRESS environment and write a simple TSO command which by the way is called 
>using the TSO environment.
>
>> or to set REXX variables then you need to understand a bit more about the 
>> API.
>
>Again, having a knowledge of REXX would be useful but by no means shouldn't 
>stop anyone from using the API to create variables.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News

[Jon Perryman]

On Wed, 3 Jul 2024 16:19:52 -0400, Phil Smith III  wrote:

>I don't understand "because automation loses control of storage management". 
>Can you elaborate?
.
I don't know the internals of ooRexx so I can't state what will be a problem. 
Remember that automation is a system critical product that can adversely affect 
your z/OS system and potentially your sysplex. Customers find delays and 
outages are unacceptable for automation.  

The concept of objects in automation is extremely enticing. Imagine offloading 
the workload of an LPAR to the other LPAR's in the sysplex. You're dealing with 
CICS, IMS, batch, Unix, network and more.

Consider storage persistence in products like automation and CICS which are 
shared multi-tasking environments where storage leaks can be deadly affecting 
hundreds of users. Far worse is automation that must remain active until the 
next IPL which for some z/OS systems can be several months.

With the introduction of ooRexx features like Objects and pointers, a motivated 
programmer can easily implement persistent objects in less than 1 minute. You 
write an HLASM program to obtain / release the persisten storage. Managing this 
storage is solely controlled by the customer with a very real potential for a 
storage leak. Worse yet, there is the potential storage overlays if something 
goes wrong cause complete failure automation failure. Remember that automation 
has it's fingers in everything.

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

Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News

[Jon Perryman]

On Wed, 3 Jul 2024 19:46:43 +, Seymour J Metz  wrote:

>You don't consider an application giving IRXINIT its own environments 
>and function packages to be REXX-aware?

Function programs will only execute when the REXX function is called. There's 
nothing to stop the program from being called using other methods without a 
REXX environment. The is not rexx-aware.

IRXINIT by a product is not required for a products to use REXX. For example, 
Netview allows you to use the REXX API because Netview initializes REXX. You 
can add REXX functions to the Netview function package. 

Is defining REXX functions even necessary? I vaguely remember someone doing 
something like IEFBR14(  ) without the function being defined but I could 
easily be wrong. 

>> Is ooRexx a complete replacement for IBM REXX?
>OREXX is a complete replacement for SAA REXX on OS/2; 
> Were IBM to do  port and integration of ooRexx to TSO, 
> I would expect it to be a complete replacement, at least in TSO and Unix 
> contexts.
> I don't have expectations either way for System REXX.

To say "at least in TSO and Unix" implies people expect IBM to do a half assed 
implementation of ooRexx that is incompatible with automation, CICS, IMS, batch 
rexx, system rexx and others not mentioned. Your expectation is for users to 
use 2 unique REXX variants on the same system depending upon environment.

Even Unix frowns upon unique programming language variants. Remember Python 2.x 
vs Python 3.x.

Also remember OS/2 (like all Unix variants) is a very simplistic 
implementation. The same ooRexx is easily used from any process. For z/OS, you 
must port ooRexx to automation, CICS, IMS and more. IBM REXX was designed to be 
environment agnostic and simple changes to incompatible routines.
 
> I doubbt that there is a Rexx developer on the planet that would agree with 
> you.

Most product developers would not want to deal with ooRexx and changes to their 
documentation. Given that IBM is not going to port ooRexx to z/OS, I suspect 
most REXX programmers would agree with me. With all it's blemishes, it's the 
same on all z/OS systems, same across all products and is fully supported / 
tested.

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

Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News

[Jon Perryman]

On Wed, 3 Jul 2024 16:11:45 +, Seymour J Metz  wrote:

>. > z/OS REXX on the other hand automatically integrates into most available 
>environments.
>No. Various applications are REXX-aware, 
> and they would continue to be so were IBM to make ooRexx a supported 
> scripting language.

There is no such thing as REXX-aware. You register your product's REXX callable 
routines and environment. Your product uses various REXX API's (e.g. 
variables). Is ooRexx a complete replacement for IBM REXX? With it's Java 
requirement, does CICS now support calling JAVA programs? How about products 
that support REXX but not JAVA?

ooRexx would be a terrible language for automation because automation loses 
control of storage management. Those oop features come at a cost. If your 
product isn't essential then ooRexx is fine but can be a huge problem for 
system critical products.

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

Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News

[Jon Perryman]

On Mon, 1 Jul 2024 12:03:08 -0400, Phil Smith III  wrote:

>1) It's IBM and too many folks therefore concluded it must be bad.

IBM never concluded REXX is bad. There are design decisions that upset folks. 
From a developer perspective I agree with those decisions because things like 
storage cleanup would become a nightmare. Imagine the problems your automation 
product would encounter (e.g. delays & storage problems).

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

Re: As a long-time Rexx programmer

[Jon Perryman]

On Wed, 3 Jul 2024 16:07:21 +, Seymour J Metz  wrote:

>> The syntax is self-evident
>Alas, no; if it were the tech writers wouldn't consistently get it wrong.

No one said tech writes got it wrong nor consistently wrong. The original 
complaint was about unusual and incomplete. REXX quoting, concatenation, 
address SDSF ISFEXEC DA & more. Why have a repeat where SDSF & ISFEXEC identify 
the environment. 

The SDSF syntax is self evident which is a string as used in the SDSF batch 
interface. ADDRESS SDSF and quoting is a REXX paradigm documented in REXX. The 
documentation doesn't require explanation of these because they are fully 
documented in REXX. It would certainly be helpful knowing REXX but it is not a 
requirement.

>> IBM designed REXX to completely avoid the need for product developers to 
>> understand REXX.
>In some cases, but if you want to defnne functions

While I wouldn't recommend it, you don't need to understand the REXX language 
to write a REXX function.

That being said, most products rarely create REXX functions because of possible 
naming conflicts.  Instead, an ADDRESS environment is created but even that is 
not a requirement. E.g. when running in TSO skip creating an ADDRESS 
environment and write a simple TSO command which by the way is called using the 
TSO environment.

> or to set REXX variables then you need to understand a bit more about the API.

Again, having a knowledge of REXX would be useful but by no means shouldn't 
stop anyone from using the API to create variables. 

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

Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News

[Jon Perryman]

On Wed, 3 Jul 2024 13:19:13 +0200, Rony G. Flatscher  
wrote:

>No, it was *not* designed for Unix. It is available for Unix, Windows, Apple, 
>and many more
>operating systems.

While they may not adhere to the UNIX standards, those OS's are for all 
pratical purposes a UNIX variant with very similar concepts. While there are 
some differences, they are not completely foreign like (z/OS, z/VSE & z/VM) 
where OORexx will have major compatibility issues.

>By the way, the first operating system IBM released ooRexx was OS/2 Warp. 

ooRexx was probably a simple port because of it's similarities to UNIX.

>Object REXX/ooRexx has all address environments that have ever been
> written for Rexx as it offers the REXX SAA interface,

I'm not bashing ooRexx. I'm sure that it's a great language but as a product 
developer, my products effortlessly integrate in IBM REXX.

> The availability of C++ APIs is one of the reasons why it has become quite 
> easy to integrate ooRexx with any OO system.

Where is IBM REXX being used for complete applications where OOP is useful? 
Automation is the largest REXX user but OOP is of little use. TSO uses rexx for 
environmental setup and small problem resolution.  

>is also responsible for making it possible to implement Java interface and 
>abstract classes in
>ooRexx classes, implementing abstract Java methods in plain [oo]Rexx! :)

This is a nice feature but are these the types of problems that z/OS users want 
to solve using REXX? Why not just use JAVA directly since ooRexx must use it 
under the covers for processing Java methods. 

>With the Java  bindings, you can integrate ooRexx with any complex application 
>system that offers
>Java APIs, like SAP [1], PeopleSoft [2], and many more.

IBM REXX environment integration is a 0 step implementation for the customer 
and end user. 

On the other hand, ooRexx requires some configuration for each ooRexx 
environment to be used. At a very minimum for each environment, you must define 
the Java libraries. For more complicated products like SAP, you must install 
the SAP Java connector. While these tasks seem trivial, you must remember an 
end user may want to use this but a system admin typically performs these tasks 
and must perform these on each system where ooRexx is needed. This is not 
automatic like in z/OS.

>This support is available out of the box for Windows, Linux, and Apple. You 
>write one ooRexx script
>on Windows and can run it unchanged on Linux or Apple, and vice versa. 

These are compatible UNIX variants where everything is similar. IBM Rexx exec's 
are not portable between z/OS, z/VM & z/VSE. The same is true for ooRexx. 

>> z/OS REXX on the other hand automatically integrates into most available 
>> environments.
>Yes, because IBM created REXX and integrated it in z/OS.

Too funny because REXX is not integrated in z/OS. REXX was originally written 
for VM and designed to be disconnected from everything by dynamic ADDRESS 
environments. It can be a challenge to find the REXX anchor control blocks 
because of the REXX execution environment (e.g. CICS, IMS TSO, automation & 
more). Instead of integration, it is a REXX design philosophy that does not 
make it OS dependent.   

>The problem is that IBM has never improved the REXX language on the mainframe 
>in the past decades,

Do you think it's a coincidence that variables can't be passed between REXX 
members nor the ability to pass stem variables? Ask yourself why automation 
products implemented this capability instead of making it common to all REXX 
environments. I'm guessing that the lack of improvements to REXX is more about 
discouraging it's use as an application language than simply not improving it.

>Now, ooRexx being TRL2 (and much more) would improve the productivity that 
>REXX allows in a
>remarkable way. Hence, if offered on the mainframe, then it would allow for a 
>huge jump to a modern
>version of REXX, buying a lot of functionality and productivity for the 
>customers.

No doubt REXX productivity could easily be improved but there must be 
underlying reasons for not doing so. My guess is to limit the language use to 
solving trivial problems.

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

Re: As a long-time Rexx programmer

[Jon Perryman]

On Wed, 3 Jul 2024 07:36:39 -0500, Paul Gilmartin  wrote:

>> call-by-reference is a parameter passing format used by programs.
>No.  I once looked at the SMP/E API which depends heavily on passing
>references.  Has anyone been able to address the SMP/E API from Rexx?

ADDRESS LINKPGM GIMAPI arg1 arg2 arg... has been around as far as I can 
remember.

You'll need to be familiar with using storage( ), overlay( ), C2X( ), X2C( ), 
just to name a few.

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

Re: As a long-time Rexx programmer

[Jon Perryman]

On Mon, 1 Jul 2024 10:04:46 -0500, Paul Gilmartin  wrote:

>What correction would you expect? The TSO documentation teems with instances
>of quoting rather than references to rules, and the JCL documentation of 
>temporary
>data set names lacks a clear reference to "Determining Equivalent JCL".

This is specifically about SDSF documentation which does not (for the most 
part) have quoting. The SDSF team did not understand how REXX quoting works 
which led to the documentation being a bit peculiar but still being useful. 
This documentation has existed for years which means it has been adequate for 
those who needed it. Documentation only changes when someone complains or new 
features are added.

>REXX lacks call-by-reference, expected by programmers of most other languages,
>in lieu of which it provides a pseudo-call-by-name, confusing such programmers
>(even sometimes me.)

I'm not sure how call-by-reference is relevant to SDSF REXX interface. 
call-by-reference is a parameter passing format used by programs. If you need 
call-by-reference, I believe it's either ADDRESS LINK or ADDRESS LINKMVS. If 
those can't satisfy call-by-reference, then create a REXX environment specific 
to be used for call-by-reference.

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

Re: As a long-time Rexx programmer

[Jon Perryman]

On Mon, 1 Jul 2024 15:01:37 +, Seymour J Metz  wrote:

> the question is whether they should be offering uninforme4d guesses as syntax 
> rules.
> IMHO they should be providing tested examples and referring readers to the 
> Rexx documentation for details.

IBM designed REXX to completely avoid the need for product developers to 
understand REXX. You create a unique REXX address environment and a simple 
interface (thru ADDRESS environment) that receives a string & returns REXX 
variables. You process the string as a command valid for your product which can 
be anything you want.

SDSF has examples which is the only section I ever looked at. The syntax is 
self-evident because it follows the batch interface. I suspect the 
documentation refers readers to the REXX documentation but there are always 
people who can't connect the dots. While this isn't rocket science, the 
documentation exists solely to keep customers from calling support. Sometimes 
there is a need to cross contaminate a product's manuals to avoid the need to 
call support for help.

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

Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News

[Jon Perryman]

On Sun, 30 Jun 2024 13:28:20 +, Seymour J Metz  wrote:

>The landscape would be quite different were IBM to provide legacy streams, 
> port ooRexx to TSO and include BSF4ooRexx as part of z/OS. 
> On my PCs I've pretty much abandoned SAA Rexx.

Nothing motivates IBM to port OOREXX. It is a waste of IBM manpower because it 
was designed for UNIX with very limited address environments and a small user 
community which means it's usefulness is very limited. E.g. It's certainly 
better than shell scripts but it hasn't replaced them. Then comes the question 
about integration which I'm guessing doesn't include automatic integration with 
SAP, PeopleSoft, various databases and much more. z/OS REXX on the other hand 
automatically integrates into most available environments. IBM REXX was never 
designed to build complicated applications.

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

Re: As a long-time Rexx programmer

[Jon Perryman]

On Thu, 13 Jun 2024 14:40:05 -0400, Phil Smith III  wrote:

>...am I the only one who SMH at the documentation for things like ISFEXEC
> (https://www.ibm.com/docs/en/zos/2.4.0?topic=language-issuing-commands-isfexec
>  )? 
> It reads like it was written by someone who doesn't quite understand how 
> variables/literals work in Rexx:

Why would anyone expect SDSF support & dev to know REXX when it's not part of 
their job? REXX documentation belongs with REXX and in the case of quoting, 
it's only mentioned because SDSF support received multiple calls caused by 
special characters. Since most people go directly to the examples, it doesn't 
surprise me this has never been corrected.

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