Re: z/VM 5.3 FLIST
On the other hand, having had to read as many dumps as I once did, and having received too many files that were formatted for print, I am accustomed to 132 and find that it has none of the drawbacks that 80 byte widths present, i.e. too short to be of any use, too cramped for comments on program lines, etc. And scanning back and forth is no more of a problem than scanning up and down. :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Adam Thornton Sent: Friday, December 14, 2007 10:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 5.3 FLIST On Dec 14, 2007, at 12:18 PM, Alan Altmark wrote: > I have been ready for years to stop reformatting data to accomodate 80 > columns. Back when we used Real 3270s, that was an issue. No longer. > It is time to take a bold step forward into the 1990s. That's enough outta you, heretic. 80 columns is the right width: long enough to be useful, short enough that you don't have to scan back and forth a lot to read a line. 132 columns is unpleasant. Adam
Re: VM 5.2 using Racf can you password protect an individual file?
On Friday, 12/14/2007 at 03:58 EST, "Hamilton, Brian" <[EMAIL PROTECTED]> wrote: > Hide the passwords in the file NETRC DATA which is used for FTP What you are describing would be a native function of the CMS file system. The support you're asking for isn't there (with or without RACF or other ESM). As an alternative, since you're going to prompt a user for a password, just let FTP prompt them for the FTP password and ensure that all of the target users have the same password. Alan Altmark z/VM Development IBM Endicott
Re: VM 5.2 using Racf can you password protect an individual file?
Thats going to be a tough one.. If you come up with something you can share, let us know what you did. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Hamilton, Brian Sent: Friday, December 14, 2007 2:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM 5.2 using Racf can you password protect an individual file? Hide the passwords in the file NETRC DATA which is used for FTP _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Friday, December 14, 2007 3:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM 5.2 using Racf can you password protect an individual file? What are you trying to do? Allow an exec to be executed, but hide the code? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Hamilton, Brian Sent: Friday, December 14, 2007 2:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM 5.2 using Racf can you password protect an individual file? Hi, Using racf under VM I would like to password protect a file so that if you try to browse it or xedit the file you would be prompted to enter a password. Is it possible? Thanks Brian Hamilton
Re: VM 5.2 using Racf can you password protect an individual file?
Hide the passwords in the file NETRC DATA which is used for FTP From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Friday, December 14, 2007 3:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM 5.2 using Racf can you password protect an individual file? What are you trying to do? Allow an exec to be executed, but hide the code? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Hamilton, Brian Sent: Friday, December 14, 2007 2:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM 5.2 using Racf can you password protect an individual file? Hi, Using racf under VM I would like to password protect a file so that if you try to browse it or xedit the file you would be prompted to enter a password. Is it possible? Thanks Brian Hamilton
Re: VM 5.2 using Racf can you password protect an individual file?
What are you trying to do? Allow an exec to be executed, but hide the code? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Hamilton, Brian Sent: Friday, December 14, 2007 2:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM 5.2 using Racf can you password protect an individual file? Hi, Using racf under VM I would like to password protect a file so that if you try to browse it or xedit the file you would be prompted to enter a password. Is it possible? Thanks Brian Hamilton
Re: VM 5.2 using Racf can you password protect an individual file?
Not possible... Not even with SFS where you can give permits on file-level base. 2007/12/14, Hamilton, Brian <[EMAIL PROTECTED]>: > > Hi, > > > > Using racf under VM I would like to password protect a file so that if you > try to browse it or xedit the file you would be prompted to enter a > password. > > > > Is it possible? > > > > Thanks > > > > Brian Hamilton > -- Kris Buelens, IBM Belgium, VM customer support
VM 5.2 using Racf can you password protect an individual file?
Hi, Using racf under VM I would like to password protect a file so that if you try to browse it or xedit the file you would be prompted to enter a password. Is it possible? Thanks Brian Hamilton
Re: z/VM 5.3 FLIST
Besides, when you put a 132-column punch card into your shirt pocket (on the back side of the plastic pocket protector) it's so long that it chafes the neck. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone, and in this post certainly, do not represent the opinions or policies of Hewitt Associates. "Adam Thornton" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 12/14/2007 12:45 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: z/VM 5.3 FLIST On Dec 14, 2007, at 12:18 PM, Alan Altmark wrote: > I have been ready for years to stop reformatting data to accomodate 80 > columns. Back when we used Real 3270s, that was an issue. No > longer. It > is time to take a bold step forward into the 1990s. That's enough outta you, heretic. 80 columns is the right width: long enough to be useful, short enough that you don't have to scan back and forth a lot to read a line. 132 columns is unpleasant. Adam The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email.
Re: z/VM 5.3 FLIST
On Dec 14, 2007, at 12:18 PM, Alan Altmark wrote: I have been ready for years to stop reformatting data to accomodate 80 columns. Back when we used Real 3270s, that was an issue. No longer. It is time to take a bold step forward into the 1990s. That's enough outta you, heretic. 80 columns is the right width: long enough to be useful, short enough that you don't have to scan back and forth a lot to read a line. 132 columns is unpleasant. Adam
Re: z/VM 5.3 FLIST
> I have been ready for years to stop reformatting data to accomodate 80 > columns. Back when we used Real 3270s, that was an issue. No longer. It > is time to take a bold step forward into the 1990s. He's a witch! Burn him! (in best Monty Python style...) -- db
Re: z/VM 5.3 FLIST
40x90 is not even an option offered by my emulator. What one do you use and what other exotic sizes does it support? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, December 14, 2007 10:18 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 5.3 FLIST On Friday, 12/14/2007 at 12:40 EST, [EMAIL PROTECTED] wrote: > The USE and MENU options don?t get around the problem of the tiny > input area. On my z/VM 5.3 system I have 9 characters. But this issue with large disks threatens to get out of hand. Apparently the word isn't getting around that it is time to start scaling these large numbers on displays unless specifically asked for details. 99.999% of the time, I only care about the relative scale of file sizes. Knowing a file has 45K records is just as good as knowing it has 44,727 records. I'm just looking for the big ones to throw away. Naturally LISTFILE shouldn't do the scaling, but FILELIST and FLIST should. Sorting can still work by the unseen real number. If one does a Sort-by-Size operation, THEN the real number is shown and some non-size related field disappears. All assuming, of course, that my 90 column screen can't accomodate the whole thing. (FLIST reverts to 24x80 on my 40x90 screen.) I have been ready for years to stop reformatting data to accomodate 80 columns. Back when we used Real 3270s, that was an issue. No longer. It is time to take a bold step forward into the 1990s. Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.3 FLIST
On Friday, 12/14/2007 at 12:40 EST, [EMAIL PROTECTED] wrote: > The USE and MENU options don?t get around the problem of the tiny input area. On my z/VM 5.3 system I have 9 characters. But this issue with large disks threatens to get out of hand. Apparently the word isn't getting around that it is time to start scaling these large numbers on displays unless specifically asked for details. 99.999% of the time, I only care about the relative scale of file sizes. Knowing a file has 45K records is just as good as knowing it has 44,727 records. I'm just looking for the big ones to throw away. Naturally LISTFILE shouldn't do the scaling, but FILELIST and FLIST should. Sorting can still work by the unseen real number. If one does a Sort-by-Size operation, THEN the real number is shown and some non-size related field disappears. All assuming, of course, that my 90 column screen can't accomodate the whole thing. (FLIST reverts to 24x80 on my 40x90 screen.) I have been ready for years to stop reformatting data to accomodate 80 columns. Back when we used Real 3270s, that was an issue. No longer. It is time to take a bold step forward into the 1990s. Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.3 FLIST
The USE and MENU options don't get around the problem of the tiny input area. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Colleen Brown Sent: December 14, 2007 09:46 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 5.3 FLIST There are many appends about FLIST so I apologize if this has been suggested before. You can use the USE option of FLIST. This may give you the function you want. It is explained in the HELP file and in the CMS Commands and Utilities book. The book also shows an example of an FLISTS exec to use with the USE option. Colleen M Brown IBM z/VM and Related Products Development and Service The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
Re: z/VM 5.3 FLIST
NO !!! Then it would have to be renamed WINDOWS.. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Schuh, Richard Sent: Friday, December 14, 2007 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 5.3 FLIST Even better, make the random change with each use. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Friday, December 14, 2007 6:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 5.3 FLIST On Dec 14, 2007 1:28 PM, Phil Smith III <[EMAIL PROTECTED]> wrote: > And bemoaning, daily, the lack of similar functionality in Those Other Operating Systems (no, Windows Explorer is NOT equivalent!)... Oh dear... Just when I was going to offer a massive improvement for FLIST It removes the input area completely, and only offers you the option to position the cursor on the file and press Enter to do the "right thing" with the file. The "right thing to do" will be defined in some hard-to-change configuration files that change randomly each time you install new software (to ensure it works differently for each user). Rob (it's friday afternoon already)
Re: z/VM 5.3 FLIST
Even better, make the random change with each use. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Friday, December 14, 2007 6:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 5.3 FLIST On Dec 14, 2007 1:28 PM, Phil Smith III <[EMAIL PROTECTED]> wrote: > And bemoaning, daily, the lack of similar functionality in Those Other Operating Systems (no, Windows Explorer is NOT equivalent!)... Oh dear... Just when I was going to offer a massive improvement for FLIST It removes the input area completely, and only offers you the option to position the cursor on the file and press Enter to do the "right thing" with the file. The "right thing to do" will be defined in some hard-to-change configuration files that change randomly each time you install new software (to ensure it works differently for each user). Rob (it's friday afternoon already)
Re: z/VM 5.3 FLIST
On: Fri, Dec 14, 2007 at 09:08:11AM -0600,Brian Nielsen Wrote: } As has been mentioned here before, KEDIT & KEX are a wonderful versions of } XEDIT & REXX. What may not have been mentioned is that it also is an I will second Brian's admiration of Kedit. For those who have Kedit and are not aware of the new release, be aware that 1.6 is out of beta and is available from thier web site. -- Rich Greenberg N Ft Myers, FL, USA richgr atsign panix.com + 1 239 543 1353 Eastern time. N6LRT I speak for myself & my dogs only.VM'er since CP-67 Canines:Val, Red, Shasta & Casey (RIP), Red & Zero, Siberians Owner:Chinook-L Retired at the beach Asst Owner:Sibernet-L
Re: z/VM 5.3 FLIST
On Fri, 14 Dec 2007 09:45:51 -0500, Colleen Brown <[EMAIL PROTECTED]> wrote: >There are many appends about FLIST so I apologize if this has been >suggested before. >You can use the USE option of FLIST. This may give you the function you >want. It is explained in the HELP file and in the CMS Commands and >Utilities book. The book also shows an example of an FLISTS exec to use >with the USE option. The USE option with the MENU option is great. I first used them back in 1985 to do the screen interface for the client side of a secured printout database. Brian Nielsen
Re: z/VM 5.3 FLIST
On Fri, 14 Dec 2007 07:28:21 -0500, Phil Smith III <[EMAIL PROTECTED] software.com> wrote: >And bemoaning, daily, the lack of similar functionality in Those Other Operating Systems (no, Windows Explorer is NOT equivalent!)... As has been mentioned here before, KEDIT & KEX are a wonderful versio ns of XEDIT & REXX. What may not have been mentioned is that it also is an admirable stand-in for FILELIST/FLIST. It displays the list of files and directories right in an editable file (called dir.dir). There are a couple built-in features for working with files/directories in the list (such as KEDIT a file, navigating through the directory structure, sortin g by various attributes), and I've added a couple of my own (such as ERASE a file, RENAME a file, REFRESH the list, make the displayed directory the current directory). It supports long filenames and allows you to change the columns set aside for the names. With the ability to write KEX macro s you can also do things to lists of files. It's also easy to make it invoke your macros with key sequences or from on screen buttons. Brian Nielsen
Re: z/VM 5.3 FLIST
There are many appends about FLIST so I apologize if this has been suggested before. You can use the USE option of FLIST. This may give you the function you want. It is explained in the HELP file and in the CMS Commands and Utilities book. The book also shows an example of an FLISTS exec to use with the USE option. Colleen M Brown IBM z/VM and Related Products Development and Service
Re: z/VM 5.3 FLIST
On Dec 14, 2007 1:28 PM, Phil Smith III <[EMAIL PROTECTED]> wrote: > And bemoaning, daily, the lack of similar functionality in Those Other > Operating Systems (no, Windows Explorer is NOT equivalent!)... Oh dear... Just when I was going to offer a massive improvement for FLIST It removes the input area completely, and only offers you the option to position the cursor on the file and press Enter to do the "right thing" with the file. The "right thing to do" will be defined in some hard-to-change configuration files that change randomly each time you install new software (to ensure it works differently for each user). Rob (it's friday afternoon already)
Re: z/VM 5.3 FLIST
Given the amount of time that filelist has been available, wouldn't it be more prudent to be requesting the features you feel are lacking in filelist, rather than trying to keep an old sagging horse alive? Obviously, flist is still maintained, since it was changed in the current release. But it would seem that it is being changed without much regard for the user community. I agree that very few useful commands can be entered in seven characters. It doesn't even meet the file name size of eight. Actually, running flist here shows nine characters in the field. The statement was made that browse is required... Can the browse command not be used from filelist? I tried it, and it appears to work. My filelist doesn't have PF10 assigned to anything, and it's the vanilla filelist, so, why not put browse there? Or worst case, rearrange the keys to suit your needs, adding browse in the process? Or, change PF2 to browse, to match flist, and forgo the Refresh Pfkey? The other flist Pfkeys displayed were fairly (completely?) cryptic, and it's been way (waay) too long since I'd used it in any serious capacity. Seriously... It's time to let go of flist and move into the '80s. -- .~.Robert P. Nix Mayo Foundation /V\RO-OE-5-55200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - "In theory, theory and practice are the same, but in practice, theory and practice are different." On 12/13/07 3:48 PM, "George Haddad" <[EMAIL PROTECTED]> wrote: > Once upon a time, there was FLIST, but no FILELIST. Some of us > old-schoolers still prefer it. > > Rick Bourgeois wrote: >> That's very interesting, I've never used FLIST I've always used FILEL so I >> never saw the change. >> >> >> Rick Bourgeois >> Virtual Software Systems, Inc. >> 7715 Browns Bridge Rd >> Gainesville, GA 30506 >> [EMAIL PROTECTED] >> 770-781-3200 >> >> >> >>
Re: z/VM 5.3 FLIST
Jim Bohnsack <[EMAIL PROTECTED]> wrote: >I could retire if a had a dollar, or certainly a euro, for every time I >heard the religious argument "you have the full power of XEDIT". I >still have managed to keep a copy of the full strength FULIST and there >are very few times when I use filelist vs fulist. And then there was KFLIST (Kolinar FLIST), which had features like the /D command to delete a file *from the display* and /SV to sort *by return code from a previous command*. I used to use those all the time to build a file view, then issue "FORALL " or "FORREST " (the former is like EXECUTE *, the latter is like "EXECUTE from the current line to the end" -- very useful after you've done something like "FORALL FCOMPARE / /nt " followed by /SV). I find myself using both FLIST and FILELIST as a result; both have their place. "EXECUTE *" is the main reason FILELIST is sometimes attractive. And bemoaning, daily, the lack of similar functionality in Those Other Operating Systems (no, Windows Explorer is NOT equivalent!)... ...phsiii