2020 6:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
The EM* (sorry, that's how I recalled it) interface is to IEFDB476.
According to manual, DAIRFAIL is an alternative. The doc is in the Auth
Ass. Serv. Guide, Chapter 26, section "Processin
The EM* (sorry, that's how I recalled it) interface is to IEFDB476.
According to manual, DAIRFAIL is an alternative. The doc is in the Auth
Ass. Serv. Guide, Chapter 26, section "Processing messages from dynamic
allocation".
If you follow the instructions there, you'll get the messages you would
Sent: Wednesday, April 1, 2020 5:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
Huh. Well then, what WAS the purpose of VISAM?
Not arguing with you. Just wondering now. I KNOW my client had a home-grown
hybrid ISAM/BDAM access methond.
Charles
-Ori
: Wednesday, April 1, 2020 11:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
On Wed, 1 Apr 2020 09:01:12 -0700, Charles Mills wrote:
>I wonder if the true statement is "ISAM did not support updating a record if
>the length changed."
No,
du/~smetz3
From: IBM Mainframe Discussion List on behalf of
Steve Smith
Sent: Wednesday, April 1, 2020 1:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
Does that make a difference? The method for extracting DYNALLOC messages
is well-documented, like t
On Wed, 1 Apr 2020 09:01:12 -0700, Charles Mills wrote:
>I wonder if the true statement is "ISAM did not support updating a record if
>the length changed."
No, that's not true either. This from the previously mentioned ISAM Logiic
manual:
The WRITE KN macro instruction is used
with the READ
; Pretty well explained. You code CALL BPXWDYN "ALLOC FI(SORTOUT)
> DA(target.dataset) OLD" and voila! (Yes, you probably need some return code
> checking also.)
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LIST
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Charles Mills
Sent: Wednesday, April 1, 2020 12:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
> By the way, what ~is~ SVC 99?
First, n
ist [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bob Bridges
Sent: Tuesday, March 31, 2020 4:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
I'm trying to picture what this would involve. I don't know from SVC 99, but
it seems to me nothing very
own "VISAM."
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: Wednesday, April 1, 2020 6:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
On Tue, 31 Mar
On Tue, 31 Mar 2020 13:46:07 -0700, Charles Mills wrote:
>RECFM=V was not supported by ISAM.
It most certainly was. We used it in the early 1970s at Wayne State
University for the Admissions system.
See page 147 of the JCL Reference manual for OS/360 release 21.7
http://bitsavers.org/pdf/ibm/36
On Tue, 31 Mar 2020 19:32:53 -0400, Bob Bridges wrote:
>
>By the way, what ~is~ SVC 99? Some kind of assembler call, I suppose? I've
>written in assemblers, but haven't yet learned HLASM. One of my many
>ambitions; still trying to get around to it.
>
A Rexx programmer might think of SVC 99 as
t: Tuesday, March 31, 2020 4:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PARM= vs PARMDD= and symbol substitution
>
> There were apparently several "VISAMs" around, because OCCURS DEPENDING is
> such a basic feature of COBOL but RECFM=V was not supported by ISAM.
>
@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
There were apparently several "VISAMs" around, because OCCURS DEPENDING is such
a basic feature of COBOL but RECFM=V was not supported by ISAM.
I had a client (not FSA but interestingly also in the financial package
When you "play" with a TIOT you use an ENQUEUE of SYSZTIOT to
serialize it.
OPEN and CLOSE use SYSZTIOT, ALLOC and SVC99 use it (ALLOC
probably uses SVC99 rather than DAIR these days, but it has been
a long time since I got into that stuff).
SVC 99 is a specific SVC (Supervisor Call) that ty
SVC 99 == DYNALLOC, the most unfunctional macro ever written, i.e. replaces
6 keystrokes with 7. I guess it saves the comment?
Just for fun, I have written CALL
(15),(S99RB),VL,LINKINST=DYNALLOC,MF=(E,S99PL)
ya see, it's only one line, instead of... idk, whatever.
sas
On Tue, Mar 31, 2020 at
I'm trying to picture what this would involve. I don't know from SVC 99, but
it seems to me nothing very bad would happen. Suppose my TSO session is
running two threads at the same time. (That never happens, although I get the
impression I could make it possible by some exotic coding. We'll
ssage-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bob Bridges
Sent: Tuesday, March 31, 2020 3:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
No, much less efficient (I assume). It's an external REXX exe
No, much less efficient (I assume). It's an external REXX exec; the caller
feeds it a prefix, and it appends random numbers after the prefix until it hits
a string that doesn't represent a DD that is currently allocated. It cannot be
very fast, but then I need to call it only once or thrice in
99 service.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bob Bridges
Sent: Tuesday, March 31, 2020 2:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
In any REXX I write that has to
It's mostly a matter of how the routine comes to be in the first place.
Usually I get tired of doing some repetitive task, so I write an exec for
it. In such a case I almost always write it for foreground execution, and
in the foreground I almost never look for DD names; I just allocate the DS
dyn
On Tue, 31 Mar 2020 17:35:52 -0400, Bob Bridges wrote:
>In any REXX I write that has to know, I include this statement at the
>beginning:
>
> fbat=(sysvar('SYSENV')='BACK')
>
Of course that works only for TSO. But a prior check of PARSE SOURCE
can detect IRXJCL and UNIX.
>Hm, no one ever told
In any REXX I write that has to know, I include this statement at the beginning:
fbat=(sysvar('SYSENV')='BACK')
If SYSVAR('SYSENV') is "BACK", it's running in the background so I set the fbat
flag. Elsewhere in the program it checks FBAT:
if fbat then 'look for a DD
else 'use a predeterm
o:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tony Thigpen
Sent: Monday, March 30, 2020 8:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
Digging back into my mind for data from 1983:
Third National of Nashville (TNB) ran a bank data processing site in
Florence, AL. The
Like Tony, I come from a VSE background and mostly lurk here.
When I came to Peoria, IL, to work for Ruppman Marketing, I was told
more or less the same story but about BetaCom [not sure of the
spelling].
The way that I got it, was that this product was in a development
competition with what bec
LISTSERV.UA.EDU] on behalf of Bob
Bridges [robhbrid...@gmail.com]
Sent: Tuesday, March 31, 2020 12:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
Oh, that; I thought you meant some special JCL setting. Yeah, makes sense.
Most of the utilities I write in R
ussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, March 31, 2020 2:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
On Tue, 31 Mar 2020 12:20:27 -0400, Bob Bridges wrote:
>
>
On Tue, 31 Mar 2020 12:20:27 -0400, Bob Bridges wrote:
>
>... So such a REXX is updated to say "if I'm running in batch, look for
> this DD name; otherwise use this DSN". ...
>
How do you tell? PARSE SOURCE will distinguish IRXJCL and OMVS, but
TSO, IKJEFT01, and Edit are ambiguous. Why, w
Oh, that; I thought you meant some special JCL setting. Yeah, makes sense.
Most of the utilities I write in REXX I write for foreground operation,
command-driven, thus dynamic allocation like that. If someone prefers batch
it's easy enough to write an IKJEFT01 for it, allocating SYSPROC and/o
ehalf Of
Tony Thigpen
Sent: Monday, March 30, 2020 6:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
As I said, there are some good things and bad things for each OS.
As to your question, if someone is using the file when the 5 hour job gets to
that poin
://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob
Bridges [robhbrid...@gmail.com]
Sent: Monday, March 30, 2020 9:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
If "ty
es?
Make sense?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bob Bridges
Sent: Monday, March 30, 2020 3:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
It's clear you're tryi
If "typical Blue thinking of the age" is meant to be a sneer, I don't see it.
If I thought a change I was proposing would involve a HUGE conversion effort,
or a customer revolt - either one, to say nothing of both - I don't care how
much better I thought it might be; it would have to be an opti
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
That was an interesting and probably true VSAM story, or at least very easy to
believe true. I had a similar exposure to the "original" VSAM design from a
lecturer in an "Operating Systems and Desig
sense to me at the time. Typical Blue thinking
of the age (mid-to-late 1970's I think).
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Tony Thigpen
Sent: Monday, March 30, 2020 6:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and s
the
5-hour job already owns?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tony Thigpen
Sent: Monday, March 30, 2020 8:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
Yes, befor
It's clear you're trying to offer a solution, but I don't follow. Right, I'm
using DISP=OLD. I take it "dynamic allocation" must mean "don't allocate the
dataset until I'm ready to write to it", but when I do this:
// EXEC PGM=SORT
//SYSINDD DSN=parmlib(mbr),DISP=SHR
//SORTIN DD DS
tatements. EXEC trails the file
specifications rather than leading them.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Tony Thigpen
Sent: Monday, March 30, 2020 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
EXTER
: PARM= vs PARMDD= and symbol substitution
It's beginning to sound like z/VSE is an improvement in several ways on z/OS.
I wrote a production job recently that updates a dataset pretty much anyone can
View (a list of current Top-Secret ACIDs to see what so-and-so's ACID is, or
who
owns it is waiting on something the
5-hour job already owns?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tony Thigpen
Sent: Monday, March 30, 2020 8:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD=
It's beginning to sound like z/VSE is an improvement in several ways on z/OS.
I wrote a production job recently that updates a dataset pretty much anyone can
View (a list of current Top-Secret ACIDs to see what so-and-so's ACID is, or
who belongs to ACID such-and-such). The update has to read
Yes, before the EXEC card.
Actually, there is no 'allocation' of a file by z/VSE during the JCL
processing. The file is only 'allocated' once it is opened and
'unalocated' once the program closes the file.
For instance, if you have a 5 hour program, that just needs to update a
'totals' VSAM
On Mon, 30 Mar 2020 10:11:53 -0400, Tony Thigpen wrote:
>Coming from the z/VSE world, some of the JCL stuff in z/OS just is 'weird'.
>
I understand that in z/VSE tne DD statementw precede the EXEC for
the step. Intuitive because allocation is done first.
>1) In z/VSE, the conditional jcl statem
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
> Sucks. WAD. Sucks.
ITYM BAD.
> I raised this issue here several years ago and got the
> (condescending, IIRC) explanation: Of course it works that way.
> the converter(?) builds a control block
List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Tony Thigpen [t...@vse2pdf.com]
Sent: Monday, March 30, 2020 9:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
Actually, it makes sense to me, in a strange way.
I don't know if I can describe why it makes se
-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Monday, March 30, 2020 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
On Mon, 30 Mar 2020 09:29:35 -0400, Tony Thigpen wrote:
>Actually, it mak
I tried the sample from IBM Manual and it seems it works as designed.
I've not read properly so sorry about that.
This JCL works the way you want:
//*---*
//STP01 EXEC PGM=ICEGENER
//SYSPRINT DD DUMMY
//SYSUT1 DD *,SYMBOLS=(JCLONLY
Coming from the z/VSE world, some of the JCL stuff in z/OS just is 'weird'.
1) In z/VSE, the conditional jcl statements are more logical, not
something akin to RPN.
2) Our SETPARMs are sequential. You can have multiple SETPARMs of the
same variable in the same step and intervening statements ar
On Mon, 30 Mar 2020 09:29:35 -0400, Tony Thigpen wrote:
>Actually, it makes sense to me, in a strange way.
>I don't know if I can describe why it makes sense, but I will try.
>
>1) An // EXEC card is read and a 'step' begins. The // EXEC card itself
>must be interpreted.
>2) The rest of the step '
Actually, it makes sense to me, in a strange way.
I don't know if I can describe why it makes sense, but I will try.
1) An // EXEC card is read and a 'step' begins. The // EXEC card itself
must be interpreted.
2) The rest of the step 'stuff' (until the next // EXEC) is read in to
the pre-proces
Yep, I've asked our infra guys to verify this and report it to IBM...
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Seymour J Metz
Sent: maandag 30 maart 2020 14:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARM= vs PARMDD= and symbol substitution
Report i
Report it and see if you get a resolution of Broken As Designed (BAD).
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Windt, W.K.F. van der (Fred) [0185ecbb3806-dma
52 matches
Mail list logo
