I’m not sure why this mail suddenly appeared on the list after so many weeks
but…
Linux on 390 Port ;
VM/ESA Discussions Discussions ;
IBM Mainframe Discussion List
Hello Neal!
Hope this finds you well.
I definitely will make the effort and to attend. My email has changed from
On 2018-11-30 4:01 AM, Farley, Peter x23353 wrote:
The PDS/E directory entry for a program contains, among other information, the
EPA offset within the program.
The EPA offset is also contained in the SMDE/PMAR information returned by
DESERV.
After much RTFM however, I cannot seem to find
On 11/21/2018 11:39 AM, Jackson, Rob wrote:
This is what standalone restore is for, Sean. But if you don't have one built,
you could try this: http://www.cbttape.org/~jjaeger/zzsa.html.
I've used it before but not on anything more recent than a z10. If it will
IPL, you can find your IEFUSI
The text in the section from which the eye-catcher below was extracted
has certainly not been updated since 1988. But the last of the six PTFs
(UR43604) for this FMID (HFX1112) was made available 2 June 1995.
Mike Schwab wrote:
It hasn't been updated since 1988.
On Fri, Nov 30, 2018 at 7:00
On 2018-11-30 09:12, Pierre Fichaud wrote:
In the bind process using c89 and tunning in Unix (OMVS shell), I get the
following.
I've chopped the list.
Where are these modules in Unix?
Where are they in z/OS ?
I can't find them in any SYS1 datasets.
Thanks in advance, Pierre.
FSUMI
Those look like control block names, not modules. CSVLLCB is certainly one.
How are you defining them in your C source program? Please show us the
declarations for more help.
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of
On Sat, 1 Dec 2018 03:31:19 +1100, Greg Price wrote:
>
>Both a PDS and a PDSE program member directory entry contain the EPA
>offset. Typically the EPA is chosen from label and section ESDs because
>it matches a real or alias member name, or was explicitly named on a
>Binder ENTRY statement, or
Bob,
I forgot to mention that there are two Yahoo Groups for Netview and SA
respectively. I think that this topic might generate more responses in either
of those forums. Below is the url that I use to logon.
On Fri, 30 Nov 2018 15:17:22 +0800, Timothy Sipples wrote:
>
>IBM Program Number 5665-311, 3270 PC File Transfer Program for TSO, is
>still marketed and supported as a standalone product (as I write this).
>However, starting with z/OS 2.1, it is included in the z/OS base operating
>system
Hello:
The manual “MVS Programming: Assembler Services
Guide” Chapter 8. “Providing recovery” explains that an ESTAE that is called
with the ‘SDWACLUP’ bit on can only ‘percolate’ (SETRP RC=0). It further
explains that if you do attempt a ‘retry’ (SETRP RC=4) , the retry will be
ignored.
I
Sorry, I tried to type "PDS(E)" but the "(E)" became a Euro symbol in my mail
client. PDS/E was a substitute name, not a product. I should have switched
the format to plain text.
But the question still remains -- Where (if anywhere) is an EPA indicator in
the returned Binder API data? I know
Tony,
Thank you for responding. I, too, was surprised at the lack of response. Maybe
it has to do with the fact that I asked two days before Thanksgiving!
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cieri, Anthony
Sent:
Since I did not notice any responses, I thought I would offer my 2
cents.
We are NOT running z/OS 2.3 yet, but I did have the need to increase
this value a few years ago. The need was predicated on the installation of
Tivoli System Automation (TSA). TSA is based upon
Gord,
That did it.
No brain, no pain on my part.
I should have caught this.
The gray matter is declining.
Regards, Pierre.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
On Fri, 30 Nov 2018 at 14:37, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> Does IBM support any such clients nowadays?
I have an old (2006) version of Pcom "Workstation Program Version 5.9 for
Windows" that seems to have a built-in client.
And the Help->About has
On Thu, 29 Nov 2018 17:01:34 +, Farley, Peter x23353 wrote:
>The PDS/E directory entry for a program contains, among other information, the
>EPA offset within the program.
>
>The EPA offset is also contained in the SMDE/PMAR information returned by
>DESERV.
>
>After much RTFM however, I
I didn't notice anyone asking (or answering preemptively) the question of what
IND$FILE is or how it works. First off, it is not a 'file transfer tool' like
FTP or SFTP. It is a program that spoofs 3270 terminal data entry to up or
download data. There's a component on mainframe and another on
On 11/30/2018 8:47 AM, Paul Schuster wrote:
So my question is this: aside from ‘completeness/code purity’, is there
anything to worry about if an ESTAE attempts a ‘retry’ even though the
‘SDWACLUP’ bit is on? I can envision that the recovery routine itself may have
different logic based on
We've run with 2000 for years. Currently at z/OS 2.3. No problems.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM
Peter,
You can read the PMAR using the binder API. I had a similar problem trying
to find out where information that is in the PDS(E) directory is for a
program object in a unix file. It turns out that the information is
embedded in the program object, but, of course, the internal format
On 11/30/2018 9:13 PM, Jesse 1 Robinson wrote:
The reason it's so slow is that it simulates keyboard entry. Not elegant but
competent. Not ideal for large files, but here's how I made peace with it long
ago.
IND$FILE protocol hasn't simulated true keyboard entry for a long, Long,
LONG
On Thu, 29 Nov 2018 at 12:02, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:
> The PDS/E directory entry for a program contains, among other information,
> the EPA offset within the program.
>
> The EPA offset is also contained in the SMDE/PMAR information returned by
> DESERV.
>
>
Seymour J Metz wrote:
I believe that IND$FILE is included in your z/OS license. I also believe that
it is long out of support and less efficient than, e.g., SFTP (yes, FTP is
considered insecure these days.)
IND$FILE, as part of z/OS, remains supported. As far as I know, support
for it
Okay thanks the regular LX is easier as I only need I register to PC
Joe Reichman
170-10 73 rd ave
Fresh meadows NY 11366
> On Nov 30, 2018, at 7:36 AM, Peter Relson wrote:
>
>
> I am using s system LX but with our re-usable I would have to save the LX
> to a file
> Right ? If I restart
I am using s system LX but with our re-usable I would have to save the LX
to a file
Right ? If I restart the task right ?
No. Whether reusable or not, you in effect save the LX because you need to
build a PC number for programs to use. So you already must save it either
as part of the PC
I am sorry I should of thought this out better
If my started task goes down
And I restart it the virtual address in private of the PC routine would be
different isn’t that
An issue
Thanks
Joe Reichman
170-10 73 rd ave
Fresh meadows NY 11366
> On Nov 30, 2018, at 7:36 AM, Peter Relson
In the bind process using c89 and tunning in Unix (OMVS shell), I get the
following.
I've chopped the list.
Where are these modules in Unix?
Where are they in z/OS ?
I can't find them in any SYS1 datasets.
Thanks in advance, Pierre.
FSUMI Utility(c89)
John Eells wrote:
>IND$FILE, as part of z/OS, remains supported. As far as I know, support for
>it has never lapsed (certainly not since its inclusion into OS/390).
Indeed and thanks for the clarification. I am somewhat perplexed by this
discussion. This module is found in SYS1.CMDLIB and as
Elardus Engelbrecht wrote:
John Eells wrote:
IND$FILE, as part of z/OS, remains supported. As far as I know, support for it
has never lapsed (certainly not since its inclusion into OS/390).
Indeed and thanks for the clarification. I am somewhat perplexed by this
discussion. This module is
29 matches
Mail list logo
