Re: LOGONBY and FTP
Thanks Alan. In the interest of good citizenship I'll open a Sev 3 PMR. Regarding NOPASSWORD, we do typically use that for SVMs, etc. Not this time because of what I was testing. Mark At 11:32 AM 6/10/2009, Alan Altmark wrote: FTP logon allows users in the ACL to use "testuser.by.surrogate" to log on to TESTUSER as expected, but DOES allow TESTUSER to logon directly. This is a surprise. Bug, or feature? Bug. Feel free to open a PMR. If you want to stop authentication using TESTUSER, remove its password (ALTUSER TESTUSER NOPASSWORD). Then it can't be used as an authenticator in ANY interface (including RACROUTE REQUEST=VERIFY), it can never be revoked due to invalid password attempts, and isn't subject to password expiry rules. This effectively turns it into AUTOONLY without having to mess with the directory. Alan Altmark z/VM Development IBM Endicott
LOGONBY and FTP (was: A Strange Use Of AUTOLOG)
I played around with LOGONBY and FTP and found something a little strange. Context: z/VM 5.4 with RACF installed, CP deferring to RACF for almost everything. RACF profile SURROGAT LOGONBY.TESTUSER exists, with the ACL not including TESTUSER itself. CP logon allows users in the ACL to log on to TESTUSER using LOGONBY as expected, and doesn't allow TESTUSER to logon directly, again as expected. FTP logon allows users in the ACL to use "testuser.by.surrogate" to log on to TESTUSER as expected, but DOES allow TESTUSER to logon directly. This is a surprise. Bug, or feature? Mark Bodenstein Cornell University At 03:08 PM 6/8/2009, Alan Altmark wrote: An LBYONLY user must authenticate with their own user ID. E.g. enter maint.by.michael when ftp prompts for your user ID. Alan Altmark z/VM Development IBM Endicott
Re: CP DIAL question
Thanks Rob, for the explanation. I was much more narrow in my focus, in fact just needing to "barf a message". But even in that narrow case there is the possibility of another DIAL showing up while "barfing" to the previous one, and thus being missed. I agree that an in-pipe tool for this would be interesting and useful. Regards, Mark Bodenstein (m...@cornell.edu) Cornell University At 02:41 PM 5/28/2009, Rob van der Heij wrote: On Thu, May 28, 2009 at 6:56 PM, Mark Bodenstein wrote: > I don't understand what you mean by "prevents the pipeline from having an > actual conversation with the other terminals dialed-in." Could you explain? CMS Pipelines is multi-tasking. If you use something external to wait for the device, you can't talk to other devices at the same time. When you really just need to barf a message to the dialed terminal and then let them break the connection, that might be sufficient. I was thinking about something more flexible that takes input from the terminal and builds a response based on that. Rob
Re: CP DIAL question
Thanks Michael! Much nicer, more complete and elegant than what I threw together and shamelessly posted last week. And it did work "right out of the box"! Mark Bodenstein (m...@cornell.edu) Cornell University At 01:49 PM 5/28/2009, Michael Coffin wrote: Drop the .txt from each of the two attached files, double check the EXEC to make sure the 3270 NOT character translated OK and put them on the 191(A) disk of any virtual machine and run DIALAWAY. Try dialing the virtual machine and you'll see the contents of the LOGMSG file, press ENTER or any ATTN key and your DIALed session will be dropped. Customize both the EXEC and LOGMSG as necessary, but it should work OK "right out of the box". Enjoy! Michael Coffin, President MC Consulting Company, Inc. 57 Tamarack Drive Stoughton, Massachusetts 02072
Re: CP DIAL question
Rob,
I coded this using WAKEUP as suggested by Harry Williams and have a working
prototype which I've included below. It's not quite bullet-proof (if a
DIAL happens while processing another DIAL this won't handle it) but it's a
start.
I don't understand what you mean by "prevents the pipeline from having an
actual conversation with the other terminals dialed-in." Could you explain?
Thanks,
Mark Bodenstein (m...@cornell.edu)
Cornell University
At 09:40 AM 5/28/2009, Rob van der Heij wrote:
On Thu, May 28, 2009 at 3:19 PM, Mark Bodenstein wrote:
> I previously looked at PIPE FULLSCREEN but was a little daunted at
having to
> create a 3270 data stream. (I was also hoping that somebody had something
> coded already that we could use.) I just took another look and there's a
> sample in HELP PIPE FULLSCREEN that does what we want.
Writing to the terminal should be the least of your problems. The
plumber's nightmare here is that you can't fullscr to a GRAF when it
is not yet dialed into. There's nothing in the pipeline now that will
help you to recognize that someone knocked on the door. And polling
undialed devices does not match my desire for elegance. You could used
an external command like WAKEUP ( IO but that prevents the pipeline
from having an actual conversation with the other terminals dialed-in.
Rob (talking to the Piper right now to see if he could be inspired to
add this function)
NOTSNA EXEC: This is the driver EXEC
/* EXEC to handle CP DIALs from users trying to get to MVS */
/* Mark Bodenstein 28May09*/
address command
signal on novalue
/* Set up to handle messages - used for stopping */
'CP SET MSG IUCV'
do forever
'WAKEUP (IO IUCVMSG'
select
when rc = 7 then do
/* handle I/O interrupt */
/* on stack: *IO devaddr CSW: csw1 csw2 */
parse pull . devaddr . csw1 csw2 .
/* handle Device End */
if left( csw2, 2) = '04' /* Device End */
/* write message to the device */
/* wait for user to hit Enter */
/* then reset the device */
then 'EXEC WRRD3270' devaddr
end
when rc = 5 then do
/* handle message */
/* on stack: *type userid message-text */
parse pull '*'type userid msg
msg = strip( msg)
say type 'from' userid '('msg') - ending'
rc = 0
signal exit
end
otherwise
say 'Unexpected WAKEUP return code:' rc
signal exit
end /* select */
end /* do forever */
/* termination processing */
exit:
/* save return code */
saverc = rc
/* Clear MSG setting */
'CP SET MSG ON'
/* exit */
exit rc
WRRD3270 EXEC: This is the EXEC that writes a message to the DIALed device
/* WRRD3270 EXEC */
/* Write to a 3270 device and then read from it, discarding the result */
/* and then resetting the device. */
/* Based on examples in HELP PIPE FULLSCREEN */
/* Mark Bodenstein 28May09*/
address command
signal on novalue
arg devaddr
/* define constants */
EraseWriteAlt = 'C0'x /* Erase Write Alternate command */
WriteControlChar = '03'x /* Write Control Character */
SetBufferAddress = '11'x /* Set Buffer Address order */
InsertCursor = '13'x /* Insert Cursor order */
StartField = '1D'x/* Start Field order */
AttrProtect = '28'x /* Protected attribute byte */
AttrNoProtect = '00'x /* Unprotected attribute byte */
/* create 3270 data stream */
DataStreamOut = EraseWriteAlt||WriteControlChar||SetBufferAddress||,
''x||StartField||AttrProtect||'You have connected to',
userid()'. Hit Enter to close this session.',
StartField||AttrNoProtect||SetBufferAddress||'0012'x||,
InsertCursor
/* do the write and read */
'PIPE',
'var DataStreamOut', /* Get outbound data stream */
'| fullscreen' devaddr,/* Write it and then read */
'| hole' /* discard the results */
/* reset the device */
'CP RESET' devaddr
exit rc /* Exit */
Re: CP DIAL question
I previously looked at PIPE FULLSCREEN but was a little daunted at having to create a 3270 data stream. (I was also hoping that somebody had something coded already that we could use.) I just took another look and there's a sample in HELP PIPE FULLSCREEN that does what we want. We would also need to use WAKEUP to wait for and handle the interrupt for the DIAL and invoke the EXEC that writes the screen, but that should be pretty straightforward. Thanks! Mark Bodenstein (m...@cornell.edu) Cornell University At 11:05 PM 5/27/2009, A. Harry Williams wrote: I thought I had a sample, but I couldn't find it after looking. you could write a small exec using PIPE's fullscr. It supports DIALed devices, and you could have it simply display a page of info, and then RESET after the person hits enter or some period of time. Could be a cheap informational display /ahw
Re: CP DIAL question
We have many more people that logon to VM rather than DIAL to MVS, and we wouldn't want to confuse them, but this is an interesting idea. Thanks! Mark Bodenstein (m...@cornell.edu) Cornell University At 05:01 PM 5/27/2009, Jim Hughes wrote: Why not just change the ZVM Logo screen to contain the instructions or announcements?
Re: CP DIAL question
Changing the MSG10 screen while we still have VM VTAM is a good idea. AND we want something for afterwards that will direct users to helpful information. Thanks to everyone for your suggestions! Mark Bodenstein (m...@cornell.edu) Cornell University At 01:30 PM 5/27/2009, Tom Duerbusch wrote: The easiest way of doing this, and perhaps the less costly, is to keep the license for VM/VTAM an extra month or two and use MSG10 to inform them. After that, it's the help desk problem . Tom Duerbusch THD Consulting (RIP Grey Stripe, a great cat and my buddy for, just shy of 19 years) >>> Mark Post 5/27/2009 12:07 PM >>> >>> On 5/26/2009 at 6:08 PM, Alan Altmark wrote: > On Tuesday, 05/26/2009 at 05:54 EDT, Mark Post wrote: >> So, why don't you just update the message put out in MSG10 to say what > you want? > > That won't work if he gets rid of VTAM! :-) My reading was that he was trying to provide a transition period for his users. Mark Post
Re: CP DIAL question
Thanks for the tip Richard. That fixed the problem. The file wasn't malformed, just misshaped. :) Mark Bodenstein (m...@cornell.edu) Cornell University At 06:02 PM 5/26/2009, you wrote: On your malformed VMARC file, did you try the "pipe < file | fblock 80 0 | > file" trick? I have not needed it very often, but it does come in handy every now and then. Regards, Richard Schuh
Re: CP DIAL question
I work with Jim Bohnsack who asked the original question. Thanks for your suggestion Thomas, but since the DIAL happens (or doesn't happen) after the session is established I'm not sure how SCEXIT would help. I tried to download RXLDEV as mentioned in David Boyes note, but the VMARC file was malformed. :-( David please contact me directly if you have contact information for Rick Troth. Thanks, Mark Bodenstein (m...@cornell.edu) Cornell University At 12:44 PM 5/26/2009, Huegel, Thomas wrote: You might want to take a look at z/VM TCPIP SCEXIT program. There are two parts to it,1) SCEXIT ASSEMBLE 2) SCEXIT EXEC ... Most likely you would only have to work with the REXX code in the EXEC .. Take a look and see if this will help.
Re: New CMS based SSLSERV problem... DTCSSL300E
We have successfully tested Hummingbird HostExplorer with the old z/VM SSL, the new z/VM SSL, and z/OS SSL. Mark Bodenstein (m...@cornell.edu) Cornell University At 09:57 AM 3/19/2009, you wrote: On Thursday, 03/19/2009 at 08:39 EDT, "Mrohs, Ray" wrote: > Thanks Alan. Unfortunately our site is standardized on the Rumba client, > and the centrally managed upgrades happen once a blue moon. It looks > like it might be a while before we can utilize the new SSLSERV, even > under the best circumstances. > Is there a list of clients that have been tested and work? - IBM Personal Communications 5.9 works - Seagull's BlueZone works - x3270 works - wc3270 (Windows version of x3270) works - Zephyr Passport works - IBM Host on Demand fails - Micro Focus Rumba fails - Attachmate Reflection fails In all cases our tests were with the levels current over the past year or so. We're building a more detailed list that will include the specific levels for both tn3270 and ftp. Note that some of the above do not support negotiated SSL. Those that fail will also fail with z/OS since it's the same SSL/TLS implementation. Alan Altmark z/VM Development IBM Endicott
Re: z/vm 5.4 DVD installation
Les, It would be a Good Thing to have all needed program materials available on the DVDs, including the associated VM products. And/or available for download. Motivation: Tape drives are the least reliable part of our operation. (Admittedly we have some pretty old 3494s and pretty old 3590 drives. We're experiencing a 3494 failure as I type this.) We would like to move to a virtual tape environment with no real tape drives. This isn't quite feasible here yet for reasons besides IBM software distribution, but we hope it will be feasible soon. Mark Bodenstein ([EMAIL PROTECTED]) Cornell University At 01:53 PM 10/10/2008, you wrote: >I've done the initial install of 5.4 using the DVD and I've installed >the RSU. If I were installing from tape at this point, I would mount >the program product tape(s) and continue the installation as per the >program directories of the other programs for which we are licensed but >don't come as part of the SDO. There were only 2 DVD's shipped, the >product DVD and the RSU DVD. > >Specifically, I need to install HLASM in order to install RACF/VM. I've >got HLASM 1.5 that I put on the 5.4 system, but there should be a HLASM >1.6. It's listed on the ship list, as is VTAM and DFSMS. Directory >entries were not created for them. Nothing was loaded. Where do I find >them. I have the tapes, but I'm working remotely. I can have someone >throw the product tape onto a drive, but it seems as if it ought to be >on the DVD. One the base z/VM product and RSU1 are available on DVD. When you order other products like VTAM, DFSMS, and HLASM, they will come as part of the SDO but on 3590 or 3592 tapes only. So if you ordered them, but no tapes showed up, I would open a PMR with the support center and have them investigate why. Have your bill of material sheet ready to fax into IBM. Best Regards, Les Geer IBM z/VM and Linux Development
Re: Seeking (former) Adventurers
Interesting. I played a lot of Adventure when I was a graduate student and then employee in the Computer Science Department at Cornell. I started grad school in 1969 and got an MS and became an employee in 1971. I can't definitively name the years, but I left the University in 1976, and this was well before that. We didn't run VM yet. I'm pretty sure I played a version under TSO. I kept my hand drawn maps - too much work went into them to throw them away. I wonder if I can put my hands on them now. Mark At 02:42 PM 6/3/2008, Adam Thornton wrote: On Jun 3, 2008, at 1:10 PM, Stephen Frazier wrote: I have a copy of the source code for an early version of Adventure. I do not seem to have the University of Oklahoma mods that I wrote around 1970 anymore. That seems unlikely; pretty much all the sources agree that Adventure itself was written about 1975, and the Woods collaboration that really enabled its breakout success was 1976. So I think you probably meant 1980. Adam
ICC SSL support? (was Re: Second TCPIP stack and SSL)
Dave, When I configured OSA Express2 ICC on our z9 BC in January 2007 I didn't see any indication that SSL was supported. Did I miss something, or did something change since then? If you could send me a documentation or Redbook reference I'd appreciate it. Thanks, Mark At 09:37 AM 4/17/2008, Dave Jones wrote: Hi, Alan. See if your shop has installed and supports the OSA ICC feature. It's a no charge feature (that's goodness:-) that allows for TN3270 clients (PCOMM, Vista, etc.) to attach directly to the OSA card and appear to CP as locally attached 3270s. The VM TCP/IP stack is not involved at all and need not even be up and running. The OSA ICC also supports TN3270 connections over SSL, so you can still encrypt your TN3270 traffic, even if the SSLSERV on VM is down. You can have your cake and eat it too, at least in this situation. Have a good one. Mark Bodenstein ([EMAIL PROTECTED]) Cornell University
Re: dirm needpass no
Thanks Colleen. Could you please pass this response back to DirMaint Support? This is our production system, and we certainly want to control who can issue DirMaint commands. The question is the best way to do this. In general we want to make things secure, but also easy to use for the few authorized userids. Note that we do NOT give DirMaint authority to all of our users. We give it to a few systems programmers, and a few staff at the Help Desk that are responsible for creating VM userids. To do this, we use the following DirMaint configuration files: AUTHFOR CONTROL AUTHDASD DATADVH (Jim was probably thinking of AUTHFOR CONTROL when he said AUTHBY CONTROL.) We also use RACF to restrict access to 5VMDIR30 11F, the DirMaint primary interface code disk, to only the userids we intend to have DirMaint privileges. With all of that in place to restrict who can issue DirMaint commands, we don't want to also have to have each privileged user respond with a password to use DirMaint. I'll leave it up to Jim to respond to "If he would follow the documentation given with the product he is informed of everything he needs to know about." First he needs to take more of his blood pressure medicine. Thanks, Mark Bodenstein ([EMAIL PROTECTED]) Cornell University At 01:56 PM 11/16/2007, you wrote: From DirMaint Support: What they have done is made every command be not prompted for a password. Which of course is not the way DirMaint typically runs. Someone, probably on the listserv, told them in the past they could alter the cmds file to remove them from password authorization. Something which I would typically describe as dangerous but perhaps on their education/test system it is what they want. With this in mind these files are not typical files to be needing tailoring at all. The are tailorable if there is some special case which they seem to have. This is why they are not discussed in the documentation (TAG). In the case of AUTHBY CONTROL this is built when you use the AUTHBY function for BYUSERS. There are several control files in DirMaint which get built because the external command was issued. Therefore there is no need for the customer to be informed of this file. If he would follow the documentation given with the product he is informed of everything he needs to know about. By default DirMaint requires passwords. The way they operate as discussed they are not. However, if the issue a NEEDPASS command which is an optional command it could confuse the issue. What I believe they should have done to give everyone access to all commands by making every command a GENERAL use command. Then the password prompt would not be so confusing. But as long as they know what they have done there is no issue. Just be aware that this could be dangerous. They are giving access to everyone to DASD commands which could be a loaded gun in the hands of the wrong people Colleen M Brown IBM z/VM and Related Products Development and Service Jim Bohnsack <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System 11/14/2007 01:10 PM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: dirm needpass no I took a look at doc for 140CMDS and 150CMDS and now I see the Y or N called out for col 35. I overlooked that as I did the last time we upgraded DIRMAINT. Mark found it then as he did now. What I don't understand is what appears to be the fact that there are so many places in DIRMAINT, both the client side and the server side where authorization is granted. On the client side, there appear to be GLOBALV options that can be set and there is also the DIRM NEEDPASS NO or YES. On DIRMAINT, there is the Y or N in the 1x0CMDS DATADVH file but there is also the AUTHBY CONTROL file. The descriptions for all of them seem to be scattered in different manuals rather than having a section in the Tailoring and Admin. manual. That makes setup of DIRMAINT really messy as does many of the different configuration files. Jim
Re: dirm needpass no
Jim is away in Texas and I'm here minding the shop. (Though he seems to be reading email, so I won't be surprised if he chimes in.) I checked the 140CMDS DATADVH and 150CMDS DATADVH files on the DIRMAINT 11F minidisk on our test VM LPAR which has DirMaint at the z/VM 5.3 level. These two files had mostly Y's in column 35 for the various commands, indicating that a password was required. In production (where we don't need to specify passwords) these two files have all N's in column 35. So I edited the files to specify N's in column 35, and restarted DIRMAINT. Voila! No passwords required. This is without doing anything with GLOBALV on the client side. I checked my GLOBALV files and didn't find NEEDPASS anywhere. Just to be sure I also checked the <http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/hcsl3b21/9.43>z/VM 5.3 DirMaint<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/hcsl3b21/9.43> Tailoring and Administration Guide. NEEDPASS is defined in Table 42 as a LASTING GLOBALV variable in pool DVH15 for possible use by DVHCX* and DVHPX* exits in the user's virtual machine (client side). There's no mention of the NEEDPASS global variable being used by anything other than being available for use by these exits. Mark Bodenstein ([EMAIL PROTECTED]) Cornell University At 10:57 AM 11/12/2007, Alan Altmark wrote: On Monday, 11/12/2007 at 08:19 EST, Phil Smith III <[EMAIL PROTECTED]> wrote: > "A. Harry Williams" <[EMAIL PROTECTED]> wrote: > >No, he's talking about > >GLOBALV SELECT DVH15 SET NEEDPASS NO > > OK, I must have misunderstood part of the thread then. This is the setting I > was referring to which, as your post goes on to note, doesn't work if done > SOLELY on the client, because the server still wants a password. So, from the discussion here, I'm getting the idea that even though NEEDPASS NO is remaining set on the client side, upgrading the DIRMAINT server somehow causes it to forget its setting for that same client. And that necessitates yet another NEEDPASS NO. Do I have that right? Alan Altmark z/VM Development IBM Endicott
Re: Changing privclass of SHUTDOWN
Thanks Chuckie. I work with Jim and already know I need to watch my back. Actually I've never done this. We did have a Systems Programmer In Training (Jim loves the acronym) some years back (and in Jim's defense I have to say this was before Jim joined us) who did it three times over the course of about a month. The head systems programmer at the time made her a button to wear with one word on it in black capital letters (SHUTDOWN), with a red circle around it and a red diagonal line through it. :-) Mark Bodenstein ([EMAIL PROTECTED]) Cornell University At 12:50 PM 11/6/2007, Alan Altmark wrote: On Tuesday, 11/06/2007 at 12:25 EST, Kris Buelens <[EMAIL PROTECTED]> wrote: > > Over the course of 30 years as a VM sysprog, every VM sysprog who I have > > worked with has shutdown a VM system *ONCE.* Me too :-[ > > Every sysprog? No, not *every* sysprog, just the ones Jim has worked with. Verry interesting. One might suspect (if one were of a suspicious mind) that Jim also has his Initiates issue the "LOGO" command, too, just for fun. So a word to the wise: If you find yourself working with Jim, watch your back! He's gonna try to get you to issue SHUTDOWN at the wrong place! -- Chuckie.
Re: ADRDSSU backup of VM volume
We also use MVS to backup our VM DASD. We want a consistent image of all of our production DASD, both MVS and VM. We get this (or as close to it as we think we need) by suspending database updates and doing an ADRDSSU FlashCopy (FASTREPLICATION(REQUIRED) on MVS of all of our production DASD, both MVS and VM. (We have Shark DASD.) As a separate step we dump the flash-copied data to tape. Mark Bodenstein ([EMAIL PROTECTED]) Cornell University Ithaca, N.Y. At 08:34 AM 9/24/2007, Alain Benveniste wrote: Why do you want to use MVS to backup your VM DASD ? Don't you have a VM software to do it ? And do you IPL your mvs in lpar mode or ubder VM ?. It looks like you have a similar config to mine. I also maintain our DR procedures too. So it could be good for each one to share our experience... Alain Benveniste System programmer Paris, france
Re: zVM 5.3 TCPIP memory problem
Thanks Alan and Michael for your explanations, and thanks Rick for looking on the bright side. :-) Mark Bodenstein ([EMAIL PROTECTED]) Cornell University
Re: zVM 5.3 TCPIP memory problem
Mike, Thanks for the information. I work with Jim and am also trying to understand the differences in memory use of the z/VM 5.3 TCP/IP clients compared to the z/VM 4.4 ones. The web page you reference talks about C sockets library changes, but says these were already present in z/VM 4.4. The difference we're seeing is between 4.4 and 5.3. So does this apply? I also wonder because we're seeing this with ftp and telnet, which aren't mentioned on your web page as using the C socket library. (Do they?) I've done some more testing, and find that the 5MB or so additional memory use that we're seeing only happens when there is a DNS lookup involved. So if I do "ftp cornellc.cit.cornell.edu" I see the additional memory use, but if I do "ftp 132.236.98.12" I don't. Similarly "ftp loopback" doesn't cause the additional memory use. I see the same thing for lpr: lpr profile exec (p raw at cornellc.cit.cornell.edu causes the additional memory use, while lpr profile exec (p raw at 132.236.98.12 does not. So what is there about DNS lookup that causes this memory use, while otherwise the clients don't suck up virtual storage? Thanks, Mark Bodenstein ([EMAIL PROTECTED]) Cornell University At 01:08 PM 9/14/2007, you wrote: Jim, There are several reasons for the increased use of virtual storage when running the TCP/IP functions and utilities. You can read about some of these at <http://www.vm.ibm.com/devpages/donovanm/zvmle.html>http://www.vm.ibm.com/devpages/donovanm/zvmle.html and specifically look at <http://www.vm.ibm.com/devpages/donovanm/zvmle.html#LEstor>http://www.vm.ibm.com/devpages/donovanm/zvmle.html#LEstor The 5M "feechur" you mention is an unfortunate artifact of sockets being defined as POSIX file descriptors in the Byte File System client code. "Fixing" this involves a significant rewrite of a BFS client storage management and will most likely not happen any time soon. Mike Donovan --- zVM 5.3 TCPIP memory problem I remember back in zVM 5.1 or 5.2 days seeing on the list that there were memory problems or memory size issues. I probably didn't follow it because I was using 4.4 and probably just thought it would be fixed. Now I see that it wasn't fixed. I've just been told by IBM it's a "feechur". I'm seeing it with the TCPIP clients, FTP and LPR. They grab about 5M and don't release it. I didn't see it in putting the release together because whoever runs the MAINT id in installation with a small machine size. Does anyone have any ideas or a solution or is that just the way it is? Jim -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: Debian SSL Server
Thanks David. Glad to hear you're getting paying work. :-) Mark At 03:08 PM 8/27/2007, you wrote: Does Sine Nomine have a version of the SSL Enabler incorporating the appropriate RPM for z/VM 5.3? Not yet. It's behind a few other significant pieces of paying work at the moment. It's a few weeks away at best. More later. -- db
Re: Debian SSL Server
David, The interface between SSLSERV and TCPIP has changed in z/VM 5.3. See: http://www.vm.ibm.com/related/tcpip/tcprl2rl.html#rl2ssl Does Sine Nomine have a version of the SSL Enabler incorporating the appropriate RPM for z/VM 5.3? Thanks, Mark At 02:25 PM 8/27/2007, David Boyes wrote: It would help if you supplied us what errors youre seeing, and what you see in the TCPIP log .. I used the Debian SSL Enabler from SNA on zVM 5.1 until yesterday when I migrated to zVM 5.3 when it stopped working. I found a couple of errors and corrected them but still no go and I am still scratching my head. Has any one tried Debian SSL Enabler from SNA on 5.3 and can tell me what to expect or what to look for? Mark Bodenstein ([EMAIL PROTECTED]) Cornell University
Re: Secondary FTP Server Help
WS-FTP Pro configured for implicit SSL running under Windows XP works for us to connect to z/VM 4.4. Mark At 01:36 AM 8/9/2006, Adam Thornton wrote: On Aug 8, 2006, at 9:32 PM, Alan Ackerman wrote: We got Bluezone (trial copy) to work doing SSL FTP. We did NOT get our WS -FTP PRO client to work. We DID open a PMR, but were told the problem is in WS-FTP PRO. That's whe re it sits. FWIW I have reports of success using WS-FTP Pro. Make sure Implicit mode is enabled. My customer also defined a proxy but that may be a vagary of his network. I have not yet been successful with Glub Tech Secure FTP for Mac OS X, but I have a report that the Windows version works OK. Adam -- Mark Bodenstein ([EMAIL PROTECTED]; 607-255-8059) Mainframe Systems Programming, Systems and Operations Cornell Information Technologies Cornell University Ithaca, N.Y. 14853
