Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

[Charles Mills]

VS COBOL II Release 4 -- change bars on the doc:

x LENGTH OF Special Register 
x The LENGTH OF special register contains the number of bytes used by an
x identifier.
 
x LENGTH OF creates an implicit special register whose content is equal
x to the current byte length of the data item referenced by the
x identifier.
 
x Note:  For DBCS data items, each character occupies 2 bytes of 
x storage.

... and more

Charles

On Sun, 21 May 2023 00:51:33 +, Frank Swarbrick 
 wrote:

>At least VS COBOL II, as far as I can remember.  This is when CICS added the 
>COBOL2 translate option to allow the LENGTH argument to be omitted, since it 
>used LENGTH OF under the covers.
>Also, it's called a "special register" rather than built-in function; though 
>now there is also an intrinsic function LENGTH, as well as BYTE-LENGTH.

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

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

[Paul Gilmartin]

On Sun, 21 May 2023 18:56:39 +, Seymour J Metz wrote:

>The Initiator calls it with a 32-bit PLIST, so below the bar and if you invoke 
>it with CALL you must be aware that it is a main program and do likewise.
>
>WEe hates it, precious, we hates it.
> 
It should have been easy enough for the initiator to query the AMODE and
provide a 31-bit or 64-bit list accordingly.

This feels like a design blunder resulting from haste to deliver.  The sort
that's orders of magnitude more costly to recover from in GA than in
development.

I could even envision a bizarre compatibility accommodation in which all
the parameter values are below-the-line and bits 32-63 of GR1 address
a 31-bit plist and the entire GR1 addresses a 64-bit plist referring to the
same below-the-line valuse/

-- 
gil

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

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

[Seymour J Metz]

The Initiator calls it with a 32-bit PLIST, so below the bar and if you invoke 
it with CALL you must be aware that it is a main program and do likewise.

WEe hates it, precious, we hates it.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, May 21, 2023 2:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

On Sun, 21 May 2023 16:51:18 +, Seymour J Metz wrote:

>That's not a CALL convention. The primary use case for the halfword length is 
>programs that can be invoked with EXEC PGM=.  ...

>I assume that you're talking AMODE24 or AMODE31; for AMODE64 things are 
>different.
>
If a program object is marked AMODE 64, does EXEC PGM= cause it to be
entered with a 64-bit PLIST?  May CALL invoke it with arguments above the bar
or must the caller copy arguments to below the bar?

--
gil

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

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

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

[Seymour J Metz]

32-bit PLIST, and the AMODE64 main program is responsible for clearing the VL 
bit before using the address. BAD.

For anything else, the PLIST is 64 bits wide, there is no VL bit and the last 
pointer is followed by -1 (all fox Fox). Parameters from AMODE64 to AMODE64 may 
be above the bar. But if you want to pass it to AMODE31, ...


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, May 21, 2023 2:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

On Sun, 21 May 2023 16:51:18 +, Seymour J Metz wrote:

>That's not a CALL convention. The primary use case for the halfword length is 
>programs that can be invoked with EXEC PGM=.  ...

>I assume that you're talking AMODE24 or AMODE31; for AMODE64 things are 
>different.
>
If a program object is marked AMODE 64, does EXEC PGM= cause it to be
entered with a 64-bit PLIST?  May CALL invoke it with arguments above the bar
or must the caller copy arguments to below the bar?

--
gil

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

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

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

[Paul Gilmartin]

On Sun, 21 May 2023 16:51:18 +, Seymour J Metz wrote:

>That's not a CALL convention. The primary use case for the halfword length is 
>programs that can be invoked with EXEC PGM=.  ...

>I assume that you're talking AMODE24 or AMODE31; for AMODE64 things are 
>different.
>
If a program object is marked AMODE 64, does EXEC PGM= cause it to be
entered with a 64-bit PLIST?  May CALL invoke it with arguments above the bar
or must the caller copy arguments to below the bar?

-- 
gil

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

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

[Seymour J Metz]

That's not a CALL convention. The primary use case for the halfword length is 
programs that can be invoked with EXEC PGM=. For most subroutines, the entries 
in the PLIST point directly at the parameter or point to a language-specifc 
control block of some kind, e.g., a locator/descriptor for PLI CHAR variables. 
Always setting the end-of-list flag is a good habit to get into.

I assume that you're talking AMODE24 or AMODE31; for AMODE64 things are 
different.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, May 21, 2023 12:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

On Sun, 21 May 2023 08:02:59 +0300, Binyamin Dissen  wrote:
>
>Curious how you used a subroutine. It only worked for fields in a structure
>where you passed the address of the field and the next field and it subtracted
>the addresses?
>
>Was there a way to make COBOL pass a dope vector with descriptions of the
>field?
>
Does COBOL not follow the CALL or ADDRESS LINKMVS convention where
R1 addresses an array of fullwords where each addresses a halfword length
followed by the value?

--
gil

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

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

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

[Paul Gilmartin]

On Sun, 21 May 2023 08:02:59 +0300, Binyamin Dissen  wrote:
>
>Curious how you used a subroutine. It only worked for fields in a structure
>where you passed the address of the field and the next field and it subtracted
>the addresses?
>
>Was there a way to make COBOL pass a dope vector with descriptions of the
>field?
> 
Does COBOL not follow the CALL or ADDRESS LINKMVS convention where
R1 addresses an array of fullwords where each addresses a halfword length
followed by the value?

-- 
gil

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

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

[Binyamin Dissen]

On Sat, 20 May 2023 19:09:03 -0400 Phil Smith III  wrote:

:>Since when does COBOL have LENGTH OF? I looked for this about 12 years ago 
and didn't find it, wrote a tiny and trivial assembler function to do the same 
thing. Did I miss it, or is it new since then?

:>Not that the code has needed any support, but I'm glad that if it ever 
becomes an issue, I can say "Use the BIF instead"!

Curious how you used a subroutine. It only worked for fields in a structure
where you passed the address of the field and the next field and it subtracted
the addresses?

Was there a way to make COBOL pass a dope vector with descriptions of the
field?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

[Frank Swarbrick]

At least VS COBOL II, as far as I can remember.  This is when CICS added the 
COBOL2 translate option to allow the LENGTH argument to be omitted, since it 
used LENGTH OF under the covers.
Also, it's called a "special register" rather than built-in function; though 
now there is also an intrinsic function LENGTH, as well as BYTE-LENGTH.

One thing that LENGTH OF will do that the others won't is allow you to get the 
length of a table element without subscripting it, e.g.

01  my-table.
05  my-entry occurs 10 times.
10  me-one   pic x(8).
10  me-two   pic s9(9) comp.

call 'something' using my-table, content length of my-entry

The LENGTH OF special register and the BYTE-LENGTH function both return the 
number of bytes of a field.  The LENGTH function will return the number of 
"characters" for both USAGE DISPLAY and USAGE NATIONAL, meaning LENGTH 
OF/BYTE-LENGTH function for a PIC N(10) returns 20, while LENGTH function 
returns 10.

For the new UTF-8 it seems to do its own thing that I have not researched yet.  
But so far it returns 10 for all 3, even though it allocates 40 bytes for a PIC 
U(10).  I'm sure there is some logic behind it.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Saturday, May 20, 2023 5:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LENGTH OF in COBOL (was: ISPF HILITE Question)

Since when does COBOL have LENGTH OF? I looked for this about 12 years ago and 
didn't find it, wrote a tiny and trivial assembler function to do the same 
thing. Did I miss it, or is it new since then?

 

Not that the code has needed any support, but I'm glad that if it ever becomes 
an issue, I can say "Use the BIF instead"!


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

LENGTH OF in COBOL (was: ISPF HILITE Question)

[Phil Smith III]

Since when does COBOL have LENGTH OF? I looked for this about 12 years ago and 
didn't find it, wrote a tiny and trivial assembler function to do the same 
thing. Did I miss it, or is it new since then?

 

Not that the code has needed any support, but I'm glad that if it ever becomes 
an issue, I can say "Use the BIF instead"!


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

Re: ISPF HILITE Question

[Steve Thompson]

Thanks for that.

I just started experimenting with "functions" in COBOL 6.2 and 
saw those constructs, and just hadn't tried them yet.


Steve Thompson

On 5/19/2023 3:58 AM, Frank Swarbrick wrote:

Yes, the ISPF COBOL highlight is not up to date at the moment.  They got up to 
date a few releases back, but at least on my system they are not up to date 
with COBOL 6.3 and 6.4 at the least.

Not sure you need BYTE-LENGTH for this, though.  FUNCTION LENGTH() or LENGTH OF 
works just fine for ODO.

I recommend using the following to eliminate the need for the FUNCTION keyword.  And it 
will eliminate the "error" highlight you are seeing, since that keys of the 
FUNCTION keyword.

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
REPOSITORY.
 FUNCTION ALL INTRINSIC.

COMPUTE L = LENGTH(MYFIELD)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Thursday, May 18, 2023 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ISPF HILITE Question

I have been chasing through a few IBM ISPF manuals and I am trying to figure out why, when HILITE is COBOL, certain 
words are "pink". Now I thought this was used to show a logic error, such as an "IF" with a missing 
"END-IF", or an extraneous "END-IF".

Where my curiosity/confusion is, is this:

COBOL has [intrinsic] FUNCTIONs. And I'm trying to make use of one, but it is getting colored pink. 
Could this be because ISPF doesn't know about new functions in COBOL? In this case it is 
"BYTE-LENGTH" (because I need to know at execution time what the size of the named label 
is -- "Depending on" is being used).

Could someone point me in the approximate correct direction?

Or have I stumbled on a situation where ISPF and COBOL 6.x are not in synch?

TIA,
Steve Thompson

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

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


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

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

Re: ISPF HILITE Question

[Lionel B. Dyck]

Take a look at CBT Tape file 967 from Tom Conley - it is the CBT Usermod 
Collection for ISPF (aka CUCI) and supports many additional hilite languages 
and enhancements.


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

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Butler
Sent: Friday, May 19, 2023 8:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF HILITE Question

As an enhancement to the HILITE command, it would be nice if the list of 
keywords for any given language could be edited to customize them for 
individual use.  

I use PL/I to edit SQL statements, and a few tweaks would be nice...lacking an 
SQL type, of course.

Cheers,

Jon.

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

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

Re: ISPF HILITE Question

[Jon Butler]

As an enhancement to the HILITE command, it would be nice if the list of 
keywords for any given language could be edited to customize them for 
individual use.  

I use PL/I to edit SQL statements, and a few tweaks would be nice...lacking an 
SQL type, of course.

Cheers,

Jon.

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

Re: ISPF HILITE Question

[Frank Swarbrick]

Yes, the ISPF COBOL highlight is not up to date at the moment.  They got up to 
date a few releases back, but at least on my system they are not up to date 
with COBOL 6.3 and 6.4 at the least.

Not sure you need BYTE-LENGTH for this, though.  FUNCTION LENGTH() or LENGTH OF 
works just fine for ODO.

I recommend using the following to eliminate the need for the FUNCTION keyword. 
 And it will eliminate the "error" highlight you are seeing, since that keys of 
the FUNCTION keyword.

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
REPOSITORY.
FUNCTION ALL INTRINSIC.

COMPUTE L = LENGTH(MYFIELD)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Thursday, May 18, 2023 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ISPF HILITE Question

I have been chasing through a few IBM ISPF manuals and I am trying to figure 
out why, when HILITE is COBOL, certain words are "pink". Now I thought this was 
used to show a logic error, such as an "IF" with a missing "END-IF", or an 
extraneous "END-IF".

Where my curiosity/confusion is, is this:

COBOL has [intrinsic] FUNCTIONs. And I'm trying to make use of one, but it is 
getting colored pink. Could this be because ISPF doesn't know about new 
functions in COBOL? In this case it is "BYTE-LENGTH" (because I need to know at 
execution time what the size of the named label is -- "Depending on" is being 
used).

Could someone point me in the approximate correct direction?

Or have I stumbled on a situation where ISPF and COBOL 6.x are not in synch?

TIA,
Steve Thompson

--
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: ISPF HILITE Question

[Robert Prins]

On Thu, 18 May 2023 at 20:20, Steve Thompson  wrote:

> Or have I stumbled on a situation where ISPF and COBOL 6.x are
> not in synch?
>

This used to be the "normal" situation for PL/I, and with PL/I builtins
multiplying like rabbits, it may well be the case again. Ditto for COBOL...

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

ISPF HILITE Question

[Steve Thompson]

I have been chasing through a few IBM ISPF manuals and I am 
trying to figure out why, when HILITE is COBOL, certain words are 
"pink". Now I thought this was used to show a logic error, such 
as an "IF" with a missing "END-IF", or an extraneous "END-IF".


Where my curiosity/confusion is, is this:

COBOL has [intrinsic] FUNCTIONs. And I'm trying to make use of 
one, but it is getting colored pink. Could this be because ISPF 
doesn't know about new functions in COBOL? In this case it is 
"BYTE-LENGTH" (because I need to know at execution time what the 
size of the named label is -- "Depending on" is being used).


Could someone point me in the approximate correct direction?

Or have I stumbled on a situation where ISPF and COBOL 6.x are 
not in synch?


TIA,
Steve Thompson

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

Re: TSO IKJOPER question how about using iKJEGASI to change / get a new command buffer

[Joseph Reichman]

So the

> On May 9, 2023, at 11:14 AM, Joseph Reichman  wrote:
> 
> I could do the same with the sub command exit 
> 
>>> On May 9, 2023, at 11:10 AM, Michael Stein  wrote:
>>> 
>>> On Tue, May 09, 2023 at 07:37:27AM -0400, Joseph Reichman wrote:
>>> I am just wondering when using IKJOPER (operand) and for clarity's sake I
>>> would like to use an example from TSO TEST so I would imagine the '=' of TSO
>>> TEST is an IKJOPER
>> 
>> Well, it doesn't work like that...  Test prescans the command and
>> blanks out the '=' character..  Code from MVT IKJEGMNL:
>> 
>> SCAN EQU   *
>> *TRANSLATE AND TEST COMMAND TO DETERMINE IF IT IS AN ASSIGNMENT 
>> *COMMAND.IF NOT,LINK TO COMMAND SCAN SERVICE ROUTINE TO SCAN
>> *VERB OF COMMAND.   
>>SPACE  
>>L R4,INBUF   R4=COMMAND ADDR.  
>>LHR3,X0(,R4) NO,USE COMMAND ACTUAL LENGTH. 
>>LAR1,X4  CONSTANT OF FOUR  
>>CRR1,R3  IS THIS A NULL LINE   
>>BESCREQ1 YES --- BRANCH
>> LOOP0EQU   *
>>CLI   X4(R4),BLANK   CHECK FOR LEADING BLANK   
>>BNE   LOOP   CONTINUE. 
>>LAR4,X1(R4)  BUMP ONE. 
>>BCT   R3,LOOP0   CHECK IF ANOTHER LEADING BLANK.   
>>B SCREQ1 ALL BLANKS REQUEST NEW LINE.  
>> LOOP EQU   *
>>CLI   X4(R4),BLANK   BLANK AS A DELIMITER. 
>>BESCAN1  CAN'T BE PACH COMMAND.
>>CLI   X4(R4),LEFTPARN  LOOK FOR LEFT PAREN 
>> LEFTPARN EQU   C'('   LEFT PAREN
>>BESCAN1  THIS IS NOT A PATCH   
>>CLI   X4(R4),EQUALS  LOOK FOR EQUALS   
>> EQUALS   EQU   C'='   EQUAL SIGN
>>BESCPCH  THIS IS A PATCH   
>>LAR4,X1(R4)  ADD ONE TO ADDRESS
>>BCT   R3,LOOPFIND = OR (   
>>B SCAN1  NO FIND. CONTINUE 
>> SCPCHEQU   *  PATCH 
>>MVI   X4(R4),BLANK   BLANK OUT EQUAL SIGN FOR PARSE.   
>> BLANKEQU   C' '   BLANK.
>>L R6,PATCHSIDOBTAIN ID FOR PATCH.  
>>LHR6,X0(R6)  * 
>>B SCLINK LINK TO ASSIGNMENT COMMAND.   
>> SCAN1EQU   *
>> *LINK TO COMMAND SCAN SERVICE ROUTINE TO SCAN VERB OF COMMAND.  
>>SPACE  
>>L R4,INBUF   R4=COMMAND ADDRESS
>>L R1,WORKAREAR1=PARAMETER LIST ADDR.   
>>LAR2,N24(,R1)R2=ADDR OF FLAG WORD. 
>>LAR3,N28(,R1)R3=ADDR OF OUTPUT AREA.   
>>MVI   X0(R2),X80 INDICATE NO SYNTAX CHECK. 
>>MVC   X0(N12,R1),PARMLIST MOVE SERVICE ROUTINE PARMS   
>> * TO LIST.  
>>STM   R2,R4,N12(R1)   PLACE SCAN ROUTINE PARMS IN LIST.
>> *   
>>LINK  EP=IKJSCAN LINK TO COMMAND SCAN SERVICE ROUTINE. 
>> 
>> 
>> 
>> --
>> 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: TSO IKJOPER question

[Joseph Reichman]

I could do the same with the sub command exit 

> On May 9, 2023, at 11:10 AM, Michael Stein  wrote:
> 
> On Tue, May 09, 2023 at 07:37:27AM -0400, Joseph Reichman wrote:
>> I am just wondering when using IKJOPER (operand) and for clarity's sake I
>> would like to use an example from TSO TEST so I would imagine the '=' of TSO
>> TEST is an IKJOPER
> 
> Well, it doesn't work like that...  Test prescans the command and
> blanks out the '=' character..  Code from MVT IKJEGMNL:
> 
> SCAN EQU   *
> *TRANSLATE AND TEST COMMAND TO DETERMINE IF IT IS AN ASSIGNMENT 
> *COMMAND.IF NOT,LINK TO COMMAND SCAN SERVICE ROUTINE TO SCAN
> *VERB OF COMMAND.   
> SPACE  
> L R4,INBUF   R4=COMMAND ADDR.  
> LHR3,X0(,R4) NO,USE COMMAND ACTUAL LENGTH. 
> LAR1,X4  CONSTANT OF FOUR  
> CRR1,R3  IS THIS A NULL LINE   
> BESCREQ1 YES --- BRANCH
> LOOP0EQU   *
> CLI   X4(R4),BLANK   CHECK FOR LEADING BLANK   
> BNE   LOOP   CONTINUE. 
> LAR4,X1(R4)  BUMP ONE. 
> BCT   R3,LOOP0   CHECK IF ANOTHER LEADING BLANK.   
> B SCREQ1 ALL BLANKS REQUEST NEW LINE.  
> LOOP EQU   *
> CLI   X4(R4),BLANK   BLANK AS A DELIMITER. 
> BESCAN1  CAN'T BE PACH COMMAND.
> CLI   X4(R4),LEFTPARN  LOOK FOR LEFT PAREN 
> LEFTPARN EQU   C'('   LEFT PAREN
> BESCAN1  THIS IS NOT A PATCH   
> CLI   X4(R4),EQUALS  LOOK FOR EQUALS   
> EQUALS   EQU   C'='   EQUAL SIGN
> BESCPCH  THIS IS A PATCH   
> LAR4,X1(R4)  ADD ONE TO ADDRESS
> BCT   R3,LOOPFIND = OR (   
> B SCAN1  NO FIND. CONTINUE 
> SCPCHEQU   *  PATCH 
> MVI   X4(R4),BLANK   BLANK OUT EQUAL SIGN FOR PARSE.   
> BLANKEQU   C' '   BLANK.
> L R6,PATCHSIDOBTAIN ID FOR PATCH.  
> LHR6,X0(R6)  * 
> B SCLINK LINK TO ASSIGNMENT COMMAND.   
> SCAN1EQU   *
> *LINK TO COMMAND SCAN SERVICE ROUTINE TO SCAN VERB OF COMMAND.  
> SPACE  
> L R4,INBUF   R4=COMMAND ADDRESS
> L R1,WORKAREAR1=PARAMETER LIST ADDR.   
> LAR2,N24(,R1)R2=ADDR OF FLAG WORD. 
> LAR3,N28(,R1)R3=ADDR OF OUTPUT AREA.   
> MVI   X0(R2),X80 INDICATE NO SYNTAX CHECK. 
> MVC   X0(N12,R1),PARMLIST MOVE SERVICE ROUTINE PARMS   
> * TO LIST.  
> STM   R2,R4,N12(R1)   PLACE SCAN ROUTINE PARMS IN LIST.
> *   
> LINK  EP=IKJSCAN LINK TO COMMAND SCAN SERVICE ROUTINE. 
> 
> 
> 
> --
> 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: TSO IKJOPER question

[Michael Stein]

On Tue, May 09, 2023 at 07:37:27AM -0400, Joseph Reichman wrote:
> I am just wondering when using IKJOPER (operand) and for clarity's sake I
> would like to use an example from TSO TEST so I would imagine the '=' of TSO
> TEST is an IKJOPER

Well, it doesn't work like that...  Test prescans the command and
blanks out the '=' character..  Code from MVT IKJEGMNL:

SCAN EQU   *
*TRANSLATE AND TEST COMMAND TO DETERMINE IF IT IS AN ASSIGNMENT 
*COMMAND.IF NOT,LINK TO COMMAND SCAN SERVICE ROUTINE TO SCAN
*VERB OF COMMAND.   
 SPACE  
 L R4,INBUF   R4=COMMAND ADDR.  
 LHR3,X0(,R4) NO,USE COMMAND ACTUAL LENGTH. 
 LAR1,X4  CONSTANT OF FOUR  
 CRR1,R3  IS THIS A NULL LINE   
 BESCREQ1 YES --- BRANCH
LOOP0EQU   *
 CLI   X4(R4),BLANK   CHECK FOR LEADING BLANK   
 BNE   LOOP   CONTINUE. 
 LAR4,X1(R4)  BUMP ONE. 
 BCT   R3,LOOP0   CHECK IF ANOTHER LEADING BLANK.   
 B SCREQ1 ALL BLANKS REQUEST NEW LINE.  
LOOP EQU   *
 CLI   X4(R4),BLANK   BLANK AS A DELIMITER. 
 BESCAN1  CAN'T BE PACH COMMAND.
 CLI   X4(R4),LEFTPARN  LOOK FOR LEFT PAREN 
LEFTPARN EQU   C'('   LEFT PAREN
 BESCAN1  THIS IS NOT A PATCH   
 CLI   X4(R4),EQUALS  LOOK FOR EQUALS   
EQUALS   EQU   C'='   EQUAL SIGN
 BESCPCH  THIS IS A PATCH   
 LAR4,X1(R4)  ADD ONE TO ADDRESS
 BCT   R3,LOOPFIND = OR (   
 B SCAN1  NO FIND. CONTINUE 
SCPCHEQU   *  PATCH 
 MVI   X4(R4),BLANK   BLANK OUT EQUAL SIGN FOR PARSE.   
BLANKEQU   C' '   BLANK.
 L R6,PATCHSIDOBTAIN ID FOR PATCH.  
 LHR6,X0(R6)  * 
 B SCLINK LINK TO ASSIGNMENT COMMAND.   
SCAN1EQU   *
*LINK TO COMMAND SCAN SERVICE ROUTINE TO SCAN VERB OF COMMAND.  
 SPACE  
 L R4,INBUF   R4=COMMAND ADDRESS
 L R1,WORKAREAR1=PARAMETER LIST ADDR.   
 LAR2,N24(,R1)R2=ADDR OF FLAG WORD. 
 LAR3,N28(,R1)R3=ADDR OF OUTPUT AREA.   
 MVI   X0(R2),X80 INDICATE NO SYNTAX CHECK. 
 MVC   X0(N12,R1),PARMLIST MOVE SERVICE ROUTINE PARMS   
* TO LIST.  
 STM   R2,R4,N12(R1)   PLACE SCAN ROUTINE PARMS IN LIST.
*   
 LINK  EP=IKJSCAN LINK TO COMMAND SCAN SERVICE ROUTINE. 

 

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

Re: TSO IKJOPER question

[Joseph Reichman]

Thank you

> On May 9, 2023, at 11:02 AM, Tony Harminc  wrote:
> 
> On Tue, 9 May 2023 at 15:12, Seymour J Metz  wrote:
> 
>> I believe that the optional source tapes for OS/360 and OS/VS2 3.8 are
>> archived (CBTTAPE?), so it should be possible to examine the source code
>> for TEST.
> 
> 
> MVS 3.8 TSO modules can also conveniently be browsed at
> http://www.mainframe.eu/mvs38/asm/TSO%20(IKJ)
> 
> The first module of the "assign" pseudo-command is IKJEGPCH. It is called
> by IKJEGMNL (the subcommand prompter), which has special code to check for
> an a=b type "command".
> 
> 
>> I would expect it to be something like
>> 
>> IKJOPER 'Err label',OPERND1=OP1,RSVWD=OPLIST,OPERND2=OP2
>> OP1  IKJTERM 'Err label', ...
>> OPLIST   IKJRSVWD 'Err label'
>> IKJNAME '='
>> OP2  IKJTERM 'Err label', ...
>> 
>> The = is the operator, not a subcommand. Normally a subcommand begins with
>> a subcommand name and you use IKJSCAN to locate the offset to the
>> subcommand text; things like assignment statements are special cases.
>> 
> 
> In IKJEGPCH I see only two IKJPOSITs for the parse. But I'm not sure what
> it's working on in the command buffer, since IKJEGMNL has diddled around
> with it.
> 
> Of course this is the code as of the early 1970s, and so has doubtless
> changed quite a lot. On the other hand some of it is probably untouched.
> 
> Tony H.
> 
> --
> 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: TSO IKJOPER question

[Tony Harminc]

On Tue, 9 May 2023 at 15:12, Seymour J Metz  wrote:

> I believe that the optional source tapes for OS/360 and OS/VS2 3.8 are
> archived (CBTTAPE?), so it should be possible to examine the source code
> for TEST.


MVS 3.8 TSO modules can also conveniently be browsed at
http://www.mainframe.eu/mvs38/asm/TSO%20(IKJ)

The first module of the "assign" pseudo-command is IKJEGPCH. It is called
by IKJEGMNL (the subcommand prompter), which has special code to check for
an a=b type "command".


> I would expect it to be something like
>
>  IKJOPER 'Err label',OPERND1=OP1,RSVWD=OPLIST,OPERND2=OP2
> OP1  IKJTERM 'Err label', ...
> OPLIST   IKJRSVWD 'Err label'
>  IKJNAME '='
> OP2  IKJTERM 'Err label', ...
>
> The = is the operator, not a subcommand. Normally a subcommand begins with
> a subcommand name and you use IKJSCAN to locate the offset to the
> subcommand text; things like assignment statements are special cases.
>

In IKJEGPCH I see only two IKJPOSITs for the parse. But I'm not sure what
it's working on in the command buffer, since IKJEGMNL has diddled around
with it.

Of course this is the code as of the early 1970s, and so has doubtless
changed quite a lot. On the other hand some of it is probably untouched.

Tony H.

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

Re: TSO IKJOPER question

[Seymour J Metz]

It is not possible to use the TEST statement of IKJTSOxx to cause TEST to treat 
assignment statements as user subcommands. Furthrt, we it possible you'd need 
to duplicate the functionality of the existing assignment statement and 
distinguish a normal assignment from your version.

It is possible to process an assignment statement that you read as a 
subcommand; you just need to treat it as a special case instead of relying on 
IKJSCAN. Your code needs to recognize it as an assignment statement and pass 
the entire statement to IKJPARSE.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Joseph Reichman [reichman...@gmail.com]
Sent: Tuesday, May 9, 2023 9:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO IKJOPER question

Seymour

I can only say you are amazing

It seems it is not possible

To customize an operator like ‘=‘

As the subcommand

Must appear the first entered text

Talking in IKJTSOxx

subcmd(scmd,LOAD1)

Thank you

> On May 9, 2023, at 9:12 AM, Seymour J Metz  wrote:
>
> I believe that the optional source tapes for OS/360 and OS/VS2 3.8 are 
> archived (CBTTAPE?), so it should be possible to examine the source code for 
> TEST. I would expect it to be something like
>
> IKJOPER 'Err label',OPERND1=OP1,RSVWD=OPLIST,OPERND2=OP2
> OP1  IKJTERM 'Err label', ...
> OPLIST   IKJRSVWD 'Err label'
> IKJNAME '='
> OP2  IKJTERM 'Err label', ...
>
> The = is the operator, not a subcommand. Normally a subcommand begins with a 
> subcommand name and you use IKJSCAN to locate the offset to the subcommand 
> text; things like assignment statements are special cases.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Joseph Reichman [reichman...@gmail.com]
> Sent: Tuesday, May 9, 2023 7:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TSO IKJOPER question
>
> Hi
>
>
>
> I am just wondering when using IKJOPER (operand) and for clarity's sake I
> would like to use an example from TSO TEST so I would imagine the '=' of TSO
> TEST is an IKJOPER
>
> Used to modify storage.
>
>
>
> The subcommand is '='
>
>
>
> Does the subcommand have to be the first operand I mean clearly in the case
> of for example 3R?=X'0001' the subcommand is the second parameter
>
>
>
> If someone could clarify this would appreciate it
>
>
>
> thanks
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: TSO IKJOPER question

[Mike Schwab]

MVS 380 examined the source code included in the MVS 3.8 tapes that
various Hercules developers ordered from IBM.  For the most part, it
was at MVS 3.7 base level with many 3.7 PTFs, 3.8 base and PTFs not
included.  For a few products, the they attempted to update the source
code for the final MVS 3.8J binary version before enhancing a few of
the modules (IFOX assembler, etc).

On Tue, May 9, 2023 at 8:12 AM Seymour J Metz  wrote:
>
> I believe that the optional source tapes for OS/360 and OS/VS2 3.8 are 
> archived (CBTTAPE?), so it should be possible to examine the source code for 
> TEST. I would expect it to be something like
>
>  IKJOPER 'Err label',OPERND1=OP1,RSVWD=OPLIST,OPERND2=OP2
> OP1  IKJTERM 'Err label', ...
> OPLIST   IKJRSVWD 'Err label'
>  IKJNAME '='
> OP2  IKJTERM 'Err label', ...
>
> The = is the operator, not a subcommand. Normally a subcommand begins with a 
> subcommand name and you use IKJSCAN to locate the offset to the subcommand 
> text; things like assignment statements are special cases.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Joseph Reichman [reichman...@gmail.com]
> Sent: Tuesday, May 9, 2023 7:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TSO IKJOPER question
>
> Hi
>
>
>
> I am just wondering when using IKJOPER (operand) and for clarity's sake I
> would like to use an example from TSO TEST so I would imagine the '=' of TSO
> TEST is an IKJOPER
>
> Used to modify storage.
>
>
>
> The subcommand is '='
>
>
>
> Does the subcommand have to be the first operand I mean clearly in the case
> of for example 3R?=X'0001' the subcommand is the second parameter
>
>
>
> If someone could clarify this would appreciate it
>
>
>
> thanks
>
>
> --
> 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



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

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

Re: TSO IKJOPER question

[Joseph Reichman]

Seymour 

I can only say you are amazing 

It seems it is not possible 

To customize an operator like ‘=‘

As the subcommand 

Must appear the first entered text

Talking in IKJTSOxx 

subcmd(scmd,LOAD1)

Thank you 

> On May 9, 2023, at 9:12 AM, Seymour J Metz  wrote:
> 
> I believe that the optional source tapes for OS/360 and OS/VS2 3.8 are 
> archived (CBTTAPE?), so it should be possible to examine the source code for 
> TEST. I would expect it to be something like
> 
> IKJOPER 'Err label',OPERND1=OP1,RSVWD=OPLIST,OPERND2=OP2
> OP1  IKJTERM 'Err label', ...
> OPLIST   IKJRSVWD 'Err label'
> IKJNAME '='
> OP2  IKJTERM 'Err label', ...
> 
> The = is the operator, not a subcommand. Normally a subcommand begins with a 
> subcommand name and you use IKJSCAN to locate the offset to the subcommand 
> text; things like assignment statements are special cases.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Joseph Reichman [reichman...@gmail.com]
> Sent: Tuesday, May 9, 2023 7:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TSO IKJOPER question
> 
> Hi
> 
> 
> 
> I am just wondering when using IKJOPER (operand) and for clarity's sake I
> would like to use an example from TSO TEST so I would imagine the '=' of TSO
> TEST is an IKJOPER
> 
> Used to modify storage.
> 
> 
> 
> The subcommand is '='
> 
> 
> 
> Does the subcommand have to be the first operand I mean clearly in the case
> of for example 3R?=X'0001' the subcommand is the second parameter
> 
> 
> 
> If someone could clarify this would appreciate it
> 
> 
> 
> thanks
> 
> 
> --
> 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: TSO IKJOPER question

[Seymour J Metz]

I believe that the optional source tapes for OS/360 and OS/VS2 3.8 are archived 
(CBTTAPE?), so it should be possible to examine the source code for TEST. I 
would expect it to be something like

 IKJOPER 'Err label',OPERND1=OP1,RSVWD=OPLIST,OPERND2=OP2
OP1  IKJTERM 'Err label', ...
OPLIST   IKJRSVWD 'Err label'
 IKJNAME '='
OP2  IKJTERM 'Err label', ...

The = is the operator, not a subcommand. Normally a subcommand begins with a 
subcommand name and you use IKJSCAN to locate the offset to the subcommand 
text; things like assignment statements are special cases.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Joseph Reichman [reichman...@gmail.com]
Sent: Tuesday, May 9, 2023 7:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TSO IKJOPER question

Hi



I am just wondering when using IKJOPER (operand) and for clarity's sake I
would like to use an example from TSO TEST so I would imagine the '=' of TSO
TEST is an IKJOPER

Used to modify storage.



The subcommand is '='



Does the subcommand have to be the first operand I mean clearly in the case
of for example 3R?=X'0001' the subcommand is the second parameter



If someone could clarify this would appreciate it



thanks


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

TSO IKJOPER question

[Joseph Reichman]

Hi

 

I am just wondering when using IKJOPER (operand) and for clarity's sake I
would like to use an example from TSO TEST so I would imagine the '=' of TSO
TEST is an IKJOPER

Used to modify storage. 

 

The subcommand is '='

 

Does the subcommand have to be the first operand I mean clearly in the case
of for example 3R?=X'0001' the subcommand is the second parameter 

 

If someone could clarify this would appreciate it

 

thanks


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

Re: XLC inline assembler question

[Phil Smith III]

Thanks to all for the info!

 

(Summary for the assembler list, since the action was all on IBM-MAIN: It won't 
hurt; might affect optimization slightly, but probably not worth worrying 
about.)


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

Re: XLC inline assembler question

[Linda Chui]

On Mon, 1 May 2023 18:18:38 -0400, Phil Smith III  wrote:

>Doh, I of course meant -qasm not -dasm. 
>
> 
>
>From: Phil Smith III  
>Sent: Monday, May 1, 2023 5:02 PM
>To: ibm-m...@bama.ua.edu; IBM Mainframe Assembler List 
>(assembler-l...@listserv.uga.edu) 
>Subject: XLC inline assembler question
>
> 
>
>(Cross-posted to IBM-MAIN and the assembler list)
>
>When compiling C programs with XLC, you need to specify the -dasm flag to have 
>inline assembler code recognized as such. I can see PoE arguments for 
>requiring that option; what isn't clear is whether there's any downside to it 
>beyond the unlikely case that you decide to have a function of your own named 
>asm or __asm or __asm__. Is there? We'd rather just use it all the time, 
>rather than trying to keep track of which modules have inline assembler and 
>which don't, but not if it's going to cost significant performance at compile 
>time or something.
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

(posting on behalf of a colleague)

hi Phil,

Generally there is no downside for specifying -qasm all the time. Your analysis 
(and Paul’s) is correct.
There are a few side issues (listings changing to show ASM is in effect, etc.), 
but just turning that option on for everything should work as long as you don’t 
mind those changes occurring.

hope this helps.

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

Re: COBOL question: How to dynamically get the name of the routine that called you

[Farley, Peter]

Thanks Michael, I tried your routine here and it did exactly what I needed, so 
thank you.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Tuesday, May 2, 2023 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL question: How to dynamically get the name of the routine 
that called you

I am attempting to post the assembler program here for reference, we'll see if 
the listserv accepts it without mangling.

To use, call it passing the area you want it to return the calling program name 
in. The call_level_e equate controls how many levels up it goes.



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

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

Re: COBOL question: How to dynamically get the name of the routine that called you

[Bernd Oppolzer]

Is this z/OS? I hope so ...

You say:

I need this for determining from where a high-usage subroutine is being called 
unnecessarily in a large main program
(many called modules with multiple levels of CALL, but no recursion).

are these modules separate load modules which are dynamically called
and is the name of the load module (which may be identical to the 
program-ID) sufficient?


If so, there is no need to rely on the program name which is stored 
somewhere in the EPA signature (PPA1 block).
It is then possible to simply retrieve the EPA from the save area chain 
and check, to which
load module this entry point belongs, using the OS control blocks CDE 
and XTLST,

which is IMO a well-known method (and has no dependency on compiler releases
or even programming languages).

I wrote some dump analysis tools for customers, and they always do both 
methods,
just in case that some "free style" ASSEMBLER programs in the chain 
don't mark the
entry points in some of the known ways. Then we still have the name of 
the load module

(and maybe the offset of the entry point, if it is non-zero).

HTH, kind regards

Bernd


Am 02.05.2023 um 19:08 schrieb Schmitt, Michael:

I wrote an assembler subprogram that gets the name of the caller of the caller, i.e. 
if A > B > asm, it returns A. Or any number of levels up that you want. It 
works for static and dynamic calls, for both Language Environment compatible and 
non-LE programs.*

The logic to get the program name is non-trivial. For example, in an LE 
compatible program it depends on if the Program Prolog Area is in FASTLINK 
format or not.

I don't think this is possible to do in straight COBOL, because how would you 
get access to the registers for the save area chain? But maybe there's an LE 
service that could help.


Let me know if you're interested in the assembler program.


* assuming the program follows standard conventions for the program id 
signature string.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Tuesday, May 2, 2023 11:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL question: How to dynamically get the name of the routine that 
called you

This is an Enterprise COBOL V5/6 question.  No earlier compiler versions are 
involved.

Is it possible for a called COBOL program to dynamically determine the name of 
the calling COBOL program (i.e., the PROGRAM-ID value)?  I have been reading 
the LE Vendor Interfaces manual but I have yet to figure out now to use any of 
the documented services or control blocks to get the name of the caller.

I need this for determining from where a high-usage subroutine is being called 
unnecessarily in a large main program (many called modules with multiple levels 
of CALL, but no recursion).  The subroutine unfortunately is NOT passed the 
name of the caller in the LINKAGE parameters (that would have been too easy . . 
. ).

Any RTFM pointers or process to follow to get the caller's name would be 
appreciated.  I am willing to set up an assembler stub routine to capture the 
data if it cannot be done directly from the COBOL called subroutine.

Peter
--


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

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

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


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

Re: COBOL question: How to dynamically get the name of the routine that called you

[Schmitt, Michael]

I am attempting to post the assembler program here for reference, we'll see if 
the listserv accepts it without mangling.

To use, call it passing the area you want it to return the calling program name 
in. The call_level_e equate controls how many levels up it goes.

--
 setc  'CALLERID'
 title ' - Return name of program caller'
 csect
 amode 31
 rmode any
 using *,r15

 sysstate archlvl=OSREL,   generate z/Architecture code+
   osrel=SYSSTATE

 macro ,   sysdatc can't be in open code
 get_asmtime
 gblc  
   setc  '' date as MMDD
   aread clockd time as HHMMSSTH
setc  ''(1,4).'-'.''(5,2).'-'.''(7,2)  formatted date
setc  ''(1,2).':'.''(3,2).':'.''(5,2)  formatted time
 setc ' '
 mend

 gblc  get assembly date & time
 get_asmtime

 j start   skip over program id
 dcal1(l'prog_id)  count byte for program id
prog_id  dcc' '

savearea dc18f'0'  save area  and  my base address

startbsm   r14,r0  put caller's AMODE in r14
 stm   r14,r12,12(r13) save caller's registers
 lrr2,r13  r2  -> caller's save area
 lar13,savearear13 -> my save area & base
 str13,8(,r2)  set forward chain from caller
 str2,4(,r13)  set backward chain to caller
 drop  r15
 using savearea,r13r13 is my base register
 srr15,r15 clear return code
 l r14,=a(mainline+x'8000') set 31 bit mode
 bsm   r0,r14  branch to mainline

eojgood  srr15,r15 good return: rc = 0
eoj  l r13,4(,r13) point back to caller's save area
 str15,16(,r13)set return code
 lmr14,r12,12(r13) restore caller's registers
 oi15(r13),x'01'   set return indication
 bsm   r0,r14  return to caller & caller's mode

call_level_e equ 2 How many programs up do we go?

*  Return codes:
*  0  - CALL LEVEL caller found, name returned
*  4  - Requested CALL LEVEL not found. Highest caller returned.
*  8  - Incorrect usage: CALLERID directly called by MVS or no
*   parm provided.  No caller returned.
*
*  Registers:
* R0  - Standard system use, work register
* R1  - Standard system use, work register
* R2  - Standard system use
* R3  - Caller name parm
* R4  - Loop counter
* R5  - Save area chain pointer
* R6  - Entry point of caller
* R7  - Language Environment Program Prolog Area 1 (PPA1)
* R8  - Name of caller
* R9  -
* R10 -
* R11 -
* R12 -
* R13 - Base register, save area pointer
* R14 -
* R15 - Standard system use

mainline ds 0h

 ltr   r1,r1   if called with no parm
 jnz   main_l000
 lar15,8  rc=8: usage error
 j eojreturn
main_l000 ds 0hend if

 l r3,0(,r1)   save caller name parm address
 using caller_name_dsect,r3

 lar4,call_level_e r4 = number of callers to find
 srr6,r6   init r6 to no entry point
 srr8,r8   init r8 to no callers found

 l r5,savprev-saver(,r13)  r5 -> my caller's save area
 using saver,r5

main_l100 ds 0hdo CALL LEVEL times
 l r5,savprev climb chain

 ltr   r5,r5  if end of chain
 jnz   main_l120
 ltr   r8,r8 if no callers found
 jnz   main_l110
 lar15,8rc=8: usage error
 j eoj  return
main_l110 ds 0h  else
 lar15,4rc=4: Not enough calls
 j main_l190  found, leave
*end if
main_l120 ds 0h   end if

 l r1,savgrs15r1 = candidate entry point
 lar1,0(,r1)  clear mode bit
 crr6,r1  if same as last entry point
 jemain_l100 iterate

 lrr6,r1  r6 -> entry point

 clc   le_signature_c,5(r6)   if not Lang Environment prog
 jemain_l130
 lar8,5(,r6) use program id for caller
 j main_l150
main_l130 ds 0h   else
 lrr7,r6 r7 -> Program Prolog Area

Re: COBOL question: How to dynamically get the name of the routine that called you

[Joe Monk]

You use the LE service CEETBCK. This is the traceback utility and can be
used to walk the call chain backwards from Enteprise COBOL.

Joe



On Tue, May 2, 2023 at 12:08 PM Schmitt, Michael 
wrote:

> I wrote an assembler subprogram that gets the name of the caller of the
> caller, i.e. if A > B > asm, it returns A. Or any number of levels up that
> you want. It works for static and dynamic calls, for both Language
> Environment compatible and non-LE programs.*
>
> The logic to get the program name is non-trivial. For example, in an LE
> compatible program it depends on if the Program Prolog Area is in FASTLINK
> format or not.
>
> I don't think this is possible to do in straight COBOL, because how would
> you get access to the registers for the save area chain? But maybe there's
> an LE service that could help.
>
>
> Let me know if you're interested in the assembler program.
>
>
> * assuming the program follows standard conventions for the program id
> signature string.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Farley, Peter
> Sent: Tuesday, May 2, 2023 11:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: COBOL question: How to dynamically get the name of the routine
> that called you
>
> This is an Enterprise COBOL V5/6 question.  No earlier compiler versions
> are involved.
>
> Is it possible for a called COBOL program to dynamically determine the
> name of the calling COBOL program (i.e., the PROGRAM-ID value)?  I have
> been reading the LE Vendor Interfaces manual but I have yet to figure out
> now to use any of the documented services or control blocks to get the name
> of the caller.
>
> I need this for determining from where a high-usage subroutine is being
> called unnecessarily in a large main program (many called modules with
> multiple levels of CALL, but no recursion).  The subroutine unfortunately
> is NOT passed the name of the caller in the LINKAGE parameters (that would
> have been too easy . . . ).
>
> Any RTFM pointers or process to follow to get the caller's name would be
> appreciated.  I am willing to set up an assembler stub routine to capture
> the data if it cannot be done directly from the COBOL called subroutine.
>
> Peter
> --
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: COBOL question: How to dynamically get the name of the routine that called you

[Schmitt, Michael]

I wrote an assembler subprogram that gets the name of the caller of the caller, 
i.e. if A > B > asm, it returns A. Or any number of levels up that you want. It 
works for static and dynamic calls, for both Language Environment compatible 
and non-LE programs.*

The logic to get the program name is non-trivial. For example, in an LE 
compatible program it depends on if the Program Prolog Area is in FASTLINK 
format or not.

I don't think this is possible to do in straight COBOL, because how would you 
get access to the registers for the save area chain? But maybe there's an LE 
service that could help.


Let me know if you're interested in the assembler program.


* assuming the program follows standard conventions for the program id 
signature string.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Tuesday, May 2, 2023 11:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL question: How to dynamically get the name of the routine that 
called you

This is an Enterprise COBOL V5/6 question.  No earlier compiler versions are 
involved.

Is it possible for a called COBOL program to dynamically determine the name of 
the calling COBOL program (i.e., the PROGRAM-ID value)?  I have been reading 
the LE Vendor Interfaces manual but I have yet to figure out now to use any of 
the documented services or control blocks to get the name of the caller.

I need this for determining from where a high-usage subroutine is being called 
unnecessarily in a large main program (many called modules with multiple levels 
of CALL, but no recursion).  The subroutine unfortunately is NOT passed the 
name of the caller in the LINKAGE parameters (that would have been too easy . . 
. ).

Any RTFM pointers or process to follow to get the caller's name would be 
appreciated.  I am willing to set up an assembler stub routine to capture the 
data if it cannot be done directly from the COBOL called subroutine.

Peter
--


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

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

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

COBOL question: How to dynamically get the name of the routine that called you

[Farley, Peter]

This is an Enterprise COBOL V5/6 question.  No earlier compiler versions are 
involved.

Is it possible for a called COBOL program to dynamically determine the name of 
the calling COBOL program (i.e., the PROGRAM-ID value)?  I have been reading 
the LE Vendor Interfaces manual but I have yet to figure out now to use any of 
the documented services or control blocks to get the name of the caller.

I need this for determining from where a high-usage subroutine is being called 
unnecessarily in a large main program (many called modules with multiple levels 
of CALL, but no recursion).  The subroutine unfortunately is NOT passed the 
name of the caller in the LINKAGE parameters (that would have been too easy . . 
. ).

Any RTFM pointers or process to follow to get the caller's name would be 
appreciated.  I am willing to set up an assembler stub routine to capture the 
data if it cannot be done directly from the COBOL called subroutine.

Peter
--


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

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

Re: XLC inline assembler question

[Paul Gilmartin]

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

-- 
gil

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

Re: XLC inline assembler question

[Phil Smith III]

Doh, I of course meant -qasm not -dasm. 

 

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

 

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

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


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

XLC inline assembler question

[Phil Smith III]

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

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




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

Re: XLC architecture level question

[Charles Mills]

> where do you put it and what else do you do?

Ray and David have half of the answer. Specifically, you put it in a 
constructor for a static class instance. The first "user code" that C++ runs -- 
before int main() -- is static class constructors.

What else do you do?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of M. Ray Mullins
Sent: Wednesday, April 26, 2023 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC architecture level question

Since this is C++, I'd stick it in a constructor for main, or (less 
desirable) main::init(). No LE games needed.

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

Re: XLC architecture level question

[M. Ray Mullins]

Since this is C++, I'd stick it in a constructor for main, or (less 
desirable) main::init(). No LE games needed.


Cheers,
Ray

On 2023-04-25 14:26, Charles Mills wrote:

Setting ARCH is like playing Blackjack or Twenty-one: guess too low and it is 
sub-optimal; guess too high and you bust.

Note that everything we have said here about ARCH and TUNE applies equally to 
COBOL as to C/C++. Of course if you are writing programs for in-house use your 
universe of machines to support is much smaller. The classic error is 
forgetting about your DR machine.

At CorreLog we managed to ship a C++ build to someone who was too back-level 
for our ARCH. So George -- any of you who know George know that he is a good 
guy but a yell-er -- yelled at me that the S0C1 was totally unacceptable -- we 
needed an error message. I pointed out that SYSTEM COMPLETION CODE=0C1 *is* an 
error message, but he was not having that. So I wrote some assembler code and 
C++ to compare the compiled ARCH level -- you can retrieve it with __ARCH__ -- 
and put out our own message if there were a conflict. Obviously you need to do 
that just as early in your run process as possible or the train will have 
already left the station and run into a wall.

Here's an exercise for the readers. If you want to insert some code into a C++ module 
such that it will run just as early as possible during the run processing, where do you 
put it and what else do you do? (Hint: "right after int main(int argc, char* argv[]) 
and cross your fingers" are NOT the right answers.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, April 25, 2023 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC architecture level question

ARCH level is a "problem" I have dealt with for 12 or so years.

I say "problem" in quotes because it is not much of a problem -- you only have 
to revisit it once every two years, and even then it is not an urgent problem. So you 
don't need a solution that runs on autopilot -- you can just revisit your decision every 
two years or so.

You need a management policy. The one I have advocated to my management is "we will 
support the oldest hardware supported by the oldest supported release of z/OS." I 
point out that while there may be lots of customers out there running z9's, they probably 
are not buying a whole lot of OEM products. Currently that would be ARCH(10), 
representing the zB/EC12, supported by z/OS V2R4. Once V2R4 goes out of service it would 
become

--
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: XLC architecture level question

[David Crayford]

On 26/4/23 05:26, Charles Mills wrote:

Setting ARCH is like playing Blackjack or Twenty-one: guess too low and it is 
sub-optimal; guess too high and you bust.


We have products that build using multiple ARCH options and dynamically 
load code for the target architecture at runtime.




Here's an exercise for the readers. If you want to insert some code into a C++ module 
such that it will run just as early as possible during the run processing, where do you 
put it and what else do you do? (Hint: "right after int main(int argc, char* argv[]) 
and cross your fingers" are NOT the right answers.)


Off the top of my head you can use a CEEBINT LE initialization exit, 
although this is 31-bit non-XPLINK so a legacy solution. In C++ you can 
simply use static initialization and run code in a C++ class constructor 
after defining the class in file scope.





Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, April 25, 2023 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC architecture level question

ARCH level is a "problem" I have dealt with for 12 or so years.

I say "problem" in quotes because it is not much of a problem -- you only have 
to revisit it once every two years, and even then it is not an urgent problem. So you 
don't need a solution that runs on autopilot -- you can just revisit your decision every 
two years or so.

You need a management policy. The one I have advocated to my management is "we will 
support the oldest hardware supported by the oldest supported release of z/OS." I 
point out that while there may be lots of customers out there running z9's, they probably 
are not buying a whole lot of OEM products. Currently that would be ARCH(10), 
representing the zB/EC12, supported by z/OS V2R4. Once V2R4 goes out of service it would 
become

--
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: XLC architecture level question

[Farley, Peter]

SWAG, so I won't be surprised to be dead wrong:

As an INCLUDE in the SYSIN to the binder with an ENTRY statement naming the 
CSECT you include.  Your inserted code then has to branch to the "real" main 
entry point for C++, whatever that may be (I've not written or run any C++ on 
z/OS so I can’t be sure what that may be -- V(CEEMAIN) maybe?).

Possibly may need to ORDER your new CSECT first and let the binder default to 
the first CSECT as the entry point?

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Tuesday, April 25, 2023 5:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC architecture level question

Setting ARCH is like playing Blackjack or Twenty-one: guess too low and it is 
sub-optimal; guess too high and you bust.

Note that everything we have said here about ARCH and TUNE applies equally to 
COBOL as to C/C++. Of course if you are writing programs for in-house use your 
universe of machines to support is much smaller. The classic error is 
forgetting about your DR machine.

At CorreLog we managed to ship a C++ build to someone who was too back-level 
for our ARCH. So George -- any of you who know George know that he is a good 
guy but a yell-er -- yelled at me that the S0C1 was totally unacceptable -- we 
needed an error message. I pointed out that SYSTEM COMPLETION CODE=0C1 *is* an 
error message, but he was not having that. So I wrote some assembler code and 
C++ to compare the compiled ARCH level -- you can retrieve it with __ARCH__ -- 
and put out our own message if there were a conflict. Obviously you need to do 
that just as early in your run process as possible or the train will have 
already left the station and run into a wall.

Here's an exercise for the readers. If you want to insert some code into a C++ 
module such that it will run just as early as possible during the run 
processing, where do you put it and what else do you do? (Hint: "right after 
int main(int argc, char* argv[]) and cross your fingers" are NOT the right 
answers.) 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, April 25, 2023 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC architecture level question

ARCH level is a "problem" I have dealt with for 12 or so years. 

I say "problem" in quotes because it is not much of a problem -- you only have 
to revisit it once every two years, and even then it is not an urgent problem. 
So you don't need a solution that runs on autopilot -- you can just revisit 
your decision every two years or so.

You need a management policy. The one I have advocated to my management is "we 
will support the oldest hardware supported by the oldest supported release of 
z/OS." I point out that while there may be lots of customers out there running 
z9's, they probably are not buying a whole lot of OEM products. Currently that 
would be ARCH(10), representing the zB/EC12, supported by z/OS V2R4. Once V2R4 
goes out of service it would become
--


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


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

Re: XLC architecture level question

[Charles Mills]

Setting ARCH is like playing Blackjack or Twenty-one: guess too low and it is 
sub-optimal; guess too high and you bust.

Note that everything we have said here about ARCH and TUNE applies equally to 
COBOL as to C/C++. Of course if you are writing programs for in-house use your 
universe of machines to support is much smaller. The classic error is 
forgetting about your DR machine.

At CorreLog we managed to ship a C++ build to someone who was too back-level 
for our ARCH. So George -- any of you who know George know that he is a good 
guy but a yell-er -- yelled at me that the S0C1 was totally unacceptable -- we 
needed an error message. I pointed out that SYSTEM COMPLETION CODE=0C1 *is* an 
error message, but he was not having that. So I wrote some assembler code and 
C++ to compare the compiled ARCH level -- you can retrieve it with __ARCH__ -- 
and put out our own message if there were a conflict. Obviously you need to do 
that just as early in your run process as possible or the train will have 
already left the station and run into a wall.

Here's an exercise for the readers. If you want to insert some code into a C++ 
module such that it will run just as early as possible during the run 
processing, where do you put it and what else do you do? (Hint: "right after 
int main(int argc, char* argv[]) and cross your fingers" are NOT the right 
answers.) 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, April 25, 2023 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC architecture level question

ARCH level is a "problem" I have dealt with for 12 or so years. 

I say "problem" in quotes because it is not much of a problem -- you only have 
to revisit it once every two years, and even then it is not an urgent problem. 
So you don't need a solution that runs on autopilot -- you can just revisit 
your decision every two years or so.

You need a management policy. The one I have advocated to my management is "we 
will support the oldest hardware supported by the oldest supported release of 
z/OS." I point out that while there may be lots of customers out there running 
z9's, they probably are not buying a whole lot of OEM products. Currently that 
would be ARCH(10), representing the zB/EC12, supported by z/OS V2R4. Once V2R4 
goes out of service it would become

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

Re: XLC architecture level question

[Charles Mills]

ARCH level is a "problem" I have dealt with for 12 or so years. 

I say "problem" in quotes because it is not much of a problem -- you only
have to revisit it once every two years, and even then it is not an urgent
problem. So you don't need a solution that runs on autopilot -- you can just
revisit your decision every two years or so.

You need a management policy. The one I have advocated to my management is
"we will support the oldest hardware supported by the oldest supported
release of z/OS." I point out that while there may be lots of customers out
there running z9's, they probably are not buying a whole lot of OEM
products. Currently that would be ARCH(10), representing the zB/EC12,
supported by z/OS V2R4. Once V2R4 goes out of service it would become
ARCH(11). But it is a Product Management decision, not a techie decision.
(Do note that minimum ARCH levels do NOT change with every release: V2R4 and
V2R3 were both ARCH(10), a two-ARCH leap from V2R2).

How much does it matter? If yours is compute-intensive application that
churns along all day, then it is probably important. For other situations it
may be less important. You might want to do some benchmarks. And! There is a
companion option, TUNE. Check that one out!

Here's the good news. It's not like, say, a decision to start using EXR in
your assembler code, where the way back requires real work. Let's say you
settle on ARCH(10). And then let's say that in six months your SVP of Sales
comes running in and says "I have a $300K opportunity if we can support a
z9!!!" All you would have to do is change to ARCH(7) and do a build. It is
just a management decision whether it is worth the bother to do the build,
test and distribute. There is no real development "effort."

Also, a cheat sheet: "marketing number" (like z16) is 2 greater than ARCH
and 6 greater than HLASM ZS-n. IOW, z16 is ARCH(14) and ZS-10.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith III
Sent: Monday, April 24, 2023 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC architecture level question

Thank you! Does that default change periodically? I suppose it must-is it
always such that the default supports the oldest currently supported

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

Re: XLC architecture level question

[Phil Smith III]

Gil wrote:
>A default of "oldest currently supported" is of little use on the day
>before end of support for that version. Better would be a form to
>specify "whatever version for which support is guaranteed for N days
>from the current date." Akin to the "find ... -mtime n".

Eh? Why is it "of little use"? It's slightly suboptimal, but at least you're
not going to release something that doesn't work. What did you mean?


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

Re: XLC architecture level question

[Paul Gilmartin]

On Mon, 24 Apr 2023 17:40:16 -0400, Phil Smith III wrote:
>
>Thank you! Does that default change periodically? I suppose it must-is it
>always such that the default supports the oldest currently supported
>hardware? What we don't want to do is upgrade the compile and break our
>product for our customers. We can explicitly specify ARCH(10) now, but then
>WE have to remember to update it. If the design is to always support what
>IBM supports, we can stop worrying about it.
>
A default of "oldest currently supported" is of little use on the day before 
end of
support for that version.  Better would be a form to specify "whatever version
for which support is guaranteed for N days from the current date."  Akin to the
"find ... -mtime n".

-- 
gil

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

Re: XLC architecture level question

[Phil Smith III]

Linda Chui wrote:

>My colleague validated this issue. Yes, this is a documentation error.

>The default should be the same as the ARCH option description

>mentioned (page 63). We have notified our content editor to

>update/correct our docs.

 

>Thanks for bringing this to our attention.

 

Thank you! Does that default change periodically? I suppose it must-is it
always such that the default supports the oldest currently supported
hardware? What we don't want to do is upgrade the compile and break our
product for our customers. We can explicitly specify ARCH(10) now, but then
WE have to remember to update it. If the design is to always support what
IBM supports, we can stop worrying about it.


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

Re: XLC architecture level question

[Linda Chui]

On Mon, 24 Apr 2023 11:24:25 -0400, Phil Smith III  wrote:

>SC14-7307-40, the z/OS 2.4 XL C/C++ User's Guide, says on PDF page 63 that
>ARCH(10) is the default. However, on PDF page 580, it also says:
>Architecture target is set according to the last-found instance of the
>-qarch compiler option, provided that the specified -qarch setting is
>compatible with the compiler mode setting. If the -qarch option is not set,
>the compiler assumes a -qarch setting of 5.
>
>and it repeats that 5 is the default several times. My first thought was
>that maybe it's different when run under USS, but my  listing (with no
>explicit ARCH) includes:
>*ARCH(10)
>so I'm thinking it's a doc error. Anyone know better? Or am I fatally
>confusing something here?
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



Hi Phil,

My colleague validated this issue. Yes, this is a documentation error. The 
default should be the same as the ARCH option description mentioned (page 63).
We have notified our content editor to update/correct our docs.

Thanks for bringing this to our attention.

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

XLC architecture level question

[Phil Smith III]

SC14-7307-40, the z/OS 2.4 XL C/C++ User's Guide, says on PDF page 63 that
ARCH(10) is the default. However, on PDF page 580, it also says:
Architecture target is set according to the last-found instance of the
-qarch compiler option, provided that the specified -qarch setting is
compatible with the compiler mode setting. If the -qarch option is not set,
the compiler assumes a -qarch setting of 5.

and it repeats that 5 is the default several times. My first thought was
that maybe it's different when run under USS, but my  listing (with no
explicit ARCH) includes:
*ARCH(10)
so I'm thinking it's a doc error. Anyone know better? Or am I fatally
confusing something here?


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

Re: Question about IEAARR Process

[Peter Relson]

> Does the PC routine (IEAARR) simply branch to the Target Routine (R15)
> making it
> an extension of the IEAARR PC Service Routine?

It's not necessarily "simply" and it depends on what you mean by "an extension 
of". But for the most part "yes".
The IEAARR PC Service Routine runs in the caller's state and key (to the extent 
that an authorized user did what they're required to do). And yes, after doing 
whatever else it might feel necessary to do, it branches to the target routine.

When the target routine returns to the system via the return address in reg 14, 
the system issues the PR to match the PC

>Essentially, it works like a combo of BAKR and ESTAEX.

I'd say it works like an ARR that you do not have to be authorized to define 
and use. ESTAEX is not used. That is why it is more efficient than issuing 
ESTAEX. It is not more efficient than an ARR if you happened to be in a 
position to use an ARR.

Peter Relson
z/OS Core Technology Design


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

Re: Question about IEAARR Process

[Binyamin Dissen]

Haven't used it myself, but based on the macro expansion the GLUE would only
need to do is to perhaps place R0-R1 in the MSTA and then set R1 from AR0 and
BASR 14,15.

The predefined ARR of IEAARR would receive control upon abend and user the
MSTA area to set the parameter register and branch to the user specified ARR.

The advantage of ARR over ESTAE is that the ARR is automatically available.
The downside is the PC overhead.


On Fri, 21 Apr 2023 21:42:52 GMT "esst...@juno.com"  wrote:

:>Hello
:>.
:>.
:>Can anyone add some additional information regarding IEAARR.
:>I am trying to clean up an existing Associated Recovery Routine,
:>by first using IEAARR to drive a Target Routine that is designed to
:>Abend and drive the Associated Recovery Routine.
:>.
:>This works well .. I have No issues with IEAARR, and no issues with the ARR.
:>.
:>I have provided my IEAARR and its expansion.
:>.
:>IEAARR DYNSTORAGE=AVAIL, 
:>  ARRPTR=ARRRTN@,
:>  ARRPARAMPTR=ARRPARMS@, 
:>  PARAMPTR=TARGPARMS@,   
:>  TARGETPTR=TARGETRTN@,  
:>  TARGETSTATE=PROB   
:>.
:>400+M00M0011 DS0H IEAARR-0  
:>401+  PUSH  PRINT   
:>402+   PRINT ON 
:>403+ L 1,ARRRTN@   Pass ARR address 
:>404+ L 0,ARRPARMS@ Pass ARRPARAM address
:>405+ L 14,TARGPARMS@   Get parameter address
:>406+ SAR   0,14Pass parameter address   
:>407+ L 15,TARGETRTN@   Pass target address  
:>408+ L 14,16(0,0)  GET CVT ADDRESS  
:>409+ L 14,772(14,0)GET SFT ADDRESS  
:>410+ L 14,500(14,0)GET LX/EX FOR SERVICE RTN
:>411+ PC0(14)
:>412+ POP   PRINT
:>413+*IEAARR-0 
:>.
:>.
:>My understanding is the Expansion of IEAARR issues a Program Call (PC) to the
:>IEAARR service. Register 15 contains the address of the Target Routine.
:>.
:>Does the PC routine (IEAARR) simply branch to the Target Routine (R15) making 
it 
:>an extension of the IEAARR PC Service Routine? 
:>.
:>Is the Target Routine Attached as a separate Task ?
:>.
:>Can anyone add some details as to how IBM architected this..
:>.
:>.
:> Paul 
:>.
:>.
:>.   
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: Question about IEAARR Process

[Steve Smith]

Based on my experience (I have no inside knowledge), IEARR is a very simple
non-space-switching PC program that calls your specified EP as a
subroutine, and same goes for the ARR address.  It's very simple... no
subtask is involved, nor any of the privilege modifications that PCs would
normally be used for.  Essentially, it works like a combo of BAKR and
ESTAEX.

Possibly IEARR is more efficient than the latter.  I know I've used it a
couple of times to call subroutines that needed special abend handling; but
it has been a while.

sas


On Fri, Apr 21, 2023 at 5:44 PM esst...@juno.com  wrote:

> Hello
> ...
> Does the PC routine (IEAARR) simply branch to the Target Routine (R15)
> making it
> an extension of the IEAARR PC Service Routine?
> .
> Is the Target Routine Attached as a separate Task ?
> .
> Can anyone add some details as to how IBM architected this..
> .
> .
>  Paul
> .
> .
> .
> --
> 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

Question about IEAARR Process

[esst...@juno.com]

Hello
.
.
Can anyone add some additional information regarding IEAARR.
I am trying to clean up an existing Associated Recovery Routine,
by first using IEAARR to drive a Target Routine that is designed to
Abend and drive the Associated Recovery Routine.
.
This works well .. I have No issues with IEAARR, and no issues with the ARR.
.
I have provided my IEAARR and its expansion.
.
IEAARR DYNSTORAGE=AVAIL, 
  ARRPTR=ARRRTN@,
  ARRPARAMPTR=ARRPARMS@, 
  PARAMPTR=TARGPARMS@,   
  TARGETPTR=TARGETRTN@,  
  TARGETSTATE=PROB   
.
400+M00M0011 DS0H IEAARR-0  
401+  PUSH  PRINT   
402+   PRINT ON 
403+ L 1,ARRRTN@   Pass ARR address 
404+ L 0,ARRPARMS@ Pass ARRPARAM address
405+ L 14,TARGPARMS@   Get parameter address
406+ SAR   0,14Pass parameter address   
407+ L 15,TARGETRTN@   Pass target address  
408+ L 14,16(0,0)  GET CVT ADDRESS  
409+ L 14,772(14,0)GET SFT ADDRESS  
410+ L 14,500(14,0)GET LX/EX FOR SERVICE RTN
411+ PC0(14)
412+ POP   PRINT
413+*IEAARR-0 
.
.
My understanding is the Expansion of IEAARR issues a Program Call (PC) to the
IEAARR service. Register 15 contains the address of the Target Routine.
.
Does the PC routine (IEAARR) simply branch to the Target Routine (R15) making 
it 
an extension of the IEAARR PC Service Routine? 
.
Is the Target Routine Attached as a separate Task ?
.
Can anyone add some details as to how IBM architected this..
.
.
 Paul 
.
.
.   
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Z15 HMC Question

[Tony Harminc]

On Fri, 21 Apr 2023 at 11:33, Seymour J Metz  wrote:

> > IMHO it is not related to the group.
>
> How is a question about the HMC on an IBM mainframe not related to
> IBM-MAIN?
>

Not the group IBM-MAIN - the group the OP mentioned in "I created a custom
group that contains a subset of the LPARs defined on that CEC."

Tony H.


> From: IBM Mainframe Discussion List  on behalf
> of Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
> Sent: Friday, April 21, 2023 11:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Z15 HMC Question
>
> W dniu 20.04.2023 o 16:37, Mark Jacobs pisze:
> > I created a custom group that contains a subset of the LPARs defined on
> that CEC. When I assign an activation profile to an LPAR in the custom
> group, the new assignment isn't being reflected in the Systems Management
> tab for the LPARs I changed, it's showing the value that was assigned
> before my change.
> >
> > Is this normal?
> > Should I be concerned?
> > If we activate the LPAR using its entry in the Systems Management tab,
> which profile will it use?
> > I assume that if we activate the LPAR using its entry in the custom
> group, it WILL use the newly assigned activation profile, since that's what
> is showing.
> >
> > I have many concerns/questions.
>
> IMHO it is not related to the group.
>
>
> BTW: what does it mean "assigned to LPAR"?
> IMHO you can have multiple Reset profiles, but only one Image aka LPAR
> profile - that's because profile name is equal LPAR name. So it is
> impossible to have two LPAR profiles for one LPAR. Regarding Reset
> profiles - one of them is assigned for activation. Only one.
>
> Trivia: you can have more LPAR profiles, some of the profiles can be
> unassigned. It can be used as a trick: take LP1, save as LP1A, LP1B,
> etc. And you have backup copies. However only LP1 profile can used for
> LP1 LPAR. The rest is inactive.
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> 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: Z15 HMC Question

[Dana Mitchell]

On Fri, 21 Apr 2023 15:35:38 +, Mark Jacobs  
wrote:
>
>I can assign a different activation profile for the same physical lpar in each 
>group. I can see the benefits and potential problems by doing so. The team 
>discussed it this morning and we're all good now.
>

At a previous shop, we had several different groups, each containing all lpars. 
 Each groups' lpar entries were assigned different load profiles.  A group for 
IPLing any LPAR from SYSRESA,  one group for SYSRESB,  one group for SADUMP etc.

Dana

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

Re: Z15 HMC Question

[Radoslaw Skorupka]

W dniu 21.04.2023 o 17:32, Seymour J Metz pisze:

IMHO it is not related to the group.

How is a question about the HMC on an IBM mainframe not related to IBM-MAIN?


I did not say IBM-MAIN. I mentioned "custom group that contains a subset..."



--
Radoslaw Skorupka
Lodz, Poland








From: IBM Mainframe Discussion List  on behalf of Radoslaw 
Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 21, 2023 11:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Z15 HMC Question

W dniu 20.04.2023 o 16:37, Mark Jacobs pisze:

I created a custom group that contains a subset of the LPARs defined on that 
CEC. When I assign an activation profile to an LPAR in the custom group, the 
new assignment isn't being reflected in the Systems Management tab for the 
LPARs I changed, it's showing the value that was assigned before my change.

Is this normal?
Should I be concerned?
If we activate the LPAR using its entry in the Systems Management tab, which 
profile will it use?
I assume that if we activate the LPAR using its entry in the custom group, it 
WILL use the newly assigned activation profile, since that's what is showing.

I have many concerns/questions.

IMHO it is not related to the group.


BTW: what does it mean "assigned to LPAR"?
IMHO you can have multiple Reset profiles, but only one Image aka LPAR
profile - that's because profile name is equal LPAR name. So it is
impossible to have two LPAR profiles for one LPAR. Regarding Reset
profiles - one of them is assigned for activation. Only one.

Trivia: you can have more LPAR profiles, some of the profiles can be
unassigned. It can be used as a trick: take LP1, save as LP1A, LP1B,
etc. And you have backup copies. However only LP1 profile can used for
LP1 LPAR. The rest is inactive.


--
Radoslaw Skorupka
Lodz, Poland

--
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: Z15 HMC Question

[Mark Jacobs]

As it turned out I answered my own question yesterday late afternoon. I can 
create multiple groups, and assign the same lpar to as many groups as I desire. 

I can assign a different activation profile for the same physical lpar in each 
group. I can see the benefits and potential problems by doing so. The team 
discussed it this morning and we're all good now.

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com


--- Original Message ---
On Friday, April 21st, 2023 at 11:24 AM, Radoslaw Skorupka 
<0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:


> W dniu 20.04.2023 o 16:37, Mark Jacobs pisze:
> 
> > I created a custom group that contains a subset of the LPARs defined on 
> > that CEC. When I assign an activation profile to an LPAR in the custom 
> > group, the new assignment isn't being reflected in the Systems Management 
> > tab for the LPARs I changed, it's showing the value that was assigned 
> > before my change.
> > 
> > Is this normal?
> > Should I be concerned?
> > If we activate the LPAR using its entry in the Systems Management tab, 
> > which profile will it use?
> > I assume that if we activate the LPAR using its entry in the custom group, 
> > it WILL use the newly assigned activation profile, since that's what is 
> > showing.
> > 
> > I have many concerns/questions.
> 
> 
> IMHO it is not related to the group.
> 
> 
> BTW: what does it mean "assigned to LPAR"?
> IMHO you can have multiple Reset profiles, but only one Image aka LPAR
> profile - that's because profile name is equal LPAR name. So it is
> impossible to have two LPAR profiles for one LPAR. Regarding Reset
> profiles - one of them is assigned for activation. Only one.
> 
> Trivia: you can have more LPAR profiles, some of the profiles can be
> unassigned. It can be used as a trick: take LP1, save as LP1A, LP1B,
> etc. And you have backup copies. However only LP1 profile can used for
> LP1 LPAR. The rest is inactive.
> 
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> --
> 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: Z15 HMC Question

[Seymour J Metz]

> IMHO it is not related to the group.

How is a question about the HMC on an IBM mainframe not related to IBM-MAIN?




From: IBM Mainframe Discussion List  on behalf of 
Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 21, 2023 11:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Z15 HMC Question

W dniu 20.04.2023 o 16:37, Mark Jacobs pisze:
> I created a custom group that contains a subset of the LPARs defined on that 
> CEC. When I assign an activation profile to an LPAR in the custom group, the 
> new assignment isn't being reflected in the Systems Management tab for the 
> LPARs I changed, it's showing the value that was assigned before my change.
>
> Is this normal?
> Should I be concerned?
> If we activate the LPAR using its entry in the Systems Management tab, which 
> profile will it use?
> I assume that if we activate the LPAR using its entry in the custom group, it 
> WILL use the newly assigned activation profile, since that's what is showing.
>
> I have many concerns/questions.

IMHO it is not related to the group.


BTW: what does it mean "assigned to LPAR"?
IMHO you can have multiple Reset profiles, but only one Image aka LPAR
profile - that's because profile name is equal LPAR name. So it is
impossible to have two LPAR profiles for one LPAR. Regarding Reset
profiles - one of them is assigned for activation. Only one.

Trivia: you can have more LPAR profiles, some of the profiles can be
unassigned. It can be used as a trick: take LP1, save as LP1A, LP1B,
etc. And you have backup copies. However only LP1 profile can used for
LP1 LPAR. The rest is inactive.


--
Radoslaw Skorupka
Lodz, Poland

--
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: Z15 HMC Question

[Radoslaw Skorupka]

W dniu 20.04.2023 o 16:37, Mark Jacobs pisze:

I created a custom group that contains a subset of the LPARs defined on that 
CEC. When I assign an activation profile to an LPAR in the custom group, the 
new assignment isn't being reflected in the Systems Management tab for the 
LPARs I changed, it's showing the value that was assigned before my change.

Is this normal?
Should I be concerned?
If we activate the LPAR using its entry in the Systems Management tab, which 
profile will it use?
I assume that if we activate the LPAR using its entry in the custom group, it 
WILL use the newly assigned activation profile, since that's what is showing.

I have many concerns/questions.


IMHO it is not related to the group.


BTW: what does it mean "assigned to LPAR"?
IMHO you can have multiple Reset profiles, but only one Image aka LPAR 
profile - that's because profile name is equal LPAR name. So it is 
impossible to have two LPAR profiles for one LPAR. Regarding Reset 
profiles - one of them is assigned for activation. Only one.


Trivia: you can have more LPAR profiles, some of the profiles can be 
unassigned. It can be used as a trick: take LP1, save as LP1A, LP1B, 
etc. And you have backup copies. However only LP1 profile can used for 
LP1 LPAR. The rest is inactive.



--
Radoslaw Skorupka
Lodz, Poland

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

Z15 HMC Question

[Mark Jacobs]

I created a custom group that contains a subset of the LPARs defined on that 
CEC. When I assign an activation profile to an LPAR in the custom group, the 
new assignment isn't being reflected in the Systems Management tab for the 
LPARs I changed, it's showing the value that was assigned before my change.

Is this normal?
Should I be concerned?
If we activate the LPAR using its entry in the Systems Management tab, which 
profile will it use?
I assume that if we activate the LPAR using its entry in the custom group, it 
WILL use the newly assigned activation profile, since that's what is showing.

I have many concerns/questions.

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

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

Re: [EXTERNAL] ISPF usage question

[Robert Prins]

ot;
  end

if substr(ls, 13, 1) = '1' then
  do
line = ' - Data on line was changed by the TE, TF or ' ||,
   'TS command'
"isredit line_before .ELS = noteline (LINE)"
  end

if substr(ls, 14, 1) = '1' then
  do
line = ' - The line was renumbered'
"isredit line_before .ELS = noteline (LINE)"
  end
  end
exit 1

No clue if there's a flag for lines originating from "MD"

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather <https://prino.neocities.org/index.html>
Some REXX code for use on z/OS
<https://prino.neocities.org/zOS/zOS-Tools.html>


From: IBM Mainframe Discussion List  On Behalf Of
Pommier, Rex

> Sent: Friday, April 14, 2023 11:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] ISPF usage question
>
> Thanks, all, for your suggestions.  It is as I feared/figured.  ISPF edit
> doesn't have any mechanism to actually search for information in =NOTE= or
> ==MSG> lines without converting them to full data lines.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Horne, Jim
> Sent: Tuesday, April 11, 2023 6:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] ISPF usage question
>
> Check out the ISPF Edit LOCATE command, especially LOCATE SPECIAL and
> LOCATE NOTE
>
> Jim Horne
> -Original Message-
>
> Running certain ISPF macros and/or  commands, we get lines added to the
> ISPF edit screen with "=NOTE=" or "==MSG>" lines.  Is there a way to make
> these lines searchable without converting them to full data lines?  The
> specific instance I'm asking about is running a third party JCL checker,
> the lines output from the checker are typically notes or messages.  The
> nice thing about them being such, is they aren't really part of the member
> being edited/checked so if I save the member, these lines aren't included
> in the member being saved.  The drawback of them is that they aren't
> searchable, so for example, if I'm looking at output with a called PROC,
> and I want to search for a particular piece of substituted JCL, I can't do
> so (that I know of) unless I do a full "make data" on the member, which
> then makes me vulnerable to accidentally saving the member with all the
> notes and messages still there.
>
> 
> NOTICE: All information in and attached to the e-mails below may be
> proprietary, confidential, privileged and otherwise protected from improper
> or erroneous disclosure. If you are not the sender's intended recipient,
> you are not authorized to intercept, read, print, retain, copy, forward, or
> disseminate this message. If you have erroneously received this
> communication, please notify the sender immediately by phone (704-758-1000)
> or by e-mail and destroy all copies of this message electronic, paper, or
> otherwise. By transmitting documents via this email: Users, Customers,
> Suppliers and Vendors collectively acknowledge and agree the transmittal of
> information via email is voluntary, is offered as a convenience, and is not
> a secured method of communication; Not to transmit any payment information
> E.G. credit card, debit card, checking account, wire transfer information,
> passwords, or sensitive and personal information E.G. Driver's license,
> DOB, social security, or any other information the user wishes to remain
> confidential; To transmit only non-confidential information such as plans,
> pictures and drawings and to assume all risk and liability for and
> indemnify Lowe's from any claims, losses or damages that may arise from the
> transmittal of documents or including non-confidential information in the
> body of an email transmittal. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged. If the reader of this message is
> not the intended recipient or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any disclosure, distribution, copying, or any action taken or action
> omitted in reliance on it, is strictly prohibited and may be unlawful. If
> you have received this communication in error, please notify us immediately
> by replying to this message and destroy the material in its entirety,
> whether in electronic or hard co

Re: [EXTERNAL] ISPF usage question

[Steve Thompson]

I like that. I would work nicely with REXX.

   "It is kind of like there needs to be syntax that references
   messages lines relative to a data line. For example, if
   there's 3 messages following the data line at relative line
   number 10, these would be 10.1, 10.2, 10.3."


Steve Thompson

On 4/14/2023 1:56 PM, Schmitt, Michael wrote:

Nice idea, but doesn't work for two reasons.

The first is that LINE "retrieves the data from the DATA line" (emphasis mine), 
but messages lines are not data lines.

The second is that the syntax for retrieving data requires either LINE linenum 
or LINE label; you can't just say (varname) = LINE.

What you're seeing in the manual:

LINE
Data from this line is used

is referring to the options for the *data* part of the syntax, where you're 
assigning data to a line. It is one of the values acceptable for operand when 
using the Merge format.


I've had other people ask me about how a macro can retrieve message lines 
before. I'm thinking an enhancement request (Idea) is in order, but I'm not 
sure what to ask for. The problem is that Edit works by using relative line 
numbers, but messages have no line numbers. So if they were able to be 
referenced, how?

It is kind of like there needs to be syntax that references messages lines 
relative to a data line. For example, if there's 3 messages following the data 
line at relative line number 10, these would be 10.1, 10.2, 10.3.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Friday, April 14, 2023 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] ISPF usage question

I've never had to deal with this so I've kept my figurative mouth shut so far.  
But if you're planning to give up at this point, I'll expose my ignorance:  
Couldn't you write a REXX that uses LOCATE to find the next message or note 
line, then LINE to pull the contents of that line and examine it?  It seems to 
say here that specifying LINE without a line number pulls the current line.  
But as I say, I've never tested it.

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

/* I went water skiing and it turns out I scream the same way whether I'm about 
to be devoured by a Great White or a piece of seaweed touches my foot.  
-attributed to both Kevin James and Axel Rose */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Friday, April 14, 2023 12:28

Thanks, all, for your suggestions.  It is as I feared/figured.  ISPF edit doesn't 
have any mechanism to actually search for information in =NOTE= or ==MSG> lines 
without converting them to full data lines.

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




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


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

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

Re: [EXTERNAL] ISPF usage question

[Schmitt, Michael]

Nice idea, but doesn't work for two reasons.

The first is that LINE "retrieves the data from the DATA line" (emphasis mine), 
but messages lines are not data lines.

The second is that the syntax for retrieving data requires either LINE linenum 
or LINE label; you can't just say (varname) = LINE.

What you're seeing in the manual:

LINE
Data from this line is used

is referring to the options for the *data* part of the syntax, where you're 
assigning data to a line. It is one of the values acceptable for operand when 
using the Merge format.


I've had other people ask me about how a macro can retrieve message lines 
before. I'm thinking an enhancement request (Idea) is in order, but I'm not 
sure what to ask for. The problem is that Edit works by using relative line 
numbers, but messages have no line numbers. So if they were able to be 
referenced, how?

It is kind of like there needs to be syntax that references messages lines 
relative to a data line. For example, if there's 3 messages following the data 
line at relative line number 10, these would be 10.1, 10.2, 10.3.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Friday, April 14, 2023 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] ISPF usage question

I've never had to deal with this so I've kept my figurative mouth shut so far.  
But if you're planning to give up at this point, I'll expose my ignorance:  
Couldn't you write a REXX that uses LOCATE to find the next message or note 
line, then LINE to pull the contents of that line and examine it?  It seems to 
say here that specifying LINE without a line number pulls the current line.  
But as I say, I've never tested it.

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

/* I went water skiing and it turns out I scream the same way whether I'm about 
to be devoured by a Great White or a piece of seaweed touches my foot.  
-attributed to both Kevin James and Axel Rose */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Friday, April 14, 2023 12:28

Thanks, all, for your suggestions.  It is as I feared/figured.  ISPF edit 
doesn't have any mechanism to actually search for information in =NOTE= or 
==MSG> lines without converting them to full data lines.

--
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: [EXTERNAL] ISPF usage question

[Bob Bridges]

I've never had to deal with this so I've kept my figurative mouth shut so far.  
But if you're planning to give up at this point, I'll expose my ignorance:  
Couldn't you write a REXX that uses LOCATE to find the next message or note 
line, then LINE to pull the contents of that line and examine it?  It seems to 
say here that specifying LINE without a line number pulls the current line.  
But as I say, I've never tested it.

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

/* I went water skiing and it turns out I scream the same way whether I'm about 
to be devoured by a Great White or a piece of seaweed touches my foot.  
-attributed to both Kevin James and Axel Rose */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Friday, April 14, 2023 12:28

Thanks, all, for your suggestions.  It is as I feared/figured.  ISPF edit 
doesn't have any mechanism to actually search for information in =NOTE= or 
==MSG> lines without converting them to full data lines.  

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

Re: [EXTERNAL] ISPF usage question

[Lionel B. Dyck]

You could try something like this:

1. while in edit (or view) exclude all
2. then md to convert all
3. then do a compare * 

Now all the 'new' records will have a indicator in the record number field - I 
don't recall if you can access that but suspect you might be able to do so.


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

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Friday, April 14, 2023 11:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] ISPF usage question

Thanks, all, for your suggestions.  It is as I feared/figured.  ISPF edit 
doesn't have any mechanism to actually search for information in =NOTE= or 
==MSG> lines without converting them to full data lines.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Horne, Jim
Sent: Tuesday, April 11, 2023 6:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] ISPF usage question

Check out the ISPF Edit LOCATE command, especially LOCATE SPECIAL and LOCATE 
NOTE

Jim Horne
-Original Message-

Running certain ISPF macros and/or  commands, we get lines added to the ISPF 
edit screen with "=NOTE=" or "==MSG>" lines.  Is there a way to make these 
lines searchable without converting them to full data lines?  The specific 
instance I'm asking about is running a third party JCL checker, the lines 
output from the checker are typically notes or messages.  The nice thing about 
them being such, is they aren't really part of the member being edited/checked 
so if I save the member, these lines aren't included in the member being saved. 
 The drawback of them is that they aren't searchable, so for example, if I'm 
looking at output with a called PROC, and I want to search for a particular 
piece of substituted JCL, I can't do so (that I know of) unless I do a full 
"make data" on the member, which then makes me vulnerable to accidentally 
saving the member with all the notes and messages still there.


NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


--
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: [EXTERNAL] ISPF usage question

[Pommier, Rex]

Thanks, all, for your suggestions.  It is as I feared/figured.  ISPF edit 
doesn't have any mechanism to actually search for information in =NOTE= or 
==MSG> lines without converting them to full data lines.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Horne, Jim
Sent: Tuesday, April 11, 2023 6:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] ISPF usage question

Check out the ISPF Edit LOCATE command, especially LOCATE SPECIAL and LOCATE 
NOTE

Jim Horne
-Original Message-

Running certain ISPF macros and/or  commands, we get lines added to the ISPF 
edit screen with "=NOTE=" or "==MSG>" lines.  Is there a way to make these 
lines searchable without converting them to full data lines?  The specific 
instance I'm asking about is running a third party JCL checker, the lines 
output from the checker are typically notes or messages.  The nice thing about 
them being such, is they aren't really part of the member being edited/checked 
so if I save the member, these lines aren't included in the member being saved. 
 The drawback of them is that they aren't searchable, so for example, if I'm 
looking at output with a called PROC, and I want to search for a particular 
piece of substituted JCL, I can't do so (that I know of) unless I do a full 
"make data" on the member, which then makes me vulnerable to accidentally 
saving the member with all the notes and messages still there.


NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Re: [EXTERNAL] ISPF usage question

[Horne, Jim]

Check out the ISPF Edit LOCATE command, especially LOCATE SPECIAL and LOCATE 
NOTE

Jim Horne
-Original Message-

Running certain ISPF macros and/or  commands, we get lines added to the ISPF 
edit screen with "=NOTE=" or "==MSG>" lines.  Is there a way to make these 
lines searchable without converting them to full data lines?  The specific 
instance I'm asking about is running a third party JCL checker, the lines 
output from the checker are typically notes or messages.  The nice thing about 
them being such, is they aren't really part of the member being edited/checked 
so if I save the member, these lines aren't included in the member being saved. 
 The drawback of them is that they aren't searchable, so for example, if I'm 
looking at output with a called PROC, and I want to search for a particular 
piece of substituted JCL, I can't do so (that I know of) unless I do a full 
"make data" on the member, which then makes me vulnerable to accidentally 
saving the member with all the notes and messages still there.


NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.

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

Re: [EXTERNAL] Re: ISPF usage question

[Robert Prins]

Create a REXX exec that displays the member in View, on my own system,
don't ask, I have about a dozen "Vx" commands that open various members (or
memberlists) in  my REXX, CNTL, PROC, PL/I, DATA, etc datasets if entered
with a (partial) membername, which would solve half of the problem. As for
referencing non-data lines, if "CONTROL REFRESH" actually updates the
display from within an edit macro, you could use the ZSCREENx variables to
capture the screen and parse that out yourself. (Never tried this myself,
and right now am too busy sewing a new hitchhiking bag to actually IPL the
system to give it a try)

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather <https://prino.neocities.org/index.html>
Some REXX code for use on z/OS
<https://prino.neocities.org/zOS/zOS-Tools.html>

On Mon, 10 Apr 2023 at 21:58, Pommier, Rex  wrote:

> Thanks, Bob,
>
> I have 1 of the developers in the habit of doing just that, but I can
> already hear the howls from some of the others when they're in edit instead
> of view and accidentally overlay their JCL with the cluttered up version.
> :-)  That's why I was asking if there was some way of getting the search
> capability from within edit w/o the possibility of saving the messages and
> notes as data.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Bob Bridges
> Sent: Monday, April 10, 2023 4:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: ISPF usage question
>
> Not what you're looking for, perhaps, but if I don't want to change my
> code accidentally I've managed to thoroughly habituate myself to using View
> rather than Edit.  Pretty much all the functions you can use in Edit also
> work in View, so I expect you'll still be able to see notes and msgs.  And
> you can make them data without worrying about saving them accidentally.
>
> There may be a more direct method; I don't want to forestall any better
> answers.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* If our religion is something objective, then we must never avert our
> eyes from those elements in it which seem puzzling or repellent; for it
> will be precisely the puzzling or the repellent which conceals what we do
> not yet know and need to know.  -CS Lewis, "The Weight of Glory" */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Pommier, Rex
> Sent: Monday, April 10, 2023 17:26
>
> Yes, this is an ISPF question but I don't know of anybody in the z/OS
> world that doesn't use ISPF - and I don't know if the ISPF list (if it is
> still operational) has much traffic.  So here goes.
>
> Running certain ISPF macros and/or  commands, we get lines added to the
> ISPF edit screen with "=NOTE=" or "==MSG>" lines.  Is there a way to make
> these lines searchable without converting them to full data lines?  The
> specific instance I'm asking about is running a third party JCL checker,
> the lines output from the checker are typically notes or messages.  The
> nice thing about them being such, is they aren't really part of the member
> being edited/checked so if I save the member, these lines aren't included
> in the member being saved.  The drawback of them is that they aren't
> searchable, so for example, if I'm looking at output with a called PROC,
> and I want to search for a particular piece of substituted JCL, I can't do
> so (that I know of) unless I do a full "make data" on the member, which
> then makes me vulnerable to accidentally saving the member with all the
> notes and messages still there.
>

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

Re: [EXTERNAL] Re: ISPF usage question

[Schmitt, Michael]

And you can't create an Edit Macro to help you solve your problem, because once 
inserted, the message lines can't be referenced (probably because they have no 
line number). And macros can't use Make Data to turn the messages into 
referenceable lines.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, April 10, 2023 4:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: ISPF usage question

Thanks, Bob,

I have 1 of the developers in the habit of doing just that, but I can already 
hear the howls from some of the others when they're in edit instead of view and 
accidentally overlay their JCL with the cluttered up version.  :-)  That's why 
I was asking if there was some way of getting the search capability from within 
edit w/o the possibility of saving the messages and notes as data.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, April 10, 2023 4:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: ISPF usage question

Not what you're looking for, perhaps, but if I don't want to change my code 
accidentally I've managed to thoroughly habituate myself to using View rather 
than Edit.  Pretty much all the functions you can use in Edit also work in 
View, so I expect you'll still be able to see notes and msgs.  And you can make 
them data without worrying about saving them accidentally.

There may be a more direct method; I don't want to forestall any better answers.

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

/* If our religion is something objective, then we must never avert our eyes 
from those elements in it which seem puzzling or repellent; for it will be 
precisely the puzzling or the repellent which conceals what we do not yet know 
and need to know.  -CS Lewis, "The Weight of Glory" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, April 10, 2023 17:26

Yes, this is an ISPF question but I don't know of anybody in the z/OS world 
that doesn't use ISPF - and I don't know if the ISPF list (if it is still 
operational) has much traffic.  So here goes.

Running certain ISPF macros and/or  commands, we get lines added to the ISPF 
edit screen with "=NOTE=" or "==MSG>" lines.  Is there a way to make these 
lines searchable without converting them to full data lines?  The specific 
instance I'm asking about is running a third party JCL checker, the lines 
output from the checker are typically notes or messages.  The nice thing about 
them being such, is they aren't really part of the member being edited/checked 
so if I save the member, these lines aren't included in the member being saved. 
 The drawback of them is that they aren't searchable, so for example, if I'm 
looking at output with a called PROC, and I want to search for a particular 
piece of substituted JCL, I can't do so (that I know of) unless I do a full 
"make data" on the member, which then makes me vulnerable to accidentally 
saving the member with all the notes and messages still there.

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


--
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: ISPF usage question

[Seymour J Metz]

I don't know of any way to search them by content, but you can at least find 
them with, e.g.,

LOCATE FIRST NOTELINE .first .last


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pommier, Rex [rpomm...@sfgmembers.com]
Sent: Monday, April 10, 2023 5:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ISPF usage question

Hello list,

Yes, this is an ISPF question but I don't know of anybody in the z/OS world 
that doesn't use ISPF - and I don't know if the ISPF list (if it is still 
operational) has much traffic.  So here goes.

Running certain ISPF macros and/or  commands, we get lines added to the ISPF 
edit screen with "=NOTE=" or "==MSG>" lines.  Is there a way to make these 
lines searchable without converting them to full data lines?  The specific 
instance I'm asking about is running a third party JCL checker, the lines 
output from the checker are typically notes or messages.  The nice thing about 
them being such, is they aren't really part of the member being edited/checked 
so if I save the member, these lines aren't included in the member being saved. 
 The drawback of them is that they aren't searchable, so for example, if I'm 
looking at output with a called PROC, and I want to search for a particular 
piece of substituted JCL, I can't do so (that I know of) unless I do a full 
"make data" on the member, which then makes me vulnerable to accidentally 
saving the member with all the notes and messages still there.

TIA,

Rex

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


--
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: [EXTERNAL] Re: ISPF usage question

[Pommier, Rex]

Thanks, Bob,

I have 1 of the developers in the habit of doing just that, but I can already 
hear the howls from some of the others when they're in edit instead of view and 
accidentally overlay their JCL with the cluttered up version.  :-)  That's why 
I was asking if there was some way of getting the search capability from within 
edit w/o the possibility of saving the messages and notes as data.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, April 10, 2023 4:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: ISPF usage question

Not what you're looking for, perhaps, but if I don't want to change my code 
accidentally I've managed to thoroughly habituate myself to using View rather 
than Edit.  Pretty much all the functions you can use in Edit also work in 
View, so I expect you'll still be able to see notes and msgs.  And you can make 
them data without worrying about saving them accidentally.

There may be a more direct method; I don't want to forestall any better answers.

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

/* If our religion is something objective, then we must never avert our eyes 
from those elements in it which seem puzzling or repellent; for it will be 
precisely the puzzling or the repellent which conceals what we do not yet know 
and need to know.  -CS Lewis, "The Weight of Glory" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, April 10, 2023 17:26

Yes, this is an ISPF question but I don't know of anybody in the z/OS world 
that doesn't use ISPF - and I don't know if the ISPF list (if it is still 
operational) has much traffic.  So here goes.

Running certain ISPF macros and/or  commands, we get lines added to the ISPF 
edit screen with "=NOTE=" or "==MSG>" lines.  Is there a way to make these 
lines searchable without converting them to full data lines?  The specific 
instance I'm asking about is running a third party JCL checker, the lines 
output from the checker are typically notes or messages.  The nice thing about 
them being such, is they aren't really part of the member being edited/checked 
so if I save the member, these lines aren't included in the member being saved. 
 The drawback of them is that they aren't searchable, so for example, if I'm 
looking at output with a called PROC, and I want to search for a particular 
piece of substituted JCL, I can't do so (that I know of) unless I do a full 
"make data" on the member, which then makes me vulnerable to accidentally 
saving the member with all the notes and messages still there.

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Re: ISPF usage question

[Bob Bridges]

Not what you're looking for, perhaps, but if I don't want to change my code 
accidentally I've managed to thoroughly habituate myself to using View rather 
than Edit.  Pretty much all the functions you can use in Edit also work in 
View, so I expect you'll still be able to see notes and msgs.  And you can make 
them data without worrying about saving them accidentally.

There may be a more direct method; I don't want to forestall any better answers.

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

/* If our religion is something objective, then we must never avert our eyes 
from those elements in it which seem puzzling or repellent; for it will be 
precisely the puzzling or the repellent which conceals what we do not yet know 
and need to know.  -CS Lewis, "The Weight of Glory" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Monday, April 10, 2023 17:26

Yes, this is an ISPF question but I don't know of anybody in the z/OS world 
that doesn't use ISPF - and I don't know if the ISPF list (if it is still 
operational) has much traffic.  So here goes.

Running certain ISPF macros and/or  commands, we get lines added to the ISPF 
edit screen with "=NOTE=" or "==MSG>" lines.  Is there a way to make these 
lines searchable without converting them to full data lines?  The specific 
instance I'm asking about is running a third party JCL checker, the lines 
output from the checker are typically notes or messages.  The nice thing about 
them being such, is they aren't really part of the member being edited/checked 
so if I save the member, these lines aren't included in the member being saved. 
 The drawback of them is that they aren't searchable, so for example, if I'm 
looking at output with a called PROC, and I want to search for a particular 
piece of substituted JCL, I can't do so (that I know of) unless I do a full 
"make data" on the member, which then makes me vulnerable to accidentally 
saving the member with all the notes and messages still there.

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

ISPF usage question

[Pommier, Rex]

Hello list,

Yes, this is an ISPF question but I don't know of anybody in the z/OS world 
that doesn't use ISPF - and I don't know if the ISPF list (if it is still 
operational) has much traffic.  So here goes.

Running certain ISPF macros and/or  commands, we get lines added to the ISPF 
edit screen with "=NOTE=" or "==MSG>" lines.  Is there a way to make these 
lines searchable without converting them to full data lines?  The specific 
instance I'm asking about is running a third party JCL checker, the lines 
output from the checker are typically notes or messages.  The nice thing about 
them being such, is they aren't really part of the member being edited/checked 
so if I save the member, these lines aren't included in the member being saved. 
 The drawback of them is that they aren't searchable, so for example, if I'm 
looking at output with a called PROC, and I want to search for a particular 
piece of substituted JCL, I can't do so (that I know of) unless I do a full 
"make data" on the member, which then makes me vulnerable to accidentally 
saving the member with all the notes and messages still there.

TIA,

Rex

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Re: COBOL question

[Cameron Conacher]

Thanks.
Just to be clear.
I am running under EXPEDITER.
The program runs almost to completion.
The last two things I do:

  1.  If the Address is not NULL -> FREE
  2.  GOBACK.


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Monday, April 10, 2023 9:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: COBOL question

A lot of times, U4038 is not enough region...

Joe

On Mon, Apr 10, 2023 at 6:15 AM Cameron Conacher <
03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146bb-dmarc-requ...@listserv.ua.edu>>
 wrote:

> Good call 
>
> I ALLOCATE once.
> And just before GOBACK, I issue the FREE. Just one time.
> I am thinking it might be related to EXPEDITER.
>
> That is my current WAG.
>
>
> Thanks
>
> …….Cameron
>
> -Original Message-
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf
> Of Charles Mills
> Sent: Sunday, April 9, 2023 8:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> Subject: [External] Re: COBOL question
>
> I can't see your code of course but my WAG is a programmer logic error.
> (Sorry!) I am going to guess your logic is such that you try to free the
> same area twice or, less likely, corrupt your pointer.
>
> You say you check to see if it is null before freeing. Do you set it to
> NULL after freeing?
>
> Charles
>
> On Sun, 9 Apr 2023 23:01:05 +, Cameron Conacher <
> cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>> wrote:
>
> >Thanks Bob,
> >No I initialize the Pointer to NULL, and then allocate. Successfully.
> >And then later I check to see it the pointer = NULL. If it is not NULL,
> then I do the FREE.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the 
> message: INFO IBM-MAIN
> 
> American Express made the following annotations
> 
> This e-mail was sent to you by a representative of Amex Bank of Canada,
> P.O. Box 3204, Station "F", Toronto, ON, M1W 3W7, 
> www.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
> If you no longer wish to receive these e-mails, please notify the sender by
> reply e-mail.
>
> This e-mail is solely for the intended recipient and may contain
> confidential or privileged information. If you are not the intended
> recipient, any disclosure, copying, use, or distribution of the information
> included in this e-mail is prohibited. If you have received this e-mail in
> error, please notify the sender by reply e-mail and immediately and
> permanently delete this e-mail and any attachments. Thank you.
>
> American Express a fait les remarques suivantes
> Ce courriel vous a été envoyé par un représentant de la Banque Amex du
> Canada, C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7,
> www.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
>  Si, par la suite, vous ne souhaitez plus recevoir
> ces courriels, veuillez en aviser les expéditeurs par courriel.
>
> Ce courriel est réservé au seul destinataire indiqué et peut renfermer des
> renseignements confidentiels et privilégiés. Si vous n’êtes pas le
> destinataire prévu, toute divulgation, duplication, utilisation ou
> distribution du courriel est interdite. Si vous avez reçu ce courriel par
> erreur, veuillez en aviser l’expéditeur par courriel et détruire
> immédiatement le courriel et toute pièce jointe. Merci.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu<mailto: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<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, 

Re: COBOL question

[Joe Monk]

A lot of times, U4038 is not enough region...

Joe

On Mon, Apr 10, 2023 at 6:15 AM Cameron Conacher <
03cfc59146bb-dmarc-requ...@listserv.ua.edu> wrote:

> Good call 
>
> I ALLOCATE once.
> And just before GOBACK, I issue the FREE. Just one time.
> I am thinking it might be related to EXPEDITER.
>
> That is my current WAG.
>
>
> Thanks
>
> …….Cameron
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Charles Mills
> Sent: Sunday, April 9, 2023 8:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: COBOL question
>
> I can't see your code of course but my WAG is a programmer logic error.
> (Sorry!) I am going to guess your logic is such that you try to free the
> same area twice or, less likely, corrupt your pointer.
>
> You say you check to see if it is null before freeing. Do you set it to
> NULL after freeing?
>
> Charles
>
> On Sun, 9 Apr 2023 23:01:05 +, Cameron Conacher <
> cameron.conac...@aexp.com> wrote:
>
> >Thanks Bob,
> >No I initialize the Pointer to NULL, and then allocate. Successfully.
> >And then later I check to see it the pointer = NULL. If it is not NULL,
> then I do the FREE.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> American Express made the following annotations
> 
> This e-mail was sent to you by a representative of Amex Bank of Canada,
> P.O. Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca.
> If you no longer wish to receive these e-mails, please notify the sender by
> reply e-mail.
>
> This e-mail is solely for the intended recipient and may contain
> confidential or privileged information. If you are not the intended
> recipient, any disclosure, copying, use, or distribution of the information
> included in this e-mail is prohibited. If you have received this e-mail in
> error, please notify the sender by reply e-mail and immediately and
> permanently delete this e-mail and any attachments. Thank you.
>
> American Express a fait les remarques suivantes
> Ce courriel vous a été envoyé par un représentant de la Banque Amex du
> Canada, C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7,
> www.americanexpress.ca. Si, par la suite, vous ne souhaitez plus recevoir
> ces courriels, veuillez en aviser les expéditeurs par courriel.
>
> Ce courriel est réservé au seul destinataire indiqué et peut renfermer des
> renseignements confidentiels et privilégiés. Si vous n’êtes pas le
> destinataire prévu, toute divulgation, duplication, utilisation ou
> distribution du courriel est interdite. Si vous avez reçu ce courriel par
> erreur, veuillez en aviser l’expéditeur par courriel et détruire
> immédiatement le courriel et toute pièce jointe. Merci.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: COBOL question

[Cameron Conacher]

Good call 

I ALLOCATE once.
And just before GOBACK, I issue the FREE. Just one time.
I am thinking it might be related to EXPEDITER.

That is my current WAG.


Thanks

…….Cameron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Sunday, April 9, 2023 8:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: COBOL question

I can't see your code of course but my WAG is a programmer logic error. 
(Sorry!) I am going to guess your logic is such that you try to free the same 
area twice or, less likely, corrupt your pointer.

You say you check to see if it is null before freeing. Do you set it to NULL 
after freeing?

Charles

On Sun, 9 Apr 2023 23:01:05 +, Cameron Conacher  
wrote:

>Thanks Bob,
>No I initialize the Pointer to NULL, and then allocate. Successfully.
>And then later I check to see it the pointer = NULL. If it is not NULL, then I 
>do the FREE.

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: COBOL question

[Charles Mills]

I can't see your code of course but my WAG is a programmer logic error. 
(Sorry!) I am going to guess your logic is such that you try to free the same 
area twice or, less likely, corrupt your pointer.

You say you check to see if it is null before freeing. Do you set it to NULL 
after freeing?

Charles

On Sun, 9 Apr 2023 23:01:05 +, Cameron Conacher  
wrote:

>Thanks Bob,
>No I initialize the Pointer to NULL, and then allocate. Successfully.
>And then later I check to see it the pointer = NULL. If it is not NULL, then I 
>do the FREE.

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

Re: COBOL question

[Cameron Conacher]

Thanks Bob,
No I initialize the Pointer to NULL, and then allocate. Successfully.
And then later I check to see it the pointer = NULL. If it is not NULL, then I 
do the FREE.

Thanks

…….Cameron

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
T Roller
Sent: Saturday, April 8, 2023 8:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: COBOL question

Region card big enough? I’ve seen that abend via not enough memory.

Bob

Sent from Proton Mail for iOS

On Sat, Apr 8, 2023 at 8:17 PM, Charles Hardee  wrote:

> I have not seen this exactly like what you describe, but I do have
> some thoughts.
> The pointer you are using for the ALLOCATE, does it have a value
> clause, specifically VALUE NULL.
> If not, the pointer could have an unknown value that does not compare
> equal to NULL so you would attempt to FREE it.
>
> On Sat, Apr 8, 2023 at 6:05 PM Cameron Conacher  wrote:
>
>> Hello folks
>> I have written an IMS COBOL program. I have included a couple of
>> ALLOCATE statements.
>> At the end of processing I check my pointers and if they are not NULL
>> I try to FREE. This results in a U4038 abend. At least inside Expediter.
>> I have not used ALLOCATE/FREE before.
>> I am thinking it may be related to Expediter somehow.
>> I mean FREE is pretty darned straight forward.
>> At the moment I have commented out the statements. Memory should be
>> freed at the end of processing anyway, but good housekeeping is well good.
>> Has anyone seen this before?
>>
>> Thanks
>>
>> Sent from my iPhone
>> -
>> - 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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Re: COBOL question

[Bob T Roller]

Region card big enough? I’ve seen that abend via not enough memory.

Bob

Sent from Proton Mail for iOS

On Sat, Apr 8, 2023 at 8:17 PM, Charles Hardee  wrote:

> I have not seen this exactly like what you describe, but I do have some
> thoughts.
> The pointer you are using for the ALLOCATE, does it have a value clause,
> specifically VALUE NULL.
> If not, the pointer could have an unknown value that does not compare equal
> to NULL so you would attempt to FREE it.
>
> On Sat, Apr 8, 2023 at 6:05 PM Cameron Conacher  wrote:
>
>> Hello folks
>> I have written an IMS COBOL program. I have included a couple of ALLOCATE
>> statements.
>> At the end of processing I check my pointers and if they are not NULL I
>> try to FREE. This results in a U4038 abend. At least inside Expediter.
>> I have not used ALLOCATE/FREE before.
>> I am thinking it may be related to Expediter somehow.
>> I mean FREE is pretty darned straight forward.
>> At the moment I have commented out the statements. Memory should be freed
>> at the end of processing anyway, but good housekeeping is well good.
>> Has anyone seen this before?
>>
>> Thanks
>>
>> Sent from my iPhone
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: COBOL question

[Charles Hardee]

I have not seen this exactly like what you  describe, but I do have some
thoughts.
The pointer you are using for the ALLOCATE, does it have a value clause,
specifically VALUE NULL.
If not, the pointer could have an unknown value that does not compare equal
to NULL so you would attempt to FREE it.



On Sat, Apr 8, 2023 at 6:05 PM Cameron Conacher  wrote:

> Hello folks
> I have written an IMS  COBOL program. I have included a couple of ALLOCATE
> statements.
> At the end of processing I check my pointers and if they are not NULL I
> try to FREE. This results in a U4038 abend. At least inside Expediter.
> I have not used ALLOCATE/FREE before.
> I am thinking it may be related to Expediter somehow.
> I mean FREE is pretty darned straight forward.
> At the moment I have commented out the statements. Memory should be freed
> at the end of processing anyway, but good housekeeping is well good.
> Has anyone seen this before?
>
> Thanks
>
> Sent from my iPhone
> --
> 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

COBOL question

[Cameron Conacher]

Hello folks
I have written an IMS  COBOL program. I have included a couple of ALLOCATE 
statements.
At the end of processing I check my pointers and if they are not NULL I try to 
FREE. This results in a U4038 abend. At least inside Expediter.
I have not used ALLOCATE/FREE before. 
I am thinking it may be related to Expediter somehow.
I mean FREE is pretty darned straight forward.
At the moment I have commented out the statements. Memory should be freed at 
the end of processing anyway, but good housekeeping is well good.
Has anyone seen this before?

Thanks 

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

DB2 question about ULI (Universal adapter)

[Frank Swarbrick]

Is it the case that the parameter in the SQL parameter ATTACH option (TSO, CAF, 
etc.) does not matter as long as the DSNULI stub is included in the program 
bind?  This appears to me to be the case, but I want someone to specifically 
state it for me in case I am misunderstanding.

Also, how do I subscribe to the DB2 listserv?  It appears to be on he IDUG web 
site, but I can't find a way to register.

Frank


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

Re: REXX/COBOL conversion question

[Seymour J Metz]

It's a bit worse with ooRexx; by the time I learn the ins and outs of all of 
the classes they will have added more. Once you get used to it, it's hard to 
live without it.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rupert Reynolds [rreyno...@cix.co.uk]
Sent: Thursday, April 6, 2023 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX/COBOL conversion question

The "principle of least astonishment" works well for me in Rexx, although I
confess it took a while to make the best of it :-)

Yes, I checked in ooRexx and in the docs for Regina:-

Comparison with = is case-sensitive and leading/trailing blanks are
stripped and/or added. So ("" = "") evaluates to true.

Compare() is different--shorter string is padded on the right (with blanks
by default), but leading and trailing blanks are compared.

I wrote the proof-of-concept bytecode interpreter for my toy language
project in Rexx, and its rich text handling and arbitrary precision
arithmetic far outweighed its other quirks. 200-digit logarithms, anyone?
:-)

Roops
P.S. Most Rexx peops end up with something like dorexx.rex:-
/* Rexx to noodle about.
 Enter EXIT to quit */
do forever
  parse pull stuff
  interpret stuff
end



On Thu, 6 Apr 2023, 18:05 Seymour J Metz,  wrote:

> Why? Unless you use a strict (==) compare REXX will add trailing blanks.
>
>
>

--
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/COBOL conversion question

[Rupert Reynolds]

The "principle of least astonishment" works well for me in Rexx, although I
confess it took a while to make the best of it :-)

Yes, I checked in ooRexx and in the docs for Regina:-

Comparison with = is case-sensitive and leading/trailing blanks are
stripped and/or added. So ("" = "") evaluates to true.

Compare() is different--shorter string is padded on the right (with blanks
by default), but leading and trailing blanks are compared.

I wrote the proof-of-concept bytecode interpreter for my toy language
project in Rexx, and its rich text handling and arbitrary precision
arithmetic far outweighed its other quirks. 200-digit logarithms, anyone?
:-)

Roops
P.S. Most Rexx peops end up with something like dorexx.rex:-
/* Rexx to noodle about.
 Enter EXIT to quit */
do forever
  parse pull stuff
  interpret stuff
end



On Thu, 6 Apr 2023, 18:05 Seymour J Metz,  wrote:

> Why? Unless you use a strict (==) compare REXX will add trailing blanks.
>
>
>

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

Re: REXX/COBOL conversion question

[Seymour J Metz]

Why? Unless you use a strict (==) compare REXX will add trailing blanks.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
ITschak Mugzach [imugz...@gmail.com]
Sent: Thursday, April 6, 2023 12:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX/COBOL conversion question

The variable is defined at level 05 so it is probably part of a structure
(group item in terms of cobol). You must maintain the copect length. For
example xxx = copies(' ',12).

Btw, the compare is ok and will work same as in cobol.
Best
ITschak

בתאריך יום ה׳, 6 באפר׳ 2023 ב-17:58 מאת Allan Staller <
0387911dea17-dmarc-requ...@listserv.ua.edu>:

> Classification: Confidential
> I have the following:
>
> COBOL:
> 05 FR-KWY PIC X(12).
> IF FR-KEY=SPACES
>   MOVE..
>
> REXX:
> IF fr_key = ' ' THEN
>   Move..
>
> Are these 2 statements equivalent? I suspect REXX will do a 1 -by compare
> vs. a 12 byte compare for COBOL.
>
> Can anyone confirm?
>
> Thanks in advance,
>
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator
> or HCL or its affiliates. Views or opinions, if any, presented in this
> email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification, distribution and / or
> publication of this message without the prior written consent of authorized
> representative of HCL is strictly prohibited. If you have received this
> email in error please delete it and notify the sender immediately. Before
> opening any email and/or attachments, please check them for viruses and
> other defects.
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *

--
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/COBOL conversion question

[Seymour J Metz]

Yes to both. I rarely use ==, has = almost always has the semantics I want.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, April 6, 2023 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX/COBOL conversion question

On Thu, 6 Apr 2023 15:04:19 +, Seymour J Metz wrote:

>A compare using = adds trailing blanks; use == if you need an exact match.
>
Trailing and/or leading.

"=" has a very lenient criterion of numeric equality:
"say 2 = ' 200e-2  '"
1

"==" gives better performance (empirically).

--
gil

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

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

Re: REXX/COBOL conversion question

[ITschak Mugzach]

The variable is defined at level 05 so it is probably part of a structure
(group item in terms of cobol). You must maintain the copect length. For
example xxx = copies(' ',12).

Btw, the compare is ok and will work same as in cobol.
Best
ITschak

בתאריך יום ה׳, 6 באפר׳ 2023 ב-17:58 מאת Allan Staller <
0387911dea17-dmarc-requ...@listserv.ua.edu>:

> Classification: Confidential
> I have the following:
>
> COBOL:
> 05 FR-KWY PIC X(12).
> IF FR-KEY=SPACES
>   MOVE..
>
> REXX:
> IF fr_key = ' ' THEN
>   Move..
>
> Are these 2 statements equivalent? I suspect REXX will do a 1 -by compare
> vs. a 12 byte compare for COBOL.
>
> Can anyone confirm?
>
> Thanks in advance,
>
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator
> or HCL or its affiliates. Views or opinions, if any, presented in this
> email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification, distribution and / or
> publication of this message without the prior written consent of authorized
> representative of HCL is strictly prohibited. If you have received this
> email in error please delete it and notify the sender immediately. Before
> opening any email and/or attachments, please check them for viruses and
> other defects.
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *

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

Re: REXX/COBOL conversion question

[Warren Brown]

 Allen:  This is Warren Brown.  Do you remember working with me?
Warren 
On Thursday, April 6, 2023 at 10:58:29 AM EDT, Allan Staller 
<0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:  
 
 Classification: Confidential
I have the following:

COBOL:
05 FR-KWY PIC X(12).
IF FR-KEY=SPACES
              MOVE..

REXX:
IF fr_key = ' ' THEN
              Move..

Are these 2 statements equivalent? I suspect REXX will do a 1 -by compare vs. a 
12 byte compare for COBOL.

Can anyone confirm?

Thanks in advance,

::DISCLAIMER::

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


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

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

Re: REXX/COBOL conversion question

[Paul Gilmartin]

On Thu, 6 Apr 2023 15:04:19 +, Seymour J Metz wrote:

>A compare using = adds trailing blanks; use == if you need an exact match.
>
Trailing and/or leading.

"=" has a very lenient criterion of numeric equality:
"say 2 = ' 200e-2  '"
1

"==" gives better performance (empirically).

-- 
gil

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

Re: REXX/COBOL conversion question

[Seymour J Metz]

A compare using = adds trailing blanks; use == if you need an exact match.


From: IBM Mainframe Discussion List  on behalf of 
Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, April 6, 2023 10:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: REXX/COBOL conversion question

Classification: Confidential
I have the following:

COBOL:
05 FR-KWY PIC X(12).
IF FR-KEY=SPACES
  MOVE..

REXX:
IF fr_key = ' ' THEN
  Move..

Are these 2 statements equivalent? I suspect REXX will do a 1 -by compare vs. a 
12 byte compare for COBOL.

Can anyone confirm?

Thanks in advance,

::DISCLAIMER::

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


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

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

REXX/COBOL conversion question

[Allan Staller]

Classification: Confidential
I have the following:

COBOL:
05 FR-KWY PIC X(12).
IF FR-KEY=SPACES
  MOVE..

REXX:
IF fr_key = ' ' THEN
  Move..

Are these 2 statements equivalent? I suspect REXX will do a 1 -by compare vs. a 
12 byte compare for COBOL.

Can anyone confirm?

Thanks in advance,

::DISCLAIMER::

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


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

Re: RTM/SDWA question

[Joseph Reichman]

I understand. 

I just re-read the comments next to SDWASRSV while SDWASRGSV Is regs at time
of error for ESTAE for an FRR it SDWASR00 anyway I use a register update
block

thanks  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Peter Relson
Sent: Sunday, April 2, 2023 8:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RTM/SDWA question

The registers in the SDWA related to RB or linkage stack entry are not time
of error. There are many rules involved with when those registers are saved.

If you want registers for retry, then you should save them in a work area
that you can locate via the ESTAE parameter or the FRR parameter area. That
is what is always available to you.

Trying multiple places is not the right approach.

Peter Relson
z/OS Core Technology Design


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

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

Re: RTM/SDWA question

[Peter Relson]

The registers in the SDWA related to RB or linkage stack entry are not time of 
error. There are many rules involved with when those registers are saved.

If you want registers for retry, then you should save them in a work area that 
you can locate via the ESTAE parameter or the FRR parameter area. That is what 
is always available to you.

Trying multiple places is not the right approach.

Peter Relson
z/OS Core Technology Design


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

Re: RTM/SDWA question

[Joseph Reichman]

Thanks 
That’s what I thought 

In order for my recovery to do a retry 
My register have to be in tact 

R3 is the base for all my csects 
4 bytes off that is my eyecatcher as I branch round that comparing R3 + 4 for 
the eyecatcher is how I determine that

I start SDWAGR then I try SDWASR 

Then I try the rbregs


I preface everything with a TPROT

If everything fails I percolate 

For 2 out 3 there 64 bit registers 

Thanks 

> On Apr 1, 2023, at 8:12 AM, Peter Relson  wrote:
> 
> 
> Are the registers at SDWASR00 the same as the registers pointed to by
> SDWARBAD when SDWARBAD is around I have noticed most of the time they are
> 
> 
> Your words of "most of the time" indicate that you have observed that they 
> are not always.
> Your observation is correct. Sometimes yes, sometimes no. Read the comment on 
> the field.
> And the RB in which the error occurred is not necessarily the RB that created 
> the recovery routine.
> 
> There is very limited diagnostic use of that data, so we did not feel it 
> necessary to spend storage space in the SDWA to provide the 64-bit high 
> halves or 16-byte psw.
> 
> Peter
> 
> 
> --
> 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: RTM/SDWA question

[Peter Relson]

Are the registers at SDWASR00 the same as the registers pointed to by
SDWARBAD when SDWARBAD is around I have noticed most of the time they are


Your words of "most of the time" indicate that you have observed that they are 
not always.
Your observation is correct. Sometimes yes, sometimes no. Read the comment on 
the field.
And the RB in which the error occurred is not necessarily the RB that created 
the recovery routine.

There is very limited diagnostic use of that data, so we did not feel it 
necessary to spend storage space in the SDWA to provide the 64-bit high halves 
or 16-byte psw.

Peter


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

RTM/SDWA question

[Joseph Reichman]

Hi 

 

Are the registers at SDWASR00 the same as the registers pointed to by
SDWARBAD when SDWARBAD is around I have noticed most of the time they are
SDWAS00 doesn't have 64 bit registers 

Or PSW but if they are the same I can get them from the XSB

 

Thanks 

 


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

Re: A question or two on zOS issues

[Seymour J Metz]

AIF is your friend. That's especially true if you distribute source.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Thompson [ste...@wkyr.net]
Sent: Monday, March 27, 2023 2:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A question or two on zOS issues

"And, we're not gaining the full benefit because we can't allow
it to use vector packed instructions until all sites where the
code can run are on compatible hardware."

Welcome to the developer's heart burn.

Steve Thompson


On 3/27/2023 1:43 PM, Schmitt, Michael wrote:
> I didn't mention that because I consider it to be self-inflicted.
>
> We believed that we were consistently using correct signs, so we changed from 
> NUMPROC(MIG) to (PFD) in 2015.
>
> We're STILL running into issues with this, in fact I hit some just last week. 
> But not enough to give up and downgrade to NOPFD. Some of the bad signs are 
> originating from other languages.
>
> For binary, we've always compiled TRUNC(OPT).
>
>
> Some of our programmers believe that a numeric field with spaces should be 
> processed as zero, just because before it worked!
>
>
> Also, we do know that recompiling with COBOL z/OS 6 dramatically improves 
> performance, but we're not recompiling just to gain that, as recompiling is 
> always a risk. And, we're not gaining the full benefit because we can't allow 
> it to use vector packed instructions until all sites where the code can run 
> are on compatible hardware.
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Thompson
> Sent: Monday, March 27, 2023 12:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: A question or two on zOS issues
>
> Glad to hear that someone followed all the rules so that,
> unannounced COBOL 5+ didn't cause you packed decimal problems
> with Truncation and the like. Or same thing with binary.
>
> Steve Thompson
>
> On 3/27/2023 10:31 AM, Schmitt, Michael wrote:
>> The last time we mass-converted and recompiled our COBOL was from OS/VS 
>> COBOL to VS COBOL II in 1992. Since then we've migrated our 7 million lines 
>> of COBOL code...
>>
>> - 1998 Language Environment
>> - 2000 COBOL for MVS & VM
>> - 2003 COBOL for OS/390 & VM
>> - 2004 COBOL for z/OS & OS/390 3.2
>> - 2005  3.3
>> - 2006  3.4
>> - 2011  4.2
>> - 2020  6.2
>>
>> By doing... nothing.
>>
>> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
>> requirement for load modules.
>>
>>
>> So, in my experience, we don't need to know when our COBOL programs were 
>> last used. And we already have tools that give us the compile date and 
>> version, both from IBM and home grown.
>>
>> We still have a large number of programs that haven't been recompiled since 
>> the VS COBOL II migration. They coexist just fine.
>>
>> (You may have to *relink* to pick up the Language Environment bootstrap 
>> programs)
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Steve Pryor
>> Sent: Friday, March 24, 2023 1:39 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: A question or two on zOS issues
>>
>> There are a couple of pressing issues in z/OS that I'm sure many folks are 
>> aware of but about which there doesn't seem to be much being done. I'm 
>> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
>> talking about:
>>
>> 1.) migration to IBM's latest COBOL release, and
>>
>> 2.) the not-really-that-far-off issue of Year 2042
>>
>> I've been asked several times recently whether we (a z/OS ISV) should 
>> consider developing products to address these issues. Frankly, though, I 
>> live in an ivory tower and while I sometime *think* I know what 
>> installations problems and needs are, I'm usually surprised to find that 
>> reality is quite different. So I'd like to throw a couple of questions out 
>> to the list for comment:
>>
>> 1.) Would a reporting utility that determined which COBOL programs were 
>> executed (and which ones weren't), and what release and options they were 
>> compiled with be significantly helpful in a COBOL migration? What other 
>> features would be nice to have? Or is this a low priority for most 
>> installations, who are perhaps trying to justify keeping the mainframe alive 
>> and/or conducting business as usual, let alone doing a COBOL migration 
>> project?
>>
>> 2.) It's rather sho

Re: A question or two on zOS issues

[Seymour J Metz]

Remember, the early worm gets the bird.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Schmitt, Michael [michael.schm...@dxc.com]
Sent: Monday, March 27, 2023 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A question or two on zOS issues

You're right, and fortunately we were saved from that pain because we 
procrastinated so long. And we skipped v5 completely.

We procrastinated because it took me a long time to rewrite our load module 
analyzer, as well as other PDS-dependencies.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Monday, March 27, 2023 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A question or two on zOS issues

As long as you use the correct compiler options with COBOL 5+ to replicate 
those of your pre-5 COBOL you were likely OK.  In our shop we did not do this 
properly (*) and had issues.

(*) I believe the main issue was some pre-v5 options were not originally 
implemented in V5, so there was no possibility to replicate our V4 options.  
There were many updates to V5 (and V6) to make those options available, at 
which point the issues "went away".

From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Monday, March 27, 2023 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: A question or two on zOS issues

Glad to hear that someone followed all the rules so that,
unannounced COBOL 5+ didn't cause you packed decimal problems
with Truncation and the like. Or same thing with binary.

Steve Thompson

On 3/27/2023 10:31 AM, Schmitt, Michael wrote:
> The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
> to VS COBOL II in 1992. Since then we've migrated our 7 million lines of 
> COBOL code...
>
> - 1998 Language Environment
> - 2000 COBOL for MVS & VM
> - 2003 COBOL for OS/390 & VM
> - 2004 COBOL for z/OS & OS/390 3.2
> - 2005  3.3
> - 2006  3.4
> - 2011  4.2
> - 2020  6.2
>
> By doing... nothing.
>
> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
> requirement for load modules.
>
>
> So, in my experience, we don't need to know when our COBOL programs were last 
> used. And we already have tools that give us the compile date and version, 
> both from IBM and home grown.
>
> We still have a large number of programs that haven't been recompiled since 
> the VS COBOL II migration. They coexist just fine.
>
> (You may have to *relink* to pick up the Language Environment bootstrap 
> programs)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Pryor
> Sent: Friday, March 24, 2023 1:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A question or two on zOS issues
>
> There are a couple of pressing issues in z/OS that I'm sure many folks are 
> aware of but about which there doesn't seem to be much being done. I'm 
> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
> talking about:
>
> 1.) migration to IBM's latest COBOL release, and
>
> 2.) the not-really-that-far-off issue of Year 2042
>
> I've been asked several times recently whether we (a z/OS ISV) should 
> consider developing products to address these issues. Frankly, though, I live 
> in an ivory tower and while I sometime *think* I know what installations 
> problems and needs are, I'm usually surprised to find that reality is quite 
> different. So I'd like to throw a couple of questions out to the list for 
> comment:
>
> 1.) Would a reporting utility that determined which COBOL programs were 
> executed (and which ones weren't), and what release and options they were 
> compiled with be significantly helpful in a COBOL migration? What other 
> features would be nice to have? Or is this a low priority for most 
> installations, who are perhaps trying to justify keeping the mainframe alive 
> and/or conducting business as usual, let alone doing a COBOL migration 
> project?
>
> 2.) It's rather shocking that 2042 is so close and not much seems to be 
> happening. We are one of the vendors that have a date-simulation utility, but 
> we don't know if data centers have any near-term plans for 2042. Would it be 
> worthwhile to have a 2042 date-simulation product now, or is everyone going 
> to cross their fingers and try to use a test LPAR once the operating system 
> fully supports 2042 dates?
>
> Thanks for any comments and insight the IBM-MAIN hive mind might have.
>
> Steve Pryor
> CTO
> DTS Software, LLC
>
> --
> For IBM-MAIN subscribe / signoff / archive acc

Re: [EXTERNAL] Re: A question or two on zOS issues

[Pommier, Rex]

We did...  Had several discussions on TRUNC and various other options in the 
compiler/runtime.  Plenty of heartburn.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Monday, March 27, 2023 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: A question or two on zOS issues

Glad to hear that someone followed all the rules so that, unannounced COBOL 5+ 
didn't cause you packed decimal problems with Truncation and the like. Or same 
thing with binary.

Steve Thompson

On 3/27/2023 10:31 AM, Schmitt, Michael wrote:
> The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
> to VS COBOL II in 1992. Since then we've migrated our 7 million lines of 
> COBOL code...
>
> - 1998 Language Environment
> - 2000 COBOL for MVS & VM
> - 2003 COBOL for OS/390 & VM
> - 2004 COBOL for z/OS & OS/390 3.2
> - 2005  3.3
> - 2006  3.4
> - 2011  4.2
> - 2020  6.2
>
> By doing... nothing.
>
> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
> requirement for load modules.
>
>
> So, in my experience, we don't need to know when our COBOL programs were last 
> used. And we already have tools that give us the compile date and version, 
> both from IBM and home grown.
>
> We still have a large number of programs that haven't been recompiled since 
> the VS COBOL II migration. They coexist just fine.
>
> (You may have to *relink* to pick up the Language Environment 
> bootstrap programs)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Steve Pryor
> Sent: Friday, March 24, 2023 1:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A question or two on zOS issues
>
> There are a couple of pressing issues in z/OS that I'm sure many folks are 
> aware of but about which there doesn't seem to be much being done. I'm 
> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
> talking about:
>
> 1.) migration to IBM's latest COBOL release, and
>
> 2.) the not-really-that-far-off issue of Year 2042
>
> I've been asked several times recently whether we (a z/OS ISV) should 
> consider developing products to address these issues. Frankly, though, I live 
> in an ivory tower and while I sometime *think* I know what installations 
> problems and needs are, I'm usually surprised to find that reality is quite 
> different. So I'd like to throw a couple of questions out to the list for 
> comment:
>
> 1.) Would a reporting utility that determined which COBOL programs were 
> executed (and which ones weren't), and what release and options they were 
> compiled with be significantly helpful in a COBOL migration? What other 
> features would be nice to have? Or is this a low priority for most 
> installations, who are perhaps trying to justify keeping the mainframe alive 
> and/or conducting business as usual, let alone doing a COBOL migration 
> project?
>
> 2.) It's rather shocking that 2042 is so close and not much seems to be 
> happening. We are one of the vendors that have a date-simulation utility, but 
> we don’t know if data centers have any near-term plans for 2042. Would it be 
> worthwhile to have a 2042 date-simulation product now, or is everyone going 
> to cross their fingers and try to use a test LPAR once the operating system 
> fully supports 2042 dates?
>
> Thanks for any comments and insight the IBM-MAIN hive mind might have.
>
> Steve Pryor
> CTO
> DTS Software, LLC
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 

Re: A question or two on zOS issues

[Frank Swarbrick]

Sometimes the worm that the early bird gets is diseased.  :-)

From: IBM Mainframe Discussion List  on behalf of 
Schmitt, Michael 
Sent: Monday, March 27, 2023 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: A question or two on zOS issues

You're right, and fortunately we were saved from that pain because we 
procrastinated so long. And we skipped v5 completely.

We procrastinated because it took me a long time to rewrite our load module 
analyzer, as well as other PDS-dependencies.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Monday, March 27, 2023 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A question or two on zOS issues

As long as you use the correct compiler options with COBOL 5+ to replicate 
those of your pre-5 COBOL you were likely OK.  In our shop we did not do this 
properly (*) and had issues.

(*) I believe the main issue was some pre-v5 options were not originally 
implemented in V5, so there was no possibility to replicate our V4 options.  
There were many updates to V5 (and V6) to make those options available, at 
which point the issues "went away".

From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Monday, March 27, 2023 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: A question or two on zOS issues

Glad to hear that someone followed all the rules so that,
unannounced COBOL 5+ didn't cause you packed decimal problems
with Truncation and the like. Or same thing with binary.

Steve Thompson

On 3/27/2023 10:31 AM, Schmitt, Michael wrote:
> The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
> to VS COBOL II in 1992. Since then we've migrated our 7 million lines of 
> COBOL code...
>
> - 1998 Language Environment
> - 2000 COBOL for MVS & VM
> - 2003 COBOL for OS/390 & VM
> - 2004 COBOL for z/OS & OS/390 3.2
> - 2005  3.3
> - 2006  3.4
> - 2011  4.2
> - 2020  6.2
>
> By doing... nothing.
>
> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
> requirement for load modules.
>
>
> So, in my experience, we don't need to know when our COBOL programs were last 
> used. And we already have tools that give us the compile date and version, 
> both from IBM and home grown.
>
> We still have a large number of programs that haven't been recompiled since 
> the VS COBOL II migration. They coexist just fine.
>
> (You may have to *relink* to pick up the Language Environment bootstrap 
> programs)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Pryor
> Sent: Friday, March 24, 2023 1:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A question or two on zOS issues
>
> There are a couple of pressing issues in z/OS that I'm sure many folks are 
> aware of but about which there doesn't seem to be much being done. I'm 
> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
> talking about:
>
> 1.) migration to IBM's latest COBOL release, and
>
> 2.) the not-really-that-far-off issue of Year 2042
>
> I've been asked several times recently whether we (a z/OS ISV) should 
> consider developing products to address these issues. Frankly, though, I live 
> in an ivory tower and while I sometime *think* I know what installations 
> problems and needs are, I'm usually surprised to find that reality is quite 
> different. So I'd like to throw a couple of questions out to the list for 
> comment:
>
> 1.) Would a reporting utility that determined which COBOL programs were 
> executed (and which ones weren't), and what release and options they were 
> compiled with be significantly helpful in a COBOL migration? What other 
> features would be nice to have? Or is this a low priority for most 
> installations, who are perhaps trying to justify keeping the mainframe alive 
> and/or conducting business as usual, let alone doing a COBOL migration 
> project?
>
> 2.) It's rather shocking that 2042 is so close and not much seems to be 
> happening. We are one of the vendors that have a date-simulation utility, but 
> we don't know if data centers have any near-term plans for 2042. Would it be 
> worthwhile to have a 2042 date-simulation product now, or is everyone going 
> to cross their fingers and try to use a test LPAR once the operating system 
> fully supports 2042 dates?
>
> Thanks for any comments and insight the IBM-MAIN hive mind might have.
>
> Steve Pryor
> CTO
> DTS Software, LLC
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MA

Re: A question or two on zOS issues

[Schmitt, Michael]

You're right, and fortunately we were saved from that pain because we 
procrastinated so long. And we skipped v5 completely.

We procrastinated because it took me a long time to rewrite our load module 
analyzer, as well as other PDS-dependencies.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Monday, March 27, 2023 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A question or two on zOS issues

As long as you use the correct compiler options with COBOL 5+ to replicate 
those of your pre-5 COBOL you were likely OK.  In our shop we did not do this 
properly (*) and had issues.

(*) I believe the main issue was some pre-v5 options were not originally 
implemented in V5, so there was no possibility to replicate our V4 options.  
There were many updates to V5 (and V6) to make those options available, at 
which point the issues "went away".

From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Monday, March 27, 2023 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: A question or two on zOS issues

Glad to hear that someone followed all the rules so that,
unannounced COBOL 5+ didn't cause you packed decimal problems
with Truncation and the like. Or same thing with binary.

Steve Thompson

On 3/27/2023 10:31 AM, Schmitt, Michael wrote:
> The last time we mass-converted and recompiled our COBOL was from OS/VS COBOL 
> to VS COBOL II in 1992. Since then we've migrated our 7 million lines of 
> COBOL code...
>
> - 1998 Language Environment
> - 2000 COBOL for MVS & VM
> - 2003 COBOL for OS/390 & VM
> - 2004 COBOL for z/OS & OS/390 3.2
> - 2005  3.3
> - 2006  3.4
> - 2011  4.2
> - 2020  6.2
>
> By doing... nothing.
>
> The hardest part of going to IBM Enterprise COBOL for z/OS 6 was the PDSE 
> requirement for load modules.
>
>
> So, in my experience, we don't need to know when our COBOL programs were last 
> used. And we already have tools that give us the compile date and version, 
> both from IBM and home grown.
>
> We still have a large number of programs that haven't been recompiled since 
> the VS COBOL II migration. They coexist just fine.
>
> (You may have to *relink* to pick up the Language Environment bootstrap 
> programs)
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Pryor
> Sent: Friday, March 24, 2023 1:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A question or two on zOS issues
>
> There are a couple of pressing issues in z/OS that I'm sure many folks are 
> aware of but about which there doesn't seem to be much being done. I'm 
> curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm 
> talking about:
>
> 1.) migration to IBM's latest COBOL release, and
>
> 2.) the not-really-that-far-off issue of Year 2042
>
> I've been asked several times recently whether we (a z/OS ISV) should 
> consider developing products to address these issues. Frankly, though, I live 
> in an ivory tower and while I sometime *think* I know what installations 
> problems and needs are, I'm usually surprised to find that reality is quite 
> different. So I'd like to throw a couple of questions out to the list for 
> comment:
>
> 1.) Would a reporting utility that determined which COBOL programs were 
> executed (and which ones weren't), and what release and options they were 
> compiled with be significantly helpful in a COBOL migration? What other 
> features would be nice to have? Or is this a low priority for most 
> installations, who are perhaps trying to justify keeping the mainframe alive 
> and/or conducting business as usual, let alone doing a COBOL migration 
> project?
>
> 2.) It's rather shocking that 2042 is so close and not much seems to be 
> happening. We are one of the vendors that have a date-simulation utility, but 
> we don't know if data centers have any near-term plans for 2042. Would it be 
> worthwhile to have a 2042 date-simulation product now, or is everyone going 
> to cross their fingers and try to use a test LPAR once the operating system 
> fully supports 2042 dates?
>
> Thanks for any comments and insight the IBM-MAIN hive mind might have.
>
> Steve Pryor
> CTO
> DTS Software, LLC
>
> --
> 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

--
Regar