HDTenEightyP/NetNews huggingface dataset:
Newsgroups: bit.listserv.ibm-main
Date:         Wed, 22 Jul 1992 10:06:34 PDT
From:         "Mike Friedman (510) 642-1410" <SPGMNF@UCBCMSA.BITNET>
Subject:      Re: ESA 4.2 JES2 Routing Restriction
              22 Jul 1992 08:05:38 GMT from <pgilmart@NYX.CS.DU. EDU>

On Wed, 22 Jul 1992 08:05:38 GMT Paul Gilmartin said:
>
>BTW, how can one meaningfully use a range of userids?  Is there some
>operator command which takes all jobs are in the range of (e.g)
>Gilmartin-Woren (oops. typo) as the userid and purges them?

Well, I know we have some VM users with all-numeric userids.  Going one step
further and supposing a userid of (say) 123-456, I suppose there is increasing
opportunity for command ambiguity.  I'm not familiar with all the JES2 commands
that use ranges, especially in ESA 4.2, so I don't know how confusing it could
get.  In any case, IBM's adding of the parenthesized userid syntax in JES2
commands (with the aforementioned APAR) is their way, I guess, of avoiding this
particular kind of problem.

(By the way, I believe the APAR description also says that the hyphen would
be allowed on a JECL card only if the accompanying node is not the local node.
Whether this is really enforced, I don't know.  We don't even have the APAR
on yet!).
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Computing Services, Arizona State University
Newsgroups: bit.listserv.ibm-main
Date:         Thu, 30 Jul 1992 07:11:17 MST
From:         Bob Kaneshige <KHAAV@ASUVM.INRE.ASU.EDU>
Subject:      Re: SYSTAT program...

On Thu, 23 Jul 92 07:57:33 MST I said:
>Does anyone have a copy of the SYSTAT program that they could send me for
>ESA 4.2.  It's on the CBT tape if I recall; something we do not have here.  It
>maps out visually the storage in the system.  Thanks!
>  Bob

I'll accept ANY pre-ESA 4.2 versions :-).

  Bob
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 21 Jul 1992 11:13:18 EDT
From:         Bob Hart <BHART@KENTVM.BITNET>
Subject:      Re: NCP or VTAM problem PROG471
              16 Jul 1992 11:00:42 EDT from <PWILKIN@TRAPPER.BGSU.EDU>

We have many older IBM 3270 emulator boards here and they DON'T support
EDS (extended data stream). We have a CICS termtype defined for them
without EDS support and they work fine. The PROG471 is seen here a lot,
specifically when a user moves a PC with one of these older boards to
a different port.

You may also want to check that the VTAM logmode being used doesn't
specify EDS, or the PC may have trouble logging onto other applications
as well.

Bob Hart                      BHART@KENTVM
Technical Support             (216) 672-7971
Computer Services
Kent State University
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Wed, 29 Jul 1992 23:56:59 CDT
From:         Neal Pape <NPAPE@VM1.TUCC.TRINITY.EDU>
Subject:      MVS Allocation Recovery

How does your shop handle a production job which has gone into MVS
allocation recovery for a disk drive?  Our applications programming manager
wants to be called in all situations before any action is taken.  Our systems
programmer believes that he should be able to cancel the job if he knows
that the disk drive in question has been recently removed from the system
or does not exist, then call the applications programmer to resubmit
the job.  What do you do?
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Wed, 29 Jul 1992 12:22:48 IST
From:         Anthony Waller <P85014@BARILVM.BITNET>
Subject:      Response Problem: MVS/ESA under VM/XA
Comments: To: ibm-main@ricevm1.BITNET, vmxa-l@dearn.BITNET

  We are having a recurring problem on an MVS/ESA 3.1.3 system running
as a V=F machine under VM/XA 2.1

  The main problem is Response time.  All we see under SMART on
VM is the %CP under Display ULOG shooting up.  Normally < 10%, it
goes up to 20% and beyond (upto 60%)

  Any hints as to what might be causing this on the MVS machine?

Thanks,

-------
Anthony Waller             BITNET:    P85014@BARILVM.BITNET
Bar-Ilan University        INTERNET:  P85014@vm.biu.ac.il
Israel.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Thu, 30 Jul 1992 11:42:00 PDT
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: MVS Allocation Recovery

For allocation recovery for disks, I have TSSO reply CANCEL.  Simple.
All references to non-mounted disks are by definition an error, and
the job cannot possibly continue.

/Leonard
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: IBM-MAIN@RICEVM1.BITNET
Newsgroups: bit.listserv.ibm-main
Date:         Thu, 23 Jul 1992 14:18:05 -0400
From:         Doug Fraser <dfraser@MCMAIL.CIS.MCMASTER.CA>
Subject:      Re: 3390 blksize calculation

On Thu, 23 Jul 1992, Jerry Bryan wrote:

> In article <IBM-MAIN%92072210340646@RICEVM1.RICE.EDU>, Zoltan Forray
> <SSTSZXF@VCUVM1.BITNET> says:
>
> >For 3380 type disks, a half-track block (23400) is usually optimal for most
> >things like load libraries. If you used anything much larger, you would waste
> >a large amount of space on each track.
>
> Reasonable people can disagree about this, but I would have said that
> half-track is best for most things *except* load libraries, where
> 32K blocking is best.  Load libraries are RECFM=U, which means that
> the blocks are variable length.  Many blocks are small to medium,
> no matter what the block size is.  A block which *can* fit on the
> remainder of the track *will* be placed on the remainder of the
> track and vice versa.  Here are some examples.  1) First block is
> small, second block is half-track (fits), third block is half-track
> (doesn't fit, space wasted).   2) First block is small, second block
> is 32K (fits), third block is small (fits).  3)  First block is
> 32K, second block is small (fits), third block is 32K (doesn't
> fit).  Construct the example of your choice to prove whatever you
> want to prove.  My personal humble opinion is that 32K is fine,
> maybe even best, for load modules, because so many of the blocks
> are small.  Why not get the advantage of the occasional 32K block?

We run mvs 2.2.x now.  I believe that this was true for mvs 2.1.7 as well.
I did some experiments on this.  Our policy now is 32k load libraries for
everything new.  My experiments involved actually looking at the lengths
of the blocks of the load modules on the disk.

IEBCOPY now has a copymod statement which will copy and reblock load
modules.  You may have to be careful about concatenation of libraries.  I
don't remember.

I recommend half track blocks for other (sequential) datasets, allocating
in blocks, and rounding to cylinder boundaries if the dataset is over 1 or
2 cylinders in size.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 28 Jul 1992 16:14:00 CDT
From:         Michael Stack <A01MES1@NIU.BITNET>
Subject:      Re: Esoteric Device Message in ESA 4.2

> It didn't have to be fixed unless you did a sysgen, but then fixing it
> was critical.  By hook or by crook (or by handy dandy utility program
> that you wrote at 3:00 in the morning), you had to recatalog a lot
> of data sets.

I can add only that most shops avoided this problem by *NEVER* altering
the order of the defined esoteric names.  If DISK was the third name
and TAPE the fourth, there they remained.  Forever.  (Talk about stable
SYSGEN decks.)  And the scenario Jerry Bryan describes is the reason.
Keep in mind that this was before TSO (and even before Wylbur);  most
shops had only card readers, and to recatalog many data sets was, well,
nearly impossible.

I don't remember that DISP=(...,CATLG) used esoteric names, so that
must have been fixed by MVT release 16 or so, if not much earlier...

Michael Stack

Northern Illinois University            Internet: a01mes1@mvs.niu.edu
Computer Systems and Operations         Bitnet:   a01mes1@NIU
DeKalb, IL  60115-2854                  Lipnet:   (815) 753-9447
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 27 Jul 1992 15:22:01 EDT
From:         "Martin J. Doyle (215) 752-2296" <MBDMD@ROHVM1.BITNET>
Subject:      VIOLATE EXEC

>VM/ESA Users.  We recently converted from VM/SP rel. 5 to VM/ESA 1.1
>with ESA feature.  We used to use a REXX exec to change the
>SCIF console of our service machines like VTAM from one system programmer
>to another with this REXX Exec.  Does anyone have a REXX exec for this under
>VM/ESA 1.1 (ESA Feature)?  If you do we would very much be interested in
>getting a copy, if thats possible.
>
>Larry Dusold   <E-Mail: lrd@fdacfsan.bitnet>         <IBMMail(US4TN001)>

I've sent a copy of my VIOLATE EXEC to Larry.  In addition to making
one logged on user secondary user for another logged on user under VM/XA
2.1 it also does things like changes MGS, WNG settings, and the class
of a virtual machine.  Most of the ideas came from an assembler program
which I think was originally written by Alex Brodski.  My version is in
REXX which may be a little easier for some people to maintain and
modify.

As I said, this exec is for VM/XA 2.1.  We're in the process up migrating
from XA to ESA 1.1.  Another programmer that is working on the ESA
migration tells me that VIOLATE EXEC works just fine on ESA but if your
interested in a copy of this exec to run under ESA (or XA 2.1 for that
matter) I'd test it second level before you start letting it alter
real storage on your first level systems; always a good idea.

If anyone wants a copy just drop me a note.


Martin J. Doyle
VM Systems Programming Contractor
Rohm and Haas Company
Philadelphia,  Pennsylvania
MBDMD@ROHVM1
(215) 592-6865 (Day)
(215) 752-2296 (Evening)
Date: Wednesday, 29 Jul 1992 13:32:08 EDT
From: Jerry Bryan <BRYAN@wvnvm.wvnet.edu>
Newsgroups: bit.listserv.ibm-main
Subject: Re: UNIT and VOLUME specification (was: esoteric device message)

In article <IBM-MAIN%92072911491934@RICEVM1.RICE.EDU>, "Mark C. Lawrence"
<M.Lawrence@STANFORD.BITNET> says:
>
>Well, I think the simple answer is, "because MVS is too stupid to
>go look for the volume".  Obviously it wouldn't be real hard to do;
>just scan thru all the UCBs for online disks.  I wonder if this is on
>the list of SHARE requirements?
>
>This limitation goes all the way back to OS/360.  I think the logic
>used is:  (1) find a suitable UNIT, (2) find (or mount) a suitable
>VOLUME on that UNIT (or in that unit class).  At a time when most
>disks were mountable, this made a lot of sense.  In the era of
>nonremoveable disks it no longer does.

I think the simple answer is not quite so simple.  The real reason
(at least historically under OS/360) is that ALTRES might be a tape.
There is nothing whatsoever in the DD statement that says that the
data set is on disk.  I grant you that it is "obvious" to the
human observer that ALTRES is a disk and is already mounted and
available.

In fact, it is even more subtle that that.  ALTRES might be a
3330 or a 3350 or a 3380 or a 3390 or a 3420 tape or a 3480
tape or a (pick a unit type of your choice).  Some of these
possibilities are obviously nonsensical if ALTRES is already
mounted because if you mounted a second ALTRES on a different
unit type, you would get a DUPLICATE VOLSER message.  But the
DD statement is parsed totally independently of the existing
system configuration because of device independence.

For example, vary ALTRES offline.  Should the JCL be parsed
any differently while ALTRES is offline?  If ALTRES were offline,
how on earth could you figure out what the proper device type was?
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Fri, 31 Jul 1992 09:12:00 EDT
From:         Jim Blalock <CAREY@CLEMSON.BITNET>
Subject:      Re: IFASMFDP question

On Fri, 31 Jul 1992 07:16:59 EDT Mott Given <ntm1169@DSACG3.DSAC.DLA.MIL> said:
>             ...              Is it posssible that the IFASMFDP program
> reformatted some of the SMF records, or it is more likely that there is
> something wrong with the way that the other site is collecting their SMF
> records?

I'd suspect different levels of IFASMFDP.  I'd try copying the records
with a different utility that wouldn't monkey with the data, like
IEBGENER or maybe SAS, and see if the problem persists.  (I think that
GENER does spanned records right; I usually use SAS.)  If you have to
select particular types and if you have SAS, I'd do it this way:

  //SMFSELEC EXEC SAS
  //SMFIN DD DSN=<smf.input.dataset>,DISP=SHR,BUFNO=50
  //SMFOUT DD DSN=<selected.smf.records>,DISP=(,CATLG), etc etc
  //SYSIN DD *
    data _null_; infile smfin;
    input @2 type pib1. @;
    file smfout recfm=vbs lrecl=32756 blksize=32760; /* assumes tape */
    if type = <type 1> | type = <type 2> | type = <type 3> | etc etc ;
    put _infile_;
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: San Jose State University
Newsgroups: bit.listserv.ibm-main
Date:         Fri, 24 Jul 1992 10:35:27 PDT
From:         John Sroka <SROKA@SJSUVM1.BITNET>
Subject:      Re: IBMLink
              24 Jul 1992 11:14:13 EDT from <V4039@VM.TEMPLE.EDU>

On Fri, 24 Jul 1992 11:14:13 EDT Stan Horwitz said:
>Hello fellow IBMers;
>
>Earlier  this week,  I attended  an IBMLink  seminar at  IBM's local  HQ. The
>folks who presented the seminar touted how great IBMLink is and how we should
>use it as our primary resource for getting in touch with IBM for any reason.

But a telephone call is free.

>Yesterday, I attempted to log in to  IBMLink for the first time. When I typed
>IBMLink after logging in,  it would not respond. The system  asked me to wait
>a minute and did  nothing else. Every command I entered  was ignored. I tried
>this with  MacKermit, MSKermit, and  IBM's own software without  success. Two
>calls to IBM's  1-800 number have yet to  be answered and I am in  a hurry to
>get some information off this system and make some purchases.
>
>Does anyone have any  idea how to resolve this problem?  Am I doing something
>wrong is IBMLink as worthless as it presently seems?

It sounds like you have established the connection and are getting IBM's
Information Network (IN) screen, yes?   If you enter IBMLINK and get no
response, the most likely cause was that resource was temporarily unavailable
although usually IN will give you a message to that effect.  It's also
possible your userid has been validated for IN, but not for IBMLINK.  In
either case a call to either the IN or IBMLINK help numbers would be
appropriate.  I'm surprised you've received no response, the help desks
are usually quite prompt in responding.


We had a host connection to IBMLINK for a few years and bought into what was
then the 'Software Xcel' plan.  This gave us access to IBMMAIL (e-mail to SEs
and others), access to PSP buckets, and the capability to download fixes
directly.

We have since dropped the host connection, and have only dial-up access to the
basic IBMLINK functions.   I would have to admit the only feature I miss is
access to the PSP information.  In our view the cost of the full implementation
is prohibitive, it could probably be justified at a very large shop, or if
shared between a number of sites.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Thu, 23 Jul 1992 21:20:00 CET
From:         Maarten Ouwehand +31 71 276936 <CRISMO@RULMVS.LEIDENUNIV.NL>
Subject:      PUT-info in INFO/MVS ...

Has anybody an idea why the PUT-information in the P-file of INFO/MVS
hasn't been updated for a long time !!??
I just loaded lvl8 of INFO/MVS and the latest PUT-info is 9103 !!

This means, with the "One-year-rule", that you can only obtain
information for PTF's from PUT9102 & 9103 !
(And I just got PUT9202 on my desk !!)
See extract of P1ENTRY below !


  *** TOP OF DATA ***
  H P000001 S=INFO C=* D=APR89 E=APR90                             L=00020
  T P FILE: PTF/PLC INFORMATION--FIRST ENTRY

  The 'P' file contains PTF cover letters, MVS PTF Cross References, and
  Program Level Change (PLC) information from the VM PUT/PLC tapes.
  Up to one year's PUT tapes and the most recent PLC tapes are included.
        ~~~~~~~~~~
  PSP data for MVS, VM, IMS and NCP is also included.

      FOR ADDITIONAL INFORMATION:                       SEARCH ON:
  File Use Notes for MVS (9103)                        P2ENTRY
                     ~~~~~~~~~~
  ................


Maarten Ouwehand          Internet: crismo@rulmvs.Leidenuniv.nl
MVS Systems Programmer    Bitnet  : crismo@hlerul2
Leiden University         Fido    : 2:500/24.1982
The Netherlands           Phone   :+31 71 276963/276921
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Wed, 22 Jul 1992 13:17:46 EDT
From:         Bill Gruber <BIGCU@CUNYVM.BITNET>
Subject:      Re: ESA 4.2 JES2 Routing Restriction

On Wed, 22 Jul 1992 12:19:00 EDT John F. Chandler said:
> ... VM/ESA doesn't allow userids with hyphens (from what I hear). ...
I'm not aware of this restriction - we run VM/ESA and have ids with
hyphens in them.  But, a related comment from Leonard Woren about RACF
not allowing hyphens is PARTIALLY true for VM.   It seems that RACF will
not allow you to define a USER with a hyphen in the name, but it WILL allow
you to define a RESOURCE with a hyphen in the name.

For example, if I have a userid of LIST-L, I couldn't define the USER to
RACF, but I could give LIST-L a 191 disk and define a VMMDISK USER-L.191
to RACF.  Very weird, in my opinion.

Anyhow, since all our xxx-L userids aren't normally logged onto we just
don't define them to RACF but still take advantage of RACF to provide access
control for their disks.  This way we have not had to reanme any of our
LISTSERV lists.

Bill Gruber
City University of New York Computer Center.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: RYERSON POLYTECHNICAL INSTITUTE
Newsgroups: bit.listserv.ibm-main
Date:         Wed, 22 Jul 1992 12:18:54 EST
From:         Larry Anta <ADMN8621@RYEVM.RYERSON.CA>
Subject:      4381's Channel 0 on IP1

Can Channel 0 on Instruction Processor 1 (the second processor of a
dual) of a 4381-T92E be configured as a BLOCK multiplexor?

I know that Channel 0 on IP0 must be a BYTE multiplexor, but what about
IP1?

Thanks.

........................................................................
: Larry Anta, Systems Programmer        Toronto Ontario CANADA M5B 2K3 :
: Ryerson  Polytechnical  Institute     Voice- (416) 979-5000 Ext 6817 :
: Room AB-54    350 Victoria Street     Bitnet-ADMN8621@RYERSON        :
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Date: Thursday, 23 Jul 1992 00:03:09 EDT
From: Jerry Bryan <BRYAN@wvnvm.wvnet.edu>
Newsgroups: bit.listserv.ibm-main
Subject: Re: 3390 blksize calculation

In article <IBM-MAIN%92072210340646@RICEVM1.RICE.EDU>, Zoltan Forray
<SSTSZXF@VCUVM1.BITNET> says:

>For 3380 type disks, a half-track block (23400) is usually optimal for most
>things like load libraries. If you used anything much larger, you would waste
>a large amount of space on each track.

Reasonable people can disagree about this, but I would have said that
half-track is best for most things *except* load libraries, where
32K blocking is best.  Load libraries are RECFM=U, which means that
the blocks are variable length.  Many blocks are small to medium,
no matter what the block size is.  A block which *can* fit on the
remainder of the track *will* be placed on the remainder of the
track and vice versa.  Here are some examples.  1) First block is
small, second block is half-track (fits), third block is half-track
(doesn't fit, space wasted).   2) First block is small, second block
is 32K (fits), third block is small (fits).  3)  First block is
32K, second block is small (fits), third block is 32K (doesn't
fit).  Construct the example of your choice to prove whatever you
want to prove.  My personal humble opinion is that 32K is fine,
maybe even best, for load modules, because so many of the blocks
are small.  Why not get the advantage of the occasional 32K block?
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 28 Jul 1992 17:01:00 PDT
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: Esoteric Device Message in ESA 4.2

On Tue, 28 Jul 1992 11:59:03 EDT, BENSON@POKVMCR3.VNET.IBM.COM said:
> >(Why do I have to specify UNIT= *at all* if I specify VOL=SER= for an
> >online disk???  That's one of my pet peeves with MVS.)
>
> If you use SMS you do not have to specify either.

That doesn't really answer my question, since (a) not everyone is
running SMS (we're not) (yet?), and (b) not all volumes wil be SMS,
and (c) even with SMS, using guaranteed space, wouldn't the UNIT=
still be required?

Specifically, if ALTRES (for example) is permanently resident, why
do the following fail without UNIT=nnnn?

//OLD    DD  DISP=SHR,DSN=SYS1.LINKLIB,VOL=SER=ALTRES
//NEW    DD  DISP=(NEW,KEEP),DSN=SYSX.LINKLIB,VOL=SER=ALTRES,
//           SPACE=...,DCB=...

/Leonard
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 27 Jul 1992 14:52:00 CDT
From:         NIU 815 Larry Ludwig 753-1875 <A01LRL2@NIU.BITNET>
Subject:      Feasibility of single TOR

I apologize for reposting this question to those of you who
are on the CICS list but when I asked it on that list I got
no reponse so I thought I'd try it on the IBM-MAIN list.


I have a question about the feasibility of running all
(test, production, development, experimental) of my CICS's
using just one terminal owning region (TOR).  I now run
a configuration that looks like this:

production:   PRD1 (TOR/AOR) ---->  PRD2  (AOR/DOR)
test:         TST1 (TOR/AOR) ---->  TST2  (AOR/DOR)
development:  REG0 (standalone CICS)
develmnt2:    CSV1 (TOR/AOR) ---->  CSV2  (AOR/DOR)
expermnt1:    XPR0 (standalone CICS)
expermnt2:    XPR1 (TOR/AOR) ---->  XPR2  (AOR/DOR)
student:      STD0 (standalone CICS)

What I would like to do is something like this:

terminal:     TOR
production1:   |-------> PRD1 (AOR) -----> PRD3 (DOR)
production2:   |-------> PRD2 (AOR) -----> PRD3 (DOR)
test1:         |-------> TST1 (AOR) -----> TST3 (DOR)
test2:         |-------> TST2 (AOR) -----> TST3 (DOR)
developmnt1:   |-------> REG0 (AOR/DOR)
developmnt2:   |-------> CSV1 (AOR) -----> CSV3 (DOR)
developmnt3:   |-------> CSV2 (AOR) -----> CSV3 (DOR)
expermntl1:    |-------> XPR0 (AOR/DOR)
expermntl2:    |-------> XPR1 (AOR) -----> XPR3 (DOR)
expermntl3:    |-------> XPR2 (AOR) -----> XPR3 (DOR)
student:       |-------> STD0 (AOR/DOR)

The test, production, and development regions all use the
same set of transactions, e.g. NAT2 is defined in all
three systems; it does the same thing in each, except
it uses a separate database.  The question is this - how
can I get a production user entering NAT2 in the TOR to
go to PRD1, a test user entering NAT2 to go to TST1 and a
development user entering NAT2 to go to CSV1, without
first asking them to route themselves to the proper region
with the CRTE transaction?  The only thing I can think of
is to write a program which is linked to immediately after
they get logged on (we use ACF2) to prompt them for a
system.  This program would just issue the proper CRTE
transaction for them after checking security for that
system.

Providing new tranactions for the test and development
regions is probably not feasible.

My environment is CICS 2.1.1, MVS/ESA, ADABAS.

Any, all replys are greatly appreciated.

Larry Ludwig
CICS system programmer
Northern Illinois University

A01LRL2@NIU
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 21 Jul 1992 11:29:53 EDT
From:         "Duane D. Weaver" <WEAVER@OHSTVMA.BITNET>
Subject:      Automating SNS/FTP

We are running Interlink's SNS/FTP v1.1.1.

We are attempting to simply the specification of the FTP command
with the hostname on the command line by using a REXX exec.

When the Exec calls FTP, it appears that FTP is no longer accepting
input of userid and password from the terminal.  We tested a clist
calling (SNS) FTP and the samething happens.

Has anyone else, running SNS FTP, seen the same problem and have a solution?

Duane
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU