Re: list Unix domain sockets

[Frank Swarbrick]

There doesn't appear to be an option to display the names of the sockets.

From: IBM Mainframe Discussion List  on behalf of 
David Crayford <0595a051454b-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, April 17, 2024 5:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: list Unix domain sockets

zlsof 
https://www.ibm.com/docs/en/zos/2.4.0?topic=scd-zlsof-display-information-about-open-files-sockets-pipes

> On 17 Apr 2024, at 06:42, Frank Swarbrick  wrote:
>
> Is it possible to list Unix domain sockets?  I don't see any netstat option 
> to do so.
>
>
> --
> 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: list Unix domain sockets

[Frank Swarbrick]

Interesting.  Never would have thought of that.
Not very efficient, however!

From: IBM Mainframe Discussion List  on behalf of 
Alexander Huemer 
Sent: Tuesday, April 16, 2024 11:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: list Unix domain sockets

On Tue, Apr 16, 2024 at 10:42:01PM +, Frank Swarbrick wrote:
> Is it possible to list Unix domain sockets?  I don't see any netstat
> option to do so.

$ find / -type s

-Alex

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

list Unix domain sockets

[Frank Swarbrick]

Is it possible to list Unix domain sockets?  I don't see any netstat option to 
do so.


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

Re: EDC8114I Address family not supported

[Frank Swarbrick]

https://www.ibm.com/docs/en/zos/3.1.0?topic=errnojrs-description-location-information
https://www.ibm.com/docs/en/zos/3.1.0?topic=errnojrs-zos-unix-reason-codes

For this one, the  part means JrOK, see return code (no additional 
information).

You can also use the bpxmtext program, which is available in both TSO and the 
Unix environment.


From: IBM Mainframe Discussion List  on behalf of 
Peter Ten Eyck <04d3761a18a7-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, March 12, 2024 8:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: EDC8114I Address family not supported

I am looking in https://www.ibm.com/docs/en/SSLTBW_2.4.0/pdf/bpxa800_v2r4.pdf 
for information on this message:

EDC8114I Address family not supported. Errno/Rsn=1114/112B

I only see information for: 1114 EAFNOSUPPORT The address family is not 
supported. Where can I find out more, in particular about 112B?

Note: This message was created when attempting to start SYSLOGD.



--
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: RACF, external password management

[Frank Swarbrick]

I have a curious question about MFA on z/OS.  Does each login require a 
different token?  Meaning, if I log on to TSO and to CICS, can I use the same 
token?  I ask because I log on and off to various CICS regions throughout the 
day, and I'd hate to have to get a new token for each login.  (We don't use MFA 
right now, except for our mainframe "outsourcer" teams (Kyndryl).

I wish that you could just "logon to VTAM," as it were, and it would log you in 
to each VTAM application you use.  I don't think this is available right now, 
correct me if I'm wrong!

Frank

From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Thursday, February 29, 2024 11:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: RACF, external password management

Linda Hagedorn wrote:
>This is very promising. Do you know where I can read more about ZMFA?

The documentation landing page is here:
https://www.ibm.com/docs/en/zma

>I'm interested in knowing how to configure the external source, and how
>the token is passed back to RACF, and how long the token lasts.
>For example, if systems programmers are working a problem, we
>wouldn't want the token to expire in 3 hrs.
>Or does the token last for the duration of the session?
>If tso/ispf times out (sysprog is doing research or answering
>mgmt questions), will they have to generate a new token?

If for example you’re configuring ZMFA to use a LDAP server as an “external” 
factor then this landing page has further details:
https://www.ibm.com/docs/en/zma/2.3.0?topic=customization-configuring-ldap

I put the word external in quotation marks because the LDAP server could be 
z/OS’s LDAP server or some other LDAP server running on the same IBM Z machine. 
And LDAP is just one example. Many “external” and external factors’ interfaces 
are supported.

You can configure ZMFA for “out-of-band” authentication so that users obtain 
what’s called a “cache token credential” (CTC) to log into RACF (via TSO/E for 
example). You can choose whether the CTC is reusable and how quickly it expires.

https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-policy-token-timeout
https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-cache-token-credential-be-reusable

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

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

Re: Nanosecond resolution timestamps for HLL's?

[Frank Swarbrick]

I wish I was wrong.


$ c89 x.c

CCN0767(I) The "C/C++   " feature of z/OS is not enabled.  Contact your 
system programmer.

FSUM3065 The COMPILE step ended with return code 16.

FSUM3017 Could not compile x.c. Correct the errors and try again.



From: IBM Mainframe Discussion List  on behalf of 
Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 22, 2024 6:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

Classification: Confidential

I believe the XL/C compiler is included in the z/OS license. XL/C++ I am not 
sure about.
Your shop may never have used it, but I believe it is there. Check with your 
z/OS sysprog.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Wednesday, February 21, 2024 8:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

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

The runtime is all part of LE.

Our shop does not have the C/C++ compiler.  Never had a business need for it.  
Never even looked in to it, so I don't know the cost.

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, February 21, 2024 5:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

Michael,

I do not think it requires the C/C++ compiler to use the C RTL subroutines 
delivered in CEE.SCEELKEX.  You only need the C/C++ documentation to look up 
the routine names, though working out how the C "header" files define the 
parameters and return value and translating those to COBOL would be challenging 
without the headers installed.

Is any large commercial shop actually NOT licensing the XL C/C++ compiler these 
days?  I would hope the cost is not be so prohibitive as to bedevil the 
bean-counters looking for $$ savings.  Don't at least some vendor products 
coded in C/C++ require at least the RTL subroutines (and maybe also the C++ 
DLL's) installed in order to execute at all?  Or is that all delivered in LE?

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Wednesday, February 21, 2024 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


This requires a C compiler to be installed on z/OS, which doesn't come 
standard, correct?



And if you had z/OS XL C, how would you bind this? I mean, is this one of those 
things where you're binding against a path on the OEMVS side?



-Original Message-

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Frank 
Swarbrick

Sent: Tuesday, February 20, 2024 12:01 AM

To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

Subject: Re: Nanosecond resolution timestamps for HLL's?



Try this.



   process pgmname(longmixed) nodynam

   id division.

   program-id. 'cgettime_test'.

   data division.

   working-storage section.

   01  errno-ref   pointer.

   01  strerror-refpointer.

   01  len pic s9(9) comp-5.

   01  display-x.

   05  pic x occurs 0 to 1025 depending on len.

   01  clock_idpic s9(9) comp-5.

   01  timespec.

   05  secspic s9(9) comp-5.

   05  nsecs   pic s9(9) comp-5.

   01  rc  pic s9(9) comp-5.



   linkage section.

   01  errno   pic s9(9) comp-5.

   01  h_errno pic s9(9) comp-5.

   01  strerrorpic x(256).



   procedure division.

   call 'clock_gettime' using value clock_id

  reference timespec

returning rc

   if rc = zero

   display 'seconds: ' secs

   display 'nanoseconds:' nsecs

   else

   perform handle-error

   end-if

   goback.



   handle-error.

   call '__errno' returning errno-ref

   set address of errno to errno-ref

   call 'strerror' using value errno

returning strerror-ref

   set address of strerror to strerror-ref

   move 1025 to len

   unstring strerror delimited by x'00'

into display-x count len

   display quote display-x quote

   exit.

   end program 'cgettime_test'.





From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on beha

Re: Nanosecond resolution timestamps for HLL's?

[Frank Swarbrick]

The runtime is all part of LE.

Our shop does not have the C/C++ compiler.  Never had a business need for it.  
Never even looked in to it, so I don't know the cost.

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, February 21, 2024 5:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

Michael,

I do not think it requires the C/C++ compiler to use the C RTL subroutines 
delivered in CEE.SCEELKEX.  You only need the C/C++ documentation to look up 
the routine names, though working out how the C "header" files define the 
parameters and return value and translating those to COBOL would be challenging 
without the headers installed.

Is any large commercial shop actually NOT licensing the XL C/C++ compiler these 
days?  I would hope the cost is not be so prohibitive as to bedevil the 
bean-counters looking for $$ savings.  Don't at least some vendor products 
coded in C/C++ require at least the RTL subroutines (and maybe also the C++ 
DLL's) installed in order to execute at all?  Or is that all delivered in LE?

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Wednesday, February 21, 2024 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


This requires a C compiler to be installed on z/OS, which doesn't come 
standard, correct?



And if you had z/OS XL C, how would you bind this? I mean, is this one of those 
things where you're binding against a path on the OEMVS side?



-Original Message-

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Frank 
Swarbrick

Sent: Tuesday, February 20, 2024 12:01 AM

To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

Subject: Re: Nanosecond resolution timestamps for HLL's?



Try this.



   process pgmname(longmixed) nodynam

   id division.

   program-id. 'cgettime_test'.

   data division.

   working-storage section.

   01  errno-ref   pointer.

   01  strerror-refpointer.

   01  len pic s9(9) comp-5.

   01  display-x.

   05  pic x occurs 0 to 1025 depending on len.

   01  clock_idpic s9(9) comp-5.

   01  timespec.

   05  secspic s9(9) comp-5.

   05  nsecs   pic s9(9) comp-5.

   01  rc  pic s9(9) comp-5.



   linkage section.

   01  errno   pic s9(9) comp-5.

   01  h_errno pic s9(9) comp-5.

   01  strerrorpic x(256).



   procedure division.

   call 'clock_gettime' using value clock_id

  reference timespec

returning rc

   if rc = zero

   display 'seconds: ' secs

   display 'nanoseconds:' nsecs

   else

   perform handle-error

   end-if

   goback.



   handle-error.

   call '__errno' returning errno-ref

   set address of errno to errno-ref

   call 'strerror' using value errno

returning strerror-ref

   set address of strerror to strerror-ref

   move 1025 to len

   unstring strerror delimited by x'00'

into display-x count len

   display quote display-x quote

   exit.

   end program 'cgettime_test'.





From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu<mailto:031df298a9da-dmarc-requ...@listserv.ua.edu>>

Sent: Monday, February 19, 2024 5:30 PM

To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> 
mailto:IBM-MAIN@LISTSERV.UA.EDU>>

Subject: Re: Nanosecond resolution timestamps for HLL's?



My initial purpose is actually part of implementing COBOL-compatible min-heap 
priority queue functions that return equal-priority nodes in FIFO insert order 
when popped.  A timestamp or some other monotonically increasing integer 
tie-breaker provided with the input priority value is necessary to preserve 
FIFO order when pushing new items into the queue.  As Paul (gil) pointed out, 
named counters might provide a similar function but would be far more 
performance-expensive compared to a simple STCK value.



Yes, I am aware that STCK breaks at the epoch in 2038 (or is it 2042? I forget 
now), which isn't ALL that far away.  A MetalC implementation for STCK values 
has been coded and works acceptably, as does of course a straight-forward 
assembler implementation.  Extension to use STCKE instead of STCK would be 
trivial in either case, but of course tha

Re: Nanosecond resolution timestamps for HLL's?

[Frank Swarbrick]

No C compiler required.  The C runtime is required, but that comes with the OS 
(Language Environment).

You bind against SCEELKEX.  No Unix required.

From: IBM Mainframe Discussion List  on behalf of 
Schmitt, Michael 
Sent: Wednesday, February 21, 2024 4:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

This requires a C compiler to be installed on z/OS, which doesn't come 
standard, correct?

And if you had z/OS XL C, how would you bind this? I mean, is this one of those 
things where you're binding against a path on the OEMVS side?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Tuesday, February 20, 2024 12:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

Try this.


   process pgmname(longmixed) nodynam

   id division.

   program-id. 'cgettime_test'.

   data division.

   working-storage section.

   01  errno-ref   pointer.

   01  strerror-refpointer.

   01  len pic s9(9) comp-5.

   01  display-x.

   05  pic x occurs 0 to 1025 depending on len.



   01  clock_idpic s9(9) comp-5.

   01  timespec.

   05  secspic s9(9) comp-5.

   05  nsecs   pic s9(9) comp-5.

   01  rc  pic s9(9) comp-5.



   linkage section.

   01  errno   pic s9(9) comp-5.

   01  h_errno pic s9(9) comp-5.

   01  strerrorpic x(256).



   procedure division.

   call 'clock_gettime' using value clock_id

  reference timespec

returning rc

   if rc = zero

   display 'seconds: ' secs

   display 'nanoseconds:' nsecs

   else

   perform handle-error

   end-if

   goback.



   handle-error.

   call '__errno' returning errno-ref

   set address of errno to errno-ref

   call 'strerror' using value errno

returning strerror-ref

   set address of strerror to strerror-ref

   move 1025 to len

   unstring strerror delimited by x'00'

into display-x count len

   display quote display-x quote

   exit.



   end program 'cgettime_test'.




From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Monday, February 19, 2024 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

My initial purpose is actually part of implementing COBOL-compatible min-heap 
priority queue functions that return equal-priority nodes in FIFO insert order 
when popped.  A timestamp or some other monotonically increasing integer 
tie-breaker provided with the input priority value is necessary to preserve 
FIFO order when pushing new items into the queue.  As Paul (gil) pointed out, 
named counters might provide a similar function but would be far more 
performance-expensive compared to a simple STCK value.

Yes, I am aware that STCK breaks at the epoch in 2038 (or is it 2042? I forget 
now), which isn't ALL that far away.  A MetalC implementation for STCK values 
has been coded and works acceptably, as does of course a straight-forward 
assembler implementation.  Extension to use STCKE instead of STCK would be 
trivial in either case, but of course that also doubles the space occupied by 
the tiebreaker value.  I would much prefer an IBM-maintained solution that 
crosses the epoch barrier transparently.

A reasonably-well-performing implementation of the C function "clock_gettime()" 
would probably do the trick, if it was callable from COBOL.  David C. pointed 
out in an earlier reply that IBM XL C now has this function, if I can figure 
out how to invoke it from COBOL.  IBM is not always very good at providing 
illustrative examples for inter-language cases like this.

As for the actual business purpose, I'm not at liberty to discuss that.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
Sent: Monday, February 19, 2024 4:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


I don't understand how you will use this.



What is the business purpose?



On Sun, 18 Feb 2024 18:22:53 -0600 Peter Farley

<031df298a9da-dmarc-requ...@listserv.ua.edu<mailto:031df298a9da-dmarc-requ...@listserv.ua.edu>>
 wrote:



:>I have been reviewing all the documentation I can find to provide nano-second 
resolution timestamps from a calling HLL batch program.  STCK and STCKE 
instructions of course provide this (and more) resolution, but using

Re: Nanosecond resolution timestamps for HLL's?

[Frank Swarbrick]

I don't know how "expensive" the STORAGE runtime option is.  All I know is that 
when we were converting to LE COBOL we had programs that depended on that 
feature, so we set it.

SCEELKEX is the library to link for the clock_gettime function.

SCEELKEX
Like SCEELKED, contains Language Environment resident routines for non-XPLINK 
applications. However, case-sensitive names that can be greater than eight 
characters in length are contained in this library. This allows symbols such as 
the C/C++ printf and pthread_create functions to be resolved without requiring 
the names to be uppercased, truncated, or mapped to another symbol.

>From 
>https://www.ibm.com/docs/en/zos/2.5.0?topic=routines-planning-link-edit-run

This "crazy side deck" files are for DLLs, so you don't need it here.


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, February 20, 2024 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

Hi Frank,

Agreed, you do have to be able to read “header” files and “translate” C types 
and structures to their COBOL equivalents.

I did notice you had not set the clock_id value, but I had already looked up in 
the C header file that CLOCK_MONOTONIC is binary zero and figured you just got 
lucky on the contents of WORKING-STORAGE for that field.  Isn’t that runtime 
option expensive (in CPU time) to use?

As it happens, there are a couple of sites to which I have access that do have 
the most recent COBOL V6.4 updates (“P231130” in the heading line), and I have 
recently been playing around with the new FUNCTION prototype capabilities.  
Neat stuff for sure.

BTW, what Binder SYSLIB library is needed to get those C runtime stubs linked 
into a COBOL calling program? CEE.SCEELKED or others?  Do we need to use one of 
those crazy-looking “side deck” thingamabobs?

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Tuesday, February 20, 2024 12:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


You have to have some knowledge of C to be able to do it.  For example, I had 
to look at /usr/include/time.h to be able to known what types and sizes of the 
data fields are needed for COBOL.  And the whole __errno thing, I'm not sure 
how I figured that out.  It was some time ago.



Oh, by the way, I seem to have forgotten to explicitly set clock_id.  Luckily I 
have the runtime setting on which initiates working storage to low-values, and 
the clock_id value CLOCK_MONOTONIC is binary zero.  CLOCK_REALTIME, fwiw, is 
binary 1.  I got these from time.h as well. Anyway, I'd add those as 88 levels 
under clock_id and then set CLOCK_MONOTONIC to true before calling 
clock_gettime().



If you are lucky enough to have the most recent fix pack for Enterprise COBOL 
v6.4 you should be able to utilize function prototypes.  I don't have it, but 
I've been aware of this feature from the COBOL 2014 standard, so I think you'd 
do something like this:



id division.

function-id.

Clock-GetTime as 'clock_gettime' is prototype

entry—name is longmixed

entry-interface is static.

data division.

linkage section.

01  clock-id   pic 9(9) comp-5.

01  time-spec.

05  secondspic 9(9) comp-5.

05  nanosecondspic 9(9) comp-5.

01  result-codepic 9(9) comp-5.

procedure division using value clock-id

 reference time-spec

   returning result-code.

end function Clock-GetTime.



This would be coded ahead of the main program.  Or better yet, placed in a 
copybook and "COPYed" in at the top of the main program

You'd then add to the calling program:



configuration section.

repository.

function Clock-GetTime.



Then invoke the C routine like this:



if Clock-GetTime(clock_id timespec) = zero

[...happy path here...]

else

[...sad path here...]

end-if



You don't have to code the repository entry if you just want to add the 
FUNCTION keyword before Clock-GetTime, e.g.

if function Clock-GetTime(...) ...



You'd could also remove the "process pgmname(longmixed) nodynam", if you like, 
because those are handled by the enrty-name and entry-interface clauses of the 
function prototype definition.



Have fun!





From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu<mailto:031df298a9da-dmarc-requ...@listserv.ua.edu>>

Sent: Tuesday, February 20, 2024 8:39 AM

To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> 
mailto:IBM-MAIN@LISTSERV.UA.EDU>>

Subject: Re: Nanosecond resolution timestamps for HLL's?



Than

Re: Nanosecond resolution timestamps for HLL's?

[Frank Swarbrick]

You have to have some knowledge of C to be able to do it.  For example, I had 
to look at /usr/include/time.h to be able to known what types and sizes of the 
data fields are needed for COBOL.  And the whole __errno thing, I'm not sure 
how I figured that out.  It was some time ago.

Oh, by the way, I seem to have forgotten to explicitly set clock_id.  Luckily I 
have the runtime setting on which initiates working storage to low-values, and 
the clock_id value CLOCK_MONOTONIC is binary zero.  CLOCK_REALTIME, fwiw, is 
binary 1.  I got these from time.h as well. Anyway, I'd add those as 88 levels 
under clock_id and then set CLOCK_MONOTONIC to true before calling 
clock_gettime().

If you are lucky enough to have the most recent fix pack for Enterprise COBOL 
v6.4 you should be able to utilize function prototypes.  I don't have it, but 
I've been aware of this feature from the COBOL 2014 standard, so I think you'd 
do something like this:

id division.
function-id.
Clock-GetTime as 'clock_gettime' is prototype
entry—name is longmixed
entry-interface is static.
data division.
linkage section.
01  clock-id   pic 9(9) comp-5.
01  time-spec.
05  secondspic 9(9) comp-5.
05  nanosecondspic 9(9) comp-5.
01  result-codepic 9(9) comp-5.
procedure division using value clock-id
 reference time-spec
   returning result-code.
end function Clock-GetTime.

This would be coded ahead of the main program.  Or better yet, placed in a 
copybook and "COPYed" in at the top of the main program
You'd then add to the calling program:

configuration section.
repository.
function Clock-GetTime.

Then invoke the C routine like this:

if Clock-GetTime(clock_id timespec) = zero
[...happy path here...]
else
[...sad path here...]
end-if

You don't have to code the repository entry if you just want to add the 
FUNCTION keyword before Clock-GetTime, e.g.
if function Clock-GetTime(...) ...

You'd could also remove the "process pgmname(longmixed) nodynam", if you like, 
because those are handled by the enrty-name and entry-interface clauses of the 
function prototype definition.

Have fun!


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, February 20, 2024 8:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

Thank you very much Frank.  I will try this out on my system.

Would that such clear examples were available from IBM.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Tuesday, February 20, 2024 1:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


Try this.





   process pgmname(longmixed) nodynam



   id division.



   program-id. 'cgettime_test'.



   data division.



   working-storage section.



   01  errno-ref   pointer.



   01  strerror-refpointer.



   01  len pic s9(9) comp-5.



   01  display-x.



   05  pic x occurs 0 to 1025 depending on len.







   01  clock_idpic s9(9) comp-5.



   01  timespec.



   05  secspic s9(9) comp-5.



   05  nsecs   pic s9(9) comp-5.



   01  rc  pic s9(9) comp-5.







   linkage section.



   01  errno   pic s9(9) comp-5.



   01  h_errno pic s9(9) comp-5.



   01  strerrorpic x(256).







   procedure division.



   call 'clock_gettime' using value clock_id



  reference timespec



returning rc



   if rc = zero



   display 'seconds: ' secs



   display 'nanoseconds:' nsecs



   else



   perform handle-error



   end-if



   goback.







   handle-error.



   call '__errno' returning errno-ref



   set address of errno to errno-ref



   call 'strerror' using value errno



returning strerror-ref



   set address of strerror to strerror-ref



   move 1025 to len



   unstring strerror delimited by x'00'



into display-x count len



   display quote display-x quote



   exit.







   end program 'cgettime_test'.









From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu<mailto:031df298a9da-dmarc-requ...@listserv.ua.edu>>

Sent: Monday, February 19

Re: Nanosecond resolution timestamps for HLL's?

[Frank Swarbrick]

Try this.


   process pgmname(longmixed) nodynam

   id division.

   program-id. 'cgettime_test'.

   data division.

   working-storage section.

   01  errno-ref   pointer.

   01  strerror-refpointer.

   01  len pic s9(9) comp-5.

   01  display-x.

   05  pic x occurs 0 to 1025 depending on len.



   01  clock_idpic s9(9) comp-5.

   01  timespec.

   05  secspic s9(9) comp-5.

   05  nsecs   pic s9(9) comp-5.

   01  rc  pic s9(9) comp-5.



   linkage section.

   01  errno   pic s9(9) comp-5.

   01  h_errno pic s9(9) comp-5.

   01  strerrorpic x(256).



   procedure division.

   call 'clock_gettime' using value clock_id

  reference timespec

returning rc

   if rc = zero

   display 'seconds: ' secs

   display 'nanoseconds:' nsecs

   else

   perform handle-error

   end-if

   goback.



   handle-error.

   call '__errno' returning errno-ref

   set address of errno to errno-ref

   call 'strerror' using value errno

returning strerror-ref

   set address of strerror to strerror-ref

   move 1025 to len

   unstring strerror delimited by x'00'

into display-x count len

   display quote display-x quote

   exit.



   end program 'cgettime_test'.




From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Monday, February 19, 2024 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

My initial purpose is actually part of implementing COBOL-compatible min-heap 
priority queue functions that return equal-priority nodes in FIFO insert order 
when popped.  A timestamp or some other monotonically increasing integer 
tie-breaker provided with the input priority value is necessary to preserve 
FIFO order when pushing new items into the queue.  As Paul (gil) pointed out, 
named counters might provide a similar function but would be far more 
performance-expensive compared to a simple STCK value.

Yes, I am aware that STCK breaks at the epoch in 2038 (or is it 2042? I forget 
now), which isn’t ALL that far away.  A MetalC implementation for STCK values 
has been coded and works acceptably, as does of course a straight-forward 
assembler implementation.  Extension to use STCKE instead of STCK would be 
trivial in either case, but of course that also doubles the space occupied by 
the tiebreaker value.  I would much prefer an IBM-maintained solution that 
crosses the epoch barrier transparently.

A reasonably-well-performing implementation of the C function “clock_gettime()” 
would probably do the trick, if it was callable from COBOL.  David C. pointed 
out in an earlier reply that IBM XL C now has this function, if I can figure 
out how to invoke it from COBOL.  IBM is not always very good at providing 
illustrative examples for inter-language cases like this.

As for the actual business purpose, I’m not at liberty to discuss that.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
Sent: Monday, February 19, 2024 4:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


I don't understand how you will use this.



What is the business purpose?



On Sun, 18 Feb 2024 18:22:53 -0600 Peter Farley

<031df298a9da-dmarc-requ...@listserv.ua.edu>
 wrote:



:>I have been reviewing all the documentation I can find to provide nano-second 
resolution timestamps from a calling HLL batch program.  STCK and STCKE 
instructions of course provide this (and more) resolution, but using them from 
any HLL besides C/C++ requires an assembler subroutine (however simple that may 
be for those of us who are already comfortable in assembler).  In shops where 
any new assembler functionality is proscribed or strongly discouraged can't or 
would strongly prefer not to use assembler for this functionality.



:>The only HLL-callable function already provided in z/OS that I can find that 
provides anything near that resolution is the LE Callable Services function 
CEEGMT, but two calls to that service from a COBOL program in a row separated 
by only a few calculations and a DISPLAY to SYSOUT produce identical values.  
This is not good enough for high-volume processing needs.  Every request for a 
time value needs to generate a new higher value.



:>Is there any other place I am not yet looking which provides nano-second 
resolution like STCK/STCKE and 

Re: zsh for z/OS

[Frank Swarbrick]

know the difference between the
profiles and the RC files, so they throw all of the profiling into
(e.g.) $HOME/.bashrc. It's kinda counter-productive. The RC files are
for settings which cannot be "inherited" for one reason or another.

It gets worse with graphical logon. (But need not! Just that nobody
bothered to set things right for the graphical logon logic.)

Keep it simple and stick with the standards. Avoid shiny things and
feechers which cause konfoozhun.

-- R; <><


On 2/16/24 15:48, Michael Babcock wrote:
> According to the man page for netstat, it’s a synonym for onetstat.
> Issuing netstat in bash 5.2 says command not found.   It may be a moot
> point if it’s truly a synonym.
>
> On Fri, Feb 16, 2024 at 2:33 PM Frank Swarbrick 
> wrote:
>
>> Here's a bit of an off the wall question/request.
>>
>> Do both 'netstat' and 'onetstat' work in zsh?
>>
>> In bash, only 'onetstat' works.  I think that bash under z/OS is unable to
>> follow executables with the 'e' file type (external link).
>>
>>
>> ls -FalTHp /bin/netstat /bin/onetstat
>>
>>  erwxrwxrwx 1 BPXROOT  OMVSGRP8 Jun  1
>> 2021 /bin/netstat -> ONETSTAT
>>
>>  lrwxrwxrwx 1 BPXROOT  OMVSGRP   29 Jun  1
>> 2021 /bin/onetstat -> ../usr/lpp/tcpip/bin/onetstat
>>
>> Frank
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf
>> of Ed Jaffe <05acc3c79bf7-dmarc-requ...@listserv.ua.edu>
>> Sent: Friday, February 16, 2024 12:48 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU 
>> Subject: Re: zsh for z/OS
>>
>> On 2/16/2024 11:33 AM, Frank Swarbrick wrote:
>>> z/OS 3.1 added the Z Shell, zsh.  Is anyone using it?  How do you like
>> it.  What interesting features does it have over bash?
>>> I'm only at 2.5, so can't use it.
>> I am using it. After all, what self-respecting z/OS advocate doesn't
>> want to use a shell called Z?
>>
>> I'm not a power user. Not doing anything I couldn't also do in bash...
>>
>> --
>> Phoenix Software International
>> Edward E. Jaffe
>> 831 Parkview Drive North
>> El Segundo, CA 90245
>> https://www.phoenixsoftware.com/
>>
>>
>>
>> 
>> This e-mail message, including any attachments, appended messages and the
>> information contained therein, is for the sole use of the intended
>> recipient(s). If you are not an intended recipient or have otherwise
>> received this email message in error, any use, dissemination, distribution,
>> review, storage or copying of this e-mail message and the information
>> contained therein is strictly prohibited. If you are not an intended
>> recipient, please contact the sender by reply e-mail and destroy all copies
>> of this email message and do not otherwise utilize or retain this email
>> message or any or all of the information contained therein. Although this
>> email message and any attachments or appended messages are believed to be
>> free of any virus or other defect that might affect any computer system
>> into
>> which it is received and opened, it is the responsibility of the recipient
>> to ensure that it is virus free and no responsibility is accepted by the
>> sender for any loss or damage arising in any way from its opening or use.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
> --
> 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: zsh for z/OS

[Frank Swarbrick]

Interesting.  So it looks like (just guessing!) bash isn't able to find 
external links when following the PATH.  Or something.

Frank

From: IBM Mainframe Discussion List  on behalf of 
Michael Babcock <05ad4e2d7232-dmarc-requ...@listserv.ua.edu>
Sent: Friday, February 16, 2024 1:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zsh for z/OS

I can also cd into the bin directory and issue ./netstat and it works.

On Fri, Feb 16, 2024 at 2:33 PM Frank Swarbrick 
wrote:

> Here's a bit of an off the wall question/request.
>
> Do both 'netstat' and 'onetstat' work in zsh?
>
> In bash, only 'onetstat' works.  I think that bash under z/OS is unable to
> follow executables with the 'e' file type (external link).
>
>
> ls -FalTHp /bin/netstat /bin/onetstat
>
> erwxrwxrwx 1 BPXROOT  OMVSGRP8 Jun  1
> 2021 /bin/netstat -> ONETSTAT
>
> lrwxrwxrwx 1 BPXROOT  OMVSGRP   29 Jun  1
> 2021 /bin/onetstat -> ../usr/lpp/tcpip/bin/onetstat
>
> Frank
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Ed Jaffe <05acc3c79bf7-dmarc-requ...@listserv.ua.edu>
> Sent: Friday, February 16, 2024 12:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: zsh for z/OS
>
> On 2/16/2024 11:33 AM, Frank Swarbrick wrote:
> > z/OS 3.1 added the Z Shell, zsh.  Is anyone using it?  How do you like
> it.  What interesting features does it have over bash?
> >
> > I'm only at 2.5, so can't use it.
>
> I am using it. After all, what self-respecting z/OS advocate doesn't
> want to use a shell called Z?
>
> I'm not a power user. Not doing anything I couldn't also do in bash...
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
>
>
>
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system
> into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
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: zsh for z/OS

[Frank Swarbrick]

Here's a bit of an off the wall question/request.

Do both 'netstat' and 'onetstat' work in zsh?

In bash, only 'onetstat' works.  I think that bash under z/OS is unable to 
follow executables with the 'e' file type (external link).


ls -FalTHp /bin/netstat /bin/onetstat

erwxrwxrwx 1 BPXROOT  OMVSGRP8 Jun  1  2021 
/bin/netstat -> ONETSTAT

lrwxrwxrwx 1 BPXROOT  OMVSGRP   29 Jun  1  2021 
/bin/onetstat -> ../usr/lpp/tcpip/bin/onetstat

Frank


From: IBM Mainframe Discussion List  on behalf of Ed 
Jaffe <05acc3c79bf7-dmarc-requ...@listserv.ua.edu>
Sent: Friday, February 16, 2024 12:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zsh for z/OS

On 2/16/2024 11:33 AM, Frank Swarbrick wrote:
> z/OS 3.1 added the Z Shell, zsh.  Is anyone using it?  How do you like it.  
> What interesting features does it have over bash?
>
> I'm only at 2.5, so can't use it.

I am using it. After all, what self-respecting z/OS advocate doesn't
want to use a shell called Z?

I'm not a power user. Not doing anything I couldn't also do in bash...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

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

zsh for z/OS

[Frank Swarbrick]

z/OS 3.1 added the Z Shell, zsh.  Is anyone using it?  How do you like it.  
What interesting features does it have over bash?

I'm only at 2.5, so can't use it.

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

Re: Query - do you have access to GitHub from your z/OS system? And do you have git on your z/OS system?

[Frank Swarbrick]

I have git installed, but we don't make any real use of it at this point.
I don't have access to github because our mainframe has no internet access.  Do 
other shops mainframes have internet access?

From: IBM Mainframe Discussion List  on behalf of 
Lionel B. Dyck <057b0ee5a853-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, February 14, 2024 7:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Query - do you have access to GitHub from your z/OS system? And do you 
have git on your z/OS system?

As part of the z/OS Open Tools project I'm asking if your z/OS system has
access to GitHub. The reason for this question is that IBM, ISVs, and
open-source developers are increasingly using GitHub.

Questions:

1. Do you have access to GitHub from your z/OS system?
2. Do you have git installed on your z/OS system?

Thank you


Lionel B. Dyck <><
Github: https://github.com/lbdyck
System Z Enthusiasts Discord:
https://discord.gg/system-z-enthusiasts-880322471608344597

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

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

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

Re: Question

[Frank Swarbrick]

That is interesting indeed.  Thanks.

From: IBM Mainframe Discussion List  on behalf of 
Lionel B. Dyck <057b0ee5a853-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 8, 2024 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Question

I got this update from an IBM contact - hope it helps:

"I'm not sure if the question was answered, but any Python from Rocket at the 
3.10 or later level is the IBM SDK."


Lionel B. Dyck <><
Github: https://github.com/lbdyck
System Z Enthusiasts Discord: 
https://discord.gg/system-z-enthusiasts-880322471608344597

“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 
kekronbekron
Sent: Wednesday, February 7, 2024 11:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question

Someone will correct me if/where I'm wrong.

Open Enterprise SDK for Python - Just python. Comes with pip and virtualenv or 
venv, which are included in Python distribution these days.
pip = package manager.
virtualenv / venv = environment manager.

Rocket Python = Rocket delivers the open source tools it delivers through 
Anaconda, which is a Python environment + package manager.
I haven't looked but I believe they deliver Bash, and some other tools also via 
Anaconda "channels".

ZOSOpen Tools's Python = It's an empty wrapper. At the moment, it just exists 
to add itself as a dependency to any Python project you may want to port.
All it does is check if Python exists in your sys.

Upstreaming zOS-relevant bits of code to Python, I think, is happening 
completely separate from ZOSOpen Tools's Python.
Some of it may well be tied with "Python AI Toolkit for Z".
PATZ = Close to OE SDK for Python, but delivered via an IBM hosted & managed 
repository manager (ex: JFrog Artifactory, Sonatype Nexus).
The difference is, PATZ is also a source for python packages that have zOS 
support (+ acceleration where possible I think) added.
There's also the layer of safety of it coming from an IBM "stash" rather than 
pypi.org directly.
pypi = the "stash" where "pip install thing" will get a package from, by 
default.




On Thursday, February 8th, 2024 at 00:01, Rick Troth  wrote:

> The closest standard is Python's "ctypes".
> Now ... some of the guides I have read say that CTYPES only works with
> C, but I've found that (within limits) LE calling convention works
> well with other languages, not just C.
>
> In a previous life, I was able to call C from Python (the point being
> "to call /native/") without any special rigging other than CTYPES
> (included w Python).
>
> -- R; <><
>
>
>
> On 2/7/24 12:32, Lionel B. Dyck wrote:
>
> > Add to that question how does the z/OS Open Tools port of python
> > compare to Rockets and to the IBM Open Enterprise SDK?
> >
> > Lionel B. Dyck <><
> > Github:https://github.com/lbdyck
> > System Z Enthusiasts Discord:
> > https://discord.gg/system-z-enthusiasts-880322471608344597
> >
> > “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 listibm-m...@listserv.ua.edu On
> > Behalf Of Frank Swarbrick
> > Sent: Wednesday, February 7, 2024 11:30 AM
> > To:IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Question
> >
> > So here's a curious question. Are IBM Open Enterprise SDK for Python
> > and the Python from Rocket Software basically the same, or no?
> >
> > Frank
> > 
> > From: IBM Mainframe Discussion listibm-m...@listserv.ua.edu on
> > behalf of Peter sylvesterpeter.sylves...@gmail.com
> > Sent: Tuesday, February 6, 2024 11:15 PM To:IBM-MAIN@LISTSERV.UA.EDU
> > IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Question
> >
> > Yes, from the IBM pax installation. And a bit of pipifax. :-)
> >
> > Python 3.12.0 (heads/pyz_dev-3.12:ef647e3673, Oct 31 2023, 19:02:59)
> > [Clang
> > 14.0.0 (build 1465bdb)] on zos On 06/02/2024 19:47, Ed Jaffe wrote:
> >
> > > Yes.
> > >
> > > : >python
> > > Python 3.11.4 (heads/pyz_dev-3.11.ziip:39640ccf4b, Jul 15 2023,
> > > 05:46:13) [Clang 14.0.0 ] on zos Type "help", "copyright", "credits"
> > > or "license" for more information
> > > On 2/6/2024 10:15 AM, Steve Beaver wrote:
> > >
> > > > Does anyone have

Re: Question

[Frank Swarbrick]

So here's a curious question.  Are IBM Open Enterprise SDK for Python and the 
Python from Rocket Software basically the same, or no?

Frank

From: IBM Mainframe Discussion List  on behalf of 
Peter Sylvester 
Sent: Tuesday, February 6, 2024 11:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Question

Yes,  from the IBM pax installation. And a bit of pipifax. :-)

Python 3.12.0 (heads/pyz_dev-3.12:ef647e3673, Oct 31 2023, 19:02:59) [Clang 
14.0.0 (build 1465bdb)]
on zos
On 06/02/2024 19:47, Ed Jaffe wrote:
> Yes.
>
> : >python
> Python 3.11.4 (heads/pyz_dev-3.11.ziip:39640ccf4b, Jul 15 2023, 05:46:13) 
> [Clang 14.0.0 ] on zos
> Type "help", "copyright", "credits" or "license" for more information
> >>>
>
> On 2/6/2024 10:15 AM, Steve Beaver wrote:
>> Does anyone have Python installed in your shop?
>>
>>
>> Steve



--
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: Ent. COBOL User-defined function question

[Frank Swarbrick]

Try this shorter link:
https://www.ibm.com/support/pages/apar/PH57397
PH57397: COBOL USER-DEFINED FUNCTION 
PROTOTYPES<https://www.ibm.com/support/pages/apar/PH57397>
COBOL User-Defined Function Prototypes
www.ibm.com



From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Friday, February 2, 2024 3:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Ent. COBOL User-defined function question

<*Sigh*> Only accessible to those with a valid ShopZ login (which I do NOT 
have).

Thanks anyway.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Wayne Driscoll
Sent: Friday, February 2, 2024 4:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ent. COBOL User-defined function question


https://www.ibm.com/support/pages/apar/PH57397<https://www.ibm.com/support/pages/apar/PH57397__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Ic3mtVrIH6NPBYRIjV6-s_mr9pAjGQkc7lCfntn9qcSE4i0As0tiJhNd16wy_Ktthd7W8W10IXQti-ufq8pxAnyonEmC3VFHF_GW3nCu$>



Wayne Driscoll

wayne.drisc...@broadcom.com

All opinions are expressly my own.



Thank you for that information.  On the system where I have access to V6.4

it looks like we only have as far as the June 2023 refresh:



PP 5655-EC6 IBM Enterprise COBOL for z/OS  6.4.0 P230615



I will wait for the latest level to be applied and try again then.



Do you happen to have a link to the APAR description? I presume there is a

coordinated documentation update as well.



Peter



On Fri, Feb 2, 2024 at 3:41 PM Farley, Peter <

031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:



> Thank you for that information.  On the system where I have access to V6.4

> it looks like we only have as far as the June 2023 refresh:

>

> PP 5655-EC6 IBM Enterprise COBOL for z/OS  6.4.0 P230615

>

> I will wait for the latest level to be applied and try again then.

>

> Do you happen to have a link to the APAR description? I presume there is a

> coordinated documentation update as well.

>

> Peter

>

> From: IBM Mainframe Discussion List  On Behalf

> Of Frank Swarbrick

> Sent: Friday, February 2, 2024 2:40 PM

> To: IBM-MAIN@LISTSERV.UA.EDU

> Subject: Re: Ent. COBOL User-defined function question

>

>

> What fix level are you at?  October 2023's PTF closes APAR PH57397, which

> adds "function prototypes".  I think you would have the appropraite

> prototype defined before the program/function where it is used.  Best done

> with a COPY statement.

>

> Prior to this fix level I think your results are working as designed.

>

> Frank

> 

>

> From: IBM Mainframe Discussion List  IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Peter Farley <

> 031df298a9da-dmarc-requ...@listserv.ua.edu 031df298a9da-dmarc-requ...@listserv.ua.edu>>

>

> Sent: Thursday, February 1, 2024 9:50 AM

>

> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> <

> IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>>

>

> Subject: Ent. COBOL User-defined function question

>

> Using the listserv web interface for the first time, so I hope this goes

> through OK.

>

> In testing the new V6.4 user-defined functions capability I have found

> that it seems you cannot have a separately-compiled-and-linked user-defined

> function.  If you separately compile and link the function for dynamic load

> and execute by other programs, the other programs cannot just have a

> REPOSITORY paragraph that names the function - the function source code

> seems to be required as part of the using-program compile, otherwise you

> get an error message.

>

> Example error message:

>

> 01IDENTIFICATION DIVISION.

> 02PROGRAM-ID. FUNCTSTM

> 03ENVIRONMENT DIVISION.

> 04CONFIGURATION SECTION.

> 05REPOSITORY.

> 06FUNCTION TST1FUNC

>

> 06==> IGYDS0301-E "TST1FUNC" was specified in the "FUNCTION" phrase of

> the "REPOSITORY"

>   paragraph, but it is not the name of an user-defined

> function.  The

>   phrase was discarded.

>

> Does this mean that user-defined source code must always be included when

> compiling programs that want to use these functions?  That seems less than

> useful to me because then there is no way to maintain such functions

> independently of the programs that use them.

>

> TIA for any insight you can offer.

>

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

Re: SDSF PS Command column

[Frank Swarbrick]

If only I had superuser access!
Frank

From: IBM Mainframe Discussion List  on behalf of 
Lionel B. Dyck 
Sent: Friday, February 2, 2024 1:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SDSF PS Command column

You will need to issue the `ps -ef` command while using sudo, or su, to see all 
the processes and then the command field will be full.

You can do that using bpxwunix from within a rexx exec.


Lionel B. Dyck <><
Github: https://github.com/lbdyck
System Z Enthusiasts Discord: 
https://discord.gg/system-z-enthusiasts-880322471608344597

“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 
Perryman
Sent: Friday, February 2, 2024 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF PS Command column

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

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

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

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

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

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

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

--
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: SDSF PS Command column

[Frank Swarbrick]

I tried D OMVS,A=ALL and it (CMD) is also truncated at 40.  
oh well!

From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Friday, February 2, 2024 1:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SDSF PS Command column

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

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

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

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

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

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

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

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

Re: SDSF PS Command column

[Frank Swarbrick]

This both works and does not work.  It expands the column, but, for this column 
at least, only pads past 40 with spaces.  Perhaps the full command is stored 
only as 40 characters.  

From: IBM Mainframe Discussion List  on behalf of 
Lionel B. Dyck 
Sent: Friday, February 2, 2024 12:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SDSF PS Command column

In the menu bar click View then Arrange and then find Command in the popup
table and change the width.


Lionel B. Dyck <><
Github: https://github.com/lbdyck
System Z Enthusiasts Discord:
https://discord.gg/system-z-enthusiasts-880322471608344597

“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
Frank Swarbrick
Sent: Friday, February 2, 2024 1:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF PS Command column

Sorry, I am not trying to type a command.  Rather I am looking at the
"Command" column, and it is 40 characters in size.

From: IBM Mainframe Discussion List  on behalf of
Ituriel do Neto <03427ec2837d-dmarc-requ...@listserv.ua.edu>
Sent: Friday, February 2, 2024 12:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SDSF PS Command column

Hi,

If you type "/", a panel will pop up with more space to type commands


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer






Em sexta-feira, 2 de fevereiro de 2024 às 16:30:56 BRT, Frank Swarbrick
 escreveu:





Is there any way to get more than the first 40 characters of the associated
command line for a job in the PS screen?


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

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

Re: SDSF PS Command column

[Frank Swarbrick]

Sorry, I am not trying to type a command.  Rather I am looking at the "Command" 
column, and it is 40 characters in size.

From: IBM Mainframe Discussion List  on behalf of 
Ituriel do Neto <03427ec2837d-dmarc-requ...@listserv.ua.edu>
Sent: Friday, February 2, 2024 12:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SDSF PS Command column

Hi,

If you type "/", a panel will pop up with more space to type commands


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer






Em sexta-feira, 2 de fevereiro de 2024 às 16:30:56 BRT, Frank Swarbrick 
 escreveu:





Is there any way to get more than the first 40 characters of the associated 
command line for a job in the PS screen?


--
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: Ent. COBOL User-defined function question

[Frank Swarbrick]

What fix level are you at?  October 2023's PTF closes APAR PH57397, which adds 
"function prototypes".  I think you would have the appropraite prototype 
defined before the program/function where it is used.  Best done with a COPY 
statement.

Prior to this fix level I think your results are working as designed.

Frank

From: IBM Mainframe Discussion List  on behalf of 
Peter Farley <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 1, 2024 9:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Ent. COBOL User-defined function question

Using the listserv web interface for the first time, so I hope this goes 
through OK.

In testing the new V6.4 user-defined functions capability I have found that it 
seems you cannot have a separately-compiled-and-linked user-defined function.  
If you separately compile and link the function for dynamic load and execute by 
other programs, the other programs cannot just have a REPOSITORY paragraph that 
names the function - the function source code seems to be required as part of 
the using-program compile, otherwise you get an error message.

Example error message:

01IDENTIFICATION DIVISION.
02PROGRAM-ID. FUNCTSTM
03ENVIRONMENT DIVISION.
04CONFIGURATION SECTION.
05REPOSITORY.
06FUNCTION TST1FUNC

06==> IGYDS0301-E "TST1FUNC" was specified in the "FUNCTION" phrase of the 
"REPOSITORY"
  paragraph, but it is not the name of an user-defined 
function.  The
  phrase was discarded.

Does this mean that user-defined source code must always be included when 
compiling programs that want to use these functions?  That seems less than 
useful to me because then there is no way to maintain such functions 
independently of the programs that use them.

TIA for any insight you can offer.

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: JES2 JOBDEF DUPL_JOB=NODELAY - Any gotchas?

[Frank Swarbrick]

I tried this once for a single class in our dev region and it screwed up some 
jobs that depend on DELAY for sequencing.  
Of course something could be done about that, but I didn't feel like dealing 
with it at the time.

From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Thursday, February 1, 2024 10:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: JES2 JOBDEF DUPL_JOB=NODELAY - Any gotchas?

I am not a sysprog but I occasionally play one in my spare time. I am thinking 
of changing a system that I control to DUPL_JOB=NODELAY. Any gotchas? Anything 
I need to consider before I do this? Do most/many of you run with NO_DELAY?

I am trying to solve a problem where I have jobs delayed because the names are 
duplicates. I can't easily change the jobnames.

I can't think of any issues. We don't have any significant automation. I can't 
think of anything where jobs are referenced by name rather than Job ID.

What should I be considering?

Thanks,
Charles

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

SDSF PS Command column

[Frank Swarbrick]

Is there any way to get more than the first 40 characters of the associated 
command line for a job in the PS screen?


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

Re: netcat for z/OS?

[Frank Swarbrick]

Yeah, I need a ssh-proxyh, I think!

From: IBM Mainframe Discussion List  on behalf of 
Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu>
Sent: Friday, January 12, 2024 9:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: netcat for z/OS?

On 1/12/24 10:02 AM, Kirk Wolf wrote:
> IBM ships a command with z/OS:  "ssh-proxyc  - HTTP SOCKS-5 Proxy
> command for ssh client"

Based on the name, that seems to support SOCKS(5) proxy servers.

The (BSD) netcat (nc) `-X` means to use the HTTP(S) CONNECT protocol proxy.

> See the IBM z/OS OpenSSH User's Guide for more information.

I don't have convenient access to that document.  Though I should find a
copy as I hope it's as interesting as it could be.



--
Grant. . . .
unix || die

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

netcat for z/OS?

[Frank Swarbrick]

Is there a netcat or netcat-like tool for z/OS?  Something that can connect to 
an HTTP proxy?
The goal is to tunnel an SSH session through an HTTPS proxy.  For example, this 
works on Linux:

ssh -o "ProxyCommand nc -X connect -x myproxy:3128 %h %p" g...@ssh.github.com 
-p 443
I need nc or something similar on z/OS.  I did find something called NC110-OMVS 
on github, but I would need to have a license for the C compiler to build it; 
which I do not have.  There is a "binaries" directory with just 'nc' in it, but 
it doesn't appear to be in z/OS executable format...

There's also one written in Go, so maybe that's a possibility, but if there's 
something already built that would be great.

Thanks,
Frank

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

SSH tunneling for unattended process.

[Frank Swarbrick]

We're looking at using an SSH tunnel (or reverse tunnel) to encrypt a 
connection where the application on the other end does not support TLS.  The 
POC looks to be working.  I am now pondering on the steps required to make 
setting up the tunnel an automated process.  It seems to me that we'd want the 
z/OS user to be a "protected" user (NOPASSWORD/NOPHRASE/NOOIDCARD).  Would this 
require that we use SSH host based authentication?  I imagine that the user 
would require an OMVS segment.  I wonder if it would need a shell or home 
directory.  Any other thoughts?

Thanks,
Frank


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

Re: Dataset File System

[Frank Swarbrick]

Has anyone used sftp or scp to access an MVS dataset through DSFS?
I can't see any reason it wouldn't work.

From: IBM Mainframe Discussion List  on behalf of 
Lionel B Dyck 
Sent: Friday, December 22, 2023 4:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Dataset File System

I’ve experimented with it and found it has great potential.  I also wrote this 
https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/lionel-dyck2/2023/10/20/data-set-file-system-aka-dsfs-simplified-administr

Lionel B. Dyck <
Website: GitHub.com/lbdyck
Sent from my iPhone 15 Pro

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

> On Dec 22, 2023, at 5:37 PM, Frank Swarbrick  
> wrote:
>
> Has anyone made use of DSFS yet?  How do you like it?  Are there any caveats 
> or other weirdness?
> Frank
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Dataset File System

[Frank Swarbrick]

I'll give it a read.  Thanks!
Frank

From: IBM Mainframe Discussion List  on behalf of 
Lionel B Dyck 
Sent: Friday, December 22, 2023 4:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Dataset File System

I’ve experimented with it and found it has great potential.  I also wrote this 
https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/lionel-dyck2/2023/10/20/data-set-file-system-aka-dsfs-simplified-administr

Lionel B. Dyck <
Website: GitHub.com/lbdyck
Sent from my iPhone 15 Pro

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

> On Dec 22, 2023, at 5:37 PM, Frank Swarbrick  
> wrote:
>
> Has anyone made use of DSFS yet?  How do you like it?  Are there any caveats 
> or other weirdness?
> Frank
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Dataset File System

[Frank Swarbrick]

Has anyone made use of DSFS yet?  How do you like it?  Are there any caveats or 
other weirdness?
Frank

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

Re: VSAM GDG

[Frank Swarbrick]

Weird that it created generation 1 correctly (as a VSAM file), but only that 
generation seems to work.  Oh well!
Thanks,
Frank

From: IBM Mainframe Discussion List  on behalf of 
Richard McIntosh 
Sent: Tuesday, September 26, 2023 11:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: VSAM GDG

GDG's are for sequential files. You can make a backup of a VSAM to a sequential 
GDG though.
To create a new gen you should be using PROD.CVSC.AHI.BKP(+1)



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Tuesday, September 26, 2023 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] : VSAM GDG

Are VSAM GDGs supported?  I created the GDG base using the JCL below and was 
able to create the first generation, but when I run that job again it tries to 
create generation 1 again, giving me a JCL error because the GDS already exists.


//DEFGDG   JOB ,'DEFINE AHI GDG

//DEFINE   EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*

//SYSINDD  *

 DELETE (PROD.CVSC.AHI.BKP)

 IF MAXCC LE 8 THEN SET MAXCC=0

DEFINE GDG ( -

 NAME(PROD.CVSC.AHI.BKP) -

 LIMIT(5) -

 SCRATCH -

 )


Thanks,

Frank

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

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

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

VSAM GDG

[Frank Swarbrick]

Are VSAM GDGs supported?  I created the GDG base using the JCL below and was 
able to create the first generation, but when I run that job again it tries to 
create generation 1 again, giving me a JCL error because the GDS already exists.


//DEFGDG   JOB ,'DEFINE AHI GDG

//DEFINE   EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*

//SYSINDD  *

 DELETE (PROD.CVSC.AHI.BKP)

 IF MAXCC LE 8 THEN SET MAXCC=0

DEFINE GDG ( -

 NAME(PROD.CVSC.AHI.BKP) -

 LIMIT(5) -

 SCRATCH -

 )


Thanks,

Frank

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

Re: Unix file system ownership

[Frank Swarbrick]

Yes.

I have no idea.  I certainly wouldn't know how to do something "backdoor" with 
this.

Yes.  Me.

From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, June 14, 2023 3:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Unix file system ownership

On Wed, 14 Jun 2023 20:12:45 +, Frank Swarbrick  wrote:

>Well this was easy.  My security admin gave my production user the same UID 
>value as in test/dev and everything fell in to place.
>
Are the TSO IDs the same?

Does this give your test/dev user a back door to your production system?

Are these the same person?

--
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: Unix file system ownership

[Frank Swarbrick]

Well this was easy.  My security admin gave my production user the same UID 
value as in test/dev and everything fell in to place.

As for having the same file system mounted in two different LPARs, well, it 
seems to work fine.  We are in a sysplex, I believe.  In any case nothing 
"important" is going to be done with this file system, so I'm comfortable with 
what I have, even if it isn't 100% kosher.

From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Wednesday, June 14, 2023 12:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Unix file system ownership

I'm guessing this is hopeless, but figured I'd ask anyway.
For "some reason" we have separate RACF databases for each of our environments 
(dev/test vs production).  Because of this (I think it's the reason!) my Unix 
UID is different in production than in dev/test.  This means that even though 
my personal Unix file system is mounted at the same mount point in each, only 
in one of them (dev/test) do I technically "own" it.  I'm wondering if there 
might be some way I can "own" it in both systems.  Can UIDs be explicitly set 
to a particular value?  Or can one be mapped to another?  Or something else?


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

Unix file system ownership

[Frank Swarbrick]

I'm guessing this is hopeless, but figured I'd ask anyway.
For "some reason" we have separate RACF databases for each of our environments 
(dev/test vs production).  Because of this (I think it's the reason!) my Unix 
UID is different in production than in dev/test.  This means that even though 
my personal Unix file system is mounted at the same mount point in each, only 
in one of them (dev/test) do I technically "own" it.  I'm wondering if there 
might be some way I can "own" it in both systems.  Can UIDs be explicitly set 
to a particular value?  Or can one be mapped to another?  Or something else?


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

Re: Kafka

[Frank Swarbrick]

Ah, I should have known I'd get a "systems" answer.  I am wondering about user 
applications usage.
Frank

From: IBM Mainframe Discussion List  on behalf of 
Matt Hogstrom 
Sent: Wednesday, June 7, 2023 9:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Kafka

For SMF data, Console Logs and other operational data the ones I’m familiar 
with are:

IBM Common Data Provider
Precisely IronStream (formerly SyncSort)
Broadcom has the means to forward data through their CA Common Services


Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook <https://facebook.com/matt.hogstrom>  LinkedIn 
<https://linkedin/in/mhogstrom>  Twitter <https://twitter.com/hogstrom>

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom



> On Jun 6, 2023, at 4:00 PM, Frank Swarbrick  
> wrote:
>
> Does anyone publish messages to Kafka from z/OS?  If so, what technology do 
> you use?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

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

Kafka

[Frank Swarbrick]

Does anyone publish messages to Kafka from z/OS?  If so, what technology do you 
use?

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

Re: COBOL Field Length problem

[Frank Swarbrick]

I'm going to go out on a limb and say it's a compiler bug.  I recreated the 
issue (with this program) with both V6.3 and V6.4.

I also "solved" the issue by using BYTE-LENGTH instead of LENGTH.  But that's 
just a work-around, of course.  So you need to open a CASE with IBM to get it 
fixed.

From: IBM Mainframe Discussion List  on behalf of 
Binyamin Dissen 
Sent: Wednesday, May 24, 2023 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: COBOL Field Length problem

My next step would be to look at the generated code to see if it is using the
right element. I am not super trustful of compilers.

On Wed, 24 May 2023 16:25:21 + Billy Ashton 
wrote:

:>Hey everyone - back again with another COBOL problem. Your help with my
:>COPY REPLACING question was great and the programmer is quite happy with
:>that solution. Now, he came to me with what looks like a problem, and I
:>am not sure if we are doing something wrong, or if it is a bug in our
:>Enterprise COBOL for z/OS  6.3.0 P220314 system.
:>
:>In a nutshell, when using the LENGTH(TRIM(some-field)) function against
:>any elementary data item, it works great. However, when using it against
:>an item within an occurs (think data table), every reference beyond 1
:>gets handled as item #1. For example, if I have a group with 8 items,
:>the length of item #1 is right, but the length of item(2) through
:>item(8) is always the value of item(1). The table index can be display
:>numeric, packed, or binary, and the results are the same, so I don't
:>think it is a problem with the index, but somehow the reference is not
:>resolved correctly within the nested function.
:>
:>Maybe a short program would be helpful. I hope a 60 line program is ok!
:>Let me know what you think is happening.
:>
:>IDENTIFICATION DIVISION.
:>PROGRAM-ID. TSTPG002.
:>ENVIRONMENT DIVISION.
:>Configuration   Section.
:>Repository.
:>Function  All  Intrinsic.
:>DATA DIVISION.
:>WORKING-STORAGE SECTION.
:>01  WS.
:>05  INL-NO  PIC S9(08)  VALUE ZERO BINARY.
:>05  INL-I1  PIC S9(08)  VALUE ZERO BINARY.
:>05  INL-I2  PIC S9(08)  VALUE ZERO BINARY.
:>05  INL-H   PIC S9(08)  VALUE ZERO BINARY.
:>05  IN-GRP-X.
:>10  L1 PIC X(65) VALUE '* THIS_IS_A_COMMENT Here .28'.
:>10  L2 PIC X(65) VALUE SPACE.
:>10  L3 PIC X(65) VALUE 'COMND   VALUE1 17'.
:>10  L4 PIC X(65) VALUE 'COMND   VALUE2 21'.
:>10  L5 PIC X(65) VALUE '  COMND VALUE3 21'.
:>10  L6 PIC X(65) VALUE 'COMND VALUE4 15  '.
:>10  L7 PIC X(65) VALUE ' COMND  VAL* 27 '.
:>10  L8 PIC X(65) VALUE '* THIS_IS_A_COMMENT... 29'.
:>05   REDEFINES IN-GRP-X  OCCURS 8.
:>10  IN-LINE PIC  X(65).
:>05  Hold-L  PIC  X(65).
:>05  I1  PIC S9(08)  VALUE ZERO Binary.
:>05  I2  PIC S9(08)  VALUE ZERO.
:>
:>PROCEDURE DIVISION.
:>PERFORM VARYING I1 FROM 1 BY 1 UNTIL I1 GREATER 8
:>Move I1 to I2
:>Move In-line(I1) to Hold-L
:>Display I1 '  '
:>'+1+2+3+4'
:>'+5+6+'
:>Display '   Original: >' IN-LINE(I1) '<'
:>Display '   Trim: >' Trim(In-line(I1) Trailing) '<'
:>Compute INL-I1 = Length(Trim(In-line(I1) Trailing))
:>Compute INL-I2 = Length(Trim(In-line(I2) Trailing))
:>Compute INL-H  = Length(Trim(Hold-L  Trailing))
:>Evaluate TRUE
:>  When I1 = 1 Compute INL-NO = Length(Trim(L1 Trailing))
:>  When I1 = 2 Compute INL-NO = Length(Trim(L2 Trailing))
:>  When I1 = 3 Compute INL-NO = Length(Trim(L3 Trailing))
:>  When I1 = 4 Compute INL-NO = Length(Trim(L4 Trailing))
:>  When I1 = 5 Compute INL-NO = Length(Trim(L5 Trailing))
:>  When I1 = 6 Compute INL-NO = Length(Trim(L6 Trailing))
:>  When I1 = 7 Compute INL-NO = Length(Trim(L7 Trailing))
:>  When Other  Compute INL-NO = Length(Trim(L8 Trailing))
:>End-Evaluate
:>Display '   Lengths:'
:>'   I1(' INL-I1 ')'
:>' I2(' INL-I2 ')'
:>' Hold(' INL-H ')'
:>' By name(' INL-NO ')'
:>Display ' '
:>END-PERFORM
:>GOBACK.
:>
:>Thank you and best regards,
:>Billy Ashton
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu 

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

[Frank Swarbrick]

What was the release date on that?

From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Sunday, May 21, 2023 1:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

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

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

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: XLC version? [was: RE: XLC - Weak symbols]

[Frank Swarbrick]

Is it bad because it's slow, or some other reason(s)?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Wednesday, May 10, 2023 5:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC version? [was: RE: XLC - Weak symbols]

> On 11 May 2023, at 6:25 am, Frank Swarbrick  
> wrote:
> 
> Has anyone here ever used X11 under z/OS?

Yes, it sucks! I don’t see the point of in in 2023 where almost all GUI 
applications are browser based progressive web applications. Even IDE’s like VS 
Code are HTML/TypeScript and built with Electron. ChromeOS is a Linux 
distribution which uses Google Chrome as it’s principle UI.

> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Seymour J Metz
> Sent: Wednesday, May 10, 2023 12:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: XLC version? [was: RE: XLC - Weak symbols]
> 
> Current versions of, e.g., bash, go, ooRexx, perl, python, ruby, rust, x11.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Farley, Peter 
> [031df298a9da-dmarc-requ...@listserv.ua.edu]
> Sent: Wednesday, May 10, 2023 12:34 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: XLC version? [was: RE: XLC - Weak symbols]
> 
> "Install bash" is not a possibility in some shops.  IBM needs to make bash 
> available (and supported) in ALL delivered/updated z/OS systems, as a 
> standard part of z/OS, so that there is no choice in the matter.  Ditto for 
> all the other necessary GNU utilities of course.
> 
> Again, just my USD$0.02.
> 
> Peter
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Phil Smith III
> Sent: Wednesday, May 10, 2023 12:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: XLC version? [was: RE: XLC - Weak symbols]
> 
> Peter Farley wrote:
>> Well, if Open XL C/C++ is the "wave of the future" then IBM had 
>> better plan to also buy and integrate all of Rocket's GNU ports 
>> (especially
>> bash) because I for one can NOT work in that @#$%!^ POSIX "sh" they 
>> supply at the moment. It is a hideous shell to try to work in. It 
>> does not even support using the arrow keys to recall previous 
>> commands, the backspace key does not work to let you fix command text 
>> . . . I could go on, but what's the point. It is just plain awful.
> 
> Install bash and use that. Not disagreeing, it *is* awful. if IBM is still 
> serious about USS they need to spend a (relatively) SMALL amount of effort to 
> add standard things like bash, curl, and dos2unix. It's a huge blocker to 
> anyone trying to do real work there.
> --
> 
> 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

--
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 version? [was: RE: XLC - Weak symbols]

[Frank Swarbrick]

Has anyone here ever used X11 under z/OS?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, May 10, 2023 12:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC version? [was: RE: XLC - Weak symbols]

Current versions of, e.g., bash, go, ooRexx, perl, python, ruby, rust, x11.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, May 10, 2023 12:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC version? [was: RE: XLC - Weak symbols]

"Install bash" is not a possibility in some shops.  IBM needs to make bash 
available (and supported) in ALL delivered/updated z/OS systems, as a standard 
part of z/OS, so that there is no choice in the matter.  Ditto for all the 
other necessary GNU utilities of course.

Again, just my USD$0.02.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, May 10, 2023 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC version? [was: RE: XLC - Weak symbols]

Peter Farley wrote:
>Well, if Open XL C/C++ is the "wave of the future" then IBM had better 
>plan to also buy and integrate all of Rocket's GNU ports (especially
>bash) because I for one can NOT work in that @#$%!^ POSIX "sh" they 
>supply at the moment. It is a hideous shell to try to work in. It does 
>not even support using the arrow keys to recall previous commands, the 
>backspace key does not work to let you fix command text . . . I could 
>go on, but what's the point. It is just plain awful.

Install bash and use that. Not disagreeing, it *is* awful. if IBM is still 
serious about USS they need to spend a (relatively) SMALL amount of effort to 
add standard things like bash, curl, and dos2unix. It's a huge blocker to 
anyone trying to do real work there.
--

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

[Frank Swarbrick]

Adding the space causes the opposite problem; the valueOpt field ends with two 
parens instead of none.

I'm not the author; I'm just trying to fix it!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Tuesday, May 2, 2023 7:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX parse parens

> On 2 May 2023, at 7:30 am, Frank Swarbrick  
> wrote:
> 
> Parse Var option varOpt '(' valueOpt ‘)’



Adding an extra space after the closing parenthesis can help as a workaround.

Parse Var option varOpt '(' valueOpt ‘) ‘

Parse is good for simple text yanking but it’s not match for regular 
expressions or PEGs.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: REXX parse parens

[Frank Swarbrick]

I don't want a separate "member" value.  I want the full "TEST(MEMBER)".
This is what I have now, and it seems to work OK:

Parse Var option varOpt '(' valueOpt ')'
/* Add back closing paren, if there is a leading one */
If POS("(", valueOpt) \= 0 Then
  valueOpt = valueOpt')'


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jack Zukt
Sent: Tuesday, May 2, 2023 1:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX parse parens

Hi
This should work

Parse arg opt
Parse value opt with "(" opt") "
If  pos(" (", opt) >0 then
Parse value opt with opt" ("member")"
Do
End

Regards
Jack

On Tue, May 2, 2023, 00:31 Frank Swarbrick 
wrote:

> The following is a simplified version of some code from IBM's 
> CEEBLDTX, placed in to an EXEC I've named PARENS:
>
> Parse Arg option
> Parse Var option varOpt '(' valueOpt ')'
> Say varOpt
> Say valueOpt
>
> This handles a simple dataset name, e.g.:
>
> Test1:  PARENS COBOL(TEST):
> Results1:
> COBOL
> TEST
>
> But it doesn't work for a PDS member to following, also surrounded by
> parentheses:
>
> Test2:  PARENS COBOL(TEST(MEMBER))
> Results2:
> COBOL
> TEST(MEMBER
>
> Any simple REXX parse option to handle this, or do I need to resort to 
> more complex REXX?  Or do I just add a trailing paren if there is a 
> leading one in valueOpt?  Perhaps that's the simples answer.
>
> Frank
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

REXX parse parens

[Frank Swarbrick]

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

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

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

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

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

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

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

Frank


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

Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?]

[Frank Swarbrick]

The example has two bugs in it (a typo and a repeated line), but fixing those 
it does appear to work.  A better test would have been to compress something 
other than just binary zeroes, and also to re-init the "input" (now output) 
area so you can actually "see" it work (in the debugger).  Pretty cool 
nonetheless.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Wednesday, April 26, 2023 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: 
Unzip on z/OS ?]

An off-list communication from another interested party pointed me to this link 
to the online Enterprise COBOL Programmers Guide V6.4, which has exactly the 
documentation I have been requesting, at least for COBOL programmers:

Chapter 36. Using zlib compression from a COBOL program 
https://www.ibm.com/docs/en/cobol-zos/6.4?topic=processing-using-zlib-compression-from-cobol-program

I checked my previously saved COBOL PDF's for V6.2 and it is there as well.

Interestingly the latest PL/I Programmers Guide (V6.1) has no reference to zlib 
at all, and the last published VS Fortran documents (all of which are dated 
1993) of course have no references to it.

I will be updating my RCF to ask that the MVS manual at least reference the 
COBOL Programmer's Guide and chapter title as an example of non-C-language 
access to these functions.  I'm certain that any competent PL/I or Fortran 
programmer could figure out what to do in their language from the COBOL example.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Tuesday, April 25, 2023 5:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: 
Unzip on z/OS ?]

To be more clear: I am asking for examples of non-C-language un-authorized HLL 
calls to the "zlib" un-authorized functions and a list of any COPY/INCLUDE 
members necessary to accomplish those calls, not the zEDC authorized functions 
nor the hardware-level DFLTCC instruction.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Tuesday, April 25, 2023 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to call zEDC functions from an HLL other than C [was: RE: Unzip on 
z/OS ?]

I submitted an RCF on the subject of examples for actually using zEDC functions 
from HLL's other than C not long after this message chain and received no 
response at all from the RCF team.  A follow-up email requesting status or at 
least an acknowledgement that the documentation addition suggestion had been 
received did get a response, which was:

"Thank you for reaching out to IBM about your experience with our Documentation 
feedback.

A response is not provided for feedback sent to your product’s documentation 
team. All comments are received and evaluated to help improve the content 
experience.  Any resulting updates to the product documentation are then 
reflected in the current release of the product. Any issues that require a 
response should go through IBM support."

Since neither the zEDC redbook to which Tom Harper posted a link nor the MVS 
Callable Services for HLL's manual have any examples of how to ACTUALLY use 
zEDC functions from any HLL except C, has anyone on this list actually coded 
invocation of zEDC services from an HLL other than C who is willing (and is 
permitted) to share how they accomplished that task?

Since IBM hasn't documented it (at least not so far) I guess we have to do it 
ourselves.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Tuesday, April 4, 2023 2:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unzip on z/OS ?

You are probably right about that.  I will start one and see what they reply.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Tuesday, April 4, 2023 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unzip on z/OS ?

A similar issue happened with BPXWDYN. COBOL can't set R0. So a new entry point 
in BPXWDYN was created that handled that problem.

This all started with me writing an RCF to tell them that they didn't have a 
COBOL example. Then a C programmer (I'm guessing) wrote the COBOL code. You can 
write c in any language (one of those type of things). Problem is, it would 
confuse most COBOL programmers that, well, it would confuse most COBOL 
programmers, and so I suggested a few changes to solve the issue. Then one of 
their own people onfirmed what I said, it would be confusing to most COBOL 
programmers. And so it appears that IBM doesn't have many product developers 
that actually know COBOL. That has been my take-away from that exchange.

So you may need to do an RCF, and you may go a few rounds with them.

Just say'n'.

Steve Thompson

On 4/4/2023 1:46 PM, Farley, Peter wrote:
> The V2R5 Callable Services manual 

Re: Card processing application

[Frank Swarbrick]

I've been working with the CV Systems card system (as a client) for over 20 
years, if you have any questions.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
rpinion865
Sent: Tuesday, April 25, 2023 6:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Card processing application

Take a look at 

https://cvsystems.com/cv-payment-processing/




Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, April 25th, 2023 at 7:55 AM, Radoslaw Skorupka 
<0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:


> I'm looking for card processing application.
> I mean a system which support ATMs, POS (shop terminals), customers 
> PIN & account verification, etc.
> (note, full core-banking system is not an option).
> Oh, z/OS based. :-)
> 
> --
> 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: Cobol calling module with non alphanumeric no longer allowed???

[Frank Swarbrick]

Quite odd, I'll say.  But at least I have an answer.  Thanks!
I wonder why LONGUPPER has the restrictions it does.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Monday, April 10, 2023 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

Ah, I'm compiling with PGMNAME(COMPAT).


And I misread the documentation for PGMNAME(LONGUPPER). This behavior is 
conforming to the documentation. It says that PGMNAME(COMPAT) can contain 
national characters:

"All the characters used in the name must be alphabetic, digits, the hyphen, or 
the underscore, except that if the program-name is a literal and is in the 
outermost program, then the literal can also contain the extension characters 
@, #, and $, and the first character can be an underscore."

And that for PGMNAME(LONGMIXED) it can contain any character in the range x'41' 
- x'FE',

But PGMNAME(LONGUPPER) only allows for alphabetic, digits, hyphen, underscore. 
@, #, $ are not alphabetic.


What's interesting is that PGMNAME(COMPAT) says that:

If the first character is not alphabetic, and is not an underscore, it is 
converted as follows:
- 1-9 are translated to A-I.
- Anything else is translated to J.

I think this is a documentation error. You can call literal to a name like 
'@SESTEST' without conversion, and you can use it as a program id as long as it 
is in quotes.


It is true that it *used to be* that you couldn't have a program-id starting 
with @. I don't know at what point that restriction was lifted. Maybe with IBM 
COBOL?


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Monday, April 10, 2023 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

Interesting.  Apparently it works for both PGMNAME(COMPAT) and 
PGMNAME(LONGMIXED), but not for PGMNAME(LONGUPPER), which is what we are using.

  19 001600 procedure division.
  20 001610 call '@SEPTEST' 
  EXT

==20==> IGYPS0025-E Name "'@SEPTEST'" was invalid.  It was processed as 
"0SEPTEST".

==20==> IGYPG0020-W Name "0SEPTEST" was processed as "JSEPTEST".

  21 001700 goback.

Sounds like a bug.  Though unlike what I said, E.COBOL v4.2 has the same issue. 
 The difference for me was we had 4.2 set with PGMNAME(COMPAT) while 5+ we have 
PGMNAME(LONGUPPER).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Monday, April 10, 2023 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

A call to '@SEPTEST' compiles for me with both DYNAM and NODYNAM on COBOL for 
z/OS 6.20. Per the PGMNAME compile option, this is allowed in all settings of 
that option.

What do you have for FLAGSTD?

Can you post the exact compile error?

Note that such a program id would need to be enclosed in quotes for that to 
compile.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Saturday, April 8, 2023 1:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

I am indeed using DYNAM.

I have no great need for this to work.  Just something I noticed and was 
curious about.

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 7, 2023 11:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

Not true for non-static calls.  We are past COBOL 5 (V6.2 at the moment) and 
"CALL variable USING . . . " where "variable" has any of the "national" 
characters ($#@) works every time.  We have multiple dynamically called utility 
subroutines with those characters in the program name.

Why in the world are you using literal calls?  Or are you using the DYNAM 
option to convert literal calls to dynamic ones?  If so, bite the bullet - 
convert them to "CALL variable" and you are done.

The only legitimate case I have seen for using literal CALL's is when you are 
using nested subroutine programs in the same source file as the calling program.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Friday, April 7, 2023 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cobol calling module with non alphanumeric no longer allowed???

I've tried calling modules (that exist!) with both '@' and '#' signs in them 
and Enterprise COBOL 5+ does not allow this.  COBOL 4 allowed this.  Is there 
any good reason why this is the case?
--

This message and any attachments are inten

Re: Language Environment custom messages

[Frank Swarbrick]

I thought I had, but apparently not!  Now working.  Thanks.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rupert Reynolds
Sent: Monday, April 10, 2023 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Language Environment custom messages

I'm not familiar with these custom messages, but have you tried a trailing "." 
i.e. ":newline."? Only a hunch, mind you...

Rexx

On Mon, 10 Apr 2023, 17:46 Frank Swarbrick, 
wrote:

> At
> https://www.ibm.com/docs/en/zos/2.5.0?topic=cm-creating-message-source
> -file is documented creating of a "message source file" for custom LE 
> messages.
> Is anyone besides me using this?  I am having an issue with the ":newline"
> not seeming to do anything at all, and definitely not what it appears 
> to be documented as doing.  Specifically "The :newline. tag creates a 
> new message line that can be used for multiline messages." My 
> observation is that it neither creates a new message line nor does it 
> insert any control characters that would represent the beginning of a new 
> line.
>
> Here's an example message configuration:
>
> :msgno.1010
> :msgsubid.1
> :msgname.AIB-Results
> :msgclass.I
> :msg.DL/I AIB call, unexpected rtn/rsn
> :tab.+1
> :ins 1.
> :msg./
> :ins 2.
> :msg. (
> :ins 3.
> :msg./
> :ins 4.
> :msg.) for args:
> :newline
> :ins 5.
> :tab.+1
> :ins 6.
> :tab.+1
> :ins 7.
> :msg..
>
> This should (to my understanding!) start insert 5 on a new line, but 
> it is not doing so.  No space, no control character, no nothing 
> between the colon in "args:" and the value of insert #5.
>
> -
>

--
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: Language Environment custom messages

[Frank Swarbrick]

Cancel.
I missed the period after ":newline".
I swear I tried that before, but I guess not.

Any time I want to solve a simple problem I just need to post to the list then 
try something else after that and it works!  Or so it seems.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Monday, April 10, 2023 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Language Environment custom messages

At https://www.ibm.com/docs/en/zos/2.5.0?topic=cm-creating-message-source-file 
is documented creating of a "message source file" for custom LE messages.  Is 
anyone besides me using this?  I am having an issue with the ":newline" not 
seeming to do anything at all, and definitely not what it appears to be 
documented as doing.  Specifically "The :newline. tag creates a new message 
line that can be used for multiline messages." My observation is that it 
neither creates a new message line nor does it insert any control characters 
that would represent the beginning of a new line.

Here's an example message configuration:

:msgno.1010
:msgsubid.1
:msgname.AIB-Results
:msgclass.I
:msg.DL/I AIB call, unexpected rtn/rsn
:tab.+1
:ins 1.
:msg./
:ins 2.
:msg. (
:ins 3.
:msg./
:ins 4.
:msg.) for args:
:newline
:ins 5.
:tab.+1
:ins 6.
:tab.+1
:ins 7.
:msg..

This should (to my understanding!) start insert 5 on a new line, but it is not 
doing so.  No space, no control character, no nothing between the colon in 
"args:" and the value of insert #5.

--
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 calling module with non alphanumeric no longer allowed???

[Frank Swarbrick]

Interesting.  Apparently it works for both PGMNAME(COMPAT) and 
PGMNAME(LONGMIXED), but not for PGMNAME(LONGUPPER), which is what we are using.

  19 001600 procedure division. 
  
  20 001610 call '@SEPTEST' 
  EXT 

  
==20==> IGYPS0025-E Name "'@SEPTEST'" was invalid.  It was processed as 
"0SEPTEST".   

  
==20==> IGYPG0020-W Name "0SEPTEST" was processed as "JSEPTEST".
  

  
  21 001700 goback. 
  

Sounds like a bug.  Though unlike what I said, E.COBOL v4.2 has the same issue. 
 The difference for me was we had 4.2 set with PGMNAME(COMPAT) while 5+ we have 
PGMNAME(LONGUPPER).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Monday, April 10, 2023 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

A call to '@SEPTEST' compiles for me with both DYNAM and NODYNAM on COBOL for 
z/OS 6.20. Per the PGMNAME compile option, this is allowed in all settings of 
that option.

What do you have for FLAGSTD?

Can you post the exact compile error?

Note that such a program id would need to be enclosed in quotes for that to 
compile.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Saturday, April 8, 2023 1:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

I am indeed using DYNAM.

I have no great need for this to work.  Just something I noticed and was 
curious about.

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 7, 2023 11:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

Not true for non-static calls.  We are past COBOL 5 (V6.2 at the moment) and 
"CALL variable USING . . . " where "variable" has any of the "national" 
characters ($#@) works every time.  We have multiple dynamically called utility 
subroutines with those characters in the program name.

Why in the world are you using literal calls?  Or are you using the DYNAM 
option to convert literal calls to dynamic ones?  If so, bite the bullet - 
convert them to "CALL variable" and you are done.

The only legitimate case I have seen for using literal CALL's is when you are 
using nested subroutine programs in the same source file as the calling program.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Friday, April 7, 2023 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cobol calling module with non alphanumeric no longer allowed???

I've tried calling modules (that exist!) with both '@' and '#' signs in them 
and Enterprise COBOL 5+ does not allow this.  COBOL 4 allowed this.  Is there 
any good reason why this is the case?
--

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

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

Re: Cobol calling module with non alphanumeric no longer allowed???

[Frank Swarbrick]

I agree that you should be able to do dynamic calls under CICS to any routine, 
and only the EXEC CICS commands need be static.  In fact, even EXEC SQL can do 
dynamic calls if you define the appropriate entry point (DSNHLI or DSNHLI2, I 
believe) as a "program".  Program auto-install would likely help (though we 
don't use it ourselves at the moment).

Also worth noting that if you use the newish COBOL compiler directive 
">>CALLINTERFACE DYNAMIC" you can even use CALL literal to get dynamic calls 
under CICS.  Only EXEC CICS and, I believe, EXEC SQL would remain static calls. 
 (The "dynamic" SQL calls I refer to above are for programs without any EXEC 
CICS statements, and thus compiled using "batch rules" instead of CICS.)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Sunday, April 9, 2023 12:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

The only CICS routines that MUST be statically linked are the DFH 
subroutines that are called as the result of coding CICS commands like EXEC 
CICS LINK or EXEC SQL SELECT.  AFAIK, any user-written program can be defined 
to RDO including those with national characters ($#@) in the name.

I am curious, in what case(s) do you believe that a callable subroutine could 
NOT be definable in RDO?

Unless it is for very high frequency user programs where maximum performance is 
critical, statically linked functional subroutines (under CICS or not) are a 
maintenance nightmare, because when (not if) those subroutines need to change, 
whether for new function or for defect repair, EVERY program that statically 
linked them must be re-linked and (more costly and more critically) MUST be 
re-tested for quality assurance.

And even for high performance requirements, the EXEC CICS LINK (or better, a 
plain COBOL CALL variable-name, even under CICS) has a fairly efficient path to 
execute already-loaded subroutines, and if they are being used frequently they 
are almost surely already loaded in memory.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Sunday, April 9, 2023 2:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

The other reason for the literal calls is because one wants the load module to 
have the subroutines statically linked that the COBOL program is using. In this 
way there is no LOAD done during execution time because COBOL "knows" that 
these are statically linked.

There are a few reasons to want this behavior.

The major one that comes to mind is you have to have static linkage for running 
in a CICS environment because the subroutines are not CICS definable (RDO) and 
so have to be statically linked.

Steve Thompson

On 4/8/2023 1:50 AM, Farley, Peter wrote:
> Not true for non-static calls.  We are past COBOL 5 (V6.2 at the moment) and 
> "CALL variable USING . . . " where "variable" has any of the "national" 
> characters ($#@) works every time.  We have multiple dynamically called 
> utility subroutines with those characters in the program name.
>
> Why in the world are you using literal calls?  Or are you using the DYNAM 
> option to convert literal calls to dynamic ones?  If so, bite the bullet - 
> convert them to "CALL variable" and you are done.
>
> The only legitimate case I have seen for using literal CALL's is when you are 
> using nested subroutine programs in the same source file as the calling 
> program.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Frank Swarbrick
> Sent: Friday, April 7, 2023 6:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Cobol calling module with non alphanumeric no longer allowed???
>
> I've tried calling modules (that exist!) with both '@' and '#' signs in them 
> and Enterprise COBOL 5+ does not allow this.  COBOL 4 allowed this.  Is there 
> any good reason why this is the case?
--

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

Language Environment custom messages

[Frank Swarbrick]

At https://www.ibm.com/docs/en/zos/2.5.0?topic=cm-creating-message-source-file 
is documented creating of a "message source file" for custom LE messages.  Is 
anyone besides me using this?  I am having an issue with the ":newline" not 
seeming to do anything at all, and definitely not what it appears to be 
documented as doing.  Specifically "The :newline. tag creates a new message 
line that can be used for multiline messages." My observation is that it 
neither creates a new message line nor does it insert any control characters 
that would represent the beginning of a new line.

Here's an example message configuration:

:msgno.1010
:msgsubid.1
:msgname.AIB-Results
:msgclass.I
:msg.DL/I AIB call, unexpected rtn/rsn
:tab.+1
:ins 1.
:msg./
:ins 2.
:msg. (
:ins 3.
:msg./
:ins 4.
:msg.) for args:
:newline
:ins 5.
:tab.+1
:ins 6.
:tab.+1
:ins 7.
:msg..

This should (to my understanding!) start insert 5 on a new line, but it is not 
doing so.  No space, no control character, no nothing between the colon in 
"args:" and the value of insert #5.

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

Re: Call by value, final

[Frank Swarbrick]

__getcb  alias c'@@GETCB'

This works with
 call __getcb,(3)

But is rather pointless, I suppose, since I can just call @@GETCB directly.

I can also use:
__getcb  alias c'__getcb'

This also seems to assemble properly, but the binder can't find __getcb.  Which 
I sort of understand, because as you say, @@GETCB is the external name.

However in COBOL it works, because of some sort of rename process I don't 
understand.


  0 2610 CEEBPIRC   LABEL

*** M O D U L E  M A P ***



SECTIONCLASS  --- SOURCE 

OFFSET   OFFSET  NAMETYPELENGTH  DDNAME   SEQ  MEMBER





28B0  @@GETCB *  CSECT A  SYSLIB02  @@GETCB



  ***  DATA SET SUMMARY  ***



DDNAMECONCAT   FILE IDENTIFICATION



DSNLOAD 01 SYS3.ZOSD.DSN1.SDSNLOAD

SYSLIB  02 SYS1.SCEELKED

SYSLIN  02 CICS.CTS540.RSU2212.SDFHLOAD

SYSLIN  04 SYS23098.T101939.RA000.DVFJSC.OBJMOD.H02

 ***  RENAMED SYMBOL CROSS REFERENCE  ***

 -

 RENAMED SYMBOL

   SOURCE SYMBOL

 -



 @@GETCB

   __getcb



 ***  END OF RENAMED SYMBOL CROSS REFERENCE  ***

I don't know how the symbol rename process is invoked.


From: IBM Mainframe Discussion List  on behalf of 
Tony Harminc 
Sent: Saturday, April 8, 2023 8:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Call by value, final

On Sat, 8 Apr 2023 at 00:27, Frank Swarbrick
 wrote:
>
> For those interested, the following calls C function "@@GETCB" ( int 
> __getcb(int); ) passing the fullword 3 by value.  There are several 
> alternatives, as discussed earlier, but this is what I am going with.
>
> ***
> *  see if we're running under cics by calling @@GETCB with fullword   *
> *  value 3 (call by value).   *
> ***
>  ceedsa ,
>  ceecaa ,
> iscics   ceeentry main=NO
>  call  @@GETCB,(3)
>  ceeterm RC=(15)
> ppa  ceeppa ,
>  end   iscics
>
> Note:  __getcb() and @@GETCB are the same routine.  I couldn't figure out how 
> to get a lower case call literal to work.  The assembler seems OK with it, 
> but the linker is converted to upper case, even though I've specified 
> CASE(MIXED).  Any thoughts on this are welcome, even though it's working fine 
> as-is.  Using lowercase literals in this manner is allowed in COBOL, even, 
> with "PGMNAME(mIxEdCaSe)".

What goes wrong if you specify

call __getcb ?

You say "the linker is converted to upper case" - not sure what that
means. What is converting what to upper case?

Maybe you need an ALIAS assembler statement. I've used it for long
external names, but I don't know about casing. It may be that the
library supplied external name just is @@GETCB .

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: Cobol calling module with non alphanumeric no longer allowed???

[Frank Swarbrick]

I am indeed using DYNAM.

I have no great need for this to work.  Just something I noticed and was 
curious about.

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 7, 2023 11:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

Not true for non-static calls.  We are past COBOL 5 (V6.2 at the moment) and 
"CALL variable USING . . . " where "variable" has any of the "national" 
characters ($#@) works every time.  We have multiple dynamically called utility 
subroutines with those characters in the program name.

Why in the world are you using literal calls?  Or are you using the DYNAM 
option to convert literal calls to dynamic ones?  If so, bite the bullet - 
convert them to "CALL variable" and you are done.

The only legitimate case I have seen for using literal CALL's is when you are 
using nested subroutine programs in the same source file as the calling program.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Friday, April 7, 2023 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cobol calling module with non alphanumeric no longer allowed???

I've tried calling modules (that exist!) with both '@' and '#' signs in them 
and Enterprise COBOL 5+ does not allow this.  COBOL 4 allowed this.  Is there 
any good reason why this is the case?
--

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

Call by value, final

[Frank Swarbrick]

For those interested, the following calls C function "@@GETCB" ( int 
__getcb(int); ) passing the fullword 3 by value.  There are several 
alternatives, as discussed earlier, but this is what I am going with.

***
*  see if we're running under cics by calling @@GETCB with fullword   *
*  value 3 (call by value).   *
***
 ceedsa ,
 ceecaa ,
iscics   ceeentry main=NO
 call  @@GETCB,(3)
 ceeterm RC=(15)
ppa  ceeppa ,
 end   iscics

Note:  __getcb() and @@GETCB are the same routine.  I couldn't figure out how 
to get a lower case call literal to work.  The assembler seems OK with it, but 
the linker is converted to upper case, even though I've specified CASE(MIXED).  
Any thoughts on this are welcome, even though it's working fine as-is.  Using 
lowercase literals in this manner is allowed in COBOL, even, with 
"PGMNAME(mIxEdCaSe)".

By the way, there's no great reason this particular "program" couldn't be coded 
in COBOL, PL/I or even C.  I have similar code, along with additional code, in 
another assembler program, which is why I wanted to know how to call by value.

If you are interested where I found @@GETCB for checking if running in a CICS 
environment, check the  C header file.

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

Re: Not aging well (know-it-alls)

[Frank Swarbrick]

The first one is iffy, but the second one can be absolutely true.  It's best to 
at least know when one doesn't know something.

From: IBM Mainframe Discussion List  on behalf of 
Matt Hogstrom 
Sent: Friday, April 7, 2023 7:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Not aging well (know-it-alls)

Your comment wasn’t directed at my but it made me think of two of my favorite 
phrases.

"I’m proud of my humility."

“I’m smart enough to know how dumb I can be.”

Enjoy the Easter weekend all y’all.

Matt Hogstrom

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom



>
> Are you also modest, or are you vain?


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

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: Cobol calling module with non alphanumeric no longer allowed???

[Frank Swarbrick]

Literal.  The compiler flags it as not allowed.

From: IBM Mainframe Discussion List  on behalf of 
Charles Hardee 
Sent: Friday, April 7, 2023 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Cobol calling module with non alphanumeric no longer allowed???

Are you doing a call literal or call dataname?

On Friday, April 7, 2023, Frank Swarbrick 
wrote:

> I've tried calling modules (that exist!) with both '@' and '#' signs in
> them and Enterprise COBOL 5+ does not allow this.  COBOL 4 allowed this.
> Is there any good reason why this is the case?
>
> --
> 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: Not aging well (know-it-alls)

[Frank Swarbrick]

Are you also modest, or are you vain?

From: IBM Mainframe Discussion List  on behalf of 
Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 7, 2023 4:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Not aging well (know-it-alls)

I don’t lie, cheat, steal, smoke, do drugs, drink alcohol. I do lots a charity, 
give huge tips, help animal shelters, and much much more.


Sent from Yahoo Mail for iPhone


On Friday, April 7, 2023, 4:26 PM, Mike Shaw  wrote:

On Fri, Apr 7, 2023, 1:02 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> <...snip...>

>  I know my character is flawless.

<...snip...>

Wow.

Mike Shaw
MVS/QuickRef Support
Chisoft

--
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: LE runtime

[Frank Swarbrick]

I've never had issues with inlined code when using IBM Debugger.  I've never 
explicitly checked its behavior, but I've never run in to an issue.  We use 
OPT(1) [for some probably bad reason not OPT(2)].

The only times I've seen the issue Tom is referring to are:

  1.  We backed out the latest production version and replaced it with the 
previous version.  We then can no longer see the source code of the failed 
(backed out) version.
  2.  When testing we've already implemented an updated version and are trying 
to analyze the dump from a prior version.

Using IBM Fault Analyzer for both.

I don't consider them to be huge problems, and certainly not a reason to, say, 
have multiple versions of the load module and/or debug information.  Just 
something to be aware of and live with, as little as it happens.

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 7, 2023 1:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: LE runtime

That would be a failure of your development lifecycle process.  Anything 
running in production MUST have compile listings available of the exact version 
running in production, and it doesn't hurt to retain the binder listing too.  
If you are still running an "older version" in production and you also have a 
newer version in production at the same time without retaining the older 
version listing somewhere, that's a process failure.

As for debugging production COBOL code, there are hurdles there too even if 
your listing is available.  In my experience, the compiler option INLINE 
(default for higher levels of OPTIMIZE) absolutely prevents interactively 
stopping in any inlined paragraph.  At least not using the CA Intertest 
debugger, which is all we have available to us at my employer's site, so I 
don’t know what the IBM debugger is capable of.

I have found that using compiler option TEST(SOURCE) in production compiles 
subtracts very little from optimization and greatly aids debugging of 
production code (except for INLINE's - nothing helps that except re-compiling 
in test with NOINLINE and hoping the bug doesn't disappear with the test 
version).

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Friday, April 7, 2023 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE runtime

Yes, it will. And if you are debugging an abend that occurred with an older 
version of the program, the listing is no longer available in the program 
object.

--
Tom Marchant

On Fri, 7 Apr 2023 18:33:18 +, Seymour J Metz  wrote:

>Won't that replace the NOLOAD segments with the new ones?
>
>
>--
>Shmuel (Seymour J.) Metz
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
>behalf of Tom Marchant [000a2a8c2020-dmarc-requ...@listserv.ua.edu]
>Sent: Friday, April 7, 2023 2:31 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LE runtime
>
>Until the program is recompiled and relinked.
>
>--
>Tom Marchant
>
>On Fri, 7 Apr 2023 10:48:04 -0700, Tom Ross  
>wrote:
>
>>With the
>>NOLOAD class program segmenets in new COBOL the debugging data is
>>always available, always in sync
--

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


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

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

Re: U4038 - IGZ0099C Internal error CLOSE-FIB was detected in module IGZ@QSAM.

[Frank Swarbrick]

I agree that it's likely a subscript range overflow.  I believe I had this same 
symptom for a program, and the cause was trying to write beyond my 
working-storage (because of attempting to subscript beyond the length of a 
table.)  It wiped out some file area control blocks and caused this error.

From: IBM Mainframe Discussion List  on behalf of 
Schmitt, Michael 
Sent: Friday, April 7, 2023 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: U4038 - IGZ0099C Internal error CLOSE-FIB was detected in module 
IGZ@QSAM.

Since no one else has answered, I'll speculate.

One possibility is that the file is fine, but it is driving application logic 
that is stomping on LE, leading to the internal error. If COBOL, try compiling 
with SSRANGE. And add the HEAPCHK(ON) LE runtime option, such as via CEEOPTS 
DD. HEAPCHK will check for damage to the heap control information at each call 
to a Language Environment heap storage management service. If damage is found, 
it will immediately abend with a U4042. (But it won't abend on the actual line 
that is causing the damage, since it only checks when LE services are used.)

If it is an actual file problem, what is the RECFM? If it is VB, perhaps 
there's something wrong with the file structure. Try dumping the block that 
contains the problem record and inspect the BDW and RDW. And, if you copy the 
file with a utility that does record level copies (such as IEBGENER, but not 
SYNCGENER!), does it fix it?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Crusty Old Guy
Sent: Friday, April 7, 2023 11:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: U4038 - IGZ0099C Internal error CLOSE-FIB was detected in module 
IGZ@QSAM.

I have a program that abends with a U4038 on file close.  This only happens 
when a specific record is on an input file.  No record, no problem.
This is from the dump -
IGZ0099C Internal error CLOSE-FIB was detected in module IGZ@QSAM.
>From compile unit  at entry point  at compile unit offset 
>+0B5A at entry offset +0B5A at address 7B5A.
 <> LEAID LEAID001I UNRECOGNIZED CEEMGET FEEDBACK CODE: 
x000301C259C3C5C50021

U4038 is usually associated with record or storage size. Is that correct?
How can one record alter the size of a storage or record size?

Regards,
COG

--
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: LE runtime

[Frank Swarbrick]

While this is true, in that you can't look at, say, Fault Analyzer if it's dump 
is for a previous version, even having a separate debug file won't generally 
save you from that.  Because you'd usually put the new version there as well.

From: IBM Mainframe Discussion List  on behalf of Tom 
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 7, 2023 12:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: LE runtime

Until the program is recompiled and relinked.

--
Tom Marchant

On Fri, 7 Apr 2023 10:48:04 -0700, Tom Ross  wrote:

>With the
>NOLOAD class program segmenets in new COBOL the debugging data is always
>available, always in sync

--
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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Frank Swarbrick]

No one knows as little as one who think's he knows it all.

From: IBM Mainframe Discussion List  on behalf of 
Doug 
Sent: Friday, April 7, 2023 12:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

"Seldom right, but never uncertain." Frank Reagan.

Describing you, I'd venture


Doug Fuerst


-- Original Message --
From: "Bill Johnson" <0047540adefe-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@listserv.ua.edu
Sent: 07-Apr-23 13:36:27
Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by
value]

>You don’t really understand Twitter do you? If I follow the WaPo, the NYT, the 
>Guardian, the LA Times, the Miami Herald, the Associated Press, Al Jazeera 
>English, NPR, PBS, BBC, and science magazines, scientists, journalists, 
>lawyers, and other fact based sources, it’s like subscribing to them all.
>
>Add in some comedy sources and that’s my Twitter feed.
>
>
>Sent from Yahoo Mail for iPhone
>
>
>On Friday, April 7, 2023, 10:32 AM, Doug  wrote:
>
>So you get your "news" from Twitter. For me, that explains ALOT!
>
>Doug Fuerst
>
>
>-- Original Message --
>From: "Bill Johnson" <0047540adefe-dmarc-requ...@listserv.ua.edu>
>To: IBM-MAIN@listserv.ua.edu
>Sent: 07-Apr-23 8:23:03
>Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by
>value]
>
>>I’ve read numerous articles and analysis that indicates LinkedIn has a 
>>problem with embellished & fake resumes. Here’s one.
>>
>>https://www.theguardian.com/commentisfree/2022/oct/29/linkedin-has-a-fake-profile-problem-can-it-fix-this-blot-on-its-cv
>>
>>I also don’t like having my information on the internet for all to see. I’m 
>>not on Facebook, Tiktok, Instagram, but do use Twitter to satisfy my news 
>>junkie inner self.
>>
>>
>>Sent from Yahoo Mail for iPhone
>>
>>
>>On Friday, April 7, 2023, 7:32 AM, Jeremy Nicoll 
>> wrote:
>>
>>On Fri, 7 Apr 2023, at 05:36, Bill Johnson wrote:
>>>   Yes Bill Johnson is my real name and I’ve never been on LinkedIn.
>>>   That’s just an ego trip and place where people like you go for
>>>   confirmation...
>>
>>I've certainly seen some people use it as an ego-trip, for "networking"
>>and - presumably - trying to increase their chances of finding work.
>>
>>I use LinkedIn as a useful place to find out more about people whom
>>I'm going to have contact with (in any sphere, certainly not just in
>>computing).  It's particularly useful when it's not entirely clear from
>>some company's website whether they've got tens/hundreds of
>>employees or just one person working from home. (In the UK) I also
>>look at Companies House registrations of companies, who the directors
>>are etc, and look at what else they're involved in, and especially if any
>>of their prior businesses have gone under or they've been prosecuted
>>for anything.
>>
>>Eg, is that lawyer someone who's worked for one or two companies
>>for many years, or a whole string of places, never for more than a
>>year or two, or did they only qualify last year?
>>
>>Is that "data protection officer" someone with any understanding of
>>how computer systems work, or just an administrator, or a lawyer?
>>
>>Knowing more about people allows one to slant emails to them in
>>differing ways, which can be useful.
>>
>>
>>I'm listed there, but not for the purposes of finding work; mainly so
>>that people whom I once worked with have a better chance of finding
>>me if they want to.  And also - you have to be a member to be able
>>to see other people's profiles.
>>
>>--
>>Jeremy Nicoll - my opinions are my own.
>>
>>--
>>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

--
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: Just PDSE

[Frank Swarbrick]

z/OS for UNIX files holds program objects, just like PDSE as far as I know.
Now all we need is
//RUN  EXEC PGM='/u/myname/myexefile'

And, of course, allowing UNIX files in JOBLIB/STEPLIB.

From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 7, 2023 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Just PDSE

On Fri, 7 Apr 2023 16:17:04 +, Gibney, Dave wrote:

>The issue with this has always been and still is the fact that you cannot 
>safely share PDES without SYSPLEX (perhaps not full SYSPLEX) ...
>
Do program objects in a z/FS directory satisfy (some) requirements for PDSE?

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

Cobol calling module with non alphanumeric no longer allowed???

[Frank Swarbrick]

I've tried calling modules (that exist!) with both '@' and '#' signs in them 
and Enterprise COBOL 5+ does not allow this.  COBOL 4 allowed this.  Is there 
any good reason why this is the case?

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

Re: LE runtime

[Frank Swarbrick]

I didn't say anything about creating a LM or PO directly.  I don't know 
specifics on how it's done, but the debug data ends up as a NOLOAD segment of a 
PO if the TEST(NOSEPARATE) option is specified.

From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Thursday, April 6, 2023 6:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: LE runtime

Are you sure that any of them can directly create load modules or program 
objects? I suspect that they still produce object modules, albeit in a modern 
format, and require, e.g., the Binder, as a final step.

Does anybody remember SQUOZE <https://en.wikipedia.org/wiki/SQUOZE>?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Thursday, April 6, 2023 3:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE runtime

The "strange debugging option" for COBOL is, I believe, the ability to store 
the compressed source code data in a NOLOAD segment of a program object; 
something not supported with legacy load modules.  A very useful thing, in my 
opinion.  Much better than having the debug data in a separate module in a 
separate library.

From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Thursday, April 6, 2023 1:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: LE runtime

Thanks.

This (to me) seems related to the fact that PL/I still can produce
"classic" load modules,
while COBOL and C++ create program objects, which must reside in PDSEs.

With C++ (I guess), this is due to the fact that (writable) static data
can be initialized not only by
static initializers (which could be implemented by CSECT formatting),
but by function calls, which
needs init functions called after program load or task creation. So with
C++, the requirement
for program objects is driven by the language definition. But I'm not
sure about this.

For COBOL, it is kind of strange, and as I understood, it is only driven
by some sort of
debugging option which only can be handled by program objects.

The PL/1 compiler group, FWIW, stated that they don't plan to require
program objects
in the near future.

By the way: NORENT C can produce load modules, too. We still use NORENT
C generating
load modules (without the compiler options RENT, DLL, LONGNAME). I hope
that this will
be supported in the future, too ... and that "normal load modules" won't
go away soon
(I don't think it will be possible).

It would by interesting, again, what PL/X does. Maybe the new fancy
stuff is only
for the customers :-)

Kind regards

Bernd


Am 06.04.2023 um 00:26 schrieb Attila Fogarasi:
> Originally SCEERUN2 contained LE modules that had to be PDS/E while SCEERUN
> could be PDS.  Also for PL/I and Fortran only SCEERUN is needed;  Cobol and
> C/C++ needs SCEERUN2 as well as SCEERUN.  Finally some of the SCEERUN2
> modules had naming conflicts with very old pre-LE runtimes, while SCEERUN
> modules did not.
>
> On Thu, Apr 6, 2023 at 7:59 AM Frank Swarbrick 
> wrote:
>
>> What is the major difference between the SCEERUN and SCEERUN2 libraries?
>> Is RUN2 for XPLINK and RUN for non-XPLINK?
>>

--
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: LE runtime

[Frank Swarbrick]

The "strange debugging option" for COBOL is, I believe, the ability to store 
the compressed source code data in a NOLOAD segment of a program object; 
something not supported with legacy load modules.  A very useful thing, in my 
opinion.  Much better than having the debug data in a separate module in a 
separate library.

From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Thursday, April 6, 2023 1:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: LE runtime

Thanks.

This (to me) seems related to the fact that PL/I still can produce
"classic" load modules,
while COBOL and C++ create program objects, which must reside in PDSEs.

With C++ (I guess), this is due to the fact that (writable) static data
can be initialized not only by
static initializers (which could be implemented by CSECT formatting),
but by function calls, which
needs init functions called after program load or task creation. So with
C++, the requirement
for program objects is driven by the language definition. But I'm not
sure about this.

For COBOL, it is kind of strange, and as I understood, it is only driven
by some sort of
debugging option which only can be handled by program objects.

The PL/1 compiler group, FWIW, stated that they don't plan to require
program objects
in the near future.

By the way: NORENT C can produce load modules, too. We still use NORENT
C generating
load modules (without the compiler options RENT, DLL, LONGNAME). I hope
that this will
be supported in the future, too ... and that "normal load modules" won't
go away soon
(I don't think it will be possible).

It would by interesting, again, what PL/X does. Maybe the new fancy
stuff is only
for the customers :-)

Kind regards

Bernd


Am 06.04.2023 um 00:26 schrieb Attila Fogarasi:
> Originally SCEERUN2 contained LE modules that had to be PDS/E while SCEERUN
> could be PDS.  Also for PL/I and Fortran only SCEERUN is needed;  Cobol and
> C/C++ needs SCEERUN2 as well as SCEERUN.  Finally some of the SCEERUN2
> modules had naming conflicts with very old pre-LE runtimes, while SCEERUN
> modules did not.
>
> On Thu, Apr 6, 2023 at 7:59 AM Frank Swarbrick 
> wrote:
>
>> What is the major difference between the SCEERUN and SCEERUN2 libraries?
>> Is RUN2 for XPLINK and RUN for non-XPLINK?
>>

--
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: LE runtime

[Frank Swarbrick]

Thanks!

From: IBM Mainframe Discussion List  on behalf of 
Attila Fogarasi 
Sent: Wednesday, April 5, 2023 4:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: LE runtime

Originally SCEERUN2 contained LE modules that had to be PDS/E while SCEERUN
could be PDS.  Also for PL/I and Fortran only SCEERUN is needed;  Cobol and
C/C++ needs SCEERUN2 as well as SCEERUN.  Finally some of the SCEERUN2
modules had naming conflicts with very old pre-LE runtimes, while SCEERUN
modules did not.

On Thu, Apr 6, 2023 at 7:59 AM Frank Swarbrick 
wrote:

> What is the major difference between the SCEERUN and SCEERUN2 libraries?
> Is RUN2 for XPLINK and RUN for non-XPLINK?
>
> --
> 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

LE runtime

[Frank Swarbrick]

What is the major difference between the SCEERUN and SCEERUN2 libraries?  Is 
RUN2 for XPLINK and RUN for non-XPLINK?

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

Re: Unzip on z/OS ?

[Frank Swarbrick]

How do you set R0 in C?

From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Tuesday, April 4, 2023 12:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Unzip on z/OS ?

A similar issue happened with BPXWDYN. COBOL can't set R0. So a
new entry point in BPXWDYN was created that handled that problem.

This all started with me writing an RCF to tell them that they
didn't have a COBOL example. Then a C programmer (I'm guessing)
wrote the COBOL code. You can write c in any language (one of
those type of things). Problem is, it would confuse most COBOL
programmers that, well, it would confuse most COBOL programmers,
and so I suggested a few changes to solve the issue. Then one of
their own people onfirmed what I said, it would be confusing to
most COBOL programmers. And so it appears that IBM doesn't have
many product developers that actually know COBOL. That has
been my take-away from that exchange.

So you may need to do an RCF, and you may go a few rounds with them.

Just say'n'.

Steve Thompson

On 4/4/2023 1:46 PM, Farley, Peter wrote:
> The V2R5 Callable Services manual SA23-1377-50 pp 191-196 describes ONLY the 
> C language zlib library and functions.  There is no material on how to use 
> those functions from any other language than C.
>
> At the very least there is no mention of COBOL COPY members for the parameter 
> definitions nor any mention of a COBOL-compatible link library for inclusion 
> in an executable module.  Only the POSIX C link library and functions are 
> described.
>
> Am I missing something?  Like maybe the zlib C functions are compiled with 
> "#pragma linkage(entryname,OS)"?  There is no such statement in that manual 
> at all.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Ed Jaffe
> Sent: Tuesday, April 4, 2023 1:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unzip on z/OS ?
>
> On 4/4/2023 10:22 AM, Farley, Peter wrote:
>> I agree with Michael, neither that redbook nor the current (V2R5) z/OS 
>> Callable Services manual even mention COBOL or any other HLL interface or 
>> API.  Only the C language zlib library and functions are described.
> Tom provided the link to the book and on page 128 it states that the
> callable services "... are for use by any program coded in C, COBOL,
> Fortran, Pascal, or PL/I, and this information refers to programs
> written in these languages as high-level language (HLL) programs."
>
>

--
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: ASM call by value

[Frank Swarbrick]

Yes, the callee is unaware of if the caller used pass by reference or pass by 
content.  That's a call site feature only.  The callee uses (the default) call 
by reference regardless.
A "by reference" parameter can be specified for any call, and need not be "the 
same" for additional calls to the same subroutine.

Interesting you mention function prototypes.  Those were not supported until 
the 2002 COBOL standard, and still have yet to be implemented in to Enterprise 
COBOL.  Soon, perhaps.  IBM only added user-defined functions in the most 
recent version (E.C. 6.4), and without prototypes those are rather awkward, so 
I'm hopeful for prototypes "soon".

As things are, without prototypes, for the CALL statement there is no parameter 
checking.  Just like in assembler...


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Monday, April 3, 2023 9:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

On Mon, 3 Apr 2023 04:57:02 +, Frank Swarbrick  wrote:
>
>(reply)  Call by content is enforced by the caller.  Call by value is enforced 
>by the callee.
>
Ah.  In my jargon I'd use "declared".  So the callee is unaware of the
distinction between reference and content; it just sees an address in
either case.

Is "content" declared in a function prototype or at the point of call?
If the latter, I'd imagine that the same function could be called with
arguments by reference at one point and by content at another.

--
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: ASM call by value

[Frank Swarbrick]

Comments inline (reply) below (without leading >; I don't seem to have that 
feature available).


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, April 2, 2023 5:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

On Sun, 2 Apr 2023 22:37:53 +0000, Frank Swarbrick wrote:

>I'm just going to put this out there...  Dingus has an online test C compiler, 
>which outputs the generated assembler.  You can find it at 
>http://www.dignus.com/dcc/compileit.html.
>
Thanks.

>I ran the following program through it.

>void fun1(tester *, int *);
>void fun2(tester, int);
>
What do you see if you provide actual function bodies, not only prototypes/?

(reply) Are you thinking the call sites will change at all, or do you just want 
to see how called functions handle the parameters?
I can tell you for certain, even without doing it, that they (the called 
functions) are handled differently.  They have to be, after all, based on the 
fact that the parameters are passed differently.

...
>Something to note, and it's not supported by C as far as I am aware, is 
>neither of these are "pass by content".  Pass by content is "pass address of a 
>copy of the field".  So a copy is done, as with fun2, but the parameter list 
>pointed to by R1 is not the address of the copied fields but rather the 
>address of a parmeter list that contains the addresses of both copied fields.
>
Are the external semantics (not examining the generated assembly)  of
"pass by content" any different from "pass by value"?   How?

(reply)  Call by content is enforced by the caller.  Call by value is enforced 
by the callee.

It would seem more efficient for the called function to perform the copy
rather than the caller because the code to perform the copy would exist
only once in the subroutine rather than at each point of call.

(reply) well, as I said, the caller is the one who cares that the variable is 
not altered, and thus passes a copy.  It could just as well be accomplished by 
copying the variable to a temp field and passing the temp field by reference.  
I mostly use it to pass a length "special register" value,

CALL 'mysubr' USING BY REFERENCE my-string BY CONTENT LENGTH OF my-string.
This can be "shortened: to
CALL 'mysubr' USING my-string CONTENT LENGTH OF my-string.

Because a COBOL special register itself is not updateable it cannot be passed 
by reference and must be passed by value.  In general there isn't much need to 
pass an actual variable by content.
--
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: ASM call by value

[Frank Swarbrick]

I'm just going to put this out there...  Dingus has an online test C compiler, 
which outputs the generated assembler.  You can find it at 
http://www.dignus.com/dcc/compileit.html.

I ran the following program through it.

#include 
typedef struct tester {
   char c;
   int i;
   char s[80];
} tester;

void fun1(tester *, int *);
void fun2(tester, int);

int main() {
tester testr_s = {'a', 1, "this is a test"};
int maxlen = sizeof(testr_s.s);
int currlen = strnlen(testr_s, maxlen);
fun1(_s, );
fun2(testr_s, maxlen);
return 0;
}


The fun1 function takes two addresses, one pointing to a "tester" structure 
field and one pointing to an integer field that holds an integer.  This can 
either be considered "pass address of field by value" or "pass reference to 
field".

The fun2 function takes two "value" parameters.  That is, a copy of a tester 
structure and a copy of an integer.

The "main" function, less prologue and epilog is as follows (with some comments 
from me interspersed).

***   tester testr_s = {'a', 1, "this is a test"};
 MVI   84(13),129
 LA15,1(0,0)   ; 1
 ST15,88(0,13)
 L 15,@lit_213_1
 MVC   92(15,13),0(15)
* setting 3 bytes to 0x00
 XC85(3,13),85(13)
* setting 65 bytes to 0x00
 XC107(65,13),107(13)

* ***   int maxlen = sizeof(testr_s.s);
 LA2,80(0,0)   ; 80

* ***   int currlen = strnlen(testr_s, maxlen);
 MVC   176(88,13),84(13)
 ST2,264(0,13)
 LA1,176(0,13)
 L 15,@lit_213_3 ; strnlen
 BALR  14,15
 ST15,80(0,13) ; currlen

* ***   fun1(_s, );
 LA15,84(0,13)   load r15 from address of testr_s
 ST15,176(0,13)  store r15 (address of testr_s) to @a2
 LA15,80(0,13)   load r15 from address of currlen
 ST15,180(0,13)  store r15 to @a2
 LA1,176(0,13)   load r1 with address of parameter list

temp field (parameter list) for call to fun1
|...|...
|@a1|@a2
176 180
r1 = address of parameter list

 L 15,@lit_213_4 ; fun1
 BALR  14,15


* ***   fun2(testr_s, maxlen);
 MVC   176(88,13),84(13)  copy (88 bytes) to temp field 1 from 
testr_s
 ST2,264(0,13)store value of r2 to temp field 2 (tf2)
 LA1,176(0,13)load r1 with address of temp field 1

temp field (parameter list) for call to fun2
|...|...
| temp field 1 starts here (copy of structure)  
| tf2
176 
264
r1 = address of temp field 1

 L 15,@lit_213_5 ; fun2
 BALR  14,15

* ***   return 0;
 XR15,15   ; 0

Something to note, and it's not supported by C as far as I am aware, is neither 
of these are "pass by content".  Pass by content is "pass address of a copy of 
the field".  So a copy is done, as with fun2, but the parameter list pointed to 
by R1 is not the address of the copied fields but rather the address of a 
parmeter list that contains the addresses of both copied fields.

I can't explain it any better than this, so I hope it all makes sense.

Frank Swarbrick, Principal Analyst
FirstBank - Mainframe Applications Development (COBOL)


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Sunday, April 2, 2023 2:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

Does this mean that,
in the cases where the argument fits within the width of the parameter
list,
PL/X passes the actual value somehow? (which IMO means: the value goes
into the parameter list).
Or does it also in these cases only rely to the interface definition
(and calls by reference)?

Sorry about that: when I was at the (oral) exam for my computer science
grade, I only got "good"
and not "very good"; my prof told me that's because I'm a technician and
not a scientist;
I'm always focused on the implementation too much :-) my bad ... but
that doesn't change any more
after 40 years.

I would like to compare this to C, because IMO, in C, it is up to the
programmer to decide
if he or she wants larger parameters to be copied in the call by value
case or if they should be
passed by reference for performance reasons.

BTW: you are using C for z/OS development, too, as I am told. Would you
tell us if you use C with
the standard C linkage or with something like #pragma linkage (...,OS)?

Thank you, kind regards

Bernd


Am 01.

Re: CASE constructs

[Frank Swarbrick]

COBOL:

EVALUATE A = 1
WHEN TRUE [...]
WHEN FALSE [...]
END-EVALUATE

(WHEN FALSE could be WHEN OTHER in this case.)

Not many people would use this over IF ELSE, but it's available.

There's also "EVALUATE TRUE" where each WHEN is a full evaluation, eliminating 
any need for IF ELSE/IF ELSE/IF ELSE.

From: IBM Mainframe Discussion List  on behalf of 
Gibney, Dave <03b5261cfd78-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, March 30, 2023 10:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: CASE constructs

In the CASE of Software AG's language, Natural, it is WHEN ANY and WHEN NONE. 
ANY would execute after the code of the successful WHEN condition. Once in a 
while, I would wish it would execute before rather than after.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bob Bridges
> Sent: Thursday, March 30, 2023 1:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value]
>
> [EXTERNAL EMAIL]
>
> Ok, I'll bite:  What's the difference between the ANY and OTHER conditions?
>
> Oh, wait, cool!  Does the ANY condition execute even any of the above
> conditions evaluate as true?
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* It is a serious thing to live in a society of possible gods and goddesses, 
> to
> remember that the dullest and most uninteresting person you talk to may
> one day be a creature which, if you saw it now, you would be strongly
> tempted to worship, or else a horror and a corruption such as you now meet,
> if at all, only in a nightmare.  All day long we are, in some degree, helping
> each other to one of these destinations.  -C S Lewis, quoted in "In His Image"
> by Dr Paul Brand and Phillip Yancey */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Wayne Bickerdike
> Sent: Wednesday, March 29, 2023 23:40
>
> I also like CA-IDEAL. A little bit PL/I like with a nice SELECT statement:
>
>   SELECT TRANS_CODE
> WHEN 'A'
>   DO ADD_RECORD_PROC
> WHEN 'D'
>   DO DEL_RECORD_PROC
> WHEN 'P'
>   DO PURCHASE_PROC
> WHEN 'R'
>   DO RECEIPT_PROC
> WHEN ANY
>   DO LOG_TRANS
> WHEN OTHER
>   DO INVALID_CODE
> ENDSEL
>
> --
> 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: ASM call by value

[Frank Swarbrick]

Take a closer look.  "@PRINTF4", rather than "printf", is being called by the 
CALLPRTF assembler module.  ("Figure 2. Calling an intermediate C function from 
Assembler OS linkage")

@PRINTF4 (actual name _printf4) is defined later on that page:

/* this example demonstrates C/Assembler ILC */
/* part 3 of 3 (other files are CCNGCA2, CCNGCA4) */
/***\
 * This routine is an interface between assembler code  *
 * and the C/C++ library function printf(). *
 * OS linkage will not tolerate C-style variable length *
 * parameter lists, so this routine is specific to a*
 * formatting string and a single 4-byte substitution   *
 * parameter.  It's specified as an int here.   *
 * This object wil be named @PRINTF4.   *
/***/

#pragma linkage(_printf4,OS) /*function will be called from assembler*/

#include 

#pragma map(_printf4,“@PRINTF4”)

int _printf4(char *str,int i) {

   return printf(str,i);   /* call runtime library function */

}

Because of the linkage pragma that specifies "OS" I imagine that, although the 
C code is defined as "pass by value", the OS linkage overrides it to be passed 
by reference.  Just a guess; I don't have a C compiler.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, March 30, 2023 5:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

On Thu, 30 Mar 2023 23:39:30 +0200, Bernd Oppolzer wrote:
>
>"call by value" in my understanding means, that values are passed, not
>addressed.
>With the mainframe (or z/OS and CMS) linkage convention, this means,
>that values
>and not addresses are in the reg1 parameter list.
>
What happens if there are more value parameters than the total capacity of 
registers?
(But do I misunderstand?  Is the "reg1 parameter list" not actual registers but 
the
storage addressed by GR1 in the CALL macrlo?  If so, it's no practical limit.)


>see above. Because the values entered into the reg1 list "by value" can
>be negative integers
>(or other types, which need more that 4 bytes), the VL convention cannot
>be used by C callers
>
Hmmm.  In 

I see:
 EDCPRLG
 LA1,ADDR_BLK  parameter address block in r1
 L 15,=V(@PRINTF4) address of routine
 BALR  14,15   call @PRINTF4
 EDCEPIL
ADDR_BLK DC   A(FMTSTR)parameter address block with..
 DC   A(X'8000'+INTVAL)..high bit on the last address
*   ...
INTVAL   DC   F'222'The integer value displayed
*
Isn't the "X'8000'" setting the VL bit?
(I note that's a CD not an EQU.  But the reg1 PL contains an address not a 
value.)

Again, either the caller or the called routine could be able
to convert addresses to values.

--
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: ASM call by value

[Frank Swarbrick]

I just want to confirm that your understanding below is also my understanding.  
I'm not sure what others think call by value is, but I don't believe it matches 
with what C means when the term "call by value" is used.  Or COBOL or PL/I, for 
that matter.

From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Thursday, March 30, 2023 3:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

Am 30.03.2023 um 21:32 schrieb Paul Gilmartin:
> What code does the compiler generate when a long scalar such as
> _Decimal128 is
> passed by value?

The C compiler - at least - puts the long scalar in the reg1 list where
it uses more than 4 bytes.
"call by value" in my understanding means, that values are passed, not
addressed.
With the mainframe (or z/OS and CMS) linkage convention, this means,
that values
and not addresses are in the reg1 parameter list.

> Of course, the compiler can be guided by function prologues and rely on the 
> function
> to copy from a passed address to automatic storage.
>
> Does C use the CALL VL convention?

see above. Because the values entered into the reg1 list "by value" can
be negative integers
(or other types, which need more that 4 bytes), the VL convention cannot
be used by C callers
or C routines being called. The VL convention is not present in the more
"modern"
calling conventions like 64-bit parameter passing and XPLINK - maybe for
this reason.

The original z/OS linkage convention, honestly, restricts the parameter
passing mechanism to
call by reference. That's why it was changed - or enhanced - in the last
(20) years. In the 1960s
and 1970s, when z/OS linkage was first defined, there was only PL/1 and
Fortran (and COBOL,
of course), and they all had call by reference.

HTH, kind regards

Bernd

--
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: ASM call by value

[Frank Swarbrick]

Perhaps the "weird way" could be documented as an appropriate way to pass 
arguments by value instead of the standard by reference.  Then it would no 
longer be weird!

From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Wednesday, March 29, 2023 9:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

Good job.  You could have a future as an assembler programmer, because you
pay attention to the details.

Your weird way is interesting because it is correct, but... it is not
idiomatic.  So it will freak out most assembler programmers.  That's often
not a good thing, but often is not always.

sas

On Wed, Mar 29, 2023 at 7:53 PM Frank Swarbrick 
wrote:

> OK, the following three examples all seem to work.  I dare say you are
> correct about example 1 being unexpected usage of the execute mode.  I only
> came up with it my looking at an example that wasn’t working and seeing
> that putting my value there directly made it work.  But it wasn’t meant to
> be an example of good coding.
>
> *
> CALL1CALL ,(,),MF=L
> *
> ISCICS#  CEEENTRY MAIN=NO
> *
> *SEE IF WE'RE RUNNING UNDER CICS BY CALLING @@GETCb
> *WITH “VALUE” OF FULLWORD 3.
> *
> *EXAMPLE 1 (MY WEIRD WAY):
>  CALL  @@GETCB,MF=(E,=F'3')
> *
> *EXAMPLE 2 (LOAD R1 DIRECTLY WITH ADDRESS OF AREA
> *CONTAINING 3, THEN JUST CALL):
>  LA1,=F'3'
>  CALL  @@GETCB
> *
> *EXAMPLE 3 (LOAD REGISTER (2) WITH VALUE,
> *THEN CALL WITH THAT REGISTER AS THE ARGUMENT:
>  LHI   2,3
>  CALL  @@GETCB,((2)),MF=(E,CALL1)
> *
>  CEETERM RC=(15)
> *
> PPA  CEEPPA
>  CEEDSA ,
>  CEECAA ,
>  END   ISCICS#
>
> I should note that I am not a systems programmer, or even an “assembler
> programmer”.  I am a COBOL programmer who dabbles in assembler
> occasionally.  So I am bound to get a lot of things wrong.
>
> I think I’ll do with #2, since that generates the least amount of code and
> is still fairly simple to read.
>
> As for why I used X'100020003’ instead of F'1,2,3' in
> another example, it’s because I didn’t know of the availability of using
> “comma separated fullword” literals.
>
>

--
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: ASM call by value

[Frank Swarbrick]

OK, the following three examples all seem to work.  I dare say you are correct 
about example 1 being unexpected usage of the execute mode.  I only came up 
with it my looking at an example that wasn’t working and seeing that putting my 
value there directly made it work.  But it wasn’t meant to be an example of 
good coding.

*
CALL1CALL ,(,),MF=L
*
ISCICS#  CEEENTRY MAIN=NO
*
*SEE IF WE'RE RUNNING UNDER CICS BY CALLING @@GETCb
*WITH “VALUE” OF FULLWORD 3.
*
*EXAMPLE 1 (MY WEIRD WAY):
 CALL  @@GETCB,MF=(E,=F'3')
*
*EXAMPLE 2 (LOAD R1 DIRECTLY WITH ADDRESS OF AREA
*CONTAINING 3, THEN JUST CALL):
 LA1,=F'3'
 CALL  @@GETCB
*
*EXAMPLE 3 (LOAD REGISTER (2) WITH VALUE,
*THEN CALL WITH THAT REGISTER AS THE ARGUMENT:
 LHI   2,3
 CALL  @@GETCB,((2)),MF=(E,CALL1)
*
 CEETERM RC=(15)
*
PPA  CEEPPA
 CEEDSA ,
 CEECAA ,
 END   ISCICS#

I should note that I am not a systems programmer, or even an “assembler 
programmer”.  I am a COBOL programmer who dabbles in assembler occasionally.  
So I am bound to get a lot of things wrong.

I think I’ll do with #2, since that generates the least amount of code and is 
still fairly simple to read.

As for why I used X'100020003’ instead of F'1,2,3' in another 
example, it’s because I didn’t know of the availability of using “comma 
separated fullword” literals.


From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Wednesday, March 29, 2023 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

Example 1 looks as I expected, and I'd expect it to work.

You're close on Example 3, you don't want to specify MF in that case.

What you want is the call to go to the subroutine with R1->F'3'.  In Ex. 1,
R2 contains the 3, it's stored in the parmlist addressed by R1 (via MF=E).
In Ex. 3, you're doing the parmlist setup yourself, so don't code the MF
(or any parameters) and CALL will not mess with R1.

sas


On Wed, Mar 29, 2023 at 5:02 PM Frank Swarbrick 
wrote:

> So here is my attempt at specifying just a register
>
>
>   LHI   2,3
>   CALL  @@GETCB,((2)),MF=(E,CALL1)
> + DS0H
>  01-CALL
> + LA1,CALL1   LOAD PARAMETER REG 1
>  03-IHBINNRR
> + ST(2),0(0,1)STORE INTO PARAM. LIST
> 02-IHBOPLTX
> + CNOP  0,4
> 01-CALL
> + BRAS  15,*+8BRANCH AROUND VCON
>  01-CALL
> + DCV(@@GETCB)ENTRY POINT ADDRESS
> 01-CALL
> + L 15,0(15,0)LOAD 15 WITH ENTRY ADR
> 01-CALL
> + BALR  14,15 BRANCH TO ENTRY POINT
> 01-CALL
>
> If I am not mistaken, this is still performing call by reference, not call
> by value, because it's storing the address of an address that holds the
> value of 3.
>
> What I need is it to store the address of a field holding a value of 3.
> One less level of indirection.  And that's what we have here.  CHKCICS
> contains the value of 3 and address 1 is loaded with its address.
>
>   CALL  @@GETCB,MF=(E,CHKCICS3) ...WITH VALUE FULLWORD 3
> + DS0H
>  01-CALL
> + LA1,CHKCICS3LOAD PARAMETER REG 1
>  03-IHBINNRR
> + CNOP  0,4
> 01-CALL
> + BRAS  15,*+8BRANCH AROUND VCON
>  01-CALL
> + DCV(@@GETCB)ENTRY POINT ADDRESS
> 01-CALL
> + L 15,0(15,0)LOAD 15 WITH ENTRY ADR
> 01-CALL
> + BALR  14,15 BRANCH TO ENTRY POINT
> 01-CALL
>
> NOw if we just load R1 directly with the address holding the value of 3,
> then we need to do a call with no parameters passed, right?  I tried the
> following:
>
>   LA1,=F'3'
>   CALL  @@GETCB,MF=(E,CALL1) ...WITH VALUE FULLWORD 3
> + DS0H
>  01-CALL
> + LA1,CALL1   LOAD PARAMETER REG 1
>  03-IHBINNRR
> + CNOP  0,4
> 01-CALL
> + BRAS  15,*+8BRANCH AROUND VCON
>  01-CALL
> + DCV(@@GETCB)ENTRY POINT ADDRESS
> 01-CALL
> + L 15,0(15,0)LOAD 15 WITH ENTRY ADR
> 01-CALL
> + BALR  14,15 BRANCH TO ENTRY POINT
> 01-CALL
>
> I don't think that will work because it clobbers R1.
>
> I just now realized I don't want to use MF=E at all and it looks like that
> could work.  In fact, it appears to generate the same code as the second
> example (the one that works for sure), except with

Re: ASM call by value

[Frank Swarbrick]

So here is my attempt at specifying just a register


  LHI   2,3
  CALL  @@GETCB,((2)),MF=(E,CALL1)
+ DS0H   01-CALL
+ LA1,CALL1   LOAD PARAMETER REG 1   
03-IHBINNRR
+ ST(2),0(0,1)STORE INTO PARAM. LIST 
02-IHBOPLTX
+ CNOP  0,4  01-CALL
+ BRAS  15,*+8BRANCH AROUND VCON 01-CALL
+ DCV(@@GETCB)ENTRY POINT ADDRESS01-CALL
+ L 15,0(15,0)LOAD 15 WITH ENTRY ADR 01-CALL
+ BALR  14,15 BRANCH TO ENTRY POINT  01-CALL

If I am not mistaken, this is still performing call by reference, not call by 
value, because it's storing the address of an address that holds the value of 3.

What I need is it to store the address of a field holding a value of 3.  One 
less level of indirection.  And that's what we have here.  CHKCICS contains the 
value of 3 and address 1 is loaded with its address.

  CALL  @@GETCB,MF=(E,CHKCICS3) ...WITH VALUE FULLWORD 3
+ DS0H   01-CALL
+ LA1,CHKCICS3LOAD PARAMETER REG 1   
03-IHBINNRR
+ CNOP  0,4  01-CALL
+ BRAS  15,*+8BRANCH AROUND VCON 01-CALL
+ DCV(@@GETCB)ENTRY POINT ADDRESS01-CALL
+ L 15,0(15,0)LOAD 15 WITH ENTRY ADR 01-CALL
+ BALR  14,15 BRANCH TO ENTRY POINT  01-CALL

NOw if we just load R1 directly with the address holding the value of 3, then 
we need to do a call with no parameters passed, right?  I tried the following:

  LA1,=F'3'
  CALL  @@GETCB,MF=(E,CALL1) ...WITH VALUE FULLWORD 3
+ DS0H   01-CALL
+ LA1,CALL1   LOAD PARAMETER REG 1   
03-IHBINNRR
+ CNOP  0,4  01-CALL
+ BRAS  15,*+8BRANCH AROUND VCON 01-CALL
+ DCV(@@GETCB)ENTRY POINT ADDRESS01-CALL
+ L 15,0(15,0)LOAD 15 WITH ENTRY ADR 01-CALL
+ BALR  14,15 BRANCH TO ENTRY POINT  01-CALL

I don't think that will work because it clobbers R1.

I just now realized I don't want to use MF=E at all and it looks like that 
could work.  In fact, it appears to generate the same code as the second 
example (the one that works for sure), except without the loading of R1 at all, 
which of course I have done explicitly as you recommend.  I haven't tested it 
yet, but I have this all typed up soi I will send this and then respond to it 
with my results.

Thanks,
Frank


From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Tuesday, March 28, 2023 1:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

What does "didn't work" mean?  What did the CALL expansion look like?

The code might be clearer if you just coded LA R1,=F'3' before the CALL.
Your usage of MF=E is novel, and I'm hesitant to condemn it, but it's
non-standard.

Incidentally, why would you replace =F'1,2,3' on your second example with a
hex string?

sas

On Tue, Mar 28, 2023 at 3:17 PM Frank Swarbrick 
wrote:

> Another typo, of course.
> =X'000100030003' should be =X'000100020003'
> 
> From: IBM Mainframe Discussion List  on behalf
> of Frank Swarbrick 
> Sent: Tuesday, March 28, 2023 12:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: ASM call by value
>
> So that didn't work.  But after a lot of fiddling about, here's what works
> for me.  I LE enabled it so it will be reentrant.
>
> ISCICS#  CEEENTRY MAIN=NO
> *SEE IF WE'RE RUNNING UNDER CICS BY CALLING @@GETCB...
>  CALL  @@GETCB,MF=(E,=F'3') ...WITH VALUE INTEGER 3
>  CEETERM RC=(15)
> *
> PPA  CEEPPA
>  CEEDSA ,
>  CEECAA ,
>  END   ISCICS#
>
> By using the execute format of the CALL macro, assuming all of the fields
> are to be passed by value, you can place them, in order, in the execute
> literal (or whatever its called that follows the 'E').
>
> So, for example, if you wanted to call like the C statement "F(1,2,3)" you
> could do:
>  CALL  F,MF=(E,=X'000100030003')
> Or, of course, you could refer do a DC group instead of using a literal.
>
> Perhaps this will help others.
>
> Frank
>
>

-

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Frank Swarbrick]

Since COBOL 1985 (implemented with an early release of VS COBOL II) you can 
uses nested programs, which (can) have their own "local variables".

That being said, it's quite a paradigm shift for some COBOL programmers, and 
I've had pushback from them each time I've used it.  It is also just as verbose 
as any other COBOL program, which causes source code bloat if used extensively. 
 For a small procedure (nested program) there is sometimes more COBOL 
boilerplate (divisions and sections) outside of the procedure division than 
there is code inside the procedure division.

I'm not discouraging their use, nor am I necessarily encouraging it.


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Tuesday, March 28, 2023 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

With the clever use of GOTOs and the use of different variables with
strange names
for the same purpose, you can even turn a less than 1000 lines COBOL
program completely unreadable.

I see such programs almost every day.

The biggest obstacle for keeping large COBOL programs maintainable is
the lack of procedures and local variables, IMO.
Because all variables are global, it is almost impossible to structure
your program into many small independent and
separate blocks, which IMO is crucial when it comes to fighting
complexity. You need much discipline and talent,
inspired by other programming languages (in my case PL/1 - Pascal - C -
Assembler, to name a few), if you want to produce
good quality software in a shop who is COBOL only :-(

I'm doing this for more than 3 years now ... new COBOL software every
day. COBOL is not dead and will not be
for the next 10 to 20 years, at least.

Kind regards

Bernd


Am 28.03.2023 um 17:05 schrieb David Spiegel:
> Hi Bill,
> You said: "...It seems to help with maintenance and updating of large,
> complex commercial programs..."
> Back in the mid-'80s, I used to support a 3-letter software vendor's
> Payroll package.
> The source was unreadable because of the amount and size of copybooks.
> When compiled, the listing was so big that it was near impossible to
> follow.
> Needless to say, the variable and paragraph names didn't help too much.
> Have you ever tried reading a DMS for CICS (again, 40 years ago)
> generated COBOL listing?
> My point is that anything can be unreadable, including wordy COBOL.
> I used to code FORTRAN, ASSEMBLER and APL for a living (early '80s).
> These 3 can be readable if there are departmental standards in place.
>
> Caveat: I still program Rexx and given the chance would (and have)
> program(med) PL/I -- my favourite compiled language.
> (Edsger W. Dijkstra be damned. (If he had to work in a commercial (aka
> "real") environment (instead of his ivory tower), his opinion might've
> been tempered a bit.) )
>
> Regards,
> David
>

--
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: ASM call by value

[Frank Swarbrick]

Another typo, of course.
=X'000100030003' should be =X'000100020003'

From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Tuesday, March 28, 2023 12:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

So that didn't work.  But after a lot of fiddling about, here's what works for 
me.  I LE enabled it so it will be reentrant.

ISCICS#  CEEENTRY MAIN=NO
*SEE IF WE'RE RUNNING UNDER CICS BY CALLING @@GETCB...
 CALL  @@GETCB,MF=(E,=F'3') ...WITH VALUE INTEGER 3
 CEETERM RC=(15)
*
PPA  CEEPPA
 CEEDSA ,
 CEECAA ,
 END   ISCICS#

By using the execute format of the CALL macro, assuming all of the fields are 
to be passed by value, you can place them, in order, in the execute literal (or 
whatever its called that follows the 'E').

So, for example, if you wanted to call like the C statement "F(1,2,3)" you 
could do:
 CALL  F,MF=(E,=X'000100030003')
Or, of course, you could refer do a DC group instead of using a literal.

Perhaps this will help others.

Frank



From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Monday, March 27, 2023 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

So it looks like all I need is the following:
CALL @@GETCB,(3)
which should call the @@GETCB function passing integer 3 by value, returning 0 
or 1 in R15 to indicate if the task is running in a CICS environment.
Will give this a shot.  Thanks!

Frank


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Monday, March 27, 2023 12:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

Sorry that I post to the original question;
that's because most of the answers so far missed the point.

Call by value means that a value is passed to the caller;
call by reference means that a reference (technically: an address) is
passed to the caller.

In ASSEMBLER:

CALL SUBPROG,(A,B,C),VL

sends address constants of fields A, B and C to the caller (via reg1
address list),
so that is always call by reference.

You can instead send an integer constant to the caller using CALL or a
register:

CALL SUBPROG,(1024,(R3))

with the integer constant, this sure is call by value, but you are
limited to integer arguments.
With the register argument, it depends on what is contained in the
register;
if it is an address, you have call by reference again.

The only real "call by value" I can see here is the case where an
integer constant is part
of the reg1 parameter list (the 1024 constant above); and this is what C
technically does
in the "call by value" case. If C passes larger values "call by value",
it copies them in the
reg1 parameter list. This CANNOT BE DONE using the CALL macro. And this
would be
the correct answer to the original question.

HTH,
kind regards

Bernd


Am 26.03.2023 um 23:35 schrieb Frank Swarbrick:
> Can the MVS CALL macro be used to call a C function with "value" parameters 
> (rather than reference parameters)?
>
>
> --
> 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

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

Re: ASM call by value

[Frank Swarbrick]

So that didn't work.  But after a lot of fiddling about, here's what works for 
me.  I LE enabled it so it will be reentrant.

ISCICS#  CEEENTRY MAIN=NO
*SEE IF WE'RE RUNNING UNDER CICS BY CALLING @@GETCB...
 CALL  @@GETCB,MF=(E,=F'3') ...WITH VALUE INTEGER 3
 CEETERM RC=(15)
*
PPA  CEEPPA
 CEEDSA ,
 CEECAA ,
 END   ISCICS#

By using the execute format of the CALL macro, assuming all of the fields are 
to be passed by value, you can place them, in order, in the execute literal (or 
whatever its called that follows the 'E').

So, for example, if you wanted to call like the C statement "F(1,2,3)" you 
could do:
 CALL  F,MF=(E,=X'000100030003')
Or, of course, you could refer do a DC group instead of using a literal.

Perhaps this will help others.

Frank



From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Monday, March 27, 2023 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

So it looks like all I need is the following:
CALL @@GETCB,(3)
which should call the @@GETCB function passing integer 3 by value, returning 0 
or 1 in R15 to indicate if the task is running in a CICS environment.
Will give this a shot.  Thanks!

Frank


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Monday, March 27, 2023 12:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

Sorry that I post to the original question;
that's because most of the answers so far missed the point.

Call by value means that a value is passed to the caller;
call by reference means that a reference (technically: an address) is
passed to the caller.

In ASSEMBLER:

CALL SUBPROG,(A,B,C),VL

sends address constants of fields A, B and C to the caller (via reg1
address list),
so that is always call by reference.

You can instead send an integer constant to the caller using CALL or a
register:

CALL SUBPROG,(1024,(R3))

with the integer constant, this sure is call by value, but you are
limited to integer arguments.
With the register argument, it depends on what is contained in the
register;
if it is an address, you have call by reference again.

The only real "call by value" I can see here is the case where an
integer constant is part
of the reg1 parameter list (the 1024 constant above); and this is what C
technically does
in the "call by value" case. If C passes larger values "call by value",
it copies them in the
reg1 parameter list. This CANNOT BE DONE using the CALL macro. And this
would be
the correct answer to the original question.

HTH,
kind regards

Bernd


Am 26.03.2023 um 23:35 schrieb Frank Swarbrick:
> Can the MVS CALL macro be used to call a C function with "value" parameters 
> (rather than reference parameters)?
>
>
> --
> 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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Frank Swarbrick]

COBOL now has:

PERFORM UNTIL EXIT
[...]
END-PERFORM

And it has finally been implemented in Enterprise COBOL (v6.4; backported to 
v6.3 on my request!).


From: IBM Mainframe Discussion List  on behalf of 
Andrew Rowley 
Sent: Tuesday, March 28, 2023 5:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

On 28/03/2023 9:34 pm, Seymour J Metz wrote:
> I once found myself defending the common idiom
>
> for (;;) {
>foo;
> }
>
> as a perfectly clear DO FOREVER.

I'm not sure that it is completely clear, it depends on knowledge if
whether the empty statement evaluates as true or false - or just a guess
that do forever is more likely than do never...

Personally, I prefer something like:

while (TRUE)
{

}

--
Andrew Rowley
Black Hill Software

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

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

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

[Frank Swarbrick]

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

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

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

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

Re: ASM call by value

[Frank Swarbrick]

I think you are explaining what, in COBOL terms, is CALL BY CONTENT, not CALL 
BY VALUE.  CALL BY CONTENT seems to be similar (same?) as what Bernd is 
describing in PL/I with the placement of parentheses around the argument.  CALL 
BY CONTENT (in COBOL) creates a "dummy" variable, copies the "content" of the 
original variable to the dummy variable, and passes the address of the dummy 
variable.

CALL BY VALUE (in COBOL) does not do this.  CBV places the actual value 
(generally, if maybe not always) in the parameter list (where CALL BY REFERENCE 
and CALL BY CONTENT would place an address).

On the CALLEE side you also must (*) specify BY VALUE when the caller argument 
is passed BY VALUE, so that the CALLEE knows there is a value rather than an 
address in that parameter.
(*) The "exception" being that you COULD have the caller do
CALL XXX BY VALUE ADDRESS OF MY-FIELD
and have the CALLER "receive" the parameter by reference (the default) to be 
able to address the callers MY-FIELD variable.  Not generally recommended, but 
can work.

In C you always "call by value", but sometimes the value is an address 
(reference)., e.g. (as has been shown by others),
xxx(a, )
This passes the value of a and THE VALUE OF THE ADDRESS of b.  So rather, in 
COBOL this would be
call 'xxx' using by value a, by value address of b.

When invoking program 'xxx', regardless of if it is written in C, COBOL, PL/I 
or assembler, there is no other way for a COBOL program to call it passing the 
VALUE of a other than using the BY VALUE clause as shown previously.  If you 
attempted to pass BY REFERENCE (default) or BY CONTENT then the corresponding 
parameter in xxx would be the address of a, not the value of a, and would not 
work as desired. I think Bernd has shown in PL/I how to use BYVALUE or 
something like that.

Prior to BY VALUE being added to COBOL (pre-1985, I believe) you could not 
properly call a C routine that expected a value parameter.  Only C routines 
that had pointer arguments was possible.

Clear as mud?


From: IBM Mainframe Discussion List  on behalf of 
Joel C. Ewing 
Sent: Monday, March 27, 2023 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

All you really need to do a "call by value" in ASM is a special Call
macro (say maybe VCALL)  that allocates "hidden" space for a copy of the
variable value, copies the original variable, and somehow passes that to
the called program, and a programming rule that says you only invoke
that particular subroutine using the intended interface.  You can even
add a special Subroutine entry macro and employ some "tricks" so that
attempts to reference the subroutine name by an ordinary Call macro or
direct reference will fail.

If your only allowed interfaces to the subroutine allows it so see the
value of a variable passed by the caller but not change the
corresponding variable known to the caller, then that IS call by value,
no matter what the underlying implementation in low-level code.

Native machine instructions and standard subroutine linkages may only
support call by reference, but the advantage of a macro assembler is
that you can extend the language through macros and create an enhanced
language that can do so much more. Some notable examples of this are
various implementations using macros that allow use of
structured-programming control constructs and recursive procedures with
dynamic variable storage in Assembly programs.

 Joel C Ewing

On 3/27/23 09:13, Bernd Oppolzer wrote:
>DCL X BIN FIXED (31);
>CALL SUB ((X));
>
> SUB: PROC (P);
>DCL P BIN FIXED (31);
>
>END SUB;
>
> The statement CALL SUB ((X));
> creates a dummy argument for X (that is, a copy of variable X).
> The CALL statement passes THE ADDRESS of that copy to the SUB subroutine.
> This is NOT call by value.
>
> The subroutine cannot change X, because it gets the address of the
> copy of X
> and not the address of X. That is:
>
> call by reference of a dummy argument
> and not
> call by value
>
> The types of X and P may be different; if so, the dummy argument gets
> the type of P.
> In this case, no parantheses are required (but a warning message is
> issued, if there are
> no parentheses). But the mechanism is the same, regardless if the
> types match (with parantheses)
> or if the types don't match (without parantheses). Only in the case
> when the types match and
> there are no parantheses, you have a real call by reference where the
> subroutine can change
> the value of the caller.
>
> This is PL/1 ... other languages don't behave this way. With other
> languages, you will get a
> problem at runtime, if the types don't match.
>
> Kind regards
>
> Bernd
>
>
>
> Am 27.03.2023 um 16:03 schrieb Seymour J Metz:
>> Why is it important to you that an address not be passed and why do
>> you believe that a PL/I dummy variable means that the argument was
>> not passed by value? Languages specify black box behavior, not how
>> you 

Re: ASM call by value

[Frank Swarbrick]

So it looks like all I need is the following:
CALL @@GETCB,(3)
which should call the @@GETCB function passing integer 3 by value, returning 0 
or 1 in R15 to indicate if the task is running in a CICS environment.
Will give this a shot.  Thanks!

Frank


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Monday, March 27, 2023 12:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

Sorry that I post to the original question;
that's because most of the answers so far missed the point.

Call by value means that a value is passed to the caller;
call by reference means that a reference (technically: an address) is
passed to the caller.

In ASSEMBLER:

CALL SUBPROG,(A,B,C),VL

sends address constants of fields A, B and C to the caller (via reg1
address list),
so that is always call by reference.

You can instead send an integer constant to the caller using CALL or a
register:

CALL SUBPROG,(1024,(R3))

with the integer constant, this sure is call by value, but you are
limited to integer arguments.
With the register argument, it depends on what is contained in the
register;
if it is an address, you have call by reference again.

The only real "call by value" I can see here is the case where an
integer constant is part
of the reg1 parameter list (the 1024 constant above); and this is what C
technically does
in the "call by value" case. If C passes larger values "call by value",
it copies them in the
reg1 parameter list. This CANNOT BE DONE using the CALL macro. And this
would be
the correct answer to the original question.

HTH,
kind regards

Bernd


Am 26.03.2023 um 23:35 schrieb Frank Swarbrick:
> Can the MVS CALL macro be used to call a C function with "value" parameters 
> (rather than reference parameters)?
>
>
> --
> 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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Frank Swarbrick]

As a COBOL programmer for almost 27 years I agree that COBOL should not be 
dismissed.  Though, as someone who has "studied" 30+ other languages I would 
say that COBOL is somewhat unique and if it's your first and primary language 
it may cause hardships when trying to learn other languages.  But I absolutely 
agree that the dismissal of COBOL programmers is, well, not very nice to say 
the least.

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, March 26, 2023 11:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Stop the ragging on COBOL please [was: RE: ASM call by value]

I am getting increasingly tired of snide or outright dismissive references to 
COBOL and by extension to COBOL programmers.

Programmers like me.

Yes, I am also well versed in HLASM, Rexx, awk and gawk, somewhat facile in 
SORT (at least as far as knowing and using JOIN's), SQL, JCL and various other 
z/OS utilities, MetalC, and lately python and bash scripting.  I even remember 
some of the PL/I and Fortran and Pascal I used in college and my early 
employment days.  I even remember some SNOBOL, which I actually got to use 
productively at a then-major NY bank very early in my career.

COBOL pays my bills and keeps my employer operating successfully and profitably.

COBOL does NOT rot the brain.  Alcohol and various other legal and illegal 
substances can, in fact, do that.  Intelligently devising business solutions to 
business problems in ANY computer language does NOT rot the brain.

It is not funny or acceptable to say so.  It never was.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, March 26, 2023 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:



>In COBOL, for example, the following end up doing the same thing.
>
Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
brain.

--

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


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

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

Re: ASM call by value

[Frank Swarbrick]

Oops, "typo".  I meant "*k = i + j".

From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Sunday, March 26, 2023 7:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

My C is rusty... I need to review pointer/address-of syntax.  The idea for
the 3rd argument was to show one "passed by reference"; in any case
modifiable by the subroutine.

But where did x and y come from?

sas

On Sun, Mar 26, 2023 at 7:53 PM Frank Swarbrick 
wrote:

> Also, "*k = x + y".
> 
> From: IBM Mainframe Discussion List  on behalf
> of Frank Swarbrick 
> Sent: Sunday, March 26, 2023 5:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: ASM call by value
>
> I'm guessing he meant "int *k" rather than " k".
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
> Sent: Sunday, March 26, 2023 5:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: ASM call by value
>
> On Sun, 26 Mar 2023 19:35:59 -0400, Steve Smith wrote:
>
> >I forgot to mention, to pass by value with CALL, you need [a] register[s].
> >e.g.:
> >void foo(int i, int j ,  k)
> >  {
> >  k = i + j;
> >  }
> >
> That shouldn't be legal.  In fact, gcc gives me:
> cc tinyc.c   -o tinyc
> tinyc.c:3:25: error: expected parameter declarator
> void foo(int i, int j ,  k)
>
> --
> 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: ASM call by value

[Frank Swarbrick]

What do you mean "the called subroutine receives a *modifiable* pointer/address 
value."?  I don't believe that is true.  Well, it's true you can do the 
following:
foo(int *p) {
p = 0;
}

But (note, I am not a "C programmer", but I think I know it well enough) I'm 
fairly certain that if you call it "passing the address of variable 'x'", i.e. 
foo(), you will neither update 'x' nor it's address.

I suppose I could test this, but haven't done so yet.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, March 26, 2023 6:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 23:18:49 +, Frank Swarbrick wrote:

>True, but "passing by reference" and "passing a 'reference' (pointer/address) 
>by value" are the same.
>
No.  When "passing a 'reference' (pointer/address) by value" the called 
subroutine
receives a *modifiable* pointer/address value.

When "passing by reference" (supported by Pascal but not by C) the called 
routine
receives no such value.

>In COBOL, for example, the following end up doing the same thing.
>
Do not use CO BOL as an exemplar of programming discipline.  Cobol rots the 
brain.

>call 'myfunc' using by reference my-field
>call 'myfunc' using by value address of my-field
>
In the first case, what is the *modifiable* pointer/address object?  Does it 
have a name?

>Both are the same as doing the following in C:
>myfunc(_field)
>
Given suitable preceding declarations, I can do (untested):
myfunc(_field) {
my_field = your_field;
...
};

A tested example:
#include 

int scanit( char *S ) {
for ( ; *S; ++S ) {  /* "++S modifies a pointer value.  */
printf( "%c\n", *S );
};
return 0; };

int main( void ) {
return scanit( "Hello, world!" );
};

1192 $ make tinyc
cc tinyc.c   -o tinyc
1193 $ ./tinyc
H
e
l
...

--
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: ASM call by value

[Frank Swarbrick]

Also, "*k = x + y".

From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Sunday, March 26, 2023 5:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

I'm guessing he meant "int *k" rather than " k".


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, March 26, 2023 5:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 19:35:59 -0400, Steve Smith wrote:

>I forgot to mention, to pass by value with CALL, you need [a] register[s].
>e.g.:
>void foo(int i, int j ,  k)
>  {
>  k = i + j;
>  }
>
That shouldn't be legal.  In fact, gcc gives me:
cc tinyc.c   -o tinyc
tinyc.c:3:25: error: expected parameter declarator
void foo(int i, int j ,  k)

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

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

Re: ASM call by value

[Frank Swarbrick]

I'm guessing he meant "int *k" rather than " k".


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, March 26, 2023 5:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 19:35:59 -0400, Steve Smith wrote:

>I forgot to mention, to pass by value with CALL, you need [a] register[s].
>e.g.:
>void foo(int i, int j ,  k)
>  {
>  k = i + j;
>  }
>
That shouldn't be legal.  In fact, gcc gives me:
cc tinyc.c   -o tinyc
tinyc.c:3:25: error: expected parameter declarator
void foo(int i, int j ,  k)

--
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: ASM call by value

[Frank Swarbrick]

I think this is exactly what I am looking for.  Thank you.

From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Sunday, March 26, 2023 5:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

I forgot to mention, to pass by value with CALL, you need [a] register[s].
e.g.:
void foo(int i, int j ,  k)
  {
  k = i + j;
  }

* ASM
L R2,xyz
LHI R3,1
CALL FOO,((R2),(R3),BAR)
...
XYZ DS F
BAR DS F

Depending on # of registers available vs. # of value parms, CALL may become
infeasible.

sas

On Sun, Mar 26, 2023 at 6:36 PM Tony Thigpen  wrote:

> No. You will need to create a proper C-style parm list, load it's
> address into R1, and branch to the C routine address without using the
> CALL macro.
>
> Tony Thigpen
>
> Frank Swarbrick wrote on 3/26/23 17:35:
> > Can the MVS CALL macro be used to call a C function with "value"
> parameters (rather than reference parameters)?
> >
> >
> > --
> > 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: ASM call by value

[Frank Swarbrick]

True, but "passing by reference" and "passing a 'reference' (pointer/address) 
by value" are the same.

In COBOL, for example, the following end up doing the same thing.

call 'myfunc' using by reference my-field
call 'myfunc' using by value address of my-field

Both are the same as doing the following in C:
myfunc(_field)



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, March 26, 2023 4:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ASM call by value

On Sun, 26 Mar 2023 21:35:13 +, Frank Swarbrick wrote:

>Can the MVS CALL macro be used to call a C function with "value" parameters 
>(rather than reference parameters)?
>
Aren't all parameters in C passed by value?  C has no construct of "reference 
parameters".

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

ASM call by value

[Frank Swarbrick]

Can the MVS CALL macro be used to call a C function with "value" parameters 
(rather than reference parameters)?


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

Re: Crypto Express question

[Frank Swarbrick]

I'm specifically referring to payment card crypto functions, like PIN 
validation, chip cryptogram stuff, etc.

From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Monday, October 31, 2022 12:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Crypto Express question

Frank Swarbrick wrote:
> I do think that having an internal crypto card is quite a benefit,
>and CCA/ICSF is generally quite nice to work with.  That being
>said, not having to work with any crypto processing at all is even
>nicer.

"Not having to work with any crypto processing" isn't a viable option, not if 
you want even trivial security.

— — — — —
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

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