Re: IND$FILE and zFS?

[Radoslaw Skorupka]

W dniu 29.03.2021 o 21:02, Paul Gilmartin pisze:

On Mon, 29 Mar 2021 18:36:43 +, Farley, Peter x23353 wrote:

There have to be less intrusive / complex-to-implement--shop-wide alternatives, 
and an updated or open-sourced IND$FILE would provide one such.


As an ISV's employee, I was delighted with NFS.  It made desktop
filesystems visible on z/OS and Classic data sets visible on desktops.
All very transparent; no need for transfer; up/download.  Some
filesystems were mounted at two mountpoints binary and text
with CP819<->CP1047 mapping, making it possible to cross-compile
on desktop and bind to load modules on z/OS; again no explicit transfers.

I'm surprised that NFS isn't more widely embraced.  Security concerns?


I configured DFS/SMB which is more or less z/OS in Windows domain - you 
can map network drive and the drive is z/OS HFS or even datasets 
(HLQ.SLQ... level)
I really liked to watch mainframe folks when I edited VSAM KSDS using 
...Notepad. With EBCDIC-ASCII conversion and polish codepages support.
Several options of security were available: RACF, Windows Active 
Directory and some mix.


Unfortunately it wasn't accepted (mainframe "could break Windows 
security") and finally IBM announced end of the feature.


Regarding NFS - many years ago I heard a lot of bad opinions about its 
security flaws. I cannot comment it, maybe it wasn't so bad, maybe it 
was fixed.


--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IND$FILE and zFS?

[Charles Mills]

"It's a UNIX thingy; we don't want that on our mainframe."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Monday, March 29, 2021 12:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IND$FILE and zFS?

Not sure why not.  NIH is one possible reason.  "Too new-fangled for us, our 
programmers will never figure it out" might be another.  Lack of time 
(under-staffing) or sheer laziness may be other possible reasons, along with 
"We're getting off the mainframe Real Soon Now (tm) so do nothing new there" 
for yet another.

Along with blatant mis-trust of all things application-programmer friendly.

Lawyers could be yet another reason.  Fear of data breaches and the 
accompanying liabilities and reputation loss.

Probably as many reasons as there are shops.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Monday, March 29, 2021 3:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IND$FILE and zFS?

On Mon, 29 Mar 2021 18:36:43 +, Farley, Peter x23353 wrote:
>
>There have to be less intrusive / complex-to-implement--shop-wide 
>alternatives, and an updated or open-sourced IND$FILE would provide one such.
>
As an ISV's employee, I was delighted with NFS.  It made desktop filesystems 
visible on z/OS and Classic data sets visible on desktops.
All very transparent; no need for transfer; up/download.  Some filesystems were 
mounted at two mountpoints binary and text with CP819<->CP1047 mapping, making 
it possible to cross-compile on desktop and bind to load modules on z/OS; again 
no explicit transfers.

I'm surprised that NFS isn't more widely embraced.  Security concerns?

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IND$FILE and zFS?

[Paul Gilmartin]

On Mon, 29 Mar 2021 19:12:26 +, Farley, Peter x23353 wrote:

>Not sure why not.  NIH is one possible reason.  "Too new-fangled for us, our 
>programmers will never figure it out" might be another.  
>
???  It makes the desktop FS look like z/OS; view/edit with ISPF 3.17 (panel, 
not version)
and Classic data sets appear on the desktop.  Comfortable to partisans of both 
cultures.

Lack of time (under-staffing) or sheer laziness may be other possible reasons, 
along with "We're getting off the mainframe Real Soon Now (tm) so do nothing 
new there" for yet another.
> 
I grant it took multiple site visits by IBM experts to work out the kinks.  And
we had to settle for current minus one NFS version.  Sysadmins' problem,
not mine.

>Along with blatant mis-trust of all things application-programmer friendly.
>
Sysadmins are uncomfortable, perhaps envious, whenever users' understanding
exceeds theirs in any area.  Remember the now-abated threads of "How can
we prevent programmers' using this OMVS thingy?"

And early-adopter hesitancy.

>Lawyers could be yet another reason.  Fear of data breaches and the 
>accompanying liabilities and reputation loss.
>
>Probably as many reasons as there are shops.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Abend S052-104

[Binyamin Dissen]

On Sun, 28 Mar 2021 00:58:22 -0400 Gary Weinhold  wrote:

:>It was set up this way when we decided we had to add a PC to our product 
:>20 years ago.  I believe the programmer was afraid that a customer could 
:>accidentally cancel the server started task and cause all running 
:>instances of our product to abend (which could include CICS and IMS/TM 
:>regions, batch jobs and a shared dataspace).  He figured this technique 
:>would only prevent new instances of our product from starting and 
:>wouldn't be as big a problem for the customer to recover from.

Set up a RESMGR in the server that sets a bit indicating not available. It is
possible to get an 0D6 (or is it 0D7)  should a thread be in the middle of the
PC and get interrupted and then resume after the cancel completes but that
would be extremely rare,

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IND$FILE and zFS?

[Farley, Peter x23353]

Not sure why not.  NIH is one possible reason.  "Too new-fangled for us, our 
programmers will never figure it out" might be another.  Lack of time 
(under-staffing) or sheer laziness may be other possible reasons, along with 
"We're getting off the mainframe Real Soon Now (tm) so do nothing new there" 
for yet another.

Along with blatant mis-trust of all things application-programmer friendly.

Lawyers could be yet another reason.  Fear of data breaches and the 
accompanying liabilities and reputation loss.

Probably as many reasons as there are shops.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Monday, March 29, 2021 3:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IND$FILE and zFS?

On Mon, 29 Mar 2021 18:36:43 +, Farley, Peter x23353 wrote:
>
>There have to be less intrusive / complex-to-implement--shop-wide 
>alternatives, and an updated or open-sourced IND$FILE would provide one such.
>
As an ISV's employee, I was delighted with NFS.  It made desktop filesystems 
visible on z/OS and Classic data sets visible on desktops.
All very transparent; no need for transfer; up/download.  Some filesystems were 
mounted at two mountpoints binary and text with CP819<->CP1047 mapping, making 
it possible to cross-compile on desktop and bind to load modules on z/OS; again 
no explicit transfers.

I'm surprised that NFS isn't more widely embraced.  Security concerns?

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IND$FILE and zFS?

[Paul Gilmartin]

On Mon, 29 Mar 2021 18:36:43 +, Farley, Peter x23353 wrote:
>
>There have to be less intrusive / complex-to-implement--shop-wide 
>alternatives, and an updated or open-sourced IND$FILE would provide one such.
>
As an ISV's employee, I was delighted with NFS.  It made desktop
filesystems visible on z/OS and Classic data sets visible on desktops.
All very transparent; no need for transfer; up/download.  Some
filesystems were mounted at two mountpoints binary and text
with CP819<->CP1047 mapping, making it possible to cross-compile
on desktop and bind to load modules on z/OS; again no explicit transfers.

I'm surprised that NFS isn't more widely embraced.  Security concerns?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IND$FILE and zFS?

[Farley, Peter x23353]

Even large shops who are relatively up-to-date in z/OS release level have not 
made z/OSMF available to application teams in any form.  Most are limiting that 
access to systems teams and even they don’t much like it from the posts I have 
seen on this list.

There have to be less intrusive / complex-to-implement--shop-wide alternatives, 
and an updated or open-sourced IND$FILE would provide one such.

ISV's are a different kind of organization from shops that use their software, 
and are pushed much harder by IBM changes to adopt the latest whiz-bangs or 
risk being left behind.  Application shops are far more conservative and even 
backwards in adopting them.

It isn’t the right way, but it is a fact of application life.

I do have FTP to and from my employer's systems, but not every application shop 
allows that.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Andrew Rowley
Sent: Sunday, March 28, 2021 7:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IND$FILE and zFS?

On 29/03/2021 10:09 am, Radoslaw Skorupka wrote:

> However everytime someone ask about IND$FILE of transfer of 600 files 
> we see "FTP is NOT an option". Why? Well, there are reasons. Maybe not 
> reasonable, but there are. Last, but not least: still unsolved! So 
> still we will observe such questions and problems.

I understand there are sites that prohibit FTP. I am sure it is less common to 
prohibit HTTPS. There may be sites that don't allow file transfers to/from the 
mainframe - but I doubt IBM wants to enhance IND$FILE to help people circumvent 
site policy on file transfers.

> zOSMF? I'm sorry, but I bet it is less common than FTP. And as far as 
> I can guess it cannot be automated like FTP (read: batch).
> And of course one size does not fit all. Some would need compression 
> of transmitted data (what bandwidth do you have?), some would prefer 
> IND$FILE and some just FTP or FTPS or SFTP.

IBM obviously intends that z/OSMF will be used everywhere as a required 
component of z/OS.

I have automated both z/OSMF and FTP and I would say z/OSMF is far easier. It 
can be done from any language that can make HTTPS requests i.e. you can start 
with curl. The REST APIs are probably the best and most useful feature of 
z/OSMF.

Compression is not required, but it is an option selectable using the
Accept-Encoding: gzip header, i.e. a standard feature supported by most clients.

I see nothing wrong with using FTP etc. But if you need new features they might 
already be there in z/OSMF, and there is pretty much zero chance they will be 
added to IND$FILE.

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Any One Looking for new gig?

[PINION, RICHARD W.]

What ever happened to digital nomads?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Monday, March 29, 2021 9:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Any One Looking for new gig?

[External Email. Exercise caution when clicking links or opening attachments.]

Is anyone in the group a fully a position as a Lead  to convert from BMC 
products to IBM alternatives.



Must be a must a US Citizen and reside in the US




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Assembler Language Programming for IBM System z Servers

[Wendell Lovewell]

Hello all. 

Does anyone know if Dr Ehrman's excellent assembler book could be updated for 
the new instructions released since 2015?  Or, at least refreshed with current 
standards for PDF-page generation standards? 

What I mean is, it would really be helpful if:
a) The pages in the Table of Contents were hyperlinks to the actual pages 
referenced, and
b) The page numbers in the TOC matched the page numbers in the PDF file.  For 
example, "MVCLE" is listed in the TOC on page 411.  But if you alt-g to go to 
the 411th page in the PDF, you end up on the page displaying "373" at the 
bottom.  

More recent manuals "document" page numbers match the "pdf" page numbers.  But 
as best I can tell Dr. Ehrman's book hasn't been updated to reflect this. 

Is there any chance someone from IBM is reading this & can do something about 
this?  Please? 

(I know this might make more sense to post on the Assembler list, but I'm 
guessing it's more likely to be seen here.)

TIA, 
Wendell

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LFAREA in z/OS 2.3

[Harris Morgenstern]

Prior to V2R3 the specification of the 1M LFAREA resulted in storage being 
physically reserved
for  LFAREA frames (used to back IARV64 PAGEFRAMESIZE=1Meg requests), but 
which could potentially be used for other purposes.   If the system
ran low on memory,  the 1M LFAREA could  be used to satisfy  non-LFAREA 
real storage requests.   So even though the 1M LFAREA was a reservation, 
the reservation could be broken and so
it might have behaved more like a limit. 

In V2R3 and above, the real storage management is more effective at 
reducing fragmentation,
resulting in more available  1Meg units of real.   The need for the 1M 
LFAREA (as a reservation)  went away. 




Harris Morgenstern
z/OS Storage Management and System REXX
Dept. OBPA
IBM Poughkeepsie
8-295-4221 
hmor...@us.ibm.com


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Any One Looking for new gig?

[Radoslaw Skorupka]

W dniu 29.03.2021 o 15:26, Steve Beaver pisze:

Is anyone in the group a fully a position as a Lead  to convert from BMC
products to IBM alternatives.


I'm not US citizen so it is not for me however I would advice to be more 
specific.
There is big difference between tools, knowledge needed and conversion 
effort.
Example: batch scheduler conversion may take approx. 9 months and could 
require some changes in the application.

CMF to RMF seems to be easier and less risky.
Etc.

--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Abend S052-104

[Peter Relson]

It was set up this way when we decided we had to add a PC to our product
20 years ago.  I believe the programmer was afraid that a customer could
accidentally cancel the server started task and cause all running
instances of our product to abend (which could include CICS and IMS/TM
regions, batch jobs and a shared dataspace).  He figured this technique
would only prevent new instances of our product from starting and
wouldn't be as big a problem for the customer to recover from.


What specifically is the "technique"? Using LXRES within a batch job is 
simply a bad idea. 
Apparently you want a separate LXRES for each user. That's OK (if likely 
very wasteful). But then you can have multiple started tasks.
"The" server started task does not need to be the implementation. "A" 
server started task" could be (and each user connects to its own server).
And of course the server task could be made non-cancelable.

Further, canceling a server causes no abend in and of itself. Only when a 
client attempts to access would there be the expected problem, leaving 
opportunity for "waiting until restart" or whatever.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [MVS-OE] FILEDATA=RECORD writes atomic?

[Paul Gilmartin]

On 2021-03-29, at 05:18:27, William Schoen wrote:
> 
> It is done by the access method or application writing the records.
>   
Thanks.  Of course IBM might document the implementation of access
methods, though not of user-written applications.

> All writes seen by the kernel are atomic.
> If there is buffering or other type of processing by the process doing the
> writes causing records to span writes calls, all bets are off.
> I think the access methods keep records on block boundaries, but this is
> probably not the case with C file streams.
>   
The sense of my question is, does the access method perform:
buffer = RDW || data
write( buffer )
which is atomic, subject to buffer size, or:
write( RDW )
write( data )
which risks another process's inserting a record between the
RDW and the data.  In fact, for FILEDATA=TEXT that hazard
could exist betwen "write( data )" and "write( NL )".


> MVS OpenEdition  wrote on 03/27/2021 12:11:11 PM:
> 
>> From: Paul Gilmartin 
>> Date: 03/27/2021 12:11 PM
>> 
>> (cross-posting)
>> FILEDATA=RECORD causes each record to be prefixed with a quasi-RDW.
>> Is that done by the kernel or the access method?  In either case,
>> if two processes allocate the same UNIX file witn FILEDATA=RECORD,
>> PATHOPTS=O_APPEND, will the PUTs appear atomic or might the RDWs
>> and bodies from the two processes appear intermixed?

Thanks again,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Any One Looking for new gig?

[Steve Beaver]

Is anyone in the group a fully a position as a Lead  to convert from BMC
products to IBM alternatives.

 

Must be a must a US Citizen and reside in the US

 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Lead BMC products

[Steve Beaver]

Is anyone in the group a fully qualified Lead BMC products to IBM
alternatives.

Must be a must a US Citizen and reside in the US

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Control-M/Tape

[Oren, Yifat]

Hi,

Please check out Control-M/Tape CTTSBD (Data Set Stacking) 
-https://documents.bmc.com/supportu/INC/help/Main_help/en-US/index.htm#70522.htm.

It can be used to duplicate tape volumes.

Hope that helps,
Yifat



Disclaimer: These postings are my own and do not necessarily represent BMC's 
position, strategies, or opinion.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bodra - Pessoal
Sent: Friday, March 26, 2021 11:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Control-M/Tape

Hello,

 

In past when we used CA-TLMS we have CA-COPYCAT utility that help in tape 
duplication among other things.

 

Control-M/Tape has something similar to CA-Copycat?

 

Thanks

 

 

Carlos Bodra

IBM zEnterprise Certified

São Paulo - SP - Brazil

 

 


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Abend S052-104

[Rob Scott]

Gary

If you update the PPT entry for your server jobstep program to NOCANCEL, then 
you can consider moving the ownership of that PC-cp to the server.

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Gary Weinhold
Sent: 28 March 2021 05:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Abend S052-104

EXTERNAL EMAIL



Rob Scott wrote (snipped):

> From the description of the abend, if your user code runs as a jobstep in 
> something like a JES initiator, you will always be at risk from a prior batch 
> job performing an LXRES for PC-ss (without an initiator restart).
...

> Is there any reason why your user-ASID owned PC-cp cannot be owned by your 
> server-ASID ?
>
> The load module would have to be in LPA/common but could probably execute 
> exactly the same code as it does today.

and Peter Relson wrote (snipped):

> One case would be a multi-step started task (or initiated job) where the
> first step did so, and there is a second step.
> Don't do that.

Thanks, Peter and Rob.  This was a  batch job and we do not know all the
preceding job steps (we only know the prior step was IDCAMS). We know
our product can be run in multiple steps in the same job. Your responses
will enable us to help the customer research the preceding steps to the
abend in the address space.  The resolution may be as simple as changing
the job class for this job (or the cross-memory job step).  According to
the customer, this happens once in a while and rerunning the job works.

It was set up this way when we decided we had to add a PC to our product
20 years ago.  I believe the programmer was afraid that a customer could
accidentally cancel the server started task and cause all running
instances of our product to abend (which could include CICS and IMS/TM
regions, batch jobs and a shared dataspace).  He figured this technique
would only prevent new instances of our product from starting and
wouldn't be as big a problem for the customer to recover from.

Gary


Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: weinh...@dkl.com
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IND$FILE and zFS?

[Timothy Sipples]

If you're interested in creating a file transfer program compatible with 
zFS, there's a possible "head start" available: a mainframe version of the 
Kermit file transfer protocol.

http://www.columbia.edu/kermit/k370.html

Kermit can operate over TN3270(E) connections. I don't think IBM Mainframe 
Kermit was enhanced to support HFS or zFS, though, but in principle it 
could be.

By the way, the Kermit protocol's new home is at The Kermit Project:

https://www.kermitproject.org

Has anyone tried compiling and running C-Kermit on z/OS UNIX? Could it 
work over a TN3270(E) connection?

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Multiprise 3000 models

[Timothy Sipples]

Radoslaw Skorupka wrote:
>I'm curious about 3000-A10 and 3000-A20.

IBM announced these models in U.S. Announcement Letter 197-290 (September 
30, 1997). They were the "S/390 Application StarterPak" machines. There 
were a couple of followup announcements in 1998 with new software options. 
IBM withdrew these machines from marketing on February 5, 2000, via 
Announcement Letter 900-011. Announcement Letter 901-097 included the 
withdrawal of remaining machine features (OSA-2 features) effective May 7, 
2001.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN