I wonder why space is being released with the TSO ALLOC command in the first
place, this ALLOC command does not do this by itself.
It must be defined somewhere in the mgmtclas definitions and/or ACS routines.
Kees.
-Original Message-
From: IBM Mainframe Discussion List
On Mon, 10 Feb 2020 18:27:03 -0600, Fred Kaptein wrote:
>Hello,
>I have a user that is allocating a data set in TSO and REXX using the
>following command
>
>ALLOC DA('ABCD.EFG') NEW CATALOG UNIT(SYSALLDA) DSNTYPE(LIBRARY) LRECL(121)
>RECFM(F B A) CYL SPACE(9) BLOCK(27951) DIR(100)
>
>The
Close=free is a function of the close file
Sent from my iPhone
> On Feb 10, 2020, at 18:27, Fred Kaptein wrote:
>
> Hello,
> I have a user that is allocating a data set in TSO and REXX using the
> following command
>
> ALLOC DA('ABCD.EFG') NEW CATALOG UNIT(SYSALLDA) DSNTYPE(LIBRARY)
Hello,
I have a user that is allocating a data set in TSO and REXX using the following
command
ALLOC DA('ABCD.EFG') NEW CATALOG UNIT(SYSALLDA) DSNTYPE(LIBRARY) LRECL(121)
RECFM(F B A) CYL SPACE(9) BLOCK(27951) DIR(100)
The data set is allocated, but the unused space is released, so the data
JESCT?
On Mon, Feb 10, 2020 at 1:22 AM Vernooij, Kees (ITOP NM) - KLM <
kees.verno...@klm.com> wrote:
> The answers given so far imply that you know the names of the
> primary/secondary subsystems and from that determine under which you run.
> As far as I remember, there is a pointer to *the*
On Mon, 10 Feb 2020 12:21:58 -0600, Paul Gilmartin wrote:
>On Mon, 10 Feb 2020 07:58:26 -0600, Bill Godfrey wrote:
>
>>Given a USS file utf16.txt containing 6 UTF-16 characters, 12 bytes:
>>
>>>od -tx1 -An utf16.txt
>>00 28 20 1C 00 61 20 1D 00 29 00 0A
>>
>>U+0028 is left
Thanks, that makes sense.
On 2/10/2020 2:23 PM, Mike Schwab wrote:
Decimal instructions were affected. Character sets didn't really
affect other instructions.
On Mon, Feb 10, 2020 at 4:17 PM Tom Brennan wrote:
I heard about that bit in college. Do you know what it was supposed to
do
Decimal instructions were affected. Character sets didn't really
affect other instructions.
On Mon, Feb 10, 2020 at 4:17 PM Tom Brennan wrote:
>
> I heard about that bit in college. Do you know what it was supposed to
> do internally?
>
> On 2/10/2020 1:50 PM, Pew, Curtis G wrote:
> > On Feb
I heard about that bit in college. Do you know what it was supposed to
do internally?
On 2/10/2020 1:50 PM, Pew, Curtis G wrote:
On Feb 10, 2020, at 3:01 PM, Mike Schwab wrote:
ASCII wasn't finalized when the S/360 was announced. And it needed to
use existing 7 bit peripherals, tapes,
On Mon, 10 Feb 2020 21:50:59 +, Pew, Curtis G wrote:
>On Feb 10, 2020, at 3:01 PM, Mike Schwab wrote:
>>
>> ASCII wasn't finalized when the S/360 was announced. And it needed to
>> use existing 7 bit peripherals, tapes, etc.
>
>But System/360 was pupposed to be an ASCII machine, or at least
On Feb 10, 2020, at 3:01 PM, Mike Schwab wrote:
>
> ASCII wasn't finalized when the S/360 was announced. And it needed to
> use existing 7 bit peripherals, tapes, etc.
>
But System/360 was supposed to be an ASCII machine, or at least to transition
to ASCII long term. There was a bit in the
I would like to thank everyone (on and off list) for their replies. I have
several things to research. MPF, System Rexx, and such. CBT file 708.
I was aware of Brian Westerman and Syzygy, Inc before. In fact, some years ago,
when we almost indulged in a campaign to eliminate an ISV, they were on
ASCII wasn't finalized when the S/360 was announced. And it needed to
use existing 7 bit peripherals, tapes, etc.
On Mon, Feb 10, 2020 at 1:27 PM Adam Jacobvitz
<02b29b762ea6-dmarc-requ...@listserv.ua.edu> wrote:
>
> IBM mainframes still use EBCDIC?
>
> On Mon, Feb 10, 2020 at 10:54 AM, Paul
On Mon, 10 Feb 2020 19:26:46 +, Adam Jacobvitz wrote:
>IBM mainframes still use EBCDIC?
>
EBCDIC and Fixed-80 are among the bituminous progeny of the
unholy union of OS/360 and the 029 keypunch.
-- gil
--
For IBM-MAIN
On Sun, 9 Feb 2020 15:16:13 -0500, Phil Smith III wrote:
>
>On my list of "things to do when I finish the time machine": No ASCII/EBCDIC
>divide; no null-terminated strings. And something else, I forget what right
>now. I have time, I can always do it last week.
>
You've complained about
IBM mainframes still use EBCDIC?
On Mon, Feb 10, 2020 at 10:54 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 10 Feb 2020 18:43:32 +, Seymour J Metz wrote:
>
>>Why wasn't it simple matter of replacing "colon" with ":" and removing the
>>spaces?
>>
> My
On Mon, 10 Feb 2020 18:43:32 +, Seymour J Metz wrote:
>Why wasn't it simple matter of replacing "colon" with ":" and removing the
>spaces?
>
My fingers betrayed me and deleted one character too many.
I find "roboprig" overly generous; I'd call this software a robovandal. I'm
getting
Why wasn't it simple matter of replacing "colon" with ":" and removing the
spaces? I find "roboprig" overly generous; I'd call this software a robovandal.
I'm getting broadband at home, and am curious whether it is just the webmail or
the mail server that is rewriting message text. Depending
On Mon, 10 Feb 2020 07:58:26 -0600, Bill Godfrey wrote:
>Given a USS file utf16.txt containing 6 UTF-16 characters, 12 bytes:
>
>>od -tx1 -An utf16.txt
>00 28 20 1C 00 61 20 1D 00 29 00 0A
>
>U+0028 is left parenthesis
>U+201C is left double quotation mark
>U+0061 is small letter
On Sun, 9 Feb 2020 23:39:38 -0600, Mike Schwab wrote:
>EBCDIC, EBCDIC DBCS, UTF-16, and ASCII all require the user to know
>the code page for the data set. ...
>
Practically, no. A typical modern system has a ubiquitous default
Unicode page and most editors, shells, interpreters, compilers,
DBCS is not Unicode.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Edward Finnell <000248cce9f3-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, February 9, 2020 11:06 PM
To:
All talk about *anything* you don't understand is potentially dangerous.
Typically people blow away critical distinctions until they have been burned.
Experience keeps a dear school.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM
Those all relate to Unicode, not to EBCDIC DBCS.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, February 9, 2020
Thanks Kurt,
(I'm still a little fuzzy on the FIXCAT() PARM on the APPLY, but it doesn't
sound likely that I will ever use that)
The important things for me are...
1) Use SOURCEID for the when performing an apply for a FIXCAT category (which
is what I've always done).
2) Before applying,
Be careful _which_ utf-16 you've got. This example is "big-endian". If you do a
binary
copy of a file from Windows it's going to be "little-endian" and you need to do
the
iconv using 1202 instead of 1200.
ASCII is a subset of Unicode, and the UTF-8 transform of an ASCII code point is
that code point, so I'd say total upward compatibility. Of course, ASCII had
compatibility issues with itself in the early days, with some bizarre dualing
of code points.
--
Shmuel (Seymour J.) Metz
Not quite.
There are multiple EBCDIC code pages and multiple EBCDIC code pages, but ASCII
is a single 7-bit character set. There are multiple code pages that match ASCII
at 0-127 or a proper subset of that, e.g., 437, 850, 8859-*.
UTF-16 is a transform of Unicode, encoding 20-bit bytes using
On 2/7/2020 2:14 PM, MARTIN, MIKE wrote:
I am trying to figure out the difference between using SOURCEID vs. FIXCAT for
an APPLY? Example below...
APPLY CHECK SOURCEID (IBM.Function.GlobalMirror)
SOURCEID(IBM.Function.GlobalMirror) is the selection criteria. PTFs
that have the specified
Given a USS file utf16.txt containing 6 UTF-16 characters, 12 bytes:
>od -tx1 -An utf16.txt
00 28 20 1C 00 61 20 1D 00 29 00 0A
U+0028 is left parenthesis
U+201C is left double quotation mark
U+0061 is small letter "a"
U+201D is right double quotation mark
U+0029 is right
29 matches
Mail list logo
