from:"Bernd Oppolzer"

Re: S0c4 creation

2024-04-21 Thread Bernd Oppolzer


I'd suggest to be very careful with such codings;
a co-worker some years ago did this and - by accident - the code ran 
privileged,

which caused the whole LPAR to hang.

Same goes for ST at address zero, which was suggested by another poster.

Maybe it would be better to write protect your own module and try to write
into your own static CSECT. This would not put other jobs in your system 
in danger.


Or: do your SLIP trap experiments with another sort of ABEND.

Kind regards

Bernd


Am 21.04.2024 um 11:21 schrieb Rupert Reynolds:

If it's your STC, then include something dirty like

BANG NC16(4,R0),16(R0)  AND CVT pointer with itself--should fail

although I should say that might raise eyebrows on a production system ;-)

Roops

On Sun, 21 Apr 2024, 08:45 Peter, <
05e4a8a0a03d-dmarc-requ...@listserv.ua.edu> wrote:


Hello

Good morning

Is there any sample Jobs or I can enforce a s0c4 abend in a Started task ?

I am trying to teach SLIP trap to a rookie..Is there any other efficient
way to do this?

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


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

Re: How do one return a fullword binary to a C program from an assembler subroutine?

2024-04-17 Thread Bernd Oppolzer


The program has one more problem:

buffer overrun in this statement:

  char hlicmd[8];

  ...
  strcpy (hlicmd, "VGET    ");

the variable hlicmd has 8 bytes, but the strcpy copies 9 bytes,
the string VGET, 4 blanks and the terminating hex zero :-(

take care !!!

HTH, kind regards

Bernd


Am 17.04.2024 um 12:16 schrieb Bernd Oppolzer:

The reason behind this is:

C passes arguments "by value", which means that int arguments like 
textlen are passed directly as values,
not as addresses. You get the value 120 in the address list, pointed 
to by reg 1, not the address of textlen,
which is different from COBOL or FORTRAN etc (COBOL and FORTRAN use 
"call by reference", by default).


That's why you have to pass the address explicitly, if you want to get 
values back from your C subroutine.


You can write like this:

 retcode = rxhlicpl (hlicmd, name, namelen, text, );

no need to define (and use) an explicit pointer.

Take care about namelen, by the way. This will behave the same way.

Different with char arrays; the name of a char array without an index is
equivalent with the address of its first element, so it works with 
char arrays (a.k.a. strings)

WITHOUT the & operand.

HTH, kind regards

Bernd


Am 16.04.2024 um 22:14 schrieb Willy Jensen:

Found it, it was down to C pointers as expected / feared.
This works, note the use of 'textlenp' in the call:

#pragma linkage (rxhlicpl, OS)
main () {
  extern int rxhlicpl();
  int retcode;
  char hlicmd[8];
  char name[61];   /* text + eod  */
  int  *namelenp, namelen;
  char text[121];  /* text + eod  */
  int  *textlenp, textlen;
  int  retval;
-  -  -
  retcode = 0;
  strcpy (hlicmd, "VGET    ");
  strcpy (name, "TESTVAR");
  namelen = 7 ;
  textlen = 120;
  textlenp=
  retcode = rxhlicpl (hlicmd, name, namelen, text, textlenp);
  printf("rc is %d, text is %d '%s'\n\n", retcode, textlen, text);

--
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: How do one return a fullword binary to a C program from an assembler subroutine?

2024-04-17 Thread Bernd Oppolzer


The reason behind this is:

C passes arguments "by value", which means that int arguments like 
textlen are passed directly as values,
not as addresses. You get the value 120 in the address list, pointed to 
by reg 1, not the address of textlen,
which is different from COBOL or FORTRAN etc (COBOL and FORTRAN use 
"call by reference", by default).


That's why you have to pass the address explicitly, if you want to get 
values back from your C subroutine.


You can write like this:

 retcode = rxhlicpl (hlicmd, name, namelen, text, );

no need to define (and use) an explicit pointer.

Take care about namelen, by the way. This will behave the same way.

Different with char arrays; the name of a char array without an index is
equivalent with the address of its first element, so it works with char arrays 
(a.k.a. strings)
WITHOUT the & operand.

HTH, kind regards

Bernd


Am 16.04.2024 um 22:14 schrieb Willy Jensen:

Found it, it was down to C pointers as expected / feared.
This works, note the use of 'textlenp' in the call:

#pragma linkage (rxhlicpl, OS)
main () {
  extern int rxhlicpl();
  int retcode;
  char hlicmd[8];
  char name[61];   /* text + eod  */
  int  *namelenp, namelen;
  char text[121];  /* text + eod  */
  int  *textlenp, textlen;
  int  retval;
-  -  -
  retcode = 0;
  strcpy (hlicmd, "VGET");
  strcpy (name, "TESTVAR");
  namelen = 7 ;
  textlen = 120;
  textlenp=
  retcode = rxhlicpl (hlicmd, name, namelen, text, textlenp);
  printf("rc is %d, text is %d '%s'\n\n", retcode, textlen, text);

--
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: Attributes of an assemler symbol

2024-03-31 Thread Bernd Oppolzer


I forgot the SETA, of course:

   LCLA  
    SETA  10
FOO    DS    


Am 31.03.2024 um 11:31 schrieb Bernd Oppolzer:
I don't know the answer to your question. Don't know, if such an 
attribute exists or if the repetition count is really stored as an 
attribute of the symbol. But:


FOO    DS    10CL5
ENDFOO EQU   *
COUNTFOO   EQU   (ENDFOO-FOO)/L'FOO

This way you can compute the count and put it into a symbol.

Another approach would be not to use constant repetition counts, but 
macro symbols from the start, like


    LCLA  
FOO    DS    

HTH, kind regards

Bernd



Am 31.03.2024 um 10:53 schrieb Binyamin Dissen:

Given

    FOO   DS   10CL5

which attribute / macro function extracts the repetition count - 10

I assume that it must exist but I am not finding it.

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

Director, Dissen Software, Bar & Grill - Israel

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


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

Re: Attributes of an assemler symbol

2024-03-31 Thread Bernd Oppolzer

I don't know the answer to your question. Don't know, if such an 
attribute exists or if the repetition count is really stored as an 
attribute of the symbol. But:


FOODS10CL5
ENDFOO EQU   *
COUNTFOO   EQU   (ENDFOO-FOO)/L'FOO

This way you can compute the count and put it into a symbol.

Another approach would be not to use constant repetition counts, but 
macro symbols from the start, like


   LCLA  
FOODS

HTH, kind regards

Bernd



Am 31.03.2024 um 10:53 schrieb Binyamin Dissen:

Given

FOO   DS   10CL5

which attribute / macro function extracts the repetition count - 10

I assume that it must exist but I am not finding it.

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

Director, Dissen Software, Bar & Grill - Israel

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


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

Re: Algol

2024-03-18 Thread Bernd Oppolzer

This is related to Algol 60, IMO, not Algol 68. Algol 60 had a big 
influence on some machines in the 1960s.


The German mainframe Telefunken TR4, designed in the late 1950s, was a 
fully transistorized machine and was for some
years the fastest machine built in Europe. And, as Dijkstra once said, 
it was "Algol in Hardware". Some 50 machines
were built and one of them was delivered to the Netherlands (maybe 
Delft), that's probably where Dijkstra had a closer look

at this machine.

The offspring TR440 was a time sharing machine with Algol, Fortran, PL/1 
(Multics), Pascal (from Zürich), COBOL, BCPL
and was used at German universities until the early 1980s. I worked with 
it as a student from 1977 to 1981.


One of the designers of the Telefunken machines was Fritz-Rudolf 
Güntsch, who invented "virtual memory"
(some time before it was first used in the Ferranti Atlas computer). 
https://de.wikipedia.org/wiki/Fritz-Rudolf_G%C3%BCntsch
(only available in German language, sorry). Güntsch worked with 
Rutishauser and Stiefel for some time (at ETH Zürich),

who both had a big influence on the creation of the Algol 60 language.

Kind regards

Bernd


Am 18.03.2024 um 20:47 schrieb Laurence Chiu:

I cut my teeth on Algol also at university - on a Burroughs B6700 mainframe
running MCP.  Burroughs at the time were unique in that there was no
assembler language. Everything was written in a HLL, MCP was written in
ESPOL, the compiler for which was written in DCAlgol. That was just Algol
with additional functions for comms handling.  Algol was certainly my
favourite language at the time and it was cool that Burroughs even provided
source code for the compiler which was a great learning opportunity for CS
majors.

On Sun, Mar 17, 2024 at 2:33 AM Bob Bridges <
0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:


I did a lot of coding in Algol during my time at a local University in the
late '70s.  My impression at the time was that it had a serious paucity of
built-in functions, but that it enabled me to write my own and make them
easily available to my programs.  So I stuffed a library full of I/O and
string-handling functions and got along just fine, it seemed to me.

Haven't encountered it since; I don’t know what advances may have been
made in that arena.

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




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

Re: LE C growing heap issue

2024-01-04 Thread Bernd Oppolzer


I had similar situations a lot of times at different customers' locations.

It always turned out that when the developers at the customer's site 
telled me
that they returned all the storage requested to the heap, in fact they 
didn't.
There was always a small area left which was not returned or freed. This 
area was then

responsible for the growing heap on every call.

What I did to diagnose the problem has already been done here, as far as 
I can see.
The most interesting tool is the alternate heap manager (CEL4MCHK, 
IIRC), which allows
you to track all memory allocations and frees, and it even tells you the 
stack trace at the place

when the allocations have been done.

I then wrote a procedure (REXX, IIRC), which processed the output of 
CEL4MCHK, just to see
if there is a certain pattern in the areas which remain allocated. For 
example: I do exactly
1000 requests and then I look for areas which remain allocated (of a 
certain size) and
are present in the list 1000 times (or a multiple of 1000 times). Then I 
do the same 2000 times,
and look, if I have the same area 2000 times, and so on. (There is no 
need, BTW, to run
the tests until all the memory is used up ... if you do this, your 
traces will grow much too large).


Areas which remain constant if I change the number of calls are of no 
interest. But if I find areas,
which change the number exactly with the number of calls, I know the 
place where the allocation
without free has been done. And then I call the developer, who is 
responsible for the module

which does that allocation and ask him or her to fix it.

I've done this many times, and every time I found the module or function 
which was responsible
for the storage leak within some hours. The languages used (which lead 
to the storage leaks)
were C, C++ (often), and even PL/1 - this doesn't really matter, because 
it's all LE.


AFAIK, for Windows and Linux and similar platforms, there is a tool 
called ValGrind,

which does a similar analysis.

The REXX procedure was used primarily to sort and group the requests in 
the CEL4MCHK
output by size and caller sequence etc ... so that the numbers (like 
1000 and 2000 above)

can easily be recognized.

This said: there is of course a small chance that the problem is not 
inside the user's (or
customer's) code, but instead inside some of the vendor's functions (in 
this case: IBM,
for example the JSON processors mentioned). But IMO the probability is 
low ... although
in my career there were some rare situations, where after 4 weeks of 
examination of
error situations, it REALLY turned out that the error was in the IBM 
part ... and it took
me some time to convince IBM. If you want, I can tell you more about 
this ... but offline.


But even if this was the case in your situation, the CEL4MCHK method IMO 
would detect it.
Honestly: I believe, you will find out that the error is in the 
customer's code.


HTH, kind regards

Bernd


Am 04.01.2024 um 22:45 schrieb Eric Erickson:

We are in a bit of a quandary here with some memory issues surrounding our 
application. This is a multitasking LE C application running in 31 bit mode 
that utilizes the IBM JSON and EZNOSQL Services. Some of the attributes are:

•   z/OS V2.5 Operation System
•   POSIX(OFF) - all tasks/subtasks
•   Single address space (31 Bit Mode)
•   ATTACHX Multi-tasking model (no pthreads)
•   Execute as started task – Problem State – Key 4
•   Drop in/out of supervisor state as needed
•   3 EZNOSQL Databases are opened at application start and remain open 
until termination
•   Open EZNOSQL connections tokens are passed to the worker task(s) along 
with the unit of work to be processed

Our issue is that the total available heap grows until we end up exhausting all 
available memory and inevitable application failure, but the key here is that 
while the total heap grows with every unit of work processed by tasks, the in use 
amount only shows no or only a small (<128 bytes) increment between units of 
work. For example, here is a heap report (using LE __heaprpt function) example. So 
we are fairly confident that our application code is not leaking memory.

HeapReport: ZdpQuery @Start  - Total/In Use/Available:   1048576/888160/
 160416.
HeapReport: ZdpQuery @Enter  - Total/In Use/Available:   1048576/888160/
 160416.
HeapReport: ZdpQuery @Exit   - Total/In Use/Available:   1560856/888192/
 672664.
HeapReport: ZdpQuery @Enter  - Total/In Use/Available:   1560856/888192/
 672664.
HeapReport: ZdpQuery @Exit   - Total/In Use/Available:   2073088/888224/
1184864.
HeapReport: ZdpQuery @Enter  - Total/In Use/Available:   2073088/888224/
1184864.
HeapReport: ZdpQuery @Exit   - Total/In Use/Available:   2073088/888224/
1184864.
HeapReport: ZdpQuery @Enter  - Total/In Use/Available:   2073088/888224/
1184864.
HeapReport: ZdpQuery @Exit   - Total/In Use/Available:   2585376/888256/

Re: Assembler optimization OPTION

2023-12-10 Thread Bernd Oppolzer


I guess some sort of answer is:

if you have programs from - say - the 1980s and you have no reason for 
changing them - and no business case -
then you probably don't want to change them as long as they run 
satisfactorily.


Nowadays it is even trickier ... sometimes I come along some programs 
which from my technical point of view
need some maintenance, but the bean counters tell me that I am not 
allowed to do it as long as nobody is writing
a ticket for them ... and if I write a ticket myself, it has to go thru 
a lot of quality gate checks before I am allowed to
start working on it, mostly done by people, who don't know nothing about 
the technical facts ...

this can take weeks and months, and in the end, it may well be refused :-(

It seems to be easier for the top management to complain about the 
mainframe being "old and clumsy"
and then trying to replace it by what they consider "modern technology" 
... but then I see these migration projects
always failing, which keeps the mainframe running and running and the 
mainframe specialists growing older and older.


I'm 64 now, which is young, IMO.  My colleagues (still working, for the 
same customers) are 73, for example.


Kind regards

Bernd



Am 10.12.2023 um 16:06 schrieb Seymour J Metz:

Why does it take so long for people to use new features? HLASM has a lot of 
nifty things that have been around and well documented for decades.

A similar question exists for new instructions; how many shops are still 
running boxen that don't support the z immediate, long displacement and 
relative instructions, e,g.,JC, LARL, LAY?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Peter 
Relson 
Sent: Sunday, December 10, 2023 9:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler optimization OPTION

The starting point to almost all of these discussions tends to be to write 
reentrant programs (as high level languages naturally produce).

If you must stick with a non-reentrant program, consider the LOCTR directive. If you don't feel like truly moving the 
data-defining statements within your program, you can use the LOCTR directive to help to "move" data to a 
separate area. You might have an area for your "code" and an area for your "static data" and an 
area for your "dynamic data"

Peter Relson
z/OS Core Technology Design


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


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


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

Re: Assembler optimization OPTION

2023-12-09 Thread Bernd Oppolzer


There were different situations.

First of all, a co-worker on the project (from Kyndryl) helped us by 
identifying the modules which were in trouble.
I guess he used special traces or performance reports; don't know which 
sort of reports exactly. But he found

the SIIS hits somehow.

Then, when I knew the modules to examine, I found different situations 
... some examples:


1) IBM macros with inline parameter lists with SIIS issues (TIME for 
example, but others, too)

- with register parameters mostly
2) home grown macros with the same problem
3) LOOPs built by home grown SP macros with decimal control variables 
inside the instruction stream (!)
4) internal subroutines built by local macros where local static data 
immediately followed the code (same cache line)

5) other (more sophisticated) problems

I will tell you briefly what I did:

1) change the macros to list/execute form, as suggested by IBM, or 
switch to other (home grown) services
2) same as 1) or fix the macros to use a separate (workarea) DSECT, 
which is present in all our modules

3) fix the SP macros
4) if possible, move the data to the workarea DSECT; if not, enter some 
space before the data, so that the

data resides in the next cache line (256 bytes)
5) if possible, separate data from the instructions by moving it to the 
workarea which is provided by the
(already existent) startup macro; this also allows for baseless coding 
in most situations


Because the modules affected are part of the basic IMS framework of the 
customer and carry the daily
IMS dialog services with some thousand users, these modifications had to 
be tested carefully, before
putting them into production. The project started in the beginning of 
2021 and was terminated successfully

half a year later with (almost) no problems or downtimes.

HTH, kind regards

Bernd


Am 09.12.2023 um 15:38 schrieb Mike Schwab:

Putting DS and modified DCs into a separate area?

On Sat, Dec 9, 2023 at 5:17 AM Bernd Oppolzer 
wrote:


Hi,

there is no such option;
this is not possible, because with ASSEMBLER, the programmer has full
control about where he or she puts the information elements,
be it static data or code. There is no magic engine like the optimizer
with compilers which can do anything about that.

This said:

I had a project in 2021 with a large customer which had very old
ASSEMBLER programs from the 1980s, which had heavy SIIS problems
(store into instruction stream) which had to be resolved. I found out
that some of them can easily be resolved by the use of clever macros
which separate the static data from the code (by putting them in a
different CSECT or DSECT). The details are too complicated to discuss here,
but in the end, the changes to the code were minimal. And in the end, we
achieved our project goals in time and budget.

HTH, kind regards

Bernd


Am 08.12.2023 um 20:29 schrieb Ituriel do Neto:

Hello everyone,

Recently i have seen some discussions related to assembler performance

to use the L1 cache of the processor better and not mixing instructions and
data.

Can you enlighten me which assembler option can be used for this purpose?

Thanks in advance


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer

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

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





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

Re: Assembler optimization OPTION

2023-12-09 Thread Bernd Oppolzer


Hi,

there is no such option;
this is not possible, because with ASSEMBLER, the programmer has full 
control about where he or she puts the information elements,
be it static data or code. There is no magic engine like the optimizer 
with compilers which can do anything about that.


This said:

I had a project in 2021 with a large customer which had very old 
ASSEMBLER programs from the 1980s, which had heavy SIIS problems
(store into instruction stream) which had to be resolved. I found out 
that some of them can easily be resolved by the use of clever macros
which separate the static data from the code (by putting them in a 
different CSECT or DSECT). The details are too complicated to discuss here,
but in the end, the changes to the code were minimal. And in the end, we 
achieved our project goals in time and budget.


HTH, kind regards

Bernd


Am 08.12.2023 um 20:29 schrieb Ituriel do Neto:

Hello everyone,

Recently i have seen some discussions related to assembler performance to use 
the L1 cache of the processor better and not mixing instructions and data.

Can you enlighten me which assembler option can be used for this purpose?

Thanks in advance


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer

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


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

Re: PL/I question

2023-11-17 Thread Bernd Oppolzer


Sorry for jumping in VERY late.

If you have something like

    DCL X CHAR (6);

    X = DATE;

then you will get strange results, because DATE is not recognized as the 
well-known builtin function DATE which returns the
current date. But instead it is a DECIMAL FLOAT(6) variable with an 
undefined value (given the "normal" default rules, inherited
from FORTRAN, which defines an undefined variable depending on its first 
letter ... and, of course, if you don't have the more
modern compiler options which prevent you from using undefined variables 
etc.).


Now, if you want the compiler to use the builtin function DATE instead 
of this undefined variable, you have two choices:


- declare DATE as a BUILTIN function

   DCL DATE BUILTIN;
   X = DATE;

- put parantheses after DATE; that is:

   X = DATE ();

   this way, DATE is known to be the BUILTIN function "by context".

Both variants will do.

Same goes for all other builtin functions without arguments.

HTH,
kind regards

Bernd
(PL/1 teacher since 1991 - and many other stuff, ASSEMBLER, C, DB2, ...)



Am 15.11.2023 um 18:34 schrieb Binyamin Dissen:

A PL/I source code member has

DCL foobar BUILTIN

and must be compiled with RULES(LAXDCL)

I see no reference to FOOBAR as a function call.

My question is if FOOBAR was invoked, what does the BUILTIN clause do? A
different calling sequence? Looking for an internal label?

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

Director, Dissen Software, Bar & Grill - Israel

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


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

Re: PC Interference from shredder Was: Kinda fun

2023-11-12 Thread Bernd Oppolzer


I like these stories.

in the nineties I had similar problems with my new computer, which had 
external SCSI drives
in a separate box, and a 1,5 meter SCSI cable between this box and the 
PC tower.


A friend of mine who knows more about electrical engineering than I do 
came along

to look for the problem.

At some point he looked out of the window and he saw the radar tower, 
which is about
half a mile away and is needed for the traffic control of the airport 
nearby. So he speculated
about the problems coming from the radar pulses ... in fact, my office 
at that time was
in the 3rd floor of the house, and we're just in between the tower and 
the main

entry path of the airplanes.

I don't recall exactly how we fixed the problem ... today, the computer 
is still in use,
but now it is in the 2nd floor :-) in my private computer museum (OS/2 
box, still running).


Kind regards

Bernd


Am 12.11.2023 um 02:50 schrieb Steve Thompson:
Many years ago at Hagerstown MD, they had a computer (I think it was 
an NCR3 or 3000, it's just been too long ago) that at odd points would 
just fail. My father was an RF tech working on radios, and had a 
contract for the Police Department... so I will make this short. It 
turns out that a few stories below this computer room was the door out 
of the garage where the police cars were parked. And so upon exiting 
the parking garage and entering the alley to the street, officers 
would key their mics to verify their radio was working and that would 
cause the computer system to lock up (machine check?).


This was discovered by an NCR CE that had an Oscilloscope doing 
tracing trying to find what was causing this problem and just happened 
to be standing at the window looking down when a police car came out 
and the machine froze.  the police mobile radios were a harmonic 
of the system clock!! And were 100 Watts IRC.


A sign was put at the exit of the garage informing anyone who keyed 
their mic for their radio before getting out of the alley, upon being 
discovered who they were, their pay check would be the last one to be 
passed out at the end of the month. This problem had been invariably 
happening during payroll runs and they had to be restarted from the 
beginning.


Problem stopped.

Steve Thompson

Oh, and the windows did have a metal grid over them in an attempt to 
prevent things like this.


On 11/11/2023 5:07 PM, Tom Brennan wrote:
Just before I worked with mainframes I drew maps on a computer that 
had a big display, a small drawing pad and pen, and a large light 
table with a "puck" for tracing existing maps into the computer. Both 
the puck and pen worked by receiving a magnetic signal from the pad 
or table in order to determine its location.  About once a week 
someone would complain that their pen was throwing the cursor all 
over the screen, so a new pen was ordered at maybe $500.


The light table had bunch of fluorescent bulbs inside, and you could 
dim them with a knob if needed.  One day I noticed that when the 
light was either full on or full off, there was no problem with my 
pen.  But if the dimmer was in the middle, the pen had issues.  Those 
dimmers used triacs which work by holding back each AC wave a bit and 
then sharply rising.  The sharp rise generates all sorts of EMF and 
that's what was messing with the coil in the pen.


On 11/11/2023 12:55 PM, Wayne Bickerdike wrote:
On the subject of RF interference. Years ago we came back from 
living in
California to Australia. We had a 110V coffee espresso machine. It 
worked
well and we ran it from a voltage changer plugged into the socket. 
Early

rise time, my wife would go into the kitchen and make a coffee.

I'm in the habit of reading my email and surfing at that time (like 
now in

Australia).

For weeks and months my internet would go off and come back a few
minutes later. I eventually tied it back to the coffee machine/voltage
reducer. We stopped using it and all good. The wireless router runs on
2.4Ghz and is located in my study, maybe 30 feet from the kitchen 
and there

is a double brick wall in the way.

As an adjunct to this. I switch off my router at midnight and I get 
much

better sleep.

On Sun, Nov 12, 2023 at 6:11 AM Joel C. Ewing  
wrote:



I think shielding of the PC itself is unlikely the problem, unless the
case is not properly closed.  All PCs I have ever seen have metal 
cases,

which if properly seated and grounded act as a RF shield, inbound and
outbound.

Any electric motor could be producing power transients at power on/off
and possible RF interference from contact arcing (which can increase
with motor age), which might travel over the house wiring, or via air
and get picked up by other cables in the room which are connected 
to the

PC.  Any magnetic effects of a motor should be minor by comparison.

If it's a large enough motor, start up may produce a temporary dip in
voltage big enough to be a problem for a computer that is not powered
through an

Re: Will AI free Bill Johnson? (was AI will surpass human intelligence!)

2023-09-17 Thread Bernd Oppolzer

I'd really be interested, because I am collecting historic computer 
related books,

so if - by any chance - you could send it to Germany, I would be happy.
Of course, I would pay you the needed transfer costs.

For exchanging contact information, please send me an offline mail. Thanks.

BTW: https://en.wikipedia.org/wiki/Michael_Kudlick


Am 17.09.2023 um 17:04 schrieb Bill Johnson:

Good news, while cleaning out my basement, I found my college Assembler 
textbook. Along with my Assembler class final assignment printout. If anyone 
wants the book, let my know, I’ll gladly give it to you so you can learn it. 
Self taught of course.

It’s called Assembler Language Programming for the IBM Systems 360 and 370 for 
OS and DOS. Author is Michael D. Kudlick second edition.


Sent from Yahoo Mail for iPhone



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

Re: Will AI free Bill Johnson? (was AI will surpass human intelligence!)

2023-09-16 Thread Bernd Oppolzer


So sad. No laugh for a long time. I am laughing all the time :-)

Am 16.09.2023 um 17:23 schrieb Bill Johnson:

I’m going to laugh when AI replaces many of you assembler deniers. The under 40 
for sure. Maybe the under 50.


Sent from Yahoo Mail for iPhone


On Saturday, September 16, 2023, 11:00 AM, Bernd Oppolzer 
 wrote:

Let's see if Bill comments on this ...
if not, maybe the AI that wrote all the provocations now prefers to be
silent on this
to protect itself from exposure?
Does AI have a sense of humour?

Am 16.09.2023 um 08:28 schrieb Andrew Wilkinson:

You could be right.
However, my mental image is of the real Bill Johnson gagged and tied to a chair 
in his basement
while a wicked AI posts provocations to this list in order to study human 
nature. Cheers, Andrew


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

Re: Will AI free Bill Johnson? (was AI will surpass human intelligence!)

2023-09-16 Thread Bernd Oppolzer


Let's see if Bill comments on this ...
if not, maybe the AI that wrote all the provocations now prefers to be 
silent on this

to protect itself from exposure?
Does AI have a sense of humour?

Am 16.09.2023 um 08:28 schrieb Andrew Wilkinson:

You could be right.
However, my mental image is of the real Bill Johnson gagged and tied to a chair 
in his basement
while a wicked AI posts provocations to this list in order to study human 
nature. Cheers, Andrew


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

Re: Assembler, was: AI expert hot new position

2023-09-14 Thread Bernd Oppolzer

The field of AI research was founded at a workshop 
 at Dartmouth College 
 in 1956.^[r] 
 
^[2] 
 
The attendees became the leaders of AI research in the 1960s.^[s] 
 
They and their students produced programs that the press described as 
"astonishing":^[t] 
 
computers were learning checkers 
 strategies, solving word 
problems in algebra, proving logical theorems 
 and speaking English.^[u] 
 
^[3] 
 



By the middle of the 1960s, research in the U.S. was heavily funded by 
the Department of Defense ^[207] 
 
and laboratories had been established around the world.^[208] 
 
Herbert Simon  
predicted, "machines will be capable, within twenty years, of doing any 
work a man can do".^[209] 
 
Marvin Minsky  agreed, 
writing, "within a generation ... the problem of creating 'artificial 
intelligence' will substantially be solved".^[210] 




^

Am 14.09.2023 um 01:37 schrieb Bill Johnson:

AI, real AI, isn’t even a year old. I’m betting the next 3-5 decades will see 
it become the most powerful advancement in IT history.

https://www.3dbear.io/blog/the-impact-of-ai-how-artificial-intelligence-is-transforming-society




Sent from Yahoo Mail for iPhone




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

PL/I early compilers performance issues

2023-09-06 Thread Bernd Oppolzer


Thinking a little bit more about this:

the insurance company used auto variables heavily, BUT:

until the 2010 time frame, they didn't allow (or: suggested not to use) 
INTERNAL PL/1 procedures !!
Instead they had some home grown macros based on label variables, which 
worked much the same like
procedure calls, but the "program blocks", which were built using these 
macros - of course - didn't have local variables;

all variables are GLOBAL.

Using this technique, performance issues during procedure startup are no 
problem, of course.


In 2010, one of my co-workers (and a friend of mine) checked out the 
performance of these "program blocks"
and found out that the heavy use of label variables COMPROMISES the 
optimizing strategies of the modern compilers,
so that now the "program blocks" based on label variables are MUCH 
SLOWER than original PL/1 procedures.


That's why the company now changed the recommendation and asked all 
programmers to change the
programs from the old "program blocks" to normal procedures (when doing 
maintenance to the programs).
This led to significant better performance in some cases (especially in 
large Batch programs with many "program blocks").


There are still many programs using the old "program blocks", and we are 
now thinking about forcing
the transformation process in the next months. When compiling a program 
using the old feature,
you get a return code of 8 and a compiler message, but the code is 
produced, anyway.


Kind regards

Bernd


Am 07.09.2023 um 05:13 schrieb Bernd Oppolzer:

Am 07.09.2023 um 01:40 schrieb Leonard D Woren:

Michael Stein wrote on 9/6/2023 3:45 PM:
[...] PL/1 F level subroutine calls did a getmain/freemain for each 
subroutine call. Too much overhead to call even one subroutine for 
each of 30K records on a 360/91 & MVT.


Well, my recollection is that if you had only Static storage, no 
Automatic storage, it didn't do a GETMAIN.
Or was that an enhancement in the new PL/I compiler?  Was that PLIX?  
Yeah, not using stuff for decades can cause memory fade.



/Leonard



I first came into contact with PL/1 in the end of the 1980s at the 
beforementionend insurance company.
At that time, they had the V2.3 optimizer (IIRC), and it produced 
pretty amazing code. I was asked to
do PL/1 classes for the developers there. This company made (and still 
makes) heavy use of automatic storage and tried to
code all modules "naturally reentrant", that is: no modified static 
storage. So the problems with getmain/freemain
at procedure startup and end must have been long gone. That company 
started with PL/1 in the beginning of the 1980s,

before that is was an ASSEMBLER only shop. (C came later, from 1992 on).

1992 (and 1994 again) I was asked to do a dump analysis class in 
another PL/1 company. They indeed had


DEFEAULT RANGE(*) STATIC;

in almost every program. I didn't understand the reason at that time 
and thought is was for dump reading,
because static variable (in the STATIC CSECT which is part of the load 
module) are much easier to find than
auto variables (living in the stack). But now I have the impression 
that this could have simply been a performance

issue in the beginning.

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: Simple request from chatGPT to write assembler program.

2023-09-06 Thread Bernd Oppolzer


Am 07.09.2023 um 01:40 schrieb Leonard D Woren:

Michael Stein wrote on 9/6/2023 3:45 PM:
[...] PL/1 F level subroutine calls did a getmain/freemain for each 
subroutine call. Too much overhead to call even one subroutine for 
each of 30K records on a 360/91 & MVT.


Well, my recollection is that if you had only Static storage, no 
Automatic storage, it didn't do a GETMAIN.
Or was that an enhancement in the new PL/I compiler?  Was that PLIX?  
Yeah, not using stuff for decades can cause memory fade.



/Leonard



I first came into contact with PL/1 in the end of the 1980s at the 
beforementionend insurance company.
At that time, they had the V2.3 optimizer (IIRC), and it produced pretty 
amazing code. I was asked to
do PL/1 classes for the developers there. This company made (and still 
makes) heavy use of automatic storage and tried to
code all modules "naturally reentrant", that is: no modified static 
storage. So the problems with getmain/freemain
at procedure startup and end must have been long gone. That company 
started with PL/1 in the beginning of the 1980s,

before that is was an ASSEMBLER only shop. (C came later, from 1992 on).

1992 (and 1994 again) I was asked to do a dump analysis class in another 
PL/1 company. They indeed had


DEFEAULT RANGE(*) STATIC;

in almost every program. I didn't understand the reason at that time and 
thought is was for dump reading,
because static variable (in the STATIC CSECT which is part of the load 
module) are much easier to find than
auto variables (living in the stack). But now I have the impression that 
this could have simply been a performance

issue in the beginning.

Kind regards

Bernd

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

Re: Simple request from chatGPT to write assembler program.

2023-09-06 Thread Bernd Oppolzer


Ok ... not quire correct, but:
the first ASSEMBLER languages go back to the years 1947 to 1951, if my 
sources are right;
there was some sort of ASSEMBLER for the 701 (which was available in 
1953, IIRC).

The first HLL was Fortran, IMO, which should be 1956 ca.
So there are some years in the 1950 time frame, where ASSEMBLER was the 
only choice;

that's what I am talking about.
IIRC, in the first years of HLLs, there were some debates that HLLs are 
not usable because of
the poor code the compilers generated at that time. This was true even 
in the 1960s for the

first versions of PL/1.
Kind regards
Bernd


Am 06.09.2023 um 17:55 schrieb Seymour J Metz:

because in the 1950s and 1960s,
it was the only language we had.

?

COBOL
COMIT
FACT
FARGO
FORTRAN
IPL-V
LISP
PL/I
RPG
SNOBOL




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

Re: Simple request from chatGPT to write assembler program.

2023-09-06 Thread Bernd Oppolzer

What you are quoting (1., 2., 3.) are facts ... of course true, and 
nothing to dispute about.
But your conclusions are wrong ... Assembler is of value anyway; Ray 
Mullins DID say that.
For example for studying the outcome of translators and for performance 
analysis etc.
IMO knowledge of Assembler is NEEDED, once you want to dig a little 
deeper into machine architecture
and other related topics. The Assembler language opens the door for the 
understanding of registers,
storage, addressing schemes, operation formats and so on ... that is: 
the hardware.


IMO, you always seem to be forced to put down other people and their 
skills; I don't understand why.
But what scares me most is that your constant use of words like 
"dinosaurs" and "narcissists"
(and "idiots", BTW) in this discussions. And that's why I will not 
answer to any more mails from you from now on.

Should have done so earlier, maybe.

Bernd


Am 06.09.2023 um 14:11 schrieb Bill Johnson:

Everything I said about assembler has rung true.

1. The assembler listserv is nearly dead.
2. One of assemblers experts, Ray Mullins, stated unequivocally its market is 
getting smaller and smaller and is a niche product.
3. Bernd said since 2005, there’s been little demand for assembler training.

...

And the dinosaurs here trying so hard to not become extinct.
Notice how the 20-30 experts can’t say, Bill Johnson is right. Because it makes 
them wrong and narcissists don’t like saying they were wrong.

...


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

Re: Simple request from chatGPT to write assembler program.

2023-09-06 Thread Bernd Oppolzer

Thanks a lot,

it would be always better to give even a very small ASSEMBLER program a
test run

instead of simply posting it to a public web site.
I will fix this on Wikipedia as soon as I can.

I'm not sure if ASSEMBLER should be used by humans :-) given this episode.
In fact, it was used in the past (heavily), because in the 1950s and
1960s, it was the only language we had.
And it is still used on Mainframes (some say: Mainframe Assembler is the
only usable Assembler, all others are not)
and as long as we have large code bases in Assembler, there is no other
way than supporting it
(and we have large code bases, this is what John Ehrman once told me ...
most customers who still have that

don't want to talk about it).

Anyway: the reasons to learn it (like: to understand the code produced
by other language translators better etc.
and to understand language translators, BTW) are very valid, and that's
what Ray Mullins (liebe Grüße)

tells in his papers, too, if I understand him right.

Another fun story:

Once a co-worker of mine (at the large insurance company mentioned
earlier) had a problem with IBM software,
and while communicating with IBM, he posted a bit of ASSEMBLER code
showing the error, and the answer of

IBM support was "Customer should not use ASSEMBLER" :-)

Kind regards
Bernd

Am 06.09.2023 um 05:44 schrieb Tom Brennan:
Your sample assembled fine but abended 0C1. I made some minor mods.
Hope you don't mind my pretend German in the comments :)

The biggest problem is trying to use R15 as a base. That gets messed
up by OPEN. The other problem is LA instead of L when loading R13 for
the return. I mix those up a lot myself.

https://www.mildredbrennan.com/mvs/hello.png

P.S. My wife and I were in München last May. Beautiful city and it
was fun trying to understand the language based on a high-school class.

On 9/5/2023 6:19 PM, Bernd Oppolzer wrote:

FWIW:

ChatGPT could have used this ASSEMBLER program, which I posted some
years ago
to German Wikpedia ... this does not do the addition of two integers,
but instead it
is a simple Hello World program. In contrast to the program provided
by ChatGPT,

it has no errors (I hope) and it will work.

https://de.wikipedia.org/wiki/Liste_von_Hallo-Welt-Programmen/Assembler#IBM-Mainframe-ASSEMBLER

Kind regards

Bernd

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

Re: Simple request from chatGPT to write assembler program.

2023-09-05 Thread Bernd Oppolzer

The "version history" of the German Wikipedia article shows that I added
this ASSEMBLER source code in 2015.
The page already existed, but there was no Mainframe example, which
motivated me to add one.
I thought some minutes about adding another source using the ASSEMBLER
of the German Telefunken TR 440 mainframe
of the 1970s (TAS = Telefunken Assembler Sprache), but I didn't succeed
so far. That was the machine which
impressed me most when I started my studies of computer science in 1977
at Stuttgart university.

https://www.gettyimages.de/detail/nachrichtenfoto/grossrechner-tr-440-von-telefunken-1970-nachrichtenfoto/542347199

The comments under the article which tell some facts about ASSEMBLER
source code layout (columns 10 and 16 etc.)

have been added later by another Wikipedia author and are partly wrong.

This conversation motivated me to correct the comments ... we'll see how
long it takes until my corrections are

verified by the Wikipedia people and online.

All in German ... sorry about that.

Kind regards

Bernd

Am 06.09.2023 um 03:35 schrieb Bernd Oppolzer:

Maybe the program disqualifies because of the German comments?
But: this should be no problem for ChatGPT ... translation to english ...

Kind regards

Bernd

Am 06.09.2023 um 03:31 schrieb Bernd Oppolzer:

What I meant to say:

it would have been better, if ChatGPT had used this (my) ASSEMBLER
program from German Wikipedia ...

but apparently, it found the bad program from another source ???
Bill did not ask for a certain logic in his request; he simply asked
for some mainframe Assembler program

(not specific). So my Hello World program would qualify, too.

It would be interesting to know how ChatGPT determines which sources
are more reliable than others ...

Kind regards

Bernd

Am 06.09.2023 um 03:19 schrieb Bernd Oppolzer:

FWIW:

ChatGPT could have used this ASSEMBLER program, which I posted some
years ago
to German Wikpedia ... this does not do the addition of two
integers, but instead it
is a simple Hello World program. In contrast to the program provided
by ChatGPT,

it has no errors (I hope) and it will work.

https://de.wikipedia.org/wiki/Liste_von_Hallo-Welt-Programmen/Assembler#IBM-Mainframe-ASSEMBLER

Kind regards

Bernd

Am 06.09.2023 um 01:47 schrieb Bill Johnson:

I never presented it as a working model.

Sent from Yahoo Mail for iPhone

On Tuesday, September 5, 2023, 7:36 PM, Bernd Oppolzer
wrote:

I am not bashing it. I am simply telling you that it has a bunch of
errors and it will not work.

It's kind of interesting to me that, while I try to answer repectfully
to your mails,
almost every answer from you contains the word "idiot" or "idiotic",
which is the same in German, so I understand that well.
Is that a specific way to support your arguments?

Am 06.09.2023 um 01:31 schrieb Bill Johnson:
I find it stunning the technology people are trying to hang onto
the past (assembler) and bashing the future. (ChatGPT) Or perhaps
that’s what aging people do.

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

Re: Simple request from chatGPT to write assembler program.

2023-09-05 Thread Bernd Oppolzer

Maybe the program disqualifies because of the German comments?
But: this should be no problem for ChatGPT ... translation to english ...

Kind regards

Bernd

Am 06.09.2023 um 03:31 schrieb Bernd Oppolzer:

What I meant to say:

it would have been better, if ChatGPT had used this (my) ASSEMBLER
program from German Wikipedia ...

but apparently, it found the bad program from another source ???
Bill did not ask for a certain logic in his request; he simply asked
for some mainframe Assembler program

(not specific). So my Hello World program would qualify, too.

It would be interesting to know how ChatGPT determines which sources
are more reliable than others ...

Kind regards

Bernd

Am 06.09.2023 um 03:19 schrieb Bernd Oppolzer:

FWIW:

it has no errors (I hope) and it will work.

https://de.wikipedia.org/wiki/Liste_von_Hallo-Welt-Programmen/Assembler#IBM-Mainframe-ASSEMBLER

Kind regards

Bernd

Am 06.09.2023 um 01:47 schrieb Bill Johnson:

I never presented it as a working model.

Sent from Yahoo Mail for iPhone

On Tuesday, September 5, 2023, 7:36 PM, Bernd Oppolzer
wrote:

I am not bashing it. I am simply telling you that it has a bunch of
errors and it will not work.

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

Re: Simple request from chatGPT to write assembler program.

2023-09-05 Thread Bernd Oppolzer

What I meant to say:

it would have been better, if ChatGPT had used this (my) ASSEMBLER
program from German Wikipedia ...

but apparently, it found the bad program from another source ???
Bill did not ask for a certain logic in his request; he simply asked for
some mainframe Assembler program

(not specific). So my Hello World program would qualify, too.

It would be interesting to know how ChatGPT determines which sources are
more reliable than others ...

Kind regards

Bernd

Am 06.09.2023 um 03:19 schrieb Bernd Oppolzer:

FWIW:

it has no errors (I hope) and it will work.

https://de.wikipedia.org/wiki/Liste_von_Hallo-Welt-Programmen/Assembler#IBM-Mainframe-ASSEMBLER

Kind regards

Bernd

Am 06.09.2023 um 01:47 schrieb Bill Johnson:

I never presented it as a working model.

Sent from Yahoo Mail for iPhone

On Tuesday, September 5, 2023, 7:36 PM, Bernd Oppolzer
wrote:

I am not bashing it. I am simply telling you that it has a bunch of
errors and it will not work.

Am 06.09.2023 um 01:31 schrieb Bill Johnson:
I find it stunning the technology people are trying to hang onto the
past (assembler) and bashing the future. (ChatGPT) Or perhaps that’s
what aging people do.

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

Re: Simple request from chatGPT to write assembler program.

2023-09-05 Thread Bernd Oppolzer

FWIW:

it has no errors (I hope) and it will work.

https://de.wikipedia.org/wiki/Liste_von_Hallo-Welt-Programmen/Assembler#IBM-Mainframe-ASSEMBLER

Kind regards

Bernd

Am 06.09.2023 um 01:47 schrieb Bill Johnson:

I never presented it as a working model.

Sent from Yahoo Mail for iPhone

On Tuesday, September 5, 2023, 7:36 PM, Bernd Oppolzer
wrote:

I am not bashing it. I am simply telling you that it has a bunch of
errors and it will not work.

Am 06.09.2023 um 01:31 schrieb Bill Johnson:

I find it stunning the technology people are trying to hang onto the past
(assembler) and bashing the future. (ChatGPT) Or perhaps that’s what aging
people do.

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

Re: Simple request from chatGPT to write assembler program.

2023-09-05 Thread Bernd Oppolzer


I told you "I try to answer respectfully" ...
doesn't work always, especially if I am called an idiot in the very same 
mail that I am answering to.


Kind regards

Bernd


Am 06.09.2023 um 01:53 schrieb Bill Johnson:

If you consider this respectful, there’s something wrong with you.

“So your JCL expertise qualifies you as a systems programmer ... that's
interesting.”


Sent from Yahoo Mail for iPhone



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

Re: Simple request from chatGPT to write assembler program.

2023-09-05 Thread Bernd Oppolzer

I am not bashing it. I am simply telling you that it has a bunch of 
errors and it will not work.


It's kind of interesting to me that, while I try to answer repectfully 
to your mails,

almost every answer from you contains the word "idiot" or "idiotic",
which is the same in German, so I understand that well.
Is that a specific way to support your arguments?


Am 06.09.2023 um 01:31 schrieb Bill Johnson:

I find it stunning the technology people are trying to hang onto the past 
(assembler) and bashing the future. (ChatGPT) Or perhaps that’s what aging 
people do.





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

Re: Is the IBM Assembler List still alive

2023-09-05 Thread Bernd Oppolzer

I did regular ASSEMBLER training, provided by training companies here in 
Germany,
in the 1990 to 2005 time frame. Since then, there indeed was not much 
demand.


I worked for different mainframe customers since 2000 until today (I'm a 
freelancer),
and every one of them had some ASSEMBLER programs (more or less). In 
fact, there was one,
who used C on the mainframe heavily; this customer didn't have much 
ASSEMBLER, IIRC.

Only C and PL/1.

The co-workers at two of my current customer's sites are asking for 
ASSEMBLER training,

but the management there doesn't want to pay the price,
because they don't see the need. But they both have ASSEMBLER programs 
(one more,
the other less), and so I have to fix the problems with the ASSEMBLER 
code bases myself.


At one of these sites (which has a large ASSEMBLER code base),
they once made me hold a class for ASSEMBLER sysprogs in the 2010 time 
frame (IIRC).
I always told them (since 2000 ca.): if you don't want to run into 
problems, send me 10 guys
or young ladies at the age of 30, but they sent me 3, which were 45 
years old already.

2 of them are still there, but they don't do much.

IMO, the ASSEMBLER expertise and the support is still needed until 2030, 
at least,
at this particular company. But I'm 71 then ... not sure, how this can 
work.


I am not marketing ASSEMBLER trainings beyond the scope of my current 
customers.

Because it is not necessary; I am in charge all the time.
But, of course, if someone reads this and is interested, feel free to 
ask. I will set up
an ASSEMBLER class for you ... somewhere in Europe, at best. Languages 
are German,
English and French. Other classes, too, like DB2 or PL/1. Call  me 
offline or look

at my website.

Kind regards

Bernd


Am 06.09.2023 um 00:49 schrieb Bill Johnson:

Offering? To me it sounds like there’s no demand or there would actually be 
classes available to select as we write. There’s really nothing scheduled and 
likely won’t be. Because there’s no demand.


Sent from Yahoo Mail for iPhone


On Tuesday, September 5, 2023, 6:38 PM, Bernd Oppolzer 
 wrote:

I offer training classes,
Steve Thompson does.

If a company really wants ASSEMBLER training, they can find it here.


Am 04.09.2023 um 22:35 schrieb Bill Johnson:

I love how many of you downplay others who don’t do what you do. And act like 
it’s inferior. Plus, puff yourselves up simply for programming in Assembler. I 
made a boatload of money in 40+ years performing nearly every task on the 
mainframe. I can also code in Assembler, just never needed to. Assembler is 
still dying, as the Assembler listserv attests. Plus, the fact it’s nearly 
impossible to find a company that offers training classes in it.



--
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: Simple request from chatGPT to write assembler program.

2023-09-05 Thread Bernd Oppolzer

It will not work, because almost every single instruction has an error 
or two.

Every programmer with a little bit ASSMBLER experience can see this;
this ChatGPT program has no grasp of instruction formats, DCBs or the 
proper
use of I/O macros. I will not go into the details here ... the ASSEMBLER 
people know

what I'm talking about, and the others are not interested.

Kind regards

Bernd


Am 05.09.2023 um 18:00 schrieb Bill Johnson:

Why do you doubt it? Is it because you hope it doesn’t? Certainly, one of you 
assembler geniuses could test it.

Like Mullins said, and others mentioned, most companies that run z/OS don’t 
need assembler programmers. That numbers in the thousands if not ten thousand. 
Whereas ISV’s who are the likely users of Assembler programming, number in the 
hundreds, maybe. So install on Systems Programmers.


Sent from Yahoo Mail for iPhone


On Tuesday, September 5, 2023, 11:43 AM, Steve Thompson  wrote:

I doubt it will assemble. And even if it does, the results are
unpredictable, other than it will probably ABEND for one reason
or another.

There are no DCB, OPEN, CLOSE macros while GET and PUT are being
used.

Me thinks this AI system is confusing a few different assembly
languages together. I wonder how close they came for DOS I/O.
Steve Thompson



On 9/5/2023 11:20 AM, Tom Marchant wrote:

You're right, Tom. That is not a program. Certainly not one that will do what 
it claims to do.

-- Tom Marchant On Mon, 4 Sep 2023 10:42:51 -0700, Tom Brennan
 wrote:

I can't be sure I formatted it properly, but after looking over the
code, I have nothing to say but WTF? 

           PRINT NOGEN
           TITLE 'Simple Addition Program'
** Define storage for input numbers and result
*
NUM1    DS    F            First input number
NUM2    DS    F            Second input number
RESULT  DS    F            Result of addition
** Main program
*
MAIN    C      0        NUM1  Check if NUM1 is zero
           BE    ZERO            Branch to ZERO if true
** Read the first number from input
*
           GET    NUM1,NUMIN      Read NUM1 from input
           LA    0,NUM1          Load NUM1 into register
** Read the second number from input
*
           GET    NUM2,NUMIN      Read NUM2 from input
           A      NUM1,NUM2      Add NUM1 and NUM2
           ST    NUM1,RESULT    Store the result in RESULT
** Print the result
*
           PUT    RESULT,NUMOUT  Print the result
** Terminate the program
*
           SR    15,15          Set return code to 0
           BR    14              Return to caller
** Define input and output areas
*
NUMIN    DC    F'0'          Input buffer for numbers
NUMOUT  DC    F'0'          Output buffer for result
ZERO    DC    F'0'          Constant zero
           END  MAIN            End of program

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: Is the IBM Assembler List still alive

2023-09-05 Thread Bernd Oppolzer


Hi Peter,

this reminds me of another story ...

some day my customer (a large insurance company here in Germany) asked 
me to talk with their IBM rep,
because we had a severe problem with one of the DB2 components which I 
discovered, and I was asked to
have IBM fix it or otherwise provide a solution of my own (it was in the 
DB2 interface for Batch - CAF - IIRC,
and it used 5 % of the overall CPU in some of our IMS regions simply by 
walking sequentially through

some MVS control blocks chains)

So I called the IBM rep, and the first thing he asked me was: "are you a 
systems programmer"?
and, although I wasn't sure at that time what that means, I said: "yes, 
but why do you want to know?",

and he said: "well, if not, we're not gonna talk with you"

:-)

Kind regards

Bernd


Am 04.09.2023 um 16:23 schrieb Peter Sylvester:

Namen sind Schall und Rauch,

Some parts of the discussion reminds me to Lewis Carroll, Through the 
looking glass.


It reminds me to the citation that that I made in ibmmail descript

https://www.funet.fi/pub/doc/netinfo/EARN/ (There are some other 
gems in that directory).


"song" = "what is your profession."


Peter Sylvester




--
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: Is the IBM Assembler List still alive

2023-09-05 Thread Bernd Oppolzer


I offer training classes,
Steve Thompson does.

If a company really wants ASSEMBLER training, they can find it here.


Am 04.09.2023 um 22:35 schrieb Bill Johnson:

I love how many of you downplay others who don’t do what you do. And act like 
it’s inferior. Plus, puff yourselves up simply for programming in Assembler. I 
made a boatload of money in 40+ years performing nearly every task on the 
mainframe. I can also code in Assembler, just never needed to. Assembler is 
still dying, as the Assembler listserv attests. Plus, the fact it’s nearly 
impossible to find a company that offers training classes in it.




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

Re: Is the IBM Assembler List still alive

2023-09-05 Thread Bernd Oppolzer

So your JCL expertise qualifies you as a systems programmer ... that's 
interesting.


Am 04.09.2023 um 17:57 schrieb Bill Johnson:

To claim people who don’t code assembler or read dumps aren’t systems 
programmers is idiotic.

...

I learned zero JCL in college. I learned and became an expert at EDS. But, 
college gave me the wherewithal to know how to study and succeed.



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

Re: Is the IBM Assembler List still alive

2023-09-04 Thread Bernd Oppolzer


FWIW:

I have a computer science degree from the university of Stuttgart, 
Germany (from 1977 to 1985).
We learned Pascal first, then different Assembler languages. During my 
studies, I got interested in
compiler construction, and I am the maintainer of the New Stanford 
Pascal compiler today, look here:

http://bernd-oppolzer.de/job9.htm

Later I learned Fortran, RPG, COBOL, PL/1, REXX of course ...

During my career I met many very sharp people who didn't have a degree 
(only some sort of
on-site education, starting as an insurance specialist, for example, 
then changing to the IT department),
but they had the same (system) programming skills that I had. The degree 
is not what made me a
systems programmer. But I would not accept someone as a systems 
programmer who cannot program
in ASSEMBLER (on IBM mainframes) or in C (at Unix and Windows 
platforms). All others IMO are

some sort of admins.

Regarding "machine code": I also did classes for dump analysis, and one 
of my students said,

Bernd is reading dumps of machine code like others read the newspaper :-)
I don't want to do that; my Pascal compiler writes language specific 
dumps, where the variables
and there contents are shown in Pascal syntax, but if there are no such 
tools, and nothing helps
and the error must be solved, I read the hex dumps, of course. No matter 
if the system is MVS or VSE.


Kind regards

Bernd


Am 04.09.2023 um 04:56 schrieb Bill Johnson:

Nothing more arrogant than saying someone isn’t a systems programmer unless 
they have my abilities. And your education is meaningless, just ask Gabe 
Goldberg or “machine language” Bernd.





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

Re: Is the IBM Assembler List still alive

2023-09-03 Thread Bernd Oppolzer


+1

and I believe, I said virtually the same before, that makes 2 persons :-)


Am 03.09.2023 um 22:41 schrieb g...@gabegold.com:

That "one person's experience" was widely shared among the VM community -- 
hundreds of people collectively helping their installations benefit from what assembler 
language enables.

You might consider taking your own advice: 1 persons experience doesn’t prove 
anything.

"The fact is..." is an assertion, not a fact. It's contradicted by a great many 
people who've used assembler to advance careers and benefit their employers.

Given the number of critical bugs fixed by customers, and the number of customer system 
enhancements merged into IBM product code, sometimes NOT "making changes to 
delivered software" can be dangerous.

Assembler -- machine language -- is what actually executes, no matter what 
high-level language or utility uses/produces it. So understanding it helps 
understand much broader concepts.

Your not encountering it among your colleagues might speak more about you and 
your colleagues than assembler language itself.

Why advocate ignorance of a fundamental part of the platform for which you're 
such a relentless cheerleader?

This is a silly argument -- you dismiss and deprecate something you never 
learned; that's an uninformed position to take, no matter how many colleagues 
you've met in your many, many jobs.

Surely it's a specialized skill -- which you never acquired -- but that doesn't 
make it unimportant.

On Sun, 3 Sep 2023 16:37:39 +, Bill Johnson  wrote:


1 persons experience doesn’t prove anything ...


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

Re: Is the IBM Assembler List still alive

2023-09-02 Thread Bernd Oppolzer


Not true. I'm currently working for 2 customers (insurance companies),
both use "high level" languages like COBOL and PL/1 (and C), but in both 
companies
there is a need for ASSEMBLER coding now and then, be it enhancement to 
compile supporting routines
retrieving sources from CA Librarian libraries (where the software 
supplier does it wrong)
or diagnose programs for checking out IBM errors in CICS web service 
interfaces
or maintenance for tools that the customer wrote in the 1980s (in 
ASSEMBLER) etc. etc.


In both companies I'm the only person who still can code ASSEMBLER, and 
that's the reason

why I'm always busy and still working (I'm 64 now).

Furthermore, if you know ASSEMBLER, you can support the COBOL and PL/1 
co-workers, when it
comes to performance analysis and dump reading etc., because you can 
tell the meaning of the
statements around the error location by looking at the machine code or 
the ASSEMBLER code in compile listings


If you still have a large ASSEMBLER code base, you also need people 
capable of managing it;
unfortunately, management does not always accept this simple truth. Same 
goes, if you plan
to migrate such applications to another platform; you will never 
succeed, if you don't listen

to the ASSEMBLER experts who know what's inside the applications.

Fun fact: in a migration project, which ran into problems recently 
because of bad analysis and planning,
the management now calls the people with knowledge "insiders" ... much 
the same way like insiders
in stock trade. This IMO is very disrespectful; we didn't refuse to tell 
the managers what we know etc.;

we simple weren't asked.

Kind regards,
have a nice weekend

Bernd



Am 01.09.2023 um 16:43 schrieb Bill Johnson:

Which proves my point from a prior thread that coding and using assembler is 
almost nonexistent.


Sent from Yahoo Mail for iPhone





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

Re: Basic VM/CMS question (GENMOD)

2023-07-15 Thread Bernd Oppolzer

Thank you very much ... I have legacy code here which is from 1979 and 
1982,
and the primary targets are VM/370 and MVS 3.8, but I'm very happy that 
it runs
on current z/OS and current z/VM, too ... and it will sure run after 
some minor corrections
also from "real" MODULEs and not only via LOAD and START on z/VM. 
Although limited
to AMODE 24 / RMODE 24, at the moment, but I'm working on this 
restriction, too.


My New Stanford Pascal compiler was already promoted by IBM on a "free 
tools for z/OS" website

some years ago.

http://bernd-oppolzer.de/job9.htm

Kind regards

Bernd


Am 14.07.2023 um 15:03 schrieb Alan Altmark:

You'll get plenty of help over in the IBMVM mailing list.

When you issue the LOAD prior to the GENMOD, be sure to include the RLDSAVE 
option.  This ensures that your program can be loaded anywhere in memory, and 
CMS will not overlay the current program.  In fact, the first MODULE can invoke 
another MODULE without worrying about overlays.  That code you have to read the 
module header isn't needed.

This functionality was introduced into CMS around 1985 (VM/SP Release 4). In 
general, VM/370 is not a good place to develop applications that you intend to 
run on z/VM.

Alan Altmark
IBM

--
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: Userid schemes

2023-07-13 Thread Bernd Oppolzer


In my customer's company, we had such a scheme for decades:

first letter X for external, S or L for division
next letter S or M or K ... for city (where the department is located)
then two digits department number (38, 91, 95, ...)
then three chars from the name (OPP in my case)

that made XS95OPP for me.

Easy to remember, even for the (some hundred) co-workers who knew me and 
needed to communicate with me
over internal network or (today) via e-Mail. The mainframe user name is 
an e-Mail Alias, of course.


But really bad, if someone moves to another department or city; you 
either get rid of all your RACF rights

or the userid doesn't reflect the real allocations any more.

So now for some years, we have generic userids for the new users, which 
are allocated to RACF groups.


Because I left the company some years ago and returned later, I now have 
a userid, which doesn't tell
anything; a simple 7-letter or digit sequence like CCBUG7E; this will 
stay the same, no matter if I move to
another department. But no one can remember my userid; they always have 
to look it up in a web based
application in the intranet (much more then 10.000 employees in Germany 
alone).


Kind regards

Bernd


Am 14.07.2023 um 00:39 schrieb Lennie Dymoke-Bradshaw:

I generally dislike those schemes that make use of departments or projects,
as this means a new id must be assigned when the employee moves department.
However, some may argue this has its own benefit, as it prevents inheritance
of authorities in those situations.

Lennie
Lennie Dymoke-Bradshaw
https://rsclweb.com
'Dance like no one is watching. Encrypt like everyone is.'



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

Re: Change how LE allocates storage (subpool,key)

2023-07-13 Thread Bernd Oppolzer

This is an example for the options for the alternate LE heap manager for 
memory checks (CEL4MCHK):


//CEEOPTS  DD *
ALL31(ON),
STACK(3M,1M,ANY,KEEP),
HEAP(4K,4K,ANY,KEEP),
STORAGE(NONE,NONE,NONE,0),
RPTSTG(ON),RPTOPTS(ON),
ENVAR("_CEE_HEAP_MANAGER=CEL4MCHK",
"_CEE_MEMCHECK_TRACE=ON",
"_CEE_MEMTRACE_DEPTH=32",
"_CEE_MEMCHECK_DEPTH=32",
"_CEE_MEMCHECK_OVERLAY=OFF",
"_CEE_MEMCHECK_OVERLAYLEN=80")

Maybe it is possible (don't know) to write a heap manager of your own 
and to specify its name here,
or: to specify the name of a modified version of the Standard LE heap 
manager (with other subpools)

or: a modified version of CEL4MCHK with traces disabled
or ???

In any case, I personally would not change the behaviour of standard LE 
in the first place.


HTH, kind regards

Bernd


Am 14.07.2023 um 01:55 schrieb Bernd Oppolzer:
If there is no explicit LE option to override the standard subpools 
(which are 1 and 2, AFAIK),
then I would try to use the LE option which allows to have an 
alternate heap handler
and use a modified version of the standard LE handler. I don't recall 
the names of the runtime options,
but I used them in the past to have LE heap checks enables; that's an 
alternate LE heap handler
which writes messages about allocated and not freed storage areas ... 
I used that when looking

for memory leaks with certain C++ applications.

If you don't know what I'm talking about, I can search my archives and 
maybe find the names
of these options and some sort of presentation (IBM's or my own) on 
the topic.


But: that's only for heap storage, not for stack. Why do you want to 
have the STACK allocated
in another subpool? Normally stack allocation is not a problem; heap 
is where the problems are.


Look here: http://bernd-oppolzer.de/stackheap.pdf

HTH, kind regards

Bernd


Am 14.07.2023 um 00:11 schrieb Binyamin Dissen:

I would like to have LE use SP=132 KEY=9 for its STACK and HEAP.

I obviously could screw with CEEINT, but I don't know if that will 
affect

other storage requests.

Is there some explicit getmain routine that I can play with?

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

Director, Dissen Software, Bar & Grill - Israel

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


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

Re: Change how LE allocates storage (subpool,key)

2023-07-13 Thread Bernd Oppolzer

If there is no explicit LE option to override the standard subpools 
(which are 1 and 2, AFAIK),
then I would try to use the LE option which allows to have an alternate 
heap handler
and use a modified version of the standard LE handler. I don't recall 
the names of the runtime options,
but I used them in the past to have LE heap checks enables; that's an 
alternate LE heap handler
which writes messages about allocated and not freed storage areas ... I 
used that when looking

for memory leaks with certain C++ applications.

If you don't know what I'm talking about, I can search my archives and 
maybe find the names
of these options and some sort of presentation (IBM's or my own) on the 
topic.


But: that's only for heap storage, not for stack. Why do you want to 
have the STACK allocated
in another subpool? Normally stack allocation is not a problem; heap is 
where the problems are.


Look here: http://bernd-oppolzer.de/stackheap.pdf

HTH, kind regards

Bernd


Am 14.07.2023 um 00:11 schrieb Binyamin Dissen:

I would like to have LE use SP=132 KEY=9 for its STACK and HEAP.

I obviously could screw with CEEINT, but I don't know if that will affect
other storage requests.

Is there some explicit getmain routine that I can play with?

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

Director, Dissen Software, Bar & Grill - Israel

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


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

Re: Basic VM/CMS question (GENMOD)

2023-07-11 Thread Bernd Oppolzer


Sorry, I have to apologize ...
the error is NOT a GENMOD problem,
instead the message is written by XRUNPARM itself, when it tries to load 
the GENMODed Pascal program ...
I should have looked there first. Didn't remember that XRUNPARM does 
such a BADSIZE check,

because it worked for decades, and I never saw such a message.

There must have been some changes in z/VM, compared to prior versions, 
which invalidate the size

computations of XRUNPARM, see this logic:

    MVC   PROGNAME,PLSTPROG    OBTAIN PROGRAM NAME
    MVC   MODNAME,PROGNAME INSERT PROGRAM NAME IN FSCB
    FSSTATE FSCB=MODFSCB,ERROR=NOMODULE ENSURE PROGRAM EXISTS
    USING FSTD,R1
    MVC   MODMODE,FSTFMODE SET FILE MODE
    DROP  R1
    FSREAD FSCB=MODFSCB,ERROR=BADMOD    READ MODULE DESCRIPTOR
    FSCLOSE FSCB=MODFSCB   CLOSE MODULE FILE
    LA    R5,MODESCR   POINT TO MODULE DESCRIPTOR
    USING STRTADDR,R5
    LA    R0,ENDRUN    POINT TO END OF INTERFACE
    C R0,FRSTLOC   DOES MODULE OVERLAY INTERFACE ?
    BH    BADORG   YES
    L R2,LASTLOC   OBTAIN LAST LOCATION ADDRESS
    S R2,FREELOWE  WILL MODULE FIT IN STORAGE ?
    BP    BADSIZE  YES

I will have to examine this and try to find out what's wrong with this 
in modern z/VM.


Sorry again, have a nice day.

Bernd


Am 11.07.2023 um 22:50 schrieb Bernd Oppolzer:
Update: the error only occurs, if I specify the ORIGIN parameter on 
the LOAD command;
if I don't, the first object is loaded at hex 2, and the GENMOD 
works without problems.


But: because my command line mapping program (XRUNPARM) runs first and 
then calls the
Pascal program, the Pascal program needs to have the ORIGIN 20580 ... 
XRUNPARM is loaded at X'2'.


And: when I specify 20580 as origin, I get errors like below,
maybe directly on the GENMOD

or later, when XRUNPARM tries to load the GENMODed Pascal program:

Ready;
xrunparm fibok
"FIBOK MODULE A1" REQUIRES 246K MORE STORAGE
Ready(00104);

???

Any suggestion is appreciated ...

Kind regards

Bernd



Am 11.07.2023 um 22:24 schrieb Bernd Oppolzer:

Hello all,

I know that this is maybe not the right list for asking questions on 
the VM/CMS system,
but forgive me ... I am registered to many lists, but no VM list, and 
today I have a problem

which could be a simple problem, so I would like to try it here.

I am trying to build my Pascal compiler on a z/VM machine which is 
new to me.
It worked already on old VM/370 R6 machines and also on other flavors 
of VM,

but I never did it on a recent z/VM.

To get the Pascal programs running, it is important to build modules 
using GENMOD.
Because the Pascal programs on VM work much the same as the z/OS 
versions,
and the mapping of the VM command line (instead of the z/OS JCL parm) 
is done by
another small module which runs BEFORE the pascal program ... and 
this module

then calls the Pascal program MODULE.

So I need GENMOD on my Pascal programs to work.

But:

when I do GENMOD on my Pascal programs on this particular machine,
it always complains about not enough storage.

Thats ridiculous, because there is plenty of virtual storage (512 M).

I can do the GENMOD on only small parts of the Pascal module, like this:

LOAD PASMONN PASLIBX PASUTILS PASSNAPC FIBOK ...
GENMOD FIBOK ( FROM $PASENT TO ERRMON
"FIBOK MODULE A1" REQUIRES 135K MORE STORAGE
Ready(00104);

LOAD PASMONN PASLIBX PASUTILS PASSNAPC FIBOK ...
GENMOD FIBOK ( FROM $PASENT TO $PASINT
"FIBOK MODULE A1" REQUIRES 131K MORE STORAGE
Ready(00104);

LOAD PASMONN PASLIBX PASUTILS PASSNAPC FIBOK ...
GENMOD FIBOK ( FROM $PASENT TO $PASMAIN
"FIBOK MODULE A1" REQUIRES 244K MORE STORAGE
Ready(00104);

... as you can see, the amount of storage required increases with the 
size of

the module part that I want to be GENMODed.

BTW: if I do LOAD and then START, the Pascal program runs without 
problems.
But then I have other problems, because I cannot pass the CMS command 
line
as runtime parameters to the Pascal program (which works on other 
versions of VM,

using the GENMODed variants of my Pascal programs).

It seems as if the GENMOD here has an own storage limit which is VERY 
LOW,

and even small parts of the loaded Pascal program cannot be GENMODed.

What am I missing?

This is (AFAIK) zVM 7.2.

Thanks a lot, best 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


--
For IBM-MAIN subscribe / signoff / archive

Re: Basic VM/CMS question (GENMOD)

2023-07-11 Thread Bernd Oppolzer

Update: the error only occurs, if I specify the ORIGIN parameter on the 
LOAD command;
if I don't, the first object is loaded at hex 2, and the GENMOD 
works without problems.


But: because my command line mapping program (XRUNPARM) runs first and 
then calls the
Pascal program, the Pascal program needs to have the ORIGIN 20580 ... 
XRUNPARM is loaded at X'2'.


And: when I specify 20580 as origin, I get errors like below,
maybe directly on the GENMOD

or later, when XRUNPARM tries to load the GENMODed Pascal program:

Ready;
xrunparm fibok
"FIBOK MODULE A1" REQUIRES 246K MORE STORAGE
Ready(00104);

???

Any suggestion is appreciated ...

Kind regards

Bernd



Am 11.07.2023 um 22:24 schrieb Bernd Oppolzer:

Hello all,

I know that this is maybe not the right list for asking questions on 
the VM/CMS system,
but forgive me ... I am registered to many lists, but no VM list, and 
today I have a problem

which could be a simple problem, so I would like to try it here.

I am trying to build my Pascal compiler on a z/VM machine which is new 
to me.
It worked already on old VM/370 R6 machines and also on other flavors 
of VM,

but I never did it on a recent z/VM.

To get the Pascal programs running, it is important to build modules 
using GENMOD.
Because the Pascal programs on VM work much the same as the z/OS 
versions,
and the mapping of the VM command line (instead of the z/OS JCL parm) 
is done by
another small module which runs BEFORE the pascal program ... and this 
module

then calls the Pascal program MODULE.

So I need GENMOD on my Pascal programs to work.

But:

when I do GENMOD on my Pascal programs on this particular machine,
it always complains about not enough storage.

Thats ridiculous, because there is plenty of virtual storage (512 M).

I can do the GENMOD on only small parts of the Pascal module, like this:

LOAD PASMONN PASLIBX PASUTILS PASSNAPC FIBOK ...
GENMOD FIBOK ( FROM $PASENT TO ERRMON
"FIBOK MODULE A1" REQUIRES 135K MORE STORAGE
Ready(00104);

LOAD PASMONN PASLIBX PASUTILS PASSNAPC FIBOK ...
GENMOD FIBOK ( FROM $PASENT TO $PASINT
"FIBOK MODULE A1" REQUIRES 131K MORE STORAGE
Ready(00104);

LOAD PASMONN PASLIBX PASUTILS PASSNAPC FIBOK ...
GENMOD FIBOK ( FROM $PASENT TO $PASMAIN
"FIBOK MODULE A1" REQUIRES 244K MORE STORAGE
Ready(00104);

... as you can see, the amount of storage required increases with the 
size of

the module part that I want to be GENMODed.

BTW: if I do LOAD and then START, the Pascal program runs without 
problems.
But then I have other problems, because I cannot pass the CMS command 
line
as runtime parameters to the Pascal program (which works on other 
versions of VM,

using the GENMODed variants of my Pascal programs).

It seems as if the GENMOD here has an own storage limit which is VERY 
LOW,

and even small parts of the loaded Pascal program cannot be GENMODed.

What am I missing?

This is (AFAIK) zVM 7.2.

Thanks a lot, best 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

Basic VM/CMS question (GENMOD)

2023-07-11 Thread Bernd Oppolzer


Hello all,

I know that this is maybe not the right list for asking questions on the 
VM/CMS system,
but forgive me ... I am registered to many lists, but no VM list, and 
today I have a problem

which could be a simple problem, so I would like to try it here.

I am trying to build my Pascal compiler on a z/VM machine which is new 
to me.
It worked already on old VM/370 R6 machines and also on other flavors of 
VM,

but I never did it on a recent z/VM.

To get the Pascal programs running, it is important to build modules 
using GENMOD.

Because the Pascal programs on VM work much the same as the z/OS versions,
and the mapping of the VM command line (instead of the z/OS JCL parm) is 
done by
another small module which runs BEFORE the pascal program ... and this 
module

then calls the Pascal program MODULE.

So I need GENMOD on my Pascal programs to work.

But:

when I do GENMOD on my Pascal programs on this particular machine,
it always complains about not enough storage.

Thats ridiculous, because there is plenty of virtual storage (512 M).

I can do the GENMOD on only small parts of the Pascal module, like this:

LOAD PASMONN PASLIBX PASUTILS PASSNAPC FIBOK ...
GENMOD FIBOK ( FROM $PASENT TO ERRMON
"FIBOK MODULE A1" REQUIRES 135K MORE STORAGE
Ready(00104);

LOAD PASMONN PASLIBX PASUTILS PASSNAPC FIBOK ...
GENMOD FIBOK ( FROM $PASENT TO $PASINT
"FIBOK MODULE A1" REQUIRES 131K MORE STORAGE
Ready(00104);

LOAD PASMONN PASLIBX PASUTILS PASSNAPC FIBOK ...
GENMOD FIBOK ( FROM $PASENT TO $PASMAIN
"FIBOK MODULE A1" REQUIRES 244K MORE STORAGE
Ready(00104);

... as you can see, the amount of storage required increases with the 
size of

the module part that I want to be GENMODed.

BTW: if I do LOAD and then START, the Pascal program runs without problems.
But then I have other problems, because I cannot pass the CMS command line
as runtime parameters to the Pascal program (which works on other 
versions of VM,

using the GENMODed variants of my Pascal programs).

It seems as if the GENMOD here has an own storage limit which is VERY LOW,
and even small parts of the loaded Pascal program cannot be GENMODed.

What am I missing?

This is (AFAIK) zVM 7.2.

Thanks a lot, best regards

Bernd

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

Re: Checkpoint/restart in COBOL applications?

2023-06-18 Thread Bernd Oppolzer


I don't understand what's the implication of z/OS here;
we are using Smart/Restart, too, but IMO this is only application 
programming,

no support from the OpSys needed.

Applications running with Smart/Restart write Checkpoints with every DB2 
Commit,
that is, they record the keys involved with the controlling DB2 cursors 
AND the read and
write positions of the sequentials files in a Smart/Restart specific 
Checkpoint area
(which can be a DB2 table, but also sequential files). On restart, the 
DB2 cursors need to be repositioned,
same goes for the sequential files. But IMO that's all application 
business ...


I don't see how the OpSys is involved here ... other than the basic 
services

(DB2 Commit and positioning of files) must be provided.

Kind regards

Bernd


Am 18.06.2023 um 09:59 schrieb Binyamin Dissen:

On Sat, 17 Jun 2023 19:50:01 -0700 Tom Ross 
wrote:

:>  Does anyone know if there are people/applications using checkpoint/restart 
in
:>COBOL applications?  The doc only shows it is usable in programs that use 
SORT,
:>I have not heard of customers doing this in years, but someone in IBMMAIN 
would
:>know better than me!  The reason for the question is that IBM is considering
:>removing that capability from z/OS and we are wondering how much of an impact,
:>if any, this would be on COBOL applications?  (Actually PL/I also, but I work
:>in COBOL so kind of focused on that :-)

The Smart/Restart product uses it and runs COBOL applications.

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

Director, Dissen Software, Bar & Grill - Israel

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


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

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

2023-05-02 Thread Bernd Oppolzer


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

You say:

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

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


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

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

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

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

HTH, kind regards

Bernd


Am 02.05.2023 um 19:08 schrieb Schmitt, Michael:

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

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

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


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


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

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

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

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

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

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

Peter
--


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

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

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


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

Re: LE runtime

2023-04-06 Thread Bernd Oppolzer

I recall that if you use certain language constructs, the binder 
complains about

"this object requires PO format 3 and cannot be stored in a load module";
maybe if you initialize a static value using a function call (which is 
not valid in ANSI C).


I once had the need to convert such a C++ function to ANSI C, because 
one branch of
my customer doesn't allow C++ ... the other branch does, and I had to 
copy a routine
which creates UUIDs from the other branch. To do this in C, I had to get 
rid of the
initialization of the (writable) static data by using a function call. 
In C, it is not possible
to do function calls when initalizing static data; static data is 
initialized at enclave creation
time, and the C language description allows only constants at this time, 
no function calls.
Load modules (in the NORENT case) initialize their static data at 
compile time by
CSECT formatting. With RENT, a compiler created initialization routine 
is called, but with C,

it is not possible that this routine calls "user" routines.

Of course, if you don't do this and you use only features that could 
also be simulated

using ANSI C, you maybe don't have this problem.

So my opinion is: not all C++ programs require PDSEs, but there are 
some, which require

program objects format 3, and these will, of course, require PDSEs.

Kind regards

Bernd


Am 07.04.2023 um 02:12 schrieb Charles Mills:

C++ can produce object code that can be linked into a traditional load module 
in a PDS. I do it all the time.

Charles

On Thu, 6 Apr 2023 09:18:28 +0200, Bernd Oppolzer  
wrote:


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.

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

2023-04-06 Thread Bernd Oppolzer

IMO, the other languages (PL/I, C) also support building program objects 
and very large
programs (> 16 MB), but COBOL with the newest compiler version REQUIRES 
even small
programs to live in PDSEs (as program objects) and does not allow old 
(classic) load modules.


I'm not sure about this, but IMO in some places in the OS "old" load 
modules are still required
and program objects living in PDSEs cannot be used, maybe because PDSE 
support requires
some help from the OS, and this is not available in the very early 
stages after IPL.


Maybe, OTOH, nobody wants COBOL programs there ... these modules are 
probably

PL/X or ASSEMBLER or Metal C ...

I cannot imagine a monolithic program with code size larger than 16 MB, 
and a program which has
static tables bigger than 16 MB is, IMHO, a design failure. But this is 
maybe an old school point of view ...


Kind regards

Bernd


Am 07.04.2023 um 01:09 schrieb Attila Fogarasi:

Cobol first started to use PDS/E in 2001 when exploiting new Cobol support
for long program names, object-oriented programs and for using the Binder
for DLLs instead of the prelinker.  Program objects also cured the 16MB
maximum load module size which was becoming a problem (PO size limit is
1GB).   There are probably other Cobol language features which require
PDS/E.  I'm pretty sure this was just after Y2K, so over 20 years ago now.
Getting old enough to be called legacy :)




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

Re: LE runtime

2023-04-06 Thread Bernd Oppolzer

I don't know much about the specific output formats that the compilers 
produce,
but in the installations I know, the Binder is used to produce the load 
modules;
this is necessary because run time objects have to be linked together 
with the

output coming from the compiler.

In my historic MVS environment, I see that the compiler output is recfm 
FB 80;
the well known ESD - RLD - TXT format. Don't know if this is still in 
use today (in modern
environments). The record format of the load libraries is something like 
U 19069

(valid until today, AFAIK).

GOFF, AFAIK, is a more modern output format ... don't know if this applies
to the PL/1 and C compilers and to the output of the compilers in general
(and input to the linkers or binders).

BTW: I didn't say "strange debugging option"; what is strange IMO is the 
fact
that COBOL requires the modules in PDSEs not because the language needs 
this,
but only to support some debugging tools, which could IMO store their 
information

at another place. But the COBOL community seems to have accepted this move.

Kind regards

Bernd


Am 06.04.2023 um 14:25 schrieb Seymour J Metz:

Directly, or via GOFF to Binder?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Thursday, April 6, 2023 3: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

Re: LE runtime

2023-04-06 Thread Bernd Oppolzer


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

Re: Unzip on z/OS ?

2023-04-04 Thread Bernd Oppolzer


Found it, from 1996 :-)

 TITLE 'CCREGS - REGISTERSTAENDE VON C AUS ERMITTELN'
*
**
**
  
 PROGRAMM:  C C R E G S   
 PROGRAMMIERER: OPP   
 DATUM: 09.96 
  
 PROGRAMMBESCHREIBUNG:    
  
 AKTUELLE REGISTERSTAENDE INNERHALB EINES 
 C-MODULS ERMITTELN   
  
 DIE FUNKTION CCREGS ERHAELT ZWEI PARAMETER:  
  
 - EINEN ZEIGER AUF EINEN VEKTOR AUS 16 ZEIGERN   
   FUER DIE AUFNAHME DER REGISTER 0 BIS 15    
  
 - EINEN ZEIGER AUF EINEN VEKTOR AUS 4 DOUBLES    
   FUER DIE GLEITKOMMAREGISTER 0, 2, 4 UND 6  
  
 C-DEKLARATION: int ccregs (void **, double *);   
  
**
**
*
CCREGS   CSECT
*
R0   EQU   0
R1   EQU   1
R2   EQU   2
R3   EQU   3
R4   EQU   4
R5   EQU   5
R6   EQU   6
R7   EQU   7
R8   EQU   8
R9   EQU   9
RA   EQU   10
RB   EQU   11
RC   EQU   12
RD   EQU   13
RE   EQU   14
RF   EQU   15
*
 USING CCREGS,RF
 B WEITER  UEBERSPRINGEN DER KENNUNG
 DC    AL1(23)
 DC    CL23'CCREGS  //'
*
WEITER   DS    0H
 STM   RE,RC,12(RD)    REGISTER SICHERN
 LR    RB,RF   BASISREGISTER 11 SETZEN
 DROP  RF
 USING CCREGS,RB
*
 L R2,0(R1)
 MVC   0(52,R2),20(RD) REGISTER 0 BIS 12 AUS SAVEAREA
 ST    RD,52(R2)   REGISTER 13
 MVC   56(8,R2),12(RD) REGISTER 14 UND 15 AUS SAVEAREA
*
 L R2,4(R1)
 STD   0,0(R2) GLEITKOMMAREGISTER NULL
 STD   2,8(R2) BIS SECHS
 STD   4,16(R2)
 STD   6,24(R2)
*
 LM    RE,RC,12(RD)    REGISTER ZURUECKLADEN
 XR    RF,RF
 BR    RE
*
 END   CCREGS


Am 05.04.2023 um 03:43 schrieb Bernd Oppolzer:

Am 04.04.2023 um 23:37 schrieb Charles Mills:
I just had a similar problem: "how do you determine your entry R0 
from C?" I asked here and got no answer.


with native C, this is not possible IMO;

what I did: I wrote a (very small) ASSEMBLER routine which can be 
called from everywhere and simply stores
the actual values of the registers 0 to 15 in a vector of 16 void 
pointers passed by the C caller.


something like

extern void ccregs (void **regs);

void *regtable [16];

...

ccregs (regtable);

this way, you get - for example - regtable [13], which is the content 
of GR 13 at the time of the ccregs call.
GR 13 points to the current save area a.k.a. stack frame. From this 
save area, you can walk up to the
save area of the caller and find the registers at the time of the call 
of the current function ... this can
all be done using C. It is, BTW, even possible to analyse the whole 
save area chain this way,
including the names and addresses etc. of the surrounding stack 
frames, and the entry point,
return addresses and so on ... a complete stack trace, if you want. 
All this can be done during program run,

without interrupting or abending the current process or function.

Finding the R0 at the time of the call is very simple, once you have 
the current R13.


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: Unzip on z/OS ?

2023-04-04 Thread Bernd Oppolzer


Am 04.04.2023 um 23:37 schrieb Charles Mills:

I just had a similar problem: "how do you determine your entry R0 from C?" I 
asked here and got no answer.


with native C, this is not possible IMO;

what I did: I wrote a (very small) ASSEMBLER routine which can be called 
from everywhere and simply stores
the actual values of the registers 0 to 15 in a vector of 16 void 
pointers passed by the C caller.


something like

extern void ccregs (void **regs);

void *regtable [16];

...

ccregs (regtable);

this way, you get - for example - regtable [13], which is the content of 
GR 13 at the time of the ccregs call.
GR 13 points to the current save area a.k.a. stack frame. From this save 
area, you can walk up to the
save area of the caller and find the registers at the time of the call 
of the current function ... this can
all be done using C. It is, BTW, even possible to analyse the whole save 
area chain this way,
including the names and addresses etc. of the surrounding stack frames, 
and the entry point,
return addresses and so on ... a complete stack trace, if you want. All 
this can be done during program run,

without interrupting or abending the current process or function.

Finding the R0 at the time of the call is very simple, once you have the 
current R13.


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

Re: ASM call by value

2023-04-02 Thread Bernd Oppolzer


Now I'll try an answer to the other question(s), see below ...


Am 03.04.2023 um 01:32 schrieb Paul Gilmartin:

Are the external semantics (not examining the generated assembly) of
"pass by content" any different from "pass by value"?   How?


maybe not


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.


I don't think so.

If the copy would be done by the called routine, you would need two 
copies ...

first you would need to copy the addresses of the parameters to the stack
(because otherwise the called routine would not know where to copy the 
parameters from)
and then the second copy in the called routine, which copies the values 
from the original place
in the caller's area to the stack frame of the called routine. This 
takes more time to do it
and additional stack space for the address list, and: this is true IMO, 
no matter what platform
you are running on. It is therefore better to copy the values to the 
parameter list directly and
this must be done by the caller; the caller has to prepare the parameter 
list. BTW: this is done
this way by every compiler that I am aware of, my New Stanford Pascal 
compiler and every

other compiler that I have examined in the last years, different platforms.

This is maybe a time to space tradeoff, in the end ... but all compilers 
decide for time saving.


BTW: that's why IMO it's important to make a sharp distinction between 
call by value
as described above and - for example - PL/1 dummy arguments, which is in 
fact call by
reference with a copy of parameter values before - this is what COBOL 
calls "call by content".
For the called routine there is no difference between call by reference, 
PL/1 dummy arguments

or COBOL's call by content ... all the same.

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

2023-04-02 Thread Bernd Oppolzer


Am 03.04.2023 um 00:37 schrieb Frank Swarbrick:

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 parameter list that contains the addresses of both copied 
fields.


C only supports call by value;
if you want other things like call by reference or "call by content", as 
defined by COBOL,

you have do simulate them by passing pointers by value explicitly
(and in the case of call by content, by copying the parameters before 
passing their addresses).


C is a very small language - the C designers IMO believed that call by 
value is sufficient,
because all other call mechanisms can simulated (maybe not call by name, 
which was

introduced with ALGOL 60 and is very special).

Kind regards

Bernd

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

2023-04-02 Thread Bernd Oppolzer

I will try to answer one of your questions, see below ... kind regards / 
Bernd



Am 03.04.2023 um 01:32 schrieb Paul Gilmartin:

On Sun, 2 Apr 2023 22:37:53 +, 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/?
 ...


you will see the same, except for a chance that the functions may be 
inlined,
if you add the static attribute to them, and if they are small enough to 
enable inlining.


There is no difference in calling sequence between internal (static) and 
external functions.
At least that's the case with IBM's compilers, but I'm almost sure 
Dignus will behave the same.


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

2023-04-02 Thread Bernd Oppolzer

It just came to my mind that for C programmers I have to add the 
following remark:


it is not easy to pass arrays (vectors) by value in C, in contrast to - 
for example - Pascal.
Because in C the name of a vector is equivalent to the address of the 
element of its element zero,
this means that, if you pass a vector in C, you pass THE ADDRESS of the 
first element of the vector,

which in fact implies call by reference.

So, to get a "real" call by value for a vector in C, you have to enclose 
the vector in a struct definition,

because structs are "really" passed by value.

Something like this:

typedef struct
{
   int x [100];
}
int_vector;

void call_by_value_example (int_vector v)
{
}

int main (void)
{
   int_vector a;
   call_by_value_example (a);   // a is copied during call
}

In Pascal, there is no need to do such "struct embedding"; Pascal arrays 
will be passed by value,
if you specify the array name as a parameter (and if the function 
prototype specifies call by value;
in Pascal this is controlled by the VAR keyword ... with VAR: call by 
reference; without VAR: call by value).
And: Pascal doesn't have a rule similar to C, that the array name is the 
address of the first element;

an array is an array in Pascal and nothing else.

I mixed this up when I talked about copies of large structures during 
call by value (in C).
(I'm the maintainer of New Stanford Pascal, BTW - New Stanford Pascal 
has a CONST keyword
on parameters, too, which means: copy and call by reference, much the 
same as dummy arguments

in PL/1 or - as I learned recently - CALL BY CONTENT in COBOL).

Kind regards

Bernd


Am 02.04.2023 um 16:41 schrieb Bernd Oppolzer:

Am 02.04.2023 um 16:29 schrieb Seymour J Metz:
Regardless of the implementation, call by reference is about more 
than efficiency; sometimes a subroutine is required to alter one of 
its parameters, and call by value doesn't allow that.



That's well known;
most C textbooks tell that call by value is impractical for large 
structures or arrays
because of the copy involved; that's why for performance reasons often 
pointers are passed,

although no modification of the parameters passed is desired or required.
That's what I referred to.

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

2023-04-02 Thread Bernd Oppolzer


Am 02.04.2023 um 16:29 schrieb Seymour J Metz:

Regardless of the implementation, call by reference is about more than 
efficiency; sometimes a subroutine is required to alter one of its parameters, 
and call by value doesn't allow that.


That's well known;
most C textbooks tell that call by value is impractical for large 
structures or arrays
because of the copy involved; that's why for performance reasons often 
pointers are passed,

although no modification of the parameters passed is desired or required.
That's what I referred to.

Kind regards

Bernd

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

2023-04-02 Thread Bernd Oppolzer

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.04.2023 um 15:34 schrieb Peter Relson:

I was taught long ago that "call by value" meant simply that whatever the
target routine did to a parameter was not reflected back to the caller's argument. There
are multiple possible implementations. One is to make a copy and pass the argument by
reference to the copy. Another is to pass the actual value (somewhere, somehow).

For what it's worth, the internal PL/X that much of z/OS is written in only supports call by value for the
cases where the argument fits within the "width" of a parameter list entry (by convention, 4-bytes
for an AMODE 31 call, 8-bytes for an AMODE 64 call). PL/X's "call by value" never copies
(accompanied by passing the copy by reference). We have many places where our dynamic storage is strictly
limited such that "copy" is often not a possibility. So what happens if you have something larger
than fits but don't want it changed? Too bad. Or make your own copy. The interface definition shared by the
source and target identifies whether the parameter is to be treated as input-only or not. It is up to the
compiler to help identify places where the target code writes into something that is input-only and passed by
reference.

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

2023-03-30 Thread Bernd Oppolzer


Am 31.03.2023 um 02:12 schrieb Frank Swarbrick:

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.


this is true ... see my other post.

This means that _printf4 cannot by called by a "normal" C program,
if this #pragma linkage(...,OS) is not present at the caller's side

Maybe others have other impressions about the C implementation,
because they regularly use this #pragma linkage or because they use a 
startup macro

which does it under the cover. We don't ...

I saw the "by value" behaviour which I described in detail, when I 
looked almost every day
at dumps of C programs in the 1990s. It was crucial when debugging C 
programs on the mainframe
at that time to be able to read the parameters which are passed between 
C functions ... and there
were lots of functions passing there parameters by value. Internal C 
functions, but they produced
normal save area chains, and it was no problem to walk thru the chains 
and find the parameters

at every call level ...

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

2023-03-30 Thread Bernd Oppolzer


BTW:

this comment and the pragma

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

seems sort of ill-fated to me.

At my old customer's site (which is again my customer since 2021), we 
always had the paradigm
that every module must be able to call every other module, no matter 
what the programming language is,

and the calling module needs not know the language of the module called.

We support PL/1, C and ASSEMBLER.

The interfaces (parameter structures) are defined in a language 
independent way in a global repository,
and macros usable in the three languages are derived automatically from 
this repository. There are
more things to tell like interface version control; automatic 
up-levelling, if versions of interfaces at call time
don't match etc. ... and test tools which support isolated component 
tests, where the test cases are also built

starting from the interface definitions etc. etc.

This said, call by value in C is - at this customer's site - only 
allowed for local functions,
but not when calling external modules (which may be in C, PL/1 or 
ASSEMBLER).
In the second case, only call by reference (that is: pointer to 
structures) is possible,

because that works in all three languages.

Of course, it is kind of hard, if a 3rd party software supplier wants to 
get his software introduced
in this environment ... but it's possible, anyway. Several suppliers did 
it successfully, after we explained them,

what to do (with our help, of course).

Kind regards

Bernd


Am 31.03.2023 um 01:54 schrieb Bernd Oppolzer:


The function @PRINTF4 is also shown in the IBM example:

|/* 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 */ }|



what you see here is the special behaviour because of the #pragma 
linkage(...,OS) ..

this is NOT the standard behaviour of C.

The parameter int i is passed BY ADDR in this case ...
with the #pragma you can override nomal C "by value" behaviour (which 
means,
that the function cannot be called by "normal" C, which doesn't know 
about

this #pragma).

We never allowed the use of #pragma linkage at our site ... that's why 
we had to
build the glue functions to support the 3rd party package in the 
1990s. (Or, IIRC,

we asked the supplier of the software to do this for money).

Kind regards

Bernd



Am 31.03.2023 um 01:42 schrieb Bernd Oppolzer:

See answers below

Am 31.03.2023 um 01:23 schrieb Paul Gilmartin:

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


reg1 parameter list is the address list which register 1 points to.
So there is no practical limit on the size of the parameter list.

Of course, it is impractical to pass large structures or arrays by 
value,

but that's what every C tutorial will tell you ...



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 
<https://www.ibm.com/docs/en/zos/2.5.0?topic=programs-calling-c-code-from-assembler-c-example>

I see:
  EDCPRLG
  LA    1,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.


This @PRINTF4 cannot be the sam

Re: ASM call by value

2023-03-30 Thread Bernd Oppolzer


The function @PRINTF4 is also shown in the IBM example:

|/* 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 */ }|



what you see here is the special behaviour because of the #pragma 
linkage(...,OS) ..

this is NOT the standard behaviour of C.

The parameter int i is passed BY ADDR in this case ...
with the #pragma you can override nomal C "by value" behaviour (which 
means,

that the function cannot be called by "normal" C, which doesn't know about
this #pragma).

We never allowed the use of #pragma linkage at our site ... that's why 
we had to
build the glue functions to support the 3rd party package in the 1990s. 
(Or, IIRC,

we asked the supplier of the software to do this for money).

Kind regards

Bernd



Am 31.03.2023 um 01:42 schrieb Bernd Oppolzer:

See answers below

Am 31.03.2023 um 01:23 schrieb Paul Gilmartin:

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


reg1 parameter list is the address list which register 1 points to.
So there is no practical limit on the size of the parameter list.

Of course, it is impractical to pass large structures or arrays by value,
but that's what every C tutorial will tell you ...




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 
<https://www.ibm.com/docs/en/zos/2.5.0?topic=programs-calling-c-code-from-assembler-c-example>

I see:
  EDCPRLG
  LA    1,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.


This @PRINTF4 cannot be the same as normal PRINTF;
it must be a glue function or similar to allow an ASSEMBLER function 
to call normal PRINTF.


(only guessing, because the FMTSTR is not shown here).

If normal PRINTF is called, the sequence should look like this:

 LA    1,ADDR_BLK  parameter address block in r1
 L 15,=V(PRINTF)   address of routine
 BALR  14,15   call normal PRINTF

...

ADDR_BLK DC   A(FMTSTR)    parameter address block with..
 DC   F(222)
FMTSTR   DC   C'output of integer %d using printf'
 DC   X'00'

As you can see, because the integer value can be positive or negative,
there is no way to mark the last parameter with the leftmost bit.

Old story from my old customer:

sometime we had to introduce 3rd party software (written in C) which 
had to be
called from PL/1 routines. PL/1 at that time only had call by 
reference, but the
routines of the 3rd party software used call by value in their 
interfaces or APIs.


We had to provide so-called "glue functions" for every function of the 
3rd party
software, that had a call by value parameter ... the call by value 
parameter

was a reference-parameter in "our" interface, callable by PL/1, and then
the glue function called the 3rd party function, using the by-value 
interface.


This was in the 1990s ... today BYVALUE is supported by native PL/1.

Maybe the same is going on here with that @PRINTF4 interface ??

--
For IBM-MAIN sub

Re: ASM call by value

2023-03-30 Thread Bernd Oppolzer


See answers below

Am 31.03.2023 um 01:23 schrieb Paul Gilmartin:

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


reg1 parameter list is the address list which register 1 points to.
So there is no practical limit on the size of the parameter list.

Of course, it is impractical to pass large structures or arrays by value,
but that's what every C tutorial will tell you ...




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 
<https://www.ibm.com/docs/en/zos/2.5.0?topic=programs-calling-c-code-from-assembler-c-example>
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.


This @PRINTF4 cannot be the same as normal PRINTF;
it must be a glue function or similar to allow an ASSEMBLER function to 
call normal PRINTF.


(only guessing, because the FMTSTR is not shown here).

If normal PRINTF is called, the sequence should look like this:

 LA1,ADDR_BLK  parameter address block in r1
 L 15,=V(PRINTF)   address of routine
 BALR  14,15   call normal PRINTF

...

ADDR_BLK DC   A(FMTSTR)parameter address block with..
 DC   F(222)
FMTSTR   DC   C'output of integer %d using printf'
 DC   X'00'

As you can see, because the integer value can be positive or negative,
there is no way to mark the last parameter with the leftmost bit.

Old story from my old customer:

sometime we had to introduce 3rd party software (written in C) which had to be
called from PL/1 routines. PL/1 at that time only had call by reference, but the
routines of the 3rd party software used call by value in their interfaces or 
APIs.

We had to provide so-called "glue functions" for every function of the 3rd party
software, that had a call by value parameter ... the call by value parameter
was a reference-parameter in "our" interface, callable by PL/1, and then
the glue function called the 3rd party function, using the by-value interface.

This was in the 1990s ... today BYVALUE is supported by native PL/1.

Maybe the same is going on here with that @PRINTF4 interface ??

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

2023-03-30 Thread Bernd Oppolzer


Am 30.03.2023 um 21:32 schrieb Paul Gilmartin:

Does C use the CALL VL convention?


C has a portable solution for functions with a varying number of 
parameters,

that is the mechanism defined in the ANSI header 

Most interesting, these sort of functions - like printf() and scanf() -
need to have a certain count of fixed parameters, which by there form 
and content

define the varying number of parameters which follow.

There is no need AND NO POSSIBILITY (on the mainframe, at least) to mark 
the last parameter
in a certain way. And: the language definition doesn't say anything 
about an end mark of
the parameter list; it only tells that the first (fixed) parameters must 
tell the function

how much parameters follow.

See printf as the best known example.

Other (simpler) functions may simply require the number of parameters as 
first parameter,

for example:

look_for_maximum (5, "John", "Fred", "Jim", "Henry", "Mike");

where 5 is number of strings, which follow.

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

Re: ASM call by value

2023-03-30 Thread Bernd Oppolzer


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

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

2023-03-28 Thread Bernd Oppolzer

Very good method ... I was teaching programming during my career, much 
the same as you did,
but I never did it like that. But I also encouraged the students to 
discuss their solutions with me
and with other students and required that there be comments and 
meaningful variable names etc.


IMO, the COBOL language and the mainframe is still alive and will not 
die in the near future for the

following reasons:

- the applications are more secure because of the use of decimal data 
(0C7 will often occur, when
uninitialized data is used ... this is often detected during testing. On 
other platforms, you may get

unexpected results, but no abends)

- if you get an ABEND, you have well established analyzing and recovery 
procedures and readable dumps;
compare that to a "segmentation fault" on a Unix box ... you normally 
need to start a debugger to

examine the problem (in the production system?)

- most mainframe shops have established procedures for change management 
etc., and software

doesn't go to production untested etc.

- the system software stack is stable ... on the other platforms, it is 
possible that a software after only
3 years is "legacy" or "toxic" ... with mainframes, legacy starts after 
25 to 30 years :-)

and the software is still readable (well: normally).

Kind regards

Bernd


Am 28.03.2023 um 23:17 schrieb Steve Thompson:
In an effort to keep people from writing difficult to impossible to 
maintain code, while I was teaching COBOL, I warned the students that 
I would be picking a programming lesson, where once it was completed, 
everyone would have to swap card decks and then have to add the next 
lesson's function to it. They would be graded on getting the lesson 
done, graded on how well they could update someone else's code and on 
how problematic their code was for another person to update it. And 
then there would be one more of these that I would announce with no 
warning to do before the final program was due.


So programming task #3 was done and I announced this was the time for 
the swap.


After that lesson, and me having graded it, code started to have 
meaningful comments and better to understand variable names and logic. 
I never pulled the second one on them because I felt the mission and 
lesson had been accomplished.


I think more instructors should do things like this.

Steve Thompson


On 3/28/2023 5:01 PM, Bernd Oppolzer wrote:
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



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

2023-03-28 Thread Bernd Oppolzer

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

Re: ASM call by value

2023-03-27 Thread Bernd Oppolzer


Counter example:

DCL X BIN FIXED (31);
   CALL SUB (X);

SUB: PROC (P);
   DCL P BIN FIXED (31) BYVALUE;

   END SUB;

This is NOT the same as the example below;
a C caller (and: an ASSEMBLER caller) must do VERY DIFFERENT things to 
call the SUB here

and the SUB in the previous example.

From the perspective of the PL/1 main program, the SEMANTICS are the 
same (X is not changed),
but in this case enforced by the BYVALUE clause of the SUB subroutine 
and known for sure by all callers;
in the earlier post by the parantheses around (X) ... SUB in the earlier 
post could change its parameter P ...

who knows? The definition doesn't tell it.

HTH, kind regards

Bernd


Am 27.03.2023 um 16:13 schrieb Bernd Oppolzer:

   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 enforce that behavior.



From: IBM Mainframe Discussion List  on 
behalf of Bernd Oppolzer 

Sent: Monday, March 27, 2023 9:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

What is important to me at least: a parameter passing mechanism where
addresses are passed
and the value on the caller's side cannot be altered (because it has
been copied before, like in the
DUMMY argument mechanism of PL/1, for example) it NOT call by value.

You cannot call a true BYVALUE module or function by using such a
parameter passing mechanism.
That is: it is not only important that the caller's variable is not
altered;
it is also important that VALUEs are passed, not addressed. Otherwise
you have some sort of
"restricted" call by reference, which is not the same as call by value.

You are right, of course, that Reg 1 and DSA etc. are details of the
implementation,
only mentioned here to clarify the idea.

Kind regards

Bernd


Am 27.03.2023 um 14:25 schrieb Seymour J Metz:
There's more than one implementation; they all  
enforce the semantics. Again, what call by value is all about is 
that the caller's variable in not altered, regardless of how the 
compiler enforces that. The whole shtick with R1 and DSA is not part 
of the semantics.



From: IBM Mainframe Discussion List  on 
behalf of Bernd Oppolzer 

Sent: Monday, March 27, 2023 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value

Implementation enforces semantics in this case ...

The C implementation (on z/OS at least, but IMO on other platforms as
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process
remains reentrant.

Then the called prog can, if it wants, change the passed values, which
are in fact local variables,
as seen be the called prog. But nothing is changed from the perspective
of the caller.

This is what call by value is about.

The ASSEMBLER call macro supports this, but only for integer parms, and
not for parameter lists which
dont reside in the caller's CSECT. So we have two issues here:

- no "larger" data types supported
- no support for the reentrant case

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


--
For IBM-M

Re: ASM call by value

2023-03-27 Thread Bernd Oppolzer


   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 enforce that behavior.


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

What is important to me at least: a parameter passing mechanism where
addresses are passed
and the value on the caller's side cannot be altered (because it has
been copied before, like in the
DUMMY argument mechanism of PL/1, for example) it NOT call by value.

You cannot call a true BYVALUE module or function by using such a
parameter passing mechanism.
That is: it is not only important that the caller's variable is not
altered;
it is also important that VALUEs are passed, not addressed. Otherwise
you have some sort of
"restricted" call by reference, which is not the same as call by value.

You are right, of course, that Reg 1 and DSA etc. are details of the
implementation,
only mentioned here to clarify the idea.

Kind regards

Bernd


Am 27.03.2023 um 14:25 schrieb Seymour J Metz:

There's more than one implementation; they all  enforce the 
semantics. Again, what call by value is all about is that the caller's variable in 
not altered, regardless of how the compiler enforces that. The whole shtick with R1 
and DSA is not part of the semantics.


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

Implementation enforces semantics in this case ...

The C implementation (on z/OS at least, but IMO on other platforms as
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process
remains reentrant.

Then the called prog can, if it wants, change the passed values, which
are in fact local variables,
as seen be the called prog. But nothing is changed from the perspective
of the caller.

This is what call by value is about.

The ASSEMBLER call macro supports this, but only for integer parms, and
not for parameter lists which
dont reside in the caller's CSECT. So we have two issues here:

- no "larger" data types supported
- no support for the reentrant case

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


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

2023-03-27 Thread Bernd Oppolzer

What is important to me at least: a parameter passing mechanism where 
addresses are passed
and the value on the caller's side cannot be altered (because it has 
been copied before, like in the

DUMMY argument mechanism of PL/1, for example) it NOT call by value.

You cannot call a true BYVALUE module or function by using such a 
parameter passing mechanism.
That is: it is not only important that the caller's variable is not 
altered;
it is also important that VALUEs are passed, not addressed. Otherwise 
you have some sort of

"restricted" call by reference, which is not the same as call by value.

You are right, of course, that Reg 1 and DSA etc. are details of the 
implementation,

only mentioned here to clarify the idea.

Kind regards

Bernd


Am 27.03.2023 um 14:25 schrieb Seymour J Metz:

There's more than one implementation; they all  enforce the 
semantics. Again, what call by value is all about is that the caller's variable in 
not altered, regardless of how the compiler enforces that. The whole shtick with R1 
and DSA is not part of the semantics.


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

Implementation enforces semantics in this case ...

The C implementation (on z/OS at least, but IMO on other platforms as
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process
remains reentrant.

Then the called prog can, if it wants, change the passed values, which
are in fact local variables,
as seen be the called prog. But nothing is changed from the perspective
of the caller.

This is what call by value is about.

The ASSEMBLER call macro supports this, but only for integer parms, and
not for parameter lists which
dont reside in the caller's CSECT. So we have two issues here:

- no "larger" data types supported
- no support for the reentrant case

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

Re: ASM call by value

2023-03-27 Thread Bernd Oppolzer

Take as an easy example a C function which gets two double parms and 
builts the sum:


double sum (double x, double y)
{
    return x + y;
}

there you have register 1 pointing at an address list (which should be 
called parameter list in this case);
the first double is at 0(r1), and the second double is at 8(r1). The 
VALUEs of the doubles are passed,

not the addresses.

You cannot call this function using the ASSEMBLER CALL macro. No chance.

Kind regards

Bernd


Am 27.03.2023 um 13:10 schrieb Bernd Oppolzer:

Implementation enforces semantics in this case ...

The C implementation (on z/OS at least, but IMO on other platforms as 
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter 
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process 
remains reentrant.


Then the called prog can, if it wants, change the passed values, which 
are in fact local variables,
as seen be the called prog. But nothing is changed from the 
perspective of the caller.


This is what call by value is about.

The ASSEMBLER call macro supports this, but only for integer parms, 
and not for parameter lists which

dont reside in the caller's CSECT. So we have two issues here:

- no "larger" data types supported
- no support for the reentrant case

HTH,
kind regards

Bernd



Am 27.03.2023 um 12:57 schrieb Seymour J Metz:
No. Don't confuse semantics with implementation. Call by value means 
that the called routine can't change the parameter. Whether the 
compiler passes the address or not, it will not allow assignments to 
a call by value parameter.


Just be glad that you don't have to deal with call by name.


From: IBM Mainframe Discussion List  on 
behalf of Bernd Oppolzer 

Sent: Monday, March 27, 2023 2: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

2023-03-27 Thread Bernd Oppolzer


Implementation enforces semantics in this case ...

The C implementation (on z/OS at least, but IMO on other platforms as 
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter 
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process 
remains reentrant.


Then the called prog can, if it wants, change the passed values, which 
are in fact local variables,
as seen be the called prog. But nothing is changed from the perspective 
of the caller.


This is what call by value is about.

The ASSEMBLER call macro supports this, but only for integer parms, and 
not for parameter lists which

dont reside in the caller's CSECT. So we have two issues here:

- no "larger" data types supported
- no support for the reentrant case

HTH,
kind regards

Bernd



Am 27.03.2023 um 12:57 schrieb Seymour J Metz:

No. Don't confuse semantics with implementation. Call by value means that the 
called routine can't change the parameter. Whether the compiler passes the 
address or not, it will not allow assignments to a call by value parameter.

Just be glad that you don't have to deal with call by name.


From: IBM Mainframe Discussion List  on behalf of Bernd 
Oppolzer 
Sent: Monday, March 27, 2023 2: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: ASM call by value

2023-03-27 Thread Bernd Oppolzer


I would like to add:

if you pass the address of a constant field to the called prog using the 
CALL macro,
this looks like call by value, but in fact you have call by reference 
again, because you

pass an address in the reg1 list.

This is what PL/1 for example does, if it builds and passes a so-called 
DUMMY ARGUMENT
(in cases where types of parameters don't match or when you put 
paratheses around

your arguments).

PL/1, BTW, also supports "real" by value for some time already, if you 
code the BYVALUE parameter,

this way allowing the call of C subroutines which expect by value calls.

Kind regards

Bernd


Am 27.03.2023 um 08:52 schrieb Bernd Oppolzer:

Sorry ... in some places: replace "caller" by "called prog" ...


Am 27.03.2023 um 08:49 schrieb Bernd Oppolzer:

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

2023-03-27 Thread Bernd Oppolzer


Sorry ... in some places: replace "caller" by "called prog" ...


Am 27.03.2023 um 08:49 schrieb Bernd Oppolzer:

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

Re: ASM call by value

2023-03-27 Thread Bernd Oppolzer


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

Re: BookManager

2023-03-20 Thread Bernd Oppolzer

I would like to thank all who responded and tell you about the solution 
we found.


First of all, with some support from somewhere, we managed to re-install 
the BookManager software
on the z/OS 2.5 system - unsupported / as-is. This, at least, allows us 
to read the books temporarily

and to start the conversion from here.

Then I copied the needed books (some hundred) to Bookmaster GML format, 
which can be done
from inside READ/MVS. The MVS (or z/OS) version converts complete books 
to Bookmaster GML,
not only single paragraphs. The Bookmaster files (which are textfiles in 
the end) then were moved

to a PC (using text FTP).

Then I used B2H (the Windows variant) to create HTML from the Bookmaster 
files. I changed the
B2H REXX a little bit, so that all texts are enclosed in  tags; 
this way the line breaks etc.

from the original documents are preserved.

Task completed :-)

Some additional remarks:

the internal layout of the .BOO files is not usable and very difficult; 
4096 byte segments, word fragments
in EBCDIC, maybe some sort of linked list or tree structure. I spent 
some time trying to understand this,

but no success.

I also tried to find the Bookmaster sources - as suggested by some 
posters - at my customer's site
for the books, which were present in the "production" bookshelves, but 
also no success;
the sources were partially lost and the people responsible for the books 
have retired.

So it was best to retrieve the Bookmaster sources from the books directly.

Kind regards

Bernd


Am 28.02.2023 um 18:59 schrieb Bernd Oppolzer:

What is the preferred way to convert BookMgr books to PDF?

My customer has some home-written BookMgr books, which they cannot access
after the z/OS migration (BookMgr support was dropped with z/OS 2.4).

We managed to transfer the books to Windows (and OS/2, BTW), where we can
at least look at the books. Now I would like to convert the books to 
PDFs.
But the free Softcopy Reader refuses to print more than one (selected) 
topic
or ranges of topics; if you try to do this using the print menu 
(selected or range),

the output is always empty.

Is this a bug - or: is printing larger portions of text not allowed in 
the free version?

What are the options?

The eMail address book...@us.ibm.com, which is mentioned in the 
Softcopy Reader
help texts, doesn't exist any more (BTW: the Softcopy Reader is a 2012 
edition;

this seems to be the last one available).

Is there a documented API to read the books using a C or REXX program
and build the PDFs this way? Or build HTML from the books?

Thanks for all suggestions,
kind regards

Bernd





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

Re: Question for our international friends (mostly)

2023-03-18 Thread Bernd Oppolzer


Thank you very much,

the 2nd word is "roden" in today's German language,
roden is the infinitive form.
"Ich rode, Du rodest, er rodet, ..." etc.
a "normal" German verb.

Roden means: cut a (large amount) of trees and leave an area without trees
(Google translate says: clearing, the German word is: Lichtung).

I didn't know about this homonym so far.

Thank you again.

Kind regards

Bernd


Am 18.03.2023 um 05:57 schrieb Tony Harminc:

On Fri, 17 Mar 2023 at 21:38, Bernd Oppolzer  wrote:

Very interesting discussion.

I recently tried to understand what the correct pronounciation of the
word "router" is, because here in Germany there are different opinions. And I 
learned in
the end, that BOTH ways are correct, like "rooter" and (don't know how to spell 
the other,
maybe) "row-ter".

There are two quite different words here, with variants, conversions
n->v, v->n and so on, with ultimately quite different meanings and,
uh, roots. It's only coincidence that the spelling - and some people's
pronunciation -  has ended up the same.

First is the one that has do do with choosing or making a direction of
travel, which is verbing of the noun route, which then gets re-noun'd
to router.

This is pronounced /ruːtə/ in the UK and /raʊdər/ in the US. As
someone said, Canadians are split.

This is (part of) the OED's description of that root:

"Origin: A borrowing from French. Etymon: French route.
Etymology: < Anglo-Norman and Old French rute, Anglo-Norman and Old
French, Middle French rote, Anglo-Norman and Old French, Middle
French, French route, Middle French routte way, direction (first
quarter of the 12th cent.), course (of a ship) (c1160), path,
passageway (c1170), the course of a military march (a1683) < classical
Latin rupta (short for via rupta broken way), feminine of ruptus
broken, past participle of rumpere to break (see rumpent n.); compare
rumpere viam to open up a path. Compare post-classical Latin ruta ,
rutta way, road (13th cent. in British sources; 14th cent. in
continental sources).

The pronunciation with a diphthong is recorded from the second half of
the 18th cent. and preferred by some, but not all commentators at that
time; it disappears from standard British English in the course of the
19th cent., but is still widespread in North America.

  a. A way or course taken in moving from a starting point to a
destination; a regular line of travel or passage; the course of a
river, stream, etc. Also: a means of passage; a way in or out. Cf. en
route adv.Often with modifying word indicating the purpose of travel;
for more established compounds, as air, bus, lane-, migration-, red,
silk, stock-, trade route, etc., see the first element.

router
Electronics and Computing.

A device, circuit, algorithm, etc., which serves to determine the
destinations of individual incoming signals; esp. a device which
receives data packets and forwards them to the appropriate computer
network or part of a network."


The kind of router that removes wood comes from a different root,
pronounced raʊt in both modern UK and North American dialects:

"2. a. Woodworking. Any of various hand tools for working and shaping
grooves, rebates, and mouldings, having a narrow, often profiled,
cutter; (in later use) spec. a router plane.
  b. A machine or power tool for working and shaping grooves,
rebates, and mouldings in wood or other materials, often following a
prescribed outline."

from the verb route:
"3. b. transitive. Originally: to cut a groove or other recess in the
surface of (a material, as wood, metal, etc.) by using any of various
tools; to cut (a groove or recess) in this way. Later: to cut or work
at by using an electric router or similar tool to remove material."

in turn from wroot, v.
"Etymology: Old English wrótan , = Old Frisian *wrôta (West Frisian
wrotte , North Frisian wrote , wröte , wrät ), Middle Low German
wroten (Low German wröten ), Middle Dutch and Dutch wroeten (Antwerp
dialect wruten ), Old High German *wrôzian , ruozian to plough up, Old
Norse and Icelandic róta , (Middle) Swedish and Norwegian rota ,
Danish rode ), < wrót wroot n."

So in summary, the word that involves sending packets somewhere comes
into English from Latin, and the one to do with grooves in wood and
the like from old Germanic roots.


While doing this research, I found out that the American way to pronounce 
things often
is the OLD british way to do it, which was common in GB in the 19th century or 
earlier,
and which then changed in GB, but stayed like it was in the US of America.

Yeah - it's normal for the language of emigrants to be more
conservative than that of those who stay behind. As above, where
/raʊt/ "disappears from standard British English in the course of the
19th cent., but is still widespread in North America."

Tony H.

-

Re: Question for our international friends (mostly)

2023-03-17 Thread Bernd Oppolzer


Very interesting discussion.

I recently tried to understand what the correct pronounciation of the 
word "router" is,
because here in Germany there are different opinions. And I learned in 
the end, that BOTH
ways are correct, like "rooter" and (don't know how to spell the other, 
maybe) "row-ter".


While doing this research, I found out that the American way to 
pronounce things often
is the OLD british way to do it, which was common in GB in the 19th 
century or earlier,

and which then changed in GB, but stayed like it was in the US of America.

Kind regards

Bernd


Am 17.03.2023 um 22:45 schrieb Pew, Curtis G:

On Mar 17, 2023, at 3:59 PM, Wayne Bickerdike 
mailto:wayn...@gmail.com>> wrote:

Always amazed how US English strayed from the home origins.

Sorry to be pedantic (language history is kind of a hobby of mine), but British 
English has “strayed” from what it was in the 17th and 18th centuries as much 
as American English. Not to mention that there was even more regional variation 
in dialects back then than there is now, and some American dialects reflect 
now-vanished British dialects.

Languages constantly change, and when groups separate they change in different 
ways.


--
Curtis Pew
ITS Campus Solutions
curtis@austin.utexas.edu




--
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 for our international friends (mostly)

2023-03-17 Thread Bernd Oppolzer

There is a (sort of) rule, that C before I and E is pronounced like T-S 
(or S in France, I guess),

but before other vocals like K (as in coffee).

So for us in Germany, CICS as t-s-icks is logical.

Kind regards

Bernd


Am 17.03.2023 um 21:10 schrieb Bernd Oppolzer:
not exactly "six" ... more like "tsix", the first letter sounds like a 
Z in Germany,

a letter T followed by a letter S.

It comes to my mind that most other languages don't pronounce the 
letter Z this way,

only we Germans do ... the other (like French and English) simply say S.
For example zebra. How do you pronounce it? The word is the same in 
all three languages, I guess ...

We say t-s-ebra.

Nice ...

Kind regards

Bernd


Am 17.03.2023 um 20:36 schrieb René Jansen:

I’ve heard Germans say ‘six’; in Dutch we say ‘kicks’ like the Brits.

René


--
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 for our international friends (mostly)

2023-03-17 Thread Bernd Oppolzer

not exactly "six" ... more like "tsix", the first letter sounds like a Z 
in Germany,

a letter T followed by a letter S.

It comes to my mind that most other languages don't pronounce the letter 
Z this way,

only we Germans do ... the other (like French and English) simply say S.
For example zebra. How do you pronounce it? The word is the same in all 
three languages, I guess ...

We say t-s-ebra.

Nice ...

Kind regards

Bernd


Am 17.03.2023 um 20:36 schrieb René Jansen:

I’ve heard Germans say ‘six’; in Dutch we say ‘kicks’ like the Brits.

René


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

Re: Full TRAP feature support [was: RE: Re: z/OS 3.1 Announcement US Letter]

2023-03-01 Thread Bernd Oppolzer


Am 01.03.2023 um 19:51 schrieb Martin Trübner:


I know of one big z/OS installation that has a debugger in use that 
uses TRAP (and the author is on IBM-main as well)


That's me ... but as I said in the other mail, I am not the author of 
the debugger;
I am only the maintainer today, and I changed the breakpoint mechanism 
(was: S0C1) by TRAP in the 2010 time frame.


Kind regards

Bernd

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

Re: Full TRAP feature support [was: RE: Re: z/OS 3.1 Announcement US Letter]

2023-03-01 Thread Bernd Oppolzer


FWIW,

some years ago (maybe 2010), I replaced the breakpoint mechanism in a 
home grown debug tool
written by my customer; the breakpoints were implemented by capturing 
the S0C1 interrupts of hex zero
insertions into the load module instead of real opcodes. I now insert 
TRAP2 instead of hex zero.


So: I know how to do this ... maybe others on this list, too. The 
problem is: to insert the address of the
TRAP handler routine into the DUCT, you need to be authorized. In our 
installation, we created something
like a special "user SVC" to do this (don't know the details, because 
this was done by our systems people).
That is: a special SVC which only allows to "configure the DUCT". I 
wrote the specification, and then the

systems people created the SVC.

All other actions can be done by normal non-authorized code ... this is 
kind of easy. The rest of the debug tool
remained unchanged. The debug tool was much faster after this change, 
because the RTM work involved

by the S0C1 handling is now saved.

This is a very special application, of course, and I never would have 
thought about using TRAP2, if the
debug tool of the customer didn't exist already (since the 1980s, long 
before TRAP2 arrived, which was ca. 2000,
IIRC). But when I learned about the internals of the debug tool (the 
S0C1 mechanism), it seemed
sort of natural to me to think about this TRAP2 replacement. And the 
customer allowed me to give it a try.


If you want to know more, feel free to ask me offline; maybe I remember 
the details after all this time.
The debug tool is still in daily use by the developers at the customer's 
site (for PL/1 and ASSEMBLER programs).


Kind regards

Bernd



Am 01.03.2023 um 17:32 schrieb Farley, Peter:

<*Sigh*> Yes, I do understand the "business justification/resource allocation" 
argument/excuse.  I deal with similar issues all the time in my employer's business.  I hate 
it, but it is real.

IMHO the IBM z/OS development team should never have *needed* a "formal 
request/requirement" to implement OS support for an implemented architectural 
feature.  There is a new hardware feature, our clients will no doubt wish to take 
advantage of its benefits, let's support that feature.  Full stop.

But please accept my apologies, I am obviously beating that poor dead horse 
once again.

As an alternative, would it ever be possible for IBM to publish the program design and 
detailed error-handling needed to practically and *safely* use the TRAP feature?  Maybe a 
Redbook project sponsored by the Debug Tool team?  Something detailed enough to enable a 
knowledgeable independent developer to produce the code you say IBM won't ever write.  I 
wouldn't expect the major ISV's to undertake it, it is far too small a market for them to 
spend real money on (there is that dad-blasted "business justification" thing 
again), but an independent developer might wish to spend *their* private time on getting 
it done, IFF they had all the details needed to do it the right way without needing to 
guess what to do.

I would hope that publishing information on how to properly and safely use an 
existing (and already published) architectural feature wouldn't run afoul of IP 
concerns.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Relson
Sent: Wednesday, March 1, 2023 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1 Announcement US Letter

EXTERNAL EMAIL

Peter F wrote:

What I would like to know is when z/OS development will finally manage to find 
the round tuits to actually implement a supported API to actually be able to 
USE the TRAP (and compare-and-trap) instructions introduced to the architecture 
so long ago I have forgotten which zArch generation they in came with (and I'm 
too tired to go looking for that generation today).


I believe IBM Debug Tool uses this. But you're right that there is no API 
provided.

And given the amount of time that has gone by and the fact that, to my knowledge, there 
never has been a formal request/requirement submitted asking for such an API, the answer 
to your question (unless such a requirement is submitted) is, in practice, 
"never".

And a new requirement might be declined unless there is significant business 
justification that would make this a good candidate.

We all wish that we were in a world where "should" would match "it is", but there is always a 
resource tradeoff to be made between competing items and the question has to be answered of what would you the customer 
(and IBM) be willing to sacrifice getting in order to get "this". "Should" only takes you so far. 
That should be apparent to all (but many discussions on IBM-Main do not seem to take that into account).

Peter Relson
z/OS Core Technology Design
--

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

BookManager

2023-02-28 Thread Bernd Oppolzer


What is the preferred way to convert BookMgr books to PDF?

My customer has some home-written BookMgr books, which they cannot access
after the z/OS migration (BookMgr support was dropped with z/OS 2.4).

We managed to transfer the books to Windows (and OS/2, BTW), where we can
at least look at the books. Now I would like to convert the books to PDFs.
But the free Softcopy Reader refuses to print more than one (selected) 
topic
or ranges of topics; if you try to do this using the print menu 
(selected or range),

the output is always empty.

Is this a bug - or: is printing larger portions of text not allowed in 
the free version?

What are the options?

The eMail address book...@us.ibm.com, which is mentioned in the Softcopy 
Reader
help texts, doesn't exist any more (BTW: the Softcopy Reader is a 2012 
edition;

this seems to be the last one available).

Is there a documented API to read the books using a C or REXX program
and build the PDFs this way? Or build HTML from the books?

Thanks for all suggestions,
kind regards

Bernd

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

Re: Searching the ASVT

2023-02-05 Thread Bernd Oppolzer


Thank you all for this discussion;
I have learned something new :-)

Would you kindly look at this coding and tell me, if it is correct in 
your opinion,

and if it is allowed to execute this by non-privileged programs?

What macro calls do I need to get the needed definitions (CVT, ASVT, ASCB)?

Thanks in advance,
have a nice day

Bernd



*
*-
*    walk thru all ASCBs
*-
*
 L R10,16  LOAD ADDR OF CVT
 USING CVT,R10 SET ADDRESSABILITY TO CVT
 L R10,CVTASVT POINT TO ADDRESS SPACE VECTOR TABLE
 DROP  R10
 USING ASVT,R10    SET ADDRESSABILITY TO ASVT
 L R9,ASVTMAXU LOAD MAX. NUMBER OF ADDRESS SPACES.
 LA    R11,ASVTENTY    LOAD ADDRESS OF FIRST ASCB POINTER
 DROP  R10
*
*-
*    R11 is moved over the table of all ASCB pointers
*    R10 is no longer needed
*    R9  contains the number of entries in the ASCB table
*-
*
LOOPASVT DS    0H
 TM    0(R11),ASVTAVAL VALID ASCB Available ?
 BO    NEXTASVT    NO, CHECK NEXT ASVT ENTRY
*
*-
*    Examine ASCB
*    Use R10 to address the ASCB
*-
*
 L R10,0(R11)
 USING ASCB,R10
*
*-
*    access fields of current ASCB
*-
*
*    --- to be entered here ---
*
*-
*    advance R11 to next ASCB address
*-
*
NEXTASVT DS    0H
 LA    R11,4(,R11) Advance to NEXT ASVT ENTRY
 BCT   R9,LOOPASVT
*



Am 05.02.2023 um 07:39 schrieb Tony Harminc:

On Sat, 4 Feb 2023 at 18:00, esst...@juno.com  wrote:



I am on a z/os 2.2 system, trying to rseurrect some old code.
.
can some one confirm the instructions for Searching the
Address Space Vector Table (ASVT) on z/OS 2.2
.
This program  loads R10 with CVTASVT
L R10,CVTASVTGET ASVT ADDRESS
USING ASVT,R10  ESTABLISH ADDRESSABILITY


That's fine.



It then issues a Load Address For the first entry ?
This doesn't  look correct to me ?
LAR11,ASVTENTY   GET # OF FIRST ENTRY


It's fine. The ASVT has a bunch of header stuff, and then an array of
fullword pointers starting at ASVTENTY. The PL/X declaration may make it a
bit clearer.

Next its test for an ASCB that is assigned.

TM0(R11),ASVTAVALVALID ASCB Available ?
BORUNLOP1NO, CHECK NEXT ASVT ENTRY


It's fine.I suppose there may be a serialization issue, e.g. an ASVT
entry's assignment status may change after you've looked. But programs that
either index the ASVT with the ASID (x 4), or those that go sequentially
through the array and do  with each active address space have
done it this way forever (i.e. since 1972), and I'm sure many are still out
there working fine. Like anything, it's conceivable IBM could change this
at some point, but it's such a basic interface in MVS--> z/OS that they
would surely introduce some new data structure or API to access the list of
ASCBs rather than change the ASVT and break things all over the place.



Besides the Load Address above - How should this module
advance to the Next ASVT entry ?


There's nothing wrong with the LA. The start of the array of ASCB pointers
is at whatever offset ASVTENTY is at, and that hasn't changed in 50 years.
The content of the header info has grown, but not the offset of the array
of pointers.



Shoud I issue the following to get to the next ASVT
LR10,ASVTFRST


No. I think you're thinking that the entire ASVT has multiple instances
that are chained together. There's only one, with an array of pointers on
the end. ASVTFRST points somewhere you don't want - I think the first
*available* ASCB, though IBM doesn't document the ASCB creation logic, and
I assume things have changed with reusable ASIDs. Presumably you are not
planning to modify the ASVT, so you're not looking for an available
entry... If you are, well Just Don't. But effectively ASVTFRST is element 0
of the array of ASCB pointers, and there's no ASID 0. So if you have the
address of ASVTFRST (not the address that is *in* ASVTFRST), then you can
multiply the ASID by 4 and use it as an origin-0 array index. If you start
at ASVTENTY then it's origin-1, so add 4 (or 1 before you multiply by 4).
Or if you want to look at all active ASCBs then start with the first array
element, follow the pointer *if it's active*, and

Re: Origin of the name of sample programs DSNTEP2/4?

2022-11-28 Thread Bernd Oppolzer


Hello Peter,

IMO, the P in the name DSNTEP2 is because it is written in PL/1.
There are some other sample programs like DSNTIAD and DSNTIAUL, which 
are written in ASSEMBLER,

that's why IMO the 6th letter depends on the programming language.
DSNTIAUL is heavily used at my customer's site to do unloads of SQL 
results for archiving and

testcase construction purposes.
BTW, I wrote a replacement for DSNTEP2 and DSNTIAUL, which does the same 
as the two programs do
and much more, but I wrote it in C. It also runs on the non-mainframe 
platforms and there exists a version
for Oracle, as well. And because it also supports Load (not only Unload, 
like DSNTIAUL), it can be used
to transfer data between all flavors of DB2 and Oracle, on all platforms 
:-)
This is great for everyone who wants to do ETL jobs on sites with a mix 
of DB2 and Oracle databases.

If you want to know more, call me offline.

Kind regards

Bernd


Am 28.11.2022 um 23:37 schrieb Farley, Peter:

Cross posted to IBM-MAIN.

I asked this question earlier today over on DB2-L (the one run by IDB2UG), but 
it later occurred to me that someone here might also know the answer to my 
question.

Peter

_
From: Farley, Peter
Sent: Monday, November 28, 2022 3:08 PM
To: idb2ug-d...@connectedcommunity.org
Subject: Origin of the name of sample programs DSNTEP2/4?


Just a question of curiosity - Does anyone know where the names for the DB2 PLI 
sample programs DSNTEP2 and DSNTEP4 came from?  Is it as simple as (DB2 prefix 
DSN) + (TEst Program 2/4)?

Also, if anyone is interested I have a modified copy of DSNTEP2 that implements full 
PARM/PARMDD processing (up to the PARMDD max of 32760) for all "functional 
comment" overrides and a new SYSDATA option that writes all SELECT output to a new 
file with just one record per returned row and a single instance of the column headings 
(suitable for post-processing into CSV or other formats).  Write to me **privately** 
please (pjfarley3 at earthlink dot net) and not to this list or to this work email 
address if you are interested.

I would contribute the changes to CBTTAPE.ORG but the original DSNTEP2 code is 
copyrighted by IBM.

Peter



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

Re: Assembler courses

2022-09-26 Thread Bernd Oppolzer


What I like about my "garbage language":

since 2011 it is "my garbage language";
I can add new control statements to it and thus eliminate the need for gotos
most of the time, because the old use cases of goto now have new solutions
(similar to C). And for many other needs like string handling, File I/O 
etc., it is (for me)
far superior than other languages at hand (of course, due to extensions 
I made

in the last 10 years).

It now has more features than IBMs Pascal/VS had, and it is portable 
across platforms

(the P-Code generated on one platform will execute on the other)
and I will continue to extend it, as soon as I have more time to do so.
Ok: maybe it has more bugs than Pascal/VS, but if someone of the user 
community

tells me about serious bugs, I will try to fix them.

BTW: extending GOTO to allow identifiers as targets is not on my ToDo list
(at the moment).

Kind regards

Bernd


Am 26.09.2022 um 02:38 schrieb David Crayford:

According to Linus you’ve been brainwashed by using a garbage language 
https://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/


On 26 Sep 2022, at 1:43 am, Bernd Oppolzer  wrote:

I try to be not dogmatic about GOTO statements,
in fact, I am coding COBOL in my money (everyday) job, and there are lots of GO 
TOs around;
I try to remove them, when I do larger refactoring, but if not, I leave them 
untouched.

But now for another GOTO story.

When I started my Stanford Pascal compiler adventure in 2011, the first 
compiler pass (PASCAL1)
had around 50 GOTO statements in it (in fact: 50 numeric labels which are 
targets of GOTOs in Pascal;
in Pascal, BTW, GOTOs are allowed, but they are sort of uncomfortable;
you need a label declaration for them, not only the GOTO statement and the 
target label -
because the label is local to a block, the label number may be reused in 
different blocks).
The Stanford compiler, as many other Pascal compilers, is self-hosted,
that means, it is written in Stanford Pascal and compiled by itself.
The Stanford Pascal compiler pass 1 had 6.000 lines in 2011 ... with the 50 
labels mentioned above
(well, this was the 1982 McGill version, to be honest).

One of my first extensions to Stanford Pascal was to add CONTINUE, BREAK and 
RETURN statements
to it (semantics like in C). It turned out that almost all GOTOs were used to 
implement the missing
statements CONTINUE, BREAK and RETURN using GOTOs. I then started (after some 
time)
to remove the GOTOs by replacing them by the new statements, where this was 
possible
without problems.

Today the compiler pass 1 has almost 25.000 lines. It only contains 7 GOTO 
statemens (I just checked it).
Because, see above, I am not dogmatic about GOTO, I will leave them, as long as 
there is no need
to work on the procedures containing them.
The compiler story (including downloads) is here: 
http://bernd-oppolzer.de/job9.htm

IMO, GOTOs (and the statements mentioned above) must be used with care.
If you don't use them right, nobody will be able to follow the logic in your 
programs,
including yourself (after some time). Indentation is key, and meaningful 
comments.

Kind regards

Bernd



Am 25.09.2022 um 13:51 schrieb David Crayford:
Another thing that makes me incredibly dubious about some of the opinions in these videos 
is the hackneyed nonsense about "goto considered harmful". The original paper 
was misunderstood in that all goto statements are harmful and brainwashed a generation. 
Some of these videos present a trivial example using goto and refactor it using 
if/ifelse. In programming languages without scope based cleanup goto is not harmful. In 
fact it's leads to clean code as the branch direction is always descending to a cleanup 
block. Happily for me, the young guys I work with writing systems level Metal/C code 
haven't been seduced by this dogmatic BS.  Good C code uses goto statements as opposed to 
heavily nested or superfluously functionally decomposed routines. The IBM Openj9 JVM C 
code is a case in point 
https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/classsupport.c. I 
challenge anybody to write better code without goto statements.



--
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: Assembler courses

2022-09-25 Thread Bernd Oppolzer


After looking at your example at
https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/classsupport.c
I would like to comment:

the "goto done" in the first function is only necessary, because in C 
the return statement

serves two purposes:

- setting the return value
- returning control to the caller

In Pascal, for example, the return value of a function is set by 
assigning a value to the function name
(inside the function) and control is returned by reaching the end of the 
function, or (in case of
Stanford Pascal and more recent Pascal dialects) the return statement 
(which has no parameters etc.).


So there is a separation between the two purposes.

In Pascal then, there would be no need to branch to the end of the 
function, because there is the
one and only place where you set the function result from the local temp 
variable. Hence,
no need for a goto (no use case). The return statement would be at the 
position where the
goto done is. The value is assigned to the function name instead of the 
temp variable

(can be done at multiple places).

IIRC, this (the two purposes of the C return statement) has been 
mentioned in one
of the videos posted by Peter Sylvester. This (IMO) is a flaw of the C 
language.
There are others, for example that it's impossible to declare functions 
inside of functions

(no true ALGOL block concept).

Kind regards

Bernd


Am 25.09.2022 um 13:51 schrieb David Crayford:
Another thing that makes me incredibly dubious about some of the 
opinions in these videos is the hackneyed nonsense about "goto 
considered harmful". The original paper was misunderstood in that all 
goto statements are harmful and brainwashed a generation. Some of 
these videos present a trivial example using goto and refactor it 
using if/ifelse. In programming languages without scope based cleanup 
goto is not harmful. In fact it's leads to clean code as the branch 
direction is always descending to a cleanup block. Happily for me, the 
young guys I work with writing systems level Metal/C code haven't been 
seduced by this dogmatic BS.  Good C code uses goto statements as 
opposed to heavily nested or superfluously functionally decomposed 
routines. The IBM Openj9 JVM C code is a case in point 
https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/classsupport.c. 
I challenge anybody to write better code without goto statements.


On 20/09/2022 5:46 pm, Peter Sylvester wrote:

Hi,

49 years ago I 'stumbled' over Simula 67 (see video 1), well, at the 
university "informatik 1" course. I had gotten an Algol60 book given 
to me by my math teacher 2 years earlier. The student a year older 
learned PL/1. WE had an /168 and the Simula 67 system from the NCC 
(you can find it on the CBTTAPE, the turnkey system and elsewhere.


To assembler: On error, you got a nicely formatted storage dump of 
objects. One motivation


After two years and the first graduation (Vordiplom) with punched 
cards etc (but using the MFT like a PC), a got a job at at  the CS 
research center GMD:  MVS, TSO SPF, another universe. It would take 
to much here to explain all the reason why I did a lot of assembler 
(because of this I was able to work in an internship at the swiss 
Colony Computing Center), but I always more than mildly disliked aka 
hated the non structured way of assembled. My work was to write a 
fast program to create microfiches (block letters, index pages). The 
result were a set of structured programming macros (also on the 
cbttape).


Later  with UCLA/Mail, the formatting of "objects" on traces, dumps. 
and stack of function. Just read the "assembler" code (CBTTAPE).


Anyway, here some nice videos.

https://www.youtube.com/watch?v=pH-q2m5sb04

actually, why is smalltalk so close to objective C. Because of a Byte 
Magazine cover page.


https://www.youtube.com/watch?v=SFv8Wm2HdNM

https://www.youtube.com/watch?v=QM1iUe6IofM

https://www.youtube.com/watch?v=eEBOvqMfPoI

Some are provocative. There are many others. I really like "going 
virtually" to these conferences.


https://www.youtube.com/watch?v=_mZBa3sqTrI=45s

Sorry for this side track



--
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: Assembler courses

2022-09-25 Thread Bernd Oppolzer


I try to be not dogmatic about GOTO statements,
in fact, I am coding COBOL in my money (everyday) job, and there are 
lots of GO TOs around;
I try to remove them, when I do larger refactoring, but if not, I leave 
them untouched.


But now for another GOTO story.

When I started my Stanford Pascal compiler adventure in 2011, the first 
compiler pass (PASCAL1)
had around 50 GOTO statements in it (in fact: 50 numeric labels which 
are targets of GOTOs in Pascal;

in Pascal, BTW, GOTOs are allowed, but they are sort of uncomfortable;
you need a label declaration for them, not only the GOTO statement and 
the target label -
because the label is local to a block, the label number may be reused in 
different blocks).

The Stanford compiler, as many other Pascal compilers, is self-hosted,
that means, it is written in Stanford Pascal and compiled by itself.
The Stanford Pascal compiler pass 1 had 6.000 lines in 2011 ... with the 
50 labels mentioned above

(well, this was the 1982 McGill version, to be honest).

One of my first extensions to Stanford Pascal was to add CONTINUE, BREAK 
and RETURN statements
to it (semantics like in C). It turned out that almost all GOTOs were 
used to implement the missing
statements CONTINUE, BREAK and RETURN using GOTOs. I then started (after 
some time)
to remove the GOTOs by replacing them by the new statements, where this 
was possible

without problems.

Today the compiler pass 1 has almost 25.000 lines. It only contains 7 
GOTO statemens (I just checked it).
Because, see above, I am not dogmatic about GOTO, I will leave them, as 
long as there is no need

to work on the procedures containing them.
The compiler story (including downloads) is here: 
http://bernd-oppolzer.de/job9.htm


IMO, GOTOs (and the statements mentioned above) must be used with care.
If you don't use them right, nobody will be able to follow the logic in 
your programs,
including yourself (after some time). Indentation is key, and meaningful 
comments.


Kind regards

Bernd


Am 25.09.2022 um 13:51 schrieb David Crayford:
Another thing that makes me incredibly dubious about some of the 
opinions in these videos is the hackneyed nonsense about "goto 
considered harmful". The original paper was misunderstood in that all 
goto statements are harmful and brainwashed a generation. Some of 
these videos present a trivial example using goto and refactor it 
using if/ifelse. In programming languages without scope based cleanup 
goto is not harmful. In fact it's leads to clean code as the branch 
direction is always descending to a cleanup block. Happily for me, the 
young guys I work with writing systems level Metal/C code haven't been 
seduced by this dogmatic BS.  Good C code uses goto statements as 
opposed to heavily nested or superfluously functionally decomposed 
routines. The IBM Openj9 JVM C code is a case in point 
https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/classsupport.c. 
I challenge anybody to write better code without goto statements.





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

Re: Assembler courses

2022-09-24 Thread Bernd Oppolzer

The link to the video once again, because it was damaged by my eMail 
client:

https://www.youtube.com/watch?v=IRTfhkiAqPw

HTH, kind regards

Bernd


Am 24.09.2022 um 19:12 schrieb Bernd Oppolzer:

Sorry for this topic drift, but this is interesting, anyway.

IMO, there are some really interesting use cases for such techniques, 
for example


- sort routines where the comparison functions is generic, that is, a 
function pointer

- same for search routines
- same for dynamic arrays of structs, indexed by key structs (I 
implemented one, using AVL trees)

- a function package which prints or plots other functions

and so on.

In C, I did this using function pointers.
In Pascal, I can pass procedures or functions to procedure parameters 
(procedures passed as
parameters to other procedures), which is virtually the same as 
function pointers, but IMO
looks nicer. This is from the 1960s. I never considered this as being 
OO, but in fact,
all the above things, although implemented in procedural languages 
like C and Pascal,

are TEMPLATES.

If I really feel the need for such solutions (which I do sometimes), I 
anyway like to stick
with procedural languages like, see above, Pascal and C, and I don't 
use C++;

all the OO overhead makes me feel bad.

See this video:

Object-Oriented Programming is Embarrassing: 4 Short Examples - 
YouTube <https://www.youtube.com/watch?v=IRTfhkiAqPw>


Kind regards

Bernd


Am 24.09.2022 um 18:51 schrieb Tony Harminc:

On Fri, 23 Sept 2022 at 19:10, Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

Far worse is the attempt to use OO techniques in non-OO languages.

"Where is this function called?"
"A pointer to it is saved in a struct."
After that, it's anyone's guess.

Years ago I inherited a good size (~200 kLOC) assembler program that 
had a
lot of old-fashioned techniques. But at the same time it had a 
structured
macro scheme that was quite advanced, and included an internal 
subroutine

call/stack mechanism. I updated the macros to generate symbols for the
assembler xref/ADATA about what was being called and from where, and 
only
then discovered that the subcall macro had the option to load the 
"function

pointer" (address) from a field in a "struct" (DSECT), thus making a
complete static xref of calls impossible. The best that could be done
(other than a complete control/data flow analysis) was to also log what
updated those pointers in the struct, but correlating them was almost
impossible.

Bad code can be written using just about any programming paradigm in any
language.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: Assembler courses

2022-09-24 Thread Bernd Oppolzer


Sorry for this topic drift, but this is interesting, anyway.

IMO, there are some really interesting use cases for such techniques, 
for example


- sort routines where the comparison functions is generic, that is, a 
function pointer

- same for search routines
- same for dynamic arrays of structs, indexed by key structs (I 
implemented one, using AVL trees)

- a function package which prints or plots other functions

and so on.

In C, I did this using function pointers.
In Pascal, I can pass procedures or functions to procedure parameters 
(procedures passed as
parameters to other procedures), which is virtually the same as function 
pointers, but IMO
looks nicer. This is from the 1960s. I never considered this as being 
OO, but in fact,
all the above things, although implemented in procedural languages like 
C and Pascal,

are TEMPLATES.

If I really feel the need for such solutions (which I do sometimes), I 
anyway like to stick
with procedural languages like, see above, Pascal and C, and I don't use 
C++;

all the OO overhead makes me feel bad.

See this video:

Object-Oriented Programming is Embarrassing: 4 Short Examples - YouTube 



Kind regards

Bernd


Am 24.09.2022 um 18:51 schrieb Tony Harminc:

On Fri, 23 Sept 2022 at 19:10, Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

Far worse is the attempt to use OO techniques in non-OO languages.

"Where is this function called?"
"A pointer to it is saved in a struct."
After that, it's anyone's guess.


Years ago I inherited a good size (~200 kLOC) assembler program that had a
lot of old-fashioned techniques. But at the same time it had a structured
macro scheme that was quite advanced, and included an internal subroutine
call/stack mechanism. I updated the macros to generate symbols for the
assembler xref/ADATA about what was being called and from where, and only
then discovered that the subcall macro had the option to load the "function
pointer" (address) from a field in a "struct" (DSECT), thus making a
complete static xref of calls impossible. The best that could be done
(other than a complete control/data flow analysis) was to also log what
updated those pointers in the struct, but correlating them was almost
impossible.

Bad code can be written using just about any programming paradigm in any
language.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: Assembler courses

2022-09-23 Thread Bernd Oppolzer


Many thanks for these links;

I especially appreciate the tutorials by Brian Will "Object-Oriented 
Programming is Bad",

https://www.youtube.com/watch?v=QM1iUe6IofM

the tips how to improve procedural programming from minute 33 ca.
This is so true, but certain tips require a language more powerful than C,
for example PL/1 or Pascal, which supports nesting of procedure and 
function definitions.
I also liked the term "curly brace languages", which I never heard 
before :-)


Even if you don't agree with the opinions expressed here, it is IMO of 
great value

to look at these videos.

Kind regards

Bernd


Am 20.09.2022 um 11:46 schrieb Peter Sylvester:

Hi,

49 years ago I 'stumbled' over Simula 67 (see video 1), well, at the 
university "informatik 1" course. I had gotten an Algol60 book given 
to me by my math teacher 2 years earlier. The student a year older 
learned PL/1. WE had an /168 and the Simula 67 system from the NCC 
(you can find it on the CBTTAPE, the turnkey system and elsewhere.


To assembler: On error, you got a nicely formatted storage dump of 
objects. One motivation


After two years and the first graduation (Vordiplom) with punched 
cards etc (but using the MFT like a PC), a got a job at at  the CS 
research center GMD:  MVS, TSO SPF, another universe. It would take to 
much here to explain all the reason why I did a lot of assembler 
(because of this I was able to work in an internship at the swiss 
Colony Computing Center), but I always more than mildly disliked aka 
hated the non structured way of assembled. My work was to write a fast 
program to create microfiches (block letters, index pages). The result 
were a set of structured programming macros (also on the cbttape).


Later  with UCLA/Mail, the formatting of "objects" on traces, dumps. 
and stack of function. Just read the "assembler" code (CBTTAPE).


Anyway, here some nice videos.

https://www.youtube.com/watch?v=pH-q2m5sb04

actually, why is smalltalk so close to objective C. Because of a Byte 
Magazine cover page.


https://www.youtube.com/watch?v=SFv8Wm2HdNM

https://www.youtube.com/watch?v=QM1iUe6IofM

https://www.youtube.com/watch?v=eEBOvqMfPoI

Some are provocative. There are many others. I really like "going 
virtually" to these conferences.


https://www.youtube.com/watch?v=_mZBa3sqTrI=45s

Sorry for this side track



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

2022-09-18 Thread Bernd Oppolzer


No english verson of "Adeste fideles"?
In German we have one (since centuries, I believe): "Herbei, o Ihr 
Glaeubigen" (I omitted the Umlaut)

one of the more powerful Christmas songs IMO

Kind regards

Bernd


Am 18.09.2022 um 15:17 schrieb Bob Bridges:

"Emmanuel", indeed :).

I never took Latin (and I was astonished when I learned that my youngest daughter was 
taking it in high school; I thought it had long disappeared entirely from the public 
schools, but apparently not), and my upbringing was Episcopal not Catholic, so I never 
experienced the liturgy in Latin.  And I'm not sorry that so many old Christmas carols 
have been translated to English.  But NO ONE sings "Adeste, fideles" any more!  
I do miss that.

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




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

Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Bernd Oppolzer


You're welcome.

I simply entered "REXX SYSCALLS OPEN" into Google Search, and this was 
the first hit:

https://www.ibm.com/docs/en/zos/2.1.0?topic=commands-open-write-close-file

this is where I found the sample code.

I didn't know or use SYSCALLS before.

Kind regards

Bernd


Am 11.09.2022 um 18:29 schrieb Charles Mills:

Thank you all and especially @Bernd Oppolzer. They key is that I was not 
checking the open for success correctly. I was formatting the second file name 
incorrectly and as a result the open was failing but my code did not make me 
aware of that. Bad open of course yields a bad fd which yields a -21. It is all 
new code and I had not tested open failures specifically.

Not sure where you saw the example that you cited. The IBM doc that I am 
looking at has the following for an example (in its entirety):

"open /u/linda/my.exec" o_rdwr+o_trunc+o_creat 700

which is of course useless with regard to how one checks for errors. IBM could 
do better, especially if open is atypical in how it reports errors.

(https://www.ibm.com/docs/en/zos/2.5.0?topic=descriptions-open)

Thanks again,
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

Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Bernd Oppolzer


Once again wrong, my e-Mail client is fooling me. Next try:

'open' path, O_rdwr+O_creat+O_trunc, 660
if retval=-1 then do
    say 'file not opened, error codes' errno errnojr
    return
end
fd=retval


Am 11.09.2022 um 10:01 schrieb Bernd Oppolzer:

sorry for the strange formatting of the example code:

should be

'open' path, O_rdwr+O_creat+O_trunc, 660
if retval=-1 then do
    say 'file not opened, error codes' errno errnojr return
end
fd=retval

Kind regards

Bernd


Am 11.09.2022 um 09:57 schrieb Bernd Oppolzer:

Why is there suddenly the variable RC used to test the outcome of OPEN?
In the examples in the IBM doc I see:

|'open' path, O_rdwr+O_creat+O_trunc, 660 if retval=-1 then do say 
'file not opened, error codes' errno errnojr return end fd=retval 
|that is:


the returned fd and the code to test the success of OPEN
is both in the variable retval, not RC.

And: it would be better to assign the value of retval to
fd after the test for success.

Kind regards

Bernd


Am 11.09.2022 um 01:45 schrieb Charles Mills:
I am working on a Rexx program that reads one or more UNIX files. 
(And please, don't beat me up for Rexx; we can have the "superiority 
of Python" discussion another day.)


The logic works for the first file, but if there is a second file 
the read fails with a -21, which I interpret as "bad fd." (Am I 
wrong about that?)


Here are the read and open routines. The read routine gets called 
with the file name. It's getting that right because the first file 
works (and the second file works if it is first). There is no error 
printed by FileOpen. I can see from the Print at the start of 
ReadOneFile that the filename is correct. How could the fd be bad if 
the open succeeds?


ReadOneLogFile:
   If IsVerbose Then Call Print "ReadOneLogFile:" Arg(1)
       ADDRESS SYSCALL
   Call FileOpen Arg(1)
      Do Forever
 "read" Filefd "record" LogFileRecLen
 If Length(record) <> LogFileRecLen Then Leave
  /* snip */
  End   /* Read records forever */
      "close" Filefd
     Return

FileOpen:
   /* Open the file */
   "open" Arg(1) O_RDONLY
   Filefd = retval
   if RC = -1 Then Do
 Call Print "Error from Log File open. RC =" RC errno errnojr
 Signal EndProgram
 End  /* RC <> 0 */
   Return

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Bernd Oppolzer


sorry for the strange formatting of the example code:

should be

'open' path, O_rdwr+O_creat+O_trunc, 660
if retval=-1 then do
    say 'file not opened, error codes' errno errnojr return
end
fd=retval

Kind regards

Bernd


Am 11.09.2022 um 09:57 schrieb Bernd Oppolzer:

Why is there suddenly the variable RC used to test the outcome of OPEN?
In the examples in the IBM doc I see:

|'open' path, O_rdwr+O_creat+O_trunc, 660 if retval=-1 then do say 
'file not opened, error codes' errno errnojr return end fd=retval 
|that is:


the returned fd and the code to test the success of OPEN
is both in the variable retval, not RC.

And: it would be better to assign the value of retval to
fd after the test for success.

Kind regards

Bernd


Am 11.09.2022 um 01:45 schrieb Charles Mills:
I am working on a Rexx program that reads one or more UNIX files. 
(And please, don't beat me up for Rexx; we can have the "superiority 
of Python" discussion another day.)


The logic works for the first file, but if there is a second file the 
read fails with a -21, which I interpret as "bad fd." (Am I wrong 
about that?)


Here are the read and open routines. The read routine gets called 
with the file name. It's getting that right because the first file 
works (and the second file works if it is first). There is no error 
printed by FileOpen. I can see from the Print at the start of 
ReadOneFile that the filename is correct. How could the fd be bad if 
the open succeeds?


ReadOneLogFile:
   If IsVerbose Then Call Print "ReadOneLogFile:" Arg(1)
       ADDRESS SYSCALL
   Call FileOpen Arg(1)
      Do Forever
 "read" Filefd "record" LogFileRecLen
 If Length(record) <> LogFileRecLen Then Leave
  /* snip */
  End   /* Read records forever */
      "close" Filefd
     Return

FileOpen:
   /* Open the file */
   "open" Arg(1) O_RDONLY
   Filefd = retval
   if RC = -1 Then Do
 Call Print "Error from Log File open. RC =" RC errno errnojr
 Signal EndProgram
 End  /* RC <> 0 */
   Return

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Bernd Oppolzer


Why is there suddenly the variable RC used to test the outcome of OPEN?
In the examples in the IBM doc I see:

|'open' path, O_rdwr+O_creat+O_trunc, 660 if retval=-1 then do say 'file 
not opened, error codes' errno errnojr return end fd=retval |that is:


the returned fd and the code to test the success of OPEN
is both in the variable retval, not RC.

And: it would be better to assign the value of retval to
fd after the test for success.

Kind regards

Bernd


Am 11.09.2022 um 01:45 schrieb Charles Mills:

I am working on a Rexx program that reads one or more UNIX files. (And please, don't beat 
me up for Rexx; we can have the "superiority of Python" discussion another day.)

The logic works for the first file, but if there is a second file the read fails with a 
-21, which I interpret as "bad fd." (Am I wrong about that?)

Here are the read and open routines. The read routine gets called with the file 
name. It's getting that right because the first file works (and the second file 
works if it is first). There is no error printed by FileOpen. I can see from 
the Print at the start of ReadOneFile that the filename is correct. How could 
the fd be bad if the open succeeds?

ReadOneLogFile:
   If IsVerbose Then Call Print "ReadOneLogFile:" Arg(1)

   ADDRESS SYSCALL

   Call FileOpen Arg(1)
   
   Do Forever

 "read" Filefd "record" LogFileRecLen
 If Length(record) <> LogFileRecLen Then Leave
 
 /* snip */
 
 End   /* Read records forever */
   
   "close" Filefd
  
   Return


FileOpen:
   /* Open the file */
   "open" Arg(1) O_RDONLY
   Filefd = retval
   if RC = -1 Then Do
 Call Print "Error from Log File open. RC =" RC errno errnojr
 Signal EndProgram
 End  /* RC <> 0 */
   Return

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: C compile: INFORMATIONAL CCN4118 name C F1:2008 Character constant 'xF0' has more than 1 character.

2022-08-18 Thread Bernd Oppolzer


In EBCDIC world.

I had a hard time, when I ported the Stanford Pascal compiler to 
Windows/Unix etc.;
it compiled a Pascal Case statement (which is switch in C and SELECT in 
PL/1)

involving char constants as Case labels, and, when building the branch table
(addresses to branch to, depending on the internal value of the char),
it silently assumed the EBCDIC char set :-)

This took me some time to find and to repair and to find a platform neutral
coding in the P-Code, which is generated by the compiler. Because the 
P-Code
is assumed to run on all platforms, regardless of the platform-specific 
character set.


If you want to read more, look here: http://bernd-oppolzer.de/job9i025.htm

Kind regards

Bernd


Am 18.08.2022 um 18:13 schrieb Charles Mills:

'A' is just another way of saying 193.

'ABC' is just another way of saying 12698307.

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

Re: C compile: INFORMATIONAL CCN4118 name C F1:2008 Character constant 'xF0' has more than 1 character.

2022-08-18 Thread Bernd Oppolzer

This is quite natural, given the fact, that char in C is not really a 
type in its own right,

but instead a subtype of int, like short (only smaller).

If you keep that in mind, there is simply no difference between char 
constants

and int constants.

HTH, kind regards

Bernd


Am 17.08.2022 um 22:07 schrieb Charles Mills:

Can of worms.

No more so that the well-established int foo = 'A';


Documentation?

I am sure I did not invent the syntax. I saw it somewhere in the docs.


Portability of e.g. "int foo = 'ABC';":

What about it? Just like the well-established int foo = 'A';


Blank/null fill?

Just like for the well-established int foo = 'A'; the characters are 
low-order-justified and filled on the high side with zeros.


left/right justified?

Same as for int x = 1;


big/small-endian?

No more of an issue than for the well-established int foo = 'A';

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

Re: C compile: INFORMATIONAL CCN4118 name C F1:2008 Character constant 'xF0' has more than 1 character.

2022-08-17 Thread Bernd Oppolzer


In C, char constants are syntactically the same as int constants.

You have two choices to write hex int or char constants:

the "int" flavor:  0xf0

the "char" flavor: '\xf0'

or simply 240

or (this is ill-fated IMO) 0360 ...
because a leading zero makes the number an octal number in C

So, yes, if you choice to use the char representation, you have to code 
apostrophes, not quotes.


(IMO, apostrophe = ', quote = ")

HTH, kind regards

Bernd


Am 17.08.2022 um 11:05 schrieb Binyamin Dissen:

Quite possible.

To confirm, it is '\xf0' with surrounding quotes of \xF0 without quotes. Or
both?


On Wed, 17 Aug 2022 09:31:18 +0200 Bernd Oppolzer 
wrote:

:>Could it be that the source has been transferred in any way?
:>
:>It would be valid, if there was a backslash before the hex constant,
:>like below;
:>backslash, followed by x, followed by two hex digits is a single char in C.
:>
:>str2 = str2 ¦ '\xF0';
:>
:>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

Re: C compile: INFORMATIONAL CCN4118 name C F1:2008 Character constant 'xF0' has more than 1 character.

2022-08-17 Thread Bernd Oppolzer


Could it be that the source has been transferred in any way?

It would be valid, if there was a backslash before the hex constant, 
like below;

backslash, followed by x, followed by two hex digits is a single char in C.

str2 = str2 ¦ '\xF0';

HTH, kind regards

Bernd



Am 17.08.2022 um 09:16 schrieb Binyamin Dissen:

I have inherited some C code.

   str2 = str2 ¦ 'xF0';
   str1 = str1 >> 4;
   str1 = str1 ¦ 'xF0';

These receive

CCN4118 Character constant 'xF0' has more than 1 character.

Examining the source4 it appears the intent is for 0xF0

1. Why would this be a mere informational message? Seems like it should be a
warning. that the sizes do not match.

The code generated is


*str2 = str2 ¦ 'xF0';
   SLR  r0,r0
   IC   r0,str2(,r13,157)
   Or0,=F'10995440'
   Nr0,=F'255'
   STC  r0,str2(,r13,157)
*str1 = str1 >> 4;
   SLR  r0,r0
   IC   r0,str1(,r13,156)
   SRA  r0,4
   Nr0,=F'255'
   STC  r0,str1(,r13,156)
*str1 = str1 ¦ 'xF0';
   SLR  r0,r0
   IC   r0,str1(,r13,156)
   Or0,=F'10995440'
   Nr0,=F'255'
   STC  r0,str1(,r13,156)

10995440 = x'A7C6F0' = 'xF0'

2. This is very old cold, not compiled for years (decades?). Was there a point
in C compiler history where 'this was ever a valid hex constant?

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

Director, Dissen Software, Bar & Grill - Israel

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


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

Re: TESTAUTH from C/C++

2022-08-15 Thread Bernd Oppolzer


That's what I did, for example to be able to call SWAREQ etc. from C
or certain machine instructions which cannot be reached from C otherwise.
Very small ASSEMBLER routines with clean C interfaces.

Because we are only using 31-bit C with standard linkage conventions
and NORENT, the linkage to the ASM routines is a no-brainer. No XPLINK.
Even no LE dependencies or considerations. LE doesn't even notice
that there are some small ASM routines doing some system-related work.

Kind regards

Bernd


Am 15.08.2022 um 21:23 schrieb Kirk Wolf:

IMO, If you are going down the path of writing C/C++ for z/OS of much 
significance, you will likely need to write some assembler routines that you 
can call from C/C++.Just bite the bullet and figure out the calling 
conventions (XPLINK?) and you will be glad in the long run.

The compiler inlining support is another option that often good, but in many 
cases it can be tricky because you have to carefully declare all of the 
register clobbers, not to mention the crazy syntax and symantics of __asm.

Kirk Wolf
Dovetailed Technologies, LLC
http://coztoolkit.com
Dovetailed Technologies: +1 636.300.0901

Note: Our website and domain name have changed from dovetail.com to 
coztoolkit.com




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

Re: Some questions on SYSCALL

2022-06-30 Thread Bernd Oppolzer


Two short comments to add some heat to the discussion;
sorry for that ... I have to leave for the next two days, so I will not 
be able to follow

what happens, but anyway:

1) to David: this is only personal view, not a valid argument (not 
backed by facts);

IMO REXX has many unique features which make it easy and comfortable to use
not found elsewhere. I wrote a generator, which creates ASSEMBLER 
programs to
convert SOAP messages to COBOL structures (CommAreas) for CICS on VSE 
completely in REXX
(as a replacement for an IBM tool, which didn't work well ... 2000 lines 
of REXX).
This has been done, because REXX was the best language available at the 
customer's site
for the task. In the 1990s, I wrote a plotter server to support a 
CalComp plotter in REXX
(on VM); the pictures drawn by the applications were adjusted on the 
plotter output
optimizing the use of the paper and every 15 minutes the results of the 
optimization
was sent to the plotter. The REXX was active all the time 24/7 in a VM 
machine running
DISCONNECTED. The pictures were sent as RDR files to this machine, and 
the plotter

was attached as PRT.

2) to Charles: 13 hours? My C solution would have taken me half an hour 
at most,
if only writing the file is counted and not the collecting of the 
information,

which I cannot comment on, because I don't know the complexity.

Kind regards

Bernd


Am 30.06.2022 um 08:58 schrieb David Crayford:
REXX is never the right language unless you have no choice, such as 
using an API such as SDSF or an environment such as Netview.


On 30/06/2022 11:21 am, Charles Mills wrote:

Charles knows C++ so I don't understand why he would pick REXX
One factor is that my deployment machine does not have a C++ compiler 
and does not share DASD with my development machine. So for C++ the 
cycle is


- Edit in IDE on Windows
- Build in IDE on Windows; get to clean compile
- Upload to development machine
- Build on z/OS (hopefully no z-specific errors; if so, iterate)
- Copy load module from development to deployment (complex load 
module FTP)

- Test
- Repeat as necessary

For Rexx OTOH the cycle is
- Edit in text editor in Windows
- Upload to deployment machine (simple ASCII text upload)
- Test
- Repeat as necessary


You need a better IDE. I recommend Intellij.


A much faster development cycle.

I built, tested and deployed the new HLASM module and the Rexx code 
in about 13 hours billable (including all the discussion here). I 
doubt that I could have done that with C++. There is more to "best 
language for the job" than elegance, conciseness, "modernness" and 
efficiency of execution.


For Python there is no way of knowing, but I think I might have spent 
that much time trying to get Python downloaded and installed. IBM 
manages to make the most simple tasks difficult. For one of the two 
machines I would have had a "business" or "legal" issue that might 
have taken 13 hours; certainly would have taken weeks elapsed. And 
that is before any "learning Python" issues. I am sure it is a 
wonderful language, but I think it is wishful thinking to say "see, 
you had some API issues with Rexx; therefore you would have been 
better off with Python." I suspect I might have had some API issues 
with my first Python program. 


Also, I get great Rexx community support right here on this forum. 
Where would I go for mainframe-specific Python community support? I'm 
sure there is some relevant forum, but how active is it? OT, but I 
have gotten pretty unhappy with Stack Overflow. Too many questions 
there now seem to draw a "not a perfect question" rebuke from some 
self-important moderator.


BTW, I do think I might want to learn Python. I bought an O'Reilly 
textbook. I have a six-hour flight coming up, and I think that it 
might be just perfect for learning Python.


Charles




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

Re: Some questions on SYSCALL

2022-06-29 Thread Bernd Oppolzer


The only reason why your Python code is shorter is because you use
the builtin os.walk method to walk through the directory recursively.
A similar method could have been used in my REXX example, too,
but I wanted a command to be issued in every subdirectory
when walking through the tree,
so I had to do the recursive directory walk myself, using the recursive 
call

to the tree procedure. This is what makes my coding longer,
but this is not due to the REXX language. Be fair.

To call this verbose is simply wrong, and you are missing the point 
completely;
please show me how your Python solution looks, if you also walk the 
directory tree

by yourself and issue a command given as a parameter at every subdirectory
and not only print the name.

but I don't really want to argue on this ... this seems like a waste ot 
time.


I use the tools I have at hand ... and I didn't have Python in 1998 on 
my OS/2 boxes.
This has nothing to do with personal favor; I use the tools which make 
the most

sense for me, given my knowledge or my personal skills (which can of course
change or improve over time).

Earlier in a similar thread I told you or other posters how easy it is 
to append

small pieces of information every 15 minutes to a file using IBM's C
and still having a large blocksize etc. ... and how I would support
the simultaneous update and the reporting. The thread degraded into a
discussion about started tasks and how to implement the operator commands
to control the STCs using REXX or other languages ... again: what a 
waste of time.
For appending information to a file every 15 minutes, I would create a 
batch job
which is started every 15 minutes, controlled by UC4 or cron or whatever 
you have
... and which terminates after some milliseconds. No need for a started 
task,

which is idle most of the time.

I miss sometimes a certain cost sensitivity with the discussions here in 
IBM-MAIN,

but this should be part of our profession.

Kind regards

Bernd



Am 29.06.2022 um 23:24 schrieb David Crayford:

On 30/06/2022 4:22 am, Bernd Oppolzer wrote:



This is an old OS/2 REXX program (from the 1990s, IIRC),
used to traverse a directory tree recursively and issue a command in 
every subdirectory found:



/* rexx */

arg command

call RxFuncAdd "SysLoadFuncs", "REXXUTIL", "SysLoadFuncs"
call SysLoadFuncs

dir = directory()
if right(dir,1) = "\" then
   dir = left(dir, length(dir) - 1)

call tree dir, command

x = directory(dir)

exit


tree: procedure

   arg dir, command

   say "*** Verzeichnis in Bearbeitung: "dir" ***"

   x = directory(dir)

   command

   rc = SysFileTree("*.*", verz, "D")
   do i = 1 to verz.0
  dir = word(verz.i, 5)
  call tree dir, command
   end

   return


you may notice the recursive call of the procedure "tree".

I don't see any justification for your REXX bashing;
it's just another flavor of scripting language, which allows to do 
great things,

once you manage to use it.


Sorry Brend, but I don't consider that snippet to be great! It's a 
perfect example of flabby, verbose REXX code. The only justification 
for using REXX is that you personally favor the language. Python is 
far more succinct.


|for| |root, dirs, files ||in| |os.walk(path_of_the_directory):|
|||for| |i ||in| |files:|
|||print||(os.path.join(root, i))|


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

1 2 3 4 5 6 >

1 - 100 of 563 matches

Mail list logo