protocol enabler in assembler. Coding is simple.
Works well. I only use it outside of cics. Btw, i tried it with other
protocols like syslog and it works just fine.
ITschak
בתאריך יום א׳, 10 במרץ 2019, 18:55, מאת Bernd Oppolzer <
bernd.oppol...@t-online.de>:
Hello all,
some months ago, I
Hello all,
some months ago, I wrote a program which allows to call webservices
(HTTP POST or HTTP GET)
from batch programs, written in C or PL/1. The program (subroutine) is
written in C
and uses the standard TCP/IP socket interface, available in the
classical z/OS environment.
I am doing all
Outside USA, the two-letter acronym BS would probably not trigger
automatically the same reflex. At least it took me some seconds yesterday
to understand why the other poster was laughing about the name of BS2000.
Funny: yesterday evening (after this mail dialog) I went to the cinema and
watched
After some thinking it became clear to me what you have in mind :-)
BS is the German abbreviaton for operating system (BetriebsSystem).
Kind regards
Bernd
Am 25.01.2019 um 08:25 schrieb Sankaranarayanan, Vignesh:
I can't help but laugh at the names BS2000 and BS3000.
LMAO!
– Vignesh
Am 24.01.2019 um 18:01 schrieb R.S.:
W dniu 2019-01-24 o 14:44, Parwez Hamid pisze:
All depends whether you are asking about 'current' Z systems or the
older ones.
You can add the following:
KVM
Hitachi’s operating system, VOS
Well, IT DEPENDS.
KVM is Linux based hypervisor. Is it OS?
what a strange typo ...
"- if it really would run on a current z Hardware"
of course
Am 24.01.2019 um 13:52 schrieb Bernd Oppolzer:
Am 24.01.2019 um 13:25 schrieb R.S.:
W dniu 2019-01-24 o 13:17, John McKown pisze:
This is mainly a curiosity question. I know of: z/OS, z/VSE, z/
Am 24.01.2019 um 13:25 schrieb R.S.:
W dniu 2019-01-24 o 13:17, John McKown pisze:
This is mainly a curiosity question. I know of: z/OS, z/VSE, z/TPF, and
z/Linux. Are there any others?
OK, the real reason I'm asking is to be a bit weird in a game that I
play.
It is "No Man's Sky",which is a
Very nice. I once got a task to rewrite or migrate
some programs which originated in Poland; they were
full of polish variable names. This was very hard because
I had no idea what that variables meant ...
I remember KONIEC, which, IIRC, means end-of-file :-)
after a week or so, I understood at
...@t-online.de (Bernd Oppolzer) wrote:
using this as keyword and a well known search engine,
I found a REXX (from a french site), which I will try tomorrow.
This could be of interest to others, so here is the REXX (unedited,
no warranty),
including some original french comments:
A link, instead
ol Table (SCT) for each step
and check the return code, but I don't know how to do it in a way that IBM will
bless; AFAIK the relevant control blocks are not GUPI.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List
Hello list,
I have the need to compute (in a C, PL/1 or ASSEMBLER module)
the maximum return code of all prior steps of the running job so far.
This is intended to be the last step of the job and to write the MAXRC
into a DB2 table, which shows the requester the outcome of this
special job (in
Some weeks ago in a meeting a co-worker told us,
that in a neighbor team they have a problem with
some "legacy" software which they don't understand any more
and needs to be replaced. The software is written in Java
and is ONE YEAR OLD.
I mentioned that our legacy software is 25+ years old, and
Wild guess:
I found this explanation for S001-4 on some web sites:
S001-4 AbendInput file record length is not equal to the length stated
in the DD or the FD. Wrong length record. IO error, damaged tape, device
malfunction. With disk, reading a dataset that was allocated but never
written
Am 19.06.2018 um 22:18 schrieb Farley, Peter x23353:
The recent discussion about the ability (or not) of setting R14 values in dbx
at a break point while debugging brought me back to an old and (for me)
somewhat sore subject.
The z/Architecture hardware designers graced us with TRAP and TRAP4
... october :-)
Am 11.06.2018 um 22:10 schrieb Bernd Oppolzer:
Hi Saurabh,
you should describe in more detail,
what the content in the PDS member should look before and after
your daily change,
for example (just wild guess):
before the change:
D18610
Hello Group,
I am new to rexx and our
Hi Saurabh,
you should describe in more detail,
what the content in the PDS member should look before and after
your daily change,
for example (just wild guess):
before the change:
D18610
Hello Group,
I am new to rexx and our new requirement to edit one PDS member with
previous day day date
per 32 bits. of each register, so having the upper 32 bits set like
the address register does no harm.
On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer
<bernd.oppol...@t-online.de> wrote:
What I found most interesting in this whole thread was a suggestion
from (IIRC) a SAS guy some days before.
Am 11.05.2018 um 19:34 schrieb Paul Edwards:
On Fri, 11 May 2018 19:22:22 +0200, Bernd Oppolzer <bernd.oppol...@t-online.de>
wrote:
What I found most interesting in this whole thread was a suggestion
>from (IIRC) a SAS guy some days before. He suggested, if I understood
it
What I found most interesting in this whole thread was a suggestion
from (IIRC) a SAS guy some days before. He suggested, if I understood
it correctly, that a large application should run in AM64, but store
internally
only 32 bit pointers; the left half of all registers used as address
Am 10.05.2018 um 04:31 schrieb Tony Thigpen:
Paul said:
> You're quibbling over semantics. A program that
> uses 32-bit data registers and 32-bit address
> registers and 32-bit code pointers and 32-bit
> data pointers is a 32-bit load module.
There is just so much wrong with that statement.
Am 19.03.2018 um 17:57 schrieb R.S.:
Bernd,
I know the installation and know people related to it.
Note: your 4381 was replaced with P/390 and after few years mainframe
completely switched off.
For my knowledge they have never used VSE in production.
What they used was ODRA emulator under
Am 19.03.2018 um 17:07 schrieb Tony Harminc:
On 19 March 2018 at 11:45, Bernd Oppolzer <bernd.oppol...@t-online.de> wrote:
Stuttgart and Lodz are partner towns (jumelage in French,
don't know the English expression).
Often the expressions "twin towns" or "twin ci
Am 19.03.2018 um 10:52 schrieb R.S.:
W dniu 2018-03-19 o 06:24, ITschak Mugzach pisze:
I wonder if anyone (vendors, maybe) has an insight into the mainframe
market size:
- number of sites
- vse vs zos
- continental distribution
- sectiors
IBM?
I'm pretty sure IBM is not
Am 17.03.2018 um 04:34 schrieb David Crayford:
On 17/03/2018 9:27 AM, Bernd Oppolzer wrote:
b) the hope that younger developers can be moved to mainframe
development by a more "modern" IDE (but they aren't interested,
anyway ... they simply don't want to learn PL/1 and such thi
Am 16.03.2018 um 15:20 schrieb David Crayford:
On 16/03/2018 5:16 PM, Itschak Mugzach wrote:
The purpose of RDZ was to save expensive TSO cycles and overhead.
That's interesting! RDz spawns a UNIX process for each connection and
the server is written in Java which makes extensive JNI calls.
The company where I am working since 3 years now tried very hard to
migrate from
a home grown light weight TSO ISPF based software development platform
(using
CA librarian as source code repository) to the new Eclipse based RDz IDE.
But: no success. IBM could not deliver the solutions we
Hi,
IMO, the first save area should always be below the line.
It is provided by the operating system so that the main program of the
called application (EXEC PGM=...) can store the registers on call there.
And the first program may be AMODE 24 :-)
On the other hand, I would never use TCBFSA to
memcpy (jobname, JNPI, 8);
jobname [8] = 0x00;
printf ("jobname = %s\n", jobname);
}
Am 09.02.2018 um 12:57 schrieb Bernd Oppolzer:
This is a slightly modified version of jn2.c:
#include
#include
#include
#include
int main (int argc, char **argv)
{
int *PSA;
in
ould (as a QA person) force the coder to
eliminate these parts of the code.
Kind regards
Bernd
Am 09.02.2018 um 12:32 schrieb Bernd Oppolzer:
Am 09.02.2018 um 07:45 schrieb Elardus Engelbrecht:
Bernd Oppolzer wrote:
To be more pedantic, use additional parantheses:
ASXB = (int *) (((char *) ASCB)
these parts of the code.
Kind regards
Bernd
Am 09.02.2018 um 12:32 schrieb Bernd Oppolzer:
Am 09.02.2018 um 07:45 schrieb Elardus Engelbrecht:
Bernd Oppolzer wrote:
To be more pedantic, use additional parantheses:
ASXB = (int *) (((char *) ASCB) + 0x6c);
I C ( "I see" ;-D )
Serious
Am 09.02.2018 um 07:45 schrieb Elardus Engelbrecht:
Bernd Oppolzer wrote:
To be more pedantic, use additional parantheses:
ASXB = (int *) (((char *) ASCB) + 0x6c);
I C ( "I see" ;-D )
Seriously, I find this whole thread very interesting.
Just a question please and please
To be more pedantic, use additional parantheses:
ASXB = (int *) (((char *) ASCB) + 0x6c);
Kind regards
Bernd
Am 08.02.2018 um 20:47 schrieb Bernd Oppolzer:
int *ASCB;
int *ASXB;
ASXB = ASCB + 0x6c;
because ASCB is a pointer to int, and int has sizeof = 4,
you are in fact adding 4
int *ASCB;
int *ASXB;
ASXB = ASCB + 0x6c;
because ASCB is a pointer to int, and int has sizeof = 4,
you are in fact adding 4 * 0x6c to ASCB, that's your problem.
use the following notation, and it will work:
ASXB = (int *) ((char *) ASCB + 0x6c);
first you cast the ASCB to a char *,
IIRC, I had a similar problem once, when trying to retrieve
the DS name from a 3 byte item which was located in the TIOT
near the DD name. This was not possible to do using pure C, because
the 3 byte item (which was an address in early stages of MVS) now
is a sort of handle to an area which has
Am 13.01.2018 um 07:28 schrieb David Crayford:
On 13/01/2018 4:10 AM, Bernd Oppolzer wrote:
Am 12.01.2018 um 20:42 schrieb Seymour J Metz:
I disagree; C is not remotely like assembly language, and the
pre-processor is pathetic compared to any other macro facility that
I have seen
Am 12.01.2018 um 20:42 schrieb Seymour J Metz:
I disagree; C is not remotely like assembly language, and the pre-processor is
pathetic compared to any other macro facility that I have seen. The confusion
between pointers and arrays and the zero-delimited strings are booby traps for
the
When I worked for a big insurance company (for more than 20 years),
we did all our insurance math using binary FP. After some problems
(rounding issues) in the beginning, it worked without problems, and
it still does today. It was driven by the design decision to have the same
software working on
improvement.
HTH,
kind regards
Bernd
Am 28.11.2017 um 21:31 schrieb Bernd Oppolzer:
Very wild guess:
I had a similar behaviour once in an IBM system component.
The problem was, that this component, trying to find out if
a peculiar module has been loaded already, sequentially scanned
the list of l
Very wild guess:
I had a similar behaviour once in an IBM system component.
The problem was, that this component, trying to find out if
a peculiar module has been loaded already, sequentially scanned
the list of loaded modules (CDE/XTLST). This is no big problem,
if the number of modules in the
Am 27.11.2017 um 15:54 schrieb David Crayford:
On 27/11/2017 10:51 PM, Bernd Oppolzer wrote:
Maybe dump question:
That's a very mainframe Freudian slip ;)
Indeed, I had a good laugh myself, when your answer came in ...
it was not only a typo on my side
se
Pascal supports
call by value, too, setting the high order bit in the parameter list is
normally not a good
idea).
But this GDDM manual is long gone ... sadly.
Kind regards
Bernd
Am 27.11.2017 um 15:17 schrieb Greg Price:
On 2017-11-27 7:22 PM, Bernd Oppolzer wrote:
run on my 3279
Am 27.11.2017 um 09:47 schrieb Elardus Engelbrecht:
Bernd Oppolzer wrote:
We used GDDM and 3279 G (IIRC) displays to do preview of our plotter outputs
.
... This was in the 1985 to 1995 time frame. After that, the applications moved
off the mainframe, to Unix workstations.
Around 1990
We used GDDM and 3279 G (IIRC) displays to do preview of our
plotter outputs (which were to pe printed on big electrostatic Calcomp
plotters in the end).
The (most technical) software was written in Pascal and Fortran and
built the output using a graphic software which was called GKS (graphic
Am 08.11.2017 um 18:47 schrieb Thomas David Rivers:
Frank Swarbrick wrote:
Doesn't that make for fairly large executables?
Well - it can - but a trimmed down C library is surprisingly small.
Of course - if you're dragging C++ into this, then things get bigger; but
again - that's not the
Would the following approach help?
From C/C++, you call an ASSEMBLER submodule, which ATTACHes a subtask
and waits for its completion.
The subtask does all the 64 bit AMODE switching (and return), and
establishes
an ESTAE exit (or other technique) to handle errors that occur inside
the
Once again:
is my understanding correct, that LE cannot handle the 64 bit situation
in the SDWA
correctly, and you repair this by modifying the contents of the SDWA in
your ESTAE routine,
before percolating to LE, that is: you are "fooling" LE, this way
repairing (?) the problem
that LE has?
can the AMODE 64 Assembler routine establish its own ESTAE routine
which takes precedence over LE? Don't know, if there is already ESPIE /
ESTAE
support for the 64 bit case (don't know much about AMODE 64 altogether).
I believe that with AMODE 31 this should be possible (establishing another
runopts, will the other
options work anyway?
Obviously, there are many ways to specify run time options;
it is not totally clear to me, which ways take precedence ...
Kind regards
Bernd
Am 26.08.2017 um 23:26 schrieb Bernd Oppolzer:
Am 25.08.2017 um 22:08 schrieb Charles Mills:
I have a C
Am 25.08.2017 um 22:08 schrieb Charles Mills:
I have a C++ program compiled with
#pragma runopts( POSIX(ON),TRAP(ON,NOSPIE),NOEXECOPS )
I have my own ESTAEX. On an ABEND, if SDWACLUP is not set, I percolate,
presumably to LE's ESTAE and it drives my C Signal catcher.
It works. In testing, and
Am 26.08.2017 um 19:31 schrieb Peter Hunkeler:
Note that we're a COBOL shop, and COBOL allows operations that loose
significant digits in numbers. This causes troubles when the decimal
overflow program mask is set, which it is if C code is also part of
the application (implicit or explicit).
http://www.oracle.com/technetwork/database/enterprise-edition/tg4drda-097332.html
Am 14.08.2017 um 19:26 schrieb Bernd Oppolzer:
I don't know this,
but in the 1990s we had a product that did the opposite;
it was called "Oracle transparent gateway"
and it provided access to DB2
I don't know this,
but in the 1990s we had a product that did the opposite;
it was called "Oracle transparent gateway"
and it provided access to DB2 (or SQL/DS) databases
for Oracle applications. The DB2 databases looked to
the applications like Oracle databases; this was very interesting,
True. We had some manuals translated in German (PL/1, IIRC),
where the translation was so bad that it was almost unusable.
It turned out that the translation had been done by people
who had no understanding of the topic (PL/1, programming language).
This was in the 1980s, BTW. We used english
... some of the indentation in the first example,
which was already awful, has been further damaged
by my eMail program :-)
Am 05.08.2017 um 10:44 schrieb Bernd Oppolzer:
A similar problem occurs, when I am coding a subroutine (or function)
in C, PL/1, Pascal, whatever, and I am checking some
A similar problem occurs, when I am coding a subroutine (or function)
in C, PL/1, Pascal, whatever, and I am checking some conditions at the
start and processing should stop if the conditions aren't true, but
immediate
return is no option, because some housekeeping has to be done at the end
of
ussions on this topic on the PL/1 mailing list
(pl...@listserv.dartmouth.edu), if you are interested.
Kind regards
Bernd Oppolzer
Anyway, it's been really difficult to make out what this post is about.
What's with all the discussion about what's in the loop, &quo
Am 25.07.2017 um 22:31 schrieb Cameron Conacher:
Hello Tom,
Clearly I phrased things incorrectly.
I meant exactly that old compiler versions raised the warning message to
the effect that the VALUE IS clause was being ignored, if the VALUE IS
clause was present in the LINKAGE Section.
However,
IMHO, this kind of behaviour MUST have to do with some
logic inside the application, which allocates storage dynamically
and reacts on "short on storage" conditions from LE (aka language
environment) - which is the runtime for all compiled languages today.
Storage consumption by LE is controlled
This has already been brilliantly explained by Frank Swarbrick;
the new COBOL compiler version has a new INITIALIZE statement
which is able to INITIALIZE variables of the LINKAGE SECTION,
so that the VALUEs coded there are not comments any more,
but instead the have a meaning !!
In the past,
rame Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Bernd
Oppolzer <bernd.oppol...@t-online.de>
Sent: Wednesday, June 21, 2017 2:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I and C (was Re: Simple (?) C question)
Hi Frank,
1.) yes, the C area acquired by ma
Hi Frank,
1.) yes, the C area acquired by malloc must be freed by someone
2.) unfortunately, the PL/1 FREE statement cannot do it, because,
as I recently observed while checking some PL/1 modules for storage leaks,
PL/1 stores its heap areas (allocated by PL/1 ALLOC / FREE) in the LE
ANYWHERE
Some additional remarks below ...
Am 20.06.2017 um 22:56 schrieb Bernd Oppolzer:
I tried the program, too, using my local Watcom C compiler.
No problems, but I had to add some global definitions to make it run.
Looks like this:
#include
#include
#include
char *get_static_string(void
I tried the program, too, using my local Watcom C compiler.
No problems, but I had to add some global definitions to make it run.
Looks like this:
#include
#include
#include
char *get_static_string(void) {
static char str[81] = "This is a statically allocated C string";
return str;
}
It's thread safe in that sense that several processes
(LE enclaves) running in parallel each get their own
instance of the WSA, so there is no mixing of static
variables in this case.
Of course, if you use other variants of multi-threading
which don't involve separate (that is, parallel) LE
Am 20.06.2017 um 13:12 schrieb Don Poitras:
Not if you compile RENT. In that case the static is allocated in a separate
area rather than being inside the load module.
and: every invocation of the module from potentially parallel
LE enclaves (for example, when used inside a DB2 stored proc
What about some examples to make things clear?
500 decimal is 0x1f4 in hex (256 + 15 * 16 + 4)
in a big endian halfword (2 bytes), this looks like 01 F4
big endian fullword (4 bytes): 00 00 01 F4
when processed by a 32 bit machine (for example IBM mainframe),
both representations (2 bytes
What you really would need is an attribute on the variable definition
(in addition to a compile option) which tells if a variable is
BIGENDIAN or LITTLEENDIAN or in case of a char variable or
string, what encoding is has. PL/1, AFAIK, has all that.
If you mix BIGENDIAN and LITTLEENDIAN variables
Am 12.05.2017 um 00:08 schrieb John McKown:
On Thu, May 11, 2017 at 4:55 PM, Bernd Oppolzer <bernd.oppol...@t-online.de>
wrote:
Yes, of course. I detected the error when I looked at
my piece of software from last year which examined the different LE heaps.
and: thank you, Allan Ki
*IN EINEN C-BUFFER (DER ALS PARAMETER
*UEBERGEBEN WIRD). ZWECK DER UEBUNG:
*ZUGRIFF AUF CEECAA (COMMON ANCHOR AREA VOM LE)
*UND DAMIT AUF ANYHEAP UND BELOWHEAP
*BERND OPPOLZER / AUGUST 2016
***
*
R0
oh oh ...
I did not take this into account ...
I wrote a C program to get the HPCB addresses for Belowheap and Anyheap,
and to get them, I needed the CEECAA, and I did this by looking at reg
12 using
an ASSEMBLER subprogram:
memset (rbuffer, 0x00, sizeof (rbuffer));
MDV9970 (rbuffer);
egards
Bernd
Am 10.05.2017 um 21:25 schrieb Bernd Oppolzer:
I guess that this is the same case as finding C and PL/1 static
variables
when the C and PL/1 procedures or functions are compiled using the RENT
compiler switch.
Because:
a) auto variables are always part of the "stack" whic
I guess that this is the same case as finding C and PL/1 static variables
when the C and PL/1 procedures or functions are compiled using the RENT
compiler switch.
Because:
a) auto variables are always part of the "stack" which is addressed by
register 13
(aka save area aka dynamic save area
Different for C.
I wrote many ASSEMBLER functions callable from C
and looked at (oh so many) dumps (mine and others)
which were generated by errors in C programs. The "by value" doubles,
for example, are part of the R1 parameter list. Not sure for large
structures ...
What you describe for
Well, from a technical point of view,
languages like PL/1 (and Fortran, for example), which in their
classical form only supported call by reference, put only addresses in the
reg 1 addressed so-called parameter (address) list. (reg 1 points at the
start
of a list of parameter addresses, so
Two machines with Pentium CPUs here, running OS/2 V3.0
and Linux. One from 1997, the other from 1999.
Both in perfect state, no problems. IBM SCSI devices,
which had 5 years warranty originally, which could
make a difference. The machines were sort of expensive
at their time (7000 Deutsche Mark
better without a space:
https://en.wikipedia.org/wiki/BS2000
Kind regards
Bernd
Am 17.04.2017 um 11:01 schrieb Bernd Oppolzer:
Did anyone mention BS 2000 ?
IIRC, BS 2000 did run on IBM mainframes, too,
not only Siemens and Fujitsu.
German Wikipedia says: Architectures for BS 2000 are
S
Did anyone mention BS 2000 ?
IIRC, BS 2000 did run on IBM mainframes, too,
not only Siemens and Fujitsu.
German Wikipedia says: Architectures for BS 2000 are
S/370, S/390, SPARC, MIPS, x86
and it is still in use today.
Kind regards
Bernd
Am 17.04.2017 um 07:14 schrieb Anne & Lynn Wheeler:
Topic drift:
This is somehow easy from PL/1, for some reasons:
a) parameters to external functions can be defined in PL/1 to be
passed using NODESCRIPTOR and BYVALUE, so that the mechanisms
perfectly match the C mechanisms
b) PL/1 has a datatype CHAR (x) VARYINGZ (no typo), which means:
Hi,
if the COBOL subroutines are compiled using NORENT, there could be another
possibility; we used this at my former customer's site.
The ASSEMBLER main program could call a dummy COBOL main,
which does nothing (but builds the LE environment) and calls again the
ASSEMBLER main at a secondary
I have written something similar to this for a customer of mine,
which tested arbitrary routines (PL/1, ASSEMBLER, C). The interfaces of
the routines had to be defined to the system, and then the system could
run thousands of testcases, stored on PO members (optionally on DB2),
and compare the
At a customer of mine we had a graphic package which did the
presentation layer of the scientific and technical applications (called
GKS,
graphic kernel system). The output of GKS went to plotters (Calcomp)
and graphic displays (via GDDM). The interesting thing about this was
that you had not
Am 24.02.2017 um 14:37 schrieb R.S.:
W dniu 2017-02-23 o 20:09, Bill Woodger pisze:
Also note that if you see a current job-ad for Fujitsu Mainframe
skills in the UK, it will be for an ICL Mainframe, running VME, and
being distinctly different from... anything from IBM. The COBOL is to
the
BS2000 is a Siemens Operating System (BS = Betriebssystem, german for
Operating System)
which is still in use today. It seems to run on other platforms, too;
german Wikipedia says: S/370, S/390, MIPS, SPARC, x86.
BS3000 was a Siemens Operating System, too, but it was in fact MVS,
which lead to
I guess, Konrad Zuse in the 1930s used movie film for controlling his
machines, too.
The instructions were on the (movie film) tape, and by stepping the
tape, the machine
executed the instructions on the tape. There were no control
instructions, no conditional
branches (of course); only an
on;
until the machine went out of service in 1981.
Kind regards
Bernd Oppolzer
Am 13.01.2017 um 23:16 schrieb Bernd Oppolzer:
BTW: the teletypes were General Electric devices, and the paper tape
had 8 holes, not 5.
So every row on the tape could hold one 8-bit byte; I don't know wh
teletypes and the display terminals (text and even
vector graphic devices)
were not directly attached to the TR 440; there was a TR 86 S satellite
computer doing the I/O work.
This was in the late 1970s.
Kind regards
Bernd
Am 13.01.2017 um 23:05 schrieb Bernd Oppolzer:
When I worked
When I worked as a student at the university of Stuttgart, Germany
with the Telefunken TR 440 mainframe, before I had access to the display
terminals,
I had to use the card punch (IBM 29, IIRC). But there were also some
teletypes
attached to the machine, which could be used for a time sharing
This might not help you with your problem, but:
at a site where I was working for years, all dynamic loads or calls (all
languages,
that is, PL/1, ASSEMBLER, anc C) were done thru a site specific
interface module,
which ended up in a LOAD SVC, of course. On first call (that is, on
LOAD), the
Hi Robert,
IMO this is a valid and remarkable observation, but I don't believe that
anybody in the companies that use PL/1 heavily will take much care of it.
Because:
a) there is no time to analyze the outcome of the compiler in such depth,
that it could lead to recommendations or requests to
.ibm.com/systems/z/os/zos/features/xml/
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bernd Oppolzer
Sent: Thursday, November 17, 2016 12:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL parsing of "delimited files&q
BTW:
at the company where I am working at the moment,
we need to build "true" XLS files at the mainframe (no CSVs)
which are then transferred to a Windows network drive, so that
the clients (that is, Accounting people etc.) can fetch them from there.
The problem with mainframe generated CSVs is
I didn't know about the existence of the RFC.
I think that some things are missing,
for example: in Germany (and German editions of Office packages),
the separation char in CSV is a semicolon, because the comma is used
in numeric values instead of the decimal point
(see COBOL's "DECIMAL POINT IS
Some suggestions:
- try REPORT (LE option) to see where the storage is used (below, above,
User heap,
LE below- or anyheap) and how much storage is used before you get in
trouble; does it
depend from the amount of input data? REPORT will also show if you can
do any better
by playing with the
tsicks in Germany
same for IMS, one word, no single letters (like eems, but short ee)
same for DOS
but: zed oh ess (German pronounciation of the letters)
oh ess 390 (390 in German)
v sam (sam like sum)
DB2 (with German number "zwei")
like OS/2, btw (oh ess zwei)
on my PC I have an old version
schrieb Bernd Oppolzer:
You need two additional bytes after ONEBYTE and TWOBYTE,
so that UNPK can do its nibble switching thing there.
ONEBYTE DCX'C4'
DSC
TWOBYTE DSCL2
DSC
...
UNPK TWOBYTE(3),ONEBYTE(2)
TRTWOBYTE,HEXTAB-C'0'
...
HEXTAB DC
You need two additional bytes after ONEBYTE and TWOBYTE,
so that UNPK can do its nibble switching thing there.
ONEBYTE DCX'C4'
DSC
TWOBYTE DSCL2
DSC
...
UNPK TWOBYTE(3),ONEBYTE(2)
TRTWOBYTE,HEXTAB-C'0'
...
HEXTAB DC
Am 12.09.2016 um 16:24 schrieb Norbert Friemel:
On Mon, 12 Sep 2016 09:05:29 -0500, John McKown wrote:
We are running z/OS 1.12 on a z9BC. We have COBOL 3.4. Neither will ever be
upgraded. We will not obtain new hardware or software. Given the absolute
truth of the preceding :-( does anybody
We have such discussions at the site where I'm currently working, too.
What I miss most of the time:
there are all sorts of source code generators, most of the time little
home grown tools (written in REXX), for example: enter a name
of a DB2 table, and then the tool gets the column definitions
instrumentation different? I assume you wrap
malloc()/free() calls?
On 9/08/2016 1:50 AM, Bernd Oppolzer wrote:
IMO there is no need to create additional heaps
to support dynamic tables in COBOL.
I did some research some days ago on the LE heap
implementation and found an old IBM presentation (fro
IMO there is no need to create additional heaps
to support dynamic tables in COBOL.
I did some research some days ago on the LE heap
implementation and found an old IBM presentation (from 2005) on
this topic called "Stacks and Heaps" (you will find it using
Google, the full title reads something
201 - 300 of 564 matches
Mail list logo
