IND$FILE uses the 3270 data stream, so there's no way around locking the terminal.
Forking an FTP command might be a better option. IBM has never bought into the concept of orthogonality, and that goes well beyond supporting multiprogramming (sic) in a user friendly way. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Paul Gilmartin [[email protected]] Sent: Friday, June 10, 2022 5:09 PM To: [email protected] Subject: Re: FTP Software for Mainframe to PC On Fri, 10 Jun 2022 12:46:38 -0700, Tom Brennan wrote: > ... Now, >someone could say locking your keyboard prevents you from, say, doing >updates to the same dataset you're running FTP against. > FSVO "you". You could meddle with a concurrent batch job. > ... I would expect >normal enqueues to prevent that instead of locking you out of the entire >TSO session. Note this was late 1990's ... > Unless FTP and TSO are in the same ASID. It wasn't intended to be foolproof; oonly to give you a warm feeling. >IND$FILE of course locks up the TSO terminal because it's a command and >commands lock you up until they complete. ... > Now that fork() exists the lock should be unnecessary. IBM is historically slow to grasp the idea of multiprocessing. Does ISPF LMPUT now support concurrent update of different members of the same PDSE , for which ISPF required ENQ DSN EXC. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
