Re: z/VM 5.3 FLIST

2007-12-17 Thread Kris Buelens
VTAM does support weird sizes.  One need to code a "good" PSERVIC
in the LOGMODE.  This is what we use:
   PSERVIC=X'02800300'
The 03 near the end tells VTAM to use a WSFQ to find the screen size,
works perfectly well with for example 52x150.  Going with such a size
to TSO for example, that's another matter.

I don't remember a PCOMM level that allows to enter an arbitrary size
in its customization menu.  PCOMM 4.1 that I still daily use on OS/2
does not.

-- 
Kris Buelens,
IBM Belgium, VM customer support


Re: Dirmaint woes

2007-12-17 Thread Kris Buelens
I didn't notice a DIRM FREE was included in your append.  So, I tested
it here  with your LINGRP group definitions & free space,  and all
works fine

2007/12/17, Kris Buelens <[EMAIL PROTECTED]>:
> Issue DIRM FREE to see what DRIMAINT thinks about free space.
>
> 2007/12/17, Jerry Whitteridge <[EMAIL PROTECTED]>:
> >
> >
> > I'm trying to add an  new user having implemented Dirmaint and get a 
> > failure for no gap of sufficient  size :
> >


-- 
Kris Buelens,
IBM Belgium, VM customer support


Re: z/VM 5.3 FLIST

2007-12-17 Thread Steve Bireley
Some apps handle non-standard default sizes well, others not so well.  If your 
app can handle it, the custom default size is nice to display more than 24 
lines in 80 column (like 43 x 80) mode and a large alternate size (57 x 132) to 
display reports.  Another useful size is 62 x 160 (3290 mode), to display 4 
ISPF sessions simultaneously, using the split and splitv commands.

If you want support for 255 columns so you can get more in your XEDIT window, 
just let me know ; - ).


Steve Bireley
BlueZone Software
Integration-Emulation-Security
Free Bluezone Secure FTP
1-404-364-1731
www.bluezonesoftware.com

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan 
Altmark
Sent: Monday, December 17, 2007 9:50 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: z/VM 5.3 FLIST

On Friday, 12/14/2007 at 01:27 EST, "Schuh, Richard" <[EMAIL PROTECTED]>
wrote:
> 40x90 is not even an option offered by my emulator. What one do you use
> and what other exotic sizes does it support?

IBM PCOMM, of course!  :-)  I get any size I want by editing the .ws file
and manually filling in the height and width.  The standard pull-down on
the configuration GUI limits you to the 1980s.  :-(

I see that Seagull's Bluezone emulator includes a Custom option on the GUI
that lets you fill in the dimensions of BOTH the primary and alternate
screen sizes.  (Though I shudder to think of how apps will respond to an
alternate screen size of other than 24x80!  It's not like they query the
dimensions of anything)  Bluezone supports a maximum configuration of
98x160.  But that's ok -- I noticed last week XEDIT has a limit of 255
columns!

Alan Altmark
z/VM Development
IBM Endicott


Re: DFSMSRM Errors in RMSMASTR

2007-12-17 Thread jcanavan
 
I just looked and none of these APARs are listed in the upgrade/setup.
I have just installed DFSMS VM 221 on z/VM 5.3
The "ADDSERV" says this is at ESO0702, and the VMFINO only list apars from 1993.
Do I need these APARs for 5.3.
 












10  00/08/15 VM62522  UM29738  0008 HIPER DFSMS MOVE IN CSE CLUSTER
 9. 99/04/15 VM62133  UM29280  9903 THE FSMRMVST MODULE, FIRSTE
 8. 99/04/15 VM62089  UM29248  9903 SEVERAL PROBLEMS WITHIN THE
 7  98/07/31 VM61781  UM28993  9807 HIPER VGS FSMRMVGS TERRIBLE
 6. 96/10/21 VM60753  UM28457  9709 DFSMS PART HANDLER FSMBDMLD
 5  95/01/20 VM59034  UM26933  9501 MSFSMBAC2006E RSN3740
 4  94/03/28 VM57835  UM25767  9404 MINIDISK MOVE PROCESSING IN
 3  94/03/18 VM57630  UM25767  9404 MSFSMZCG3039E DFSMS NOT
 2  93/07/22 VM55830  UM24457  9404 ENHANCEMENTS TO RMS FUNCTION
 1. 93/03/29 VM55497  UM24117  9404 HIPER ML1 FILES ERASED WHEN






 



End of Upgrade DFSMSVM221 , Subset SMS221 , as of 2006/07/04. 







Rate this page 



Please take a moment to complete this form to help us better serve you. 












This material provides me with the information I need.
Strongly Agree Agree Neutral Disagree Strongly Disagree 







The language of this material is easy to understand.
Strongly Agree Agree Neutral Disagree Strongly Disagree 







Did the information help you to achieve your goal? 
Yes  No  Don't know 







Please provide us with comments to help improve this page:
 







Your response will be used to improve our document content. Requests for assistance, if applicable, should be submitted through your normal support channel as we cannot respond from this site.







Input the verification number to submit feedback:
Verification number: 32647  












Document information





 Product categories:



 
Software



 
Operating System



 
z/OS family





 IBM Group:

 
IBM Server Group



 Modified date:

 
2005-01-05






Translate My Page





   Select language Return to English Brazilian Portuguese French German Italian Japanese Korean Spanish Simplified Chinese Traditional Chinese 

    



Rate this page 





Help us improve this page. Your response will be used to improve our document content. Requests for assistance, if applicable, should be submitted through your normal support channel as we cannot respond from this site.





"Les Geer (607-429-3580)" <[EMAIL PROTECTED]>Sent by: The IBM z/VM Operating System  
12/12/2007 01:28 PM EST

Please respond to The IBM z/VM Operating System 



To  
"IBMVM@LISTSERV.UARK.EDU" 


cc  



bcc  



Subject  
Re: DFSMSRM Errors in RMSMASTR


>    That would be scratch0 I believe. I've been trying some stuff this>morning after reading your note. I disassociated the drive from the>scratch pool and when I re-started the RMSMASTR machine, there were no>sense errors. I was able to manually mount a tape which was volspecific.>After re-associating the drive to the scratch0 pool, I once again got>the errors on initialization of RMSMASTR.>>Which APAR(s) should I be applying to bring DFSMS/VM current?>The APARs which allow RMS to issue a query device without attachingthe device are VM64062 and VM64206 for RMS, and VM64157 for CP.However, none of this service in my belief will help solve theI/O errors you are receiving.  If you associate a device with aparticular scratch pool, and there are volumes in this pool, theI/O error seems strange.  You should ask the CE about this.  Of coursethey will point to the software.  So if you obtain a trsource trace ofthe I/O error we can tell you exactly what I/O is failing and what theerror is.Best Regards,Les GeerIBM z/VM and Linux Development__

This email may contain confidential and privileged material for the sole use of 
the intended recipient(s). Any review, use, distribution or disclosure by 
others is strictly prohibited. If you are not the intended recipient (or 
authorized to receive for the recipient), please contact the sender by reply 
email and delete all copies of this message. To reply to our email 
administrator directly, send an email to [EMAIL PROTECTED]

Re: Dirmaint woes

2007-12-17 Thread Cal Fisher
Hi Jerry

Add the user without any mdisk statements. Then get the directory entry and
add the mdisk statement back in and replace the entry. 

 

Cal Fisher

My   website

My tour in the Navy  

The   MVMUA website  

 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Jerry Whitteridge
Sent: Monday, December 17, 2007 3:44 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Dirmaint woes

 

I'm trying to add an new user having implemented Dirmaint and get a failure
for no gap of sufficient size :

 

 DVHREQ2288I Your ADD request for SLMGSB22 at * has been accepted.  
 DVHBIU3450I The source for directory entry SLMGSB22 has been updated.  
 DVHBIU3424I The next ONLINE will take place immediately.   
 DVHDRC3451I The next ONLINE will take place via delta object directory.
 DVHBIU3428I Changes made to directory entry SLMGSB22 have been placed  
 DVHBIU3428I online.
 DVHSCU3541I Work unit 17123620 has been built and queued for processing.   
 DVHSHN3541I Processing work unit 17123620 as MAINT from VT01,  
 DVHSHN3541I notifying MAINT at VT01, request 141.1 for SLMGSB22 sysaffin   
 DVHSHN3541I *; to: AMDISK 0100 3390 AUTOG 10016 LINGRP MR  
 DVHALC3297E No gap of sufficient size found in candidate area(s).  
 DVHAMD3298E DASD allocation attempt failed.
 DVHAMD3298E For: SLMGSB22 0100 Request: 3390 AUTOG 10016 LINGRP MR 
 DVHSRL3414I Workunit 17123620 has failed.  It is being saved as 17123620   
 DVHSRL3414I WUCFFAIL.  

 

I am trying to add the user with a prototype using the following definition:

 

0 * * * Top of File * * *
1 USER LINUX NOLOG 512M 2G G 
2 INCLUDE LNXDFLT
3 OPTION APPLMON 
4 MDISK 100 3390 AUTOG 10016 LINGRP MR   
5 * DISK 101 VDISK FOR SWAPGEN   
6 * DISK 102 VDISK FOR SWAPGEN   
7   MINIOPT NOMDC

 

The extent control file contains:

 

00037 :REGIONS. 
00038   *RegionId  VolSerRegStart  RegEnd  Dev-Type  Comments   
00039 VM7A4A   VM7A4A   1  END 3390-32K  Linux Disk 
00040 VM7A47   VM7A47   1  END 3390-32K  Linux Disk 
00041 VM7A48   VM7A48   1  END 3390-27   Linux Disk 
00042 VM7B4A   VM7B4A   1  END 3390-27  Linux Disk  
00043 :END. 
00044 :GROUPS.  
00045   *GroupName RegionList   
00046 LINGRP (ALLOCATE ROTATING)
00047 LINGRP VM7A4A VM7A47 VM7A48 VM7B4A
00048 :END. 
00049 :EXCLUDE. 
00050 * USERID ADDRESS  
00051 :END. 
00052 :AUTOBLOCK.   
00053   * IBM supplied defaults are contained in the AUTOBLK DATADVH file.  
00054   * The following are customer overrides and supplements. 
00055   *   
00056   *DASDType BlockSize Blocks/Unit Alloc_Unit Architecture 
00057 :END. 
00058 :DEFAULTS.
00059   * IBM supplied defaults are contained in the DEFAULTS DATADVH file. 
00060   * The following are customer overrides and supplements. 
00061   *   
00062   *DASDType Max-Size  
00063 339032760 
00064 3390-9  10017 
00065 3390-27 32760 
00066 :END. 

 

and when I issue the DIRM FREE GROUPS= LINGRP I get the following

 

FREEXT GROUP= LINGRP

 

  GROUP   REGION  VOLUMESTART  SIZE   (END) OWNER  ADDR
SA   
  -- -- -- --  

 

LINGRP   VM7A47   VM7A47  1  18228  18228 .FREE.    *

LINGRP   VM7A47   VM7A4

Re: Dirmaint woes

2007-12-17 Thread Kris Buelens
Issue DIRM FREE to see what DRIMAINT thinks about free space.

2007/12/17, Jerry Whitteridge <[EMAIL PROTECTED]>:
>
>
> I'm trying to add an  new user having implemented Dirmaint and get a failure 
> for no gap of sufficient  size :
>
>  DVHREQ2288I  Your ADD request for SLMGSB22 at * has been  accepted.
>  DVHBIU3450I The source for directory entry SLMGSB22 has been  updated.
>  DVHBIU3424I The next ONLINE  will take place  immediately.
>  DVHDRC3451I The next ONLINE will take place via delta object  directory.
>  DVHBIU3428I Changes made to directory  entry SLMGSB22 have been placed
>  DVHBIU3428I  online.
>  DVHSCU3541I Work unit 17123620 has been built and queued for  processing.
>  DVHSHN3541I Processing work unit 17123620 as  MAINT from  VT01,
>  DVHSHN3541I notifying MAINT at VT01, request 141.1 for SLMGSB22  sysaffin
>  DVHSHN3541I *; to: AMDISK 0100 3390 AUTOG 10016  LINGRP  MR
>  DVHALC3297E No gap of sufficient size found in candidate  area(s).
>  DVHAMD3298E DASD allocation attempt  failed.
>  DVHAMD3298E For: SLMGSB22 0100 Request: 3390 AUTOG 10016 LINGRP  MR
>  DVHSRL3414I  Workunit 17123620 has failed.  It is being saved as 17123620
>  DVHSRL3414I  WUCFFAIL.
>
> I am trying to add  the user with a prototype using the following definition:
>
> 0 * * * Top of  File * *  *
> 1 USER LINUX NOLOG 512M 2G  G
> 2 INCLUDE  LNXDFLT
> 3 OPTION  APPLMON
> 4 MDISK 100 3390 AUTOG 10016 LINGRP  MR
> 5 * DISK 101 VDISK FOR  SWAPGEN
> 6 * DISK 102 VDISK FOR  SWAPGEN
> 7   MINIOPT  NOMDC
>
> The extent control  file contains:
>
> 00037  :REGIONS.
> 00038   *RegionId  VolSer RegStart  RegEnd  Dev-Type   Comments
> 00039  VM7A4AVM7A4A1  END 3390-32K  Linux  Disk
> 00040  VM7A47VM7A471  END 3390-32K  Linux  Disk
> 00041  VM7A48VM7A481  END 3390-27Linux Disk
> 00042  VM7B4AVM7B4A1  END 3390-27  Linux  Disk
> 00043  :END.
> 00044  :GROUPS.
> 00045   *GroupName  RegionList
> 00046 LINGRP (ALLOCATE  ROTATING)
> 00047 LINGRP VM7A4A VM7A47 VM7A48  VM7B4A
> 00048  :END.
> 00049  :EXCLUDE.
> 00050 * USERID  ADDRESS
> 00051  :END.
> 00052  :AUTOBLOCK.
> 00053   * IBM supplied defaults are contained in the AUTOBLK  DATADVH file.
> 00054   * The following are customer overrides  and  supplements.
> 00055*
> 00056   *DASDType BlockSize Blocks/Unit Alloc_Unit  Architecture
> 00057  :END.
> 00058  :DEFAULTS.
> 00059   * IBM supplied defaults are contained in the DEFAULTS  DATADVH file.
> 00060   * The following are customer overrides and  supplements.
> 00061*
> 00062   *DASDType  Max-Size
> 00063 3390 32760
> 00064 3390-9   10017
> 00065 3390-27  32760
> 00066  :END.
>
> and when I issue the  DIRM FREE GROUPS= LINGRP I get the following
>
> FREEXT GROUP=  LINGRP
>
>   GROUP   REGION  VOLUME START  SIZE(END) OWNER  ADDR
> SA
>   -- -- -- --    
> 
>
> LINGRP   VM7A47VM7A47   1  18228  18228  .FREE.    *
> LINGRP   VM7A47   VM7A47   27343   5417   32759 .FREE.    *
> LINGRP   VM7A48VM7A48   1   30383038 .FREE.    *
> LINGRP   VM7B4A   VM7B4A   11297  21463  32759  .FREE.    *
> * * * End of  File * *  *
>
>
> I believe I should  be able to find 10016 cyls on VM6A47 and on VM7B4A. The 
> AUTHDASD DATADVH file is  as per the defaults * * * so shouldn't restrict the 
> add.
>
>
> Any clues as to what  I have missed ?
>
> Thanks
>
>
>
>
>
>
> Jerry  Whitteridge
>
> Mainframe Engineering
>
> Safeway Inc
>
> 925 951 4184
>
> [EMAIL PROTECTED]
>
>
> "Email Firewall" made the following annotations.
> --
>
>  Warning:  All e-mail sent to this address will be received by the corporate 
> e-mail system, and is subject to archival and review by someone other than 
> the recipient.  This e-mail may contain proprietary information and is 
> intended only for the use of the intended recipient(s).  If the reader of 
> this message is not the intended recipient(s), you are notified that you have 
> received this message in error and that any review, dissemination, 
> distribution or copying of this message is strictly prohibited.  If you have 
> received this message in error, please notify the sender immediately.
> ==
>
>
>
>



-- 
Kris Buelens,
IBM Belgium, VM customer support


Dirmaint woes

2007-12-17 Thread Jerry Whitteridge
I'm trying to add an new user having implemented Dirmaint and get a
failure for no gap of sufficient size :
 
 DVHREQ2288I Your ADD request for SLMGSB22 at * has been accepted.

 DVHBIU3450I The source for directory entry SLMGSB22 has been updated.

 DVHBIU3424I The next ONLINE will take place immediately.

 DVHDRC3451I The next ONLINE will take place via delta object directory.

 DVHBIU3428I Changes made to directory entry SLMGSB22 have been placed

 DVHBIU3428I online.

 DVHSCU3541I Work unit 17123620 has been built and queued for
processing.   
 DVHSHN3541I Processing work unit 17123620 as MAINT from VT01,

 DVHSHN3541I notifying MAINT at VT01, request 141.1 for SLMGSB22
sysaffin   
 DVHSHN3541I *; to: AMDISK 0100 3390 AUTOG 10016 LINGRP MR

 DVHALC3297E No gap of sufficient size found in candidate area(s).

 DVHAMD3298E DASD allocation attempt failed.

 DVHAMD3298E For: SLMGSB22 0100 Request: 3390 AUTOG 10016 LINGRP MR

 DVHSRL3414I Workunit 17123620 has failed.  It is being saved as
17123620   
 DVHSRL3414I WUCFFAIL.

 
I am trying to add the user with a prototype using the following
definition:
 
0 * * * Top of File * * *
1 USER LINUX NOLOG 512M 2G G 
2 INCLUDE LNXDFLT
3 OPTION APPLMON 
4 MDISK 100 3390 AUTOG 10016 LINGRP MR   
5 * DISK 101 VDISK FOR SWAPGEN   
6 * DISK 102 VDISK FOR SWAPGEN   
7   MINIOPT NOMDC
 
The extent control file contains:
 
00037 :REGIONS.

00038   *RegionId  VolSerRegStart  RegEnd  Dev-Type  Comments

00039 VM7A4A   VM7A4A   1  END 3390-32K  Linux Disk

00040 VM7A47   VM7A47   1  END 3390-32K  Linux Disk

00041 VM7A48   VM7A48   1  END 3390-27   Linux Disk

00042 VM7B4A   VM7B4A   1  END 3390-27  Linux Disk

00043 :END.

00044 :GROUPS.

00045   *GroupName RegionList

00046 LINGRP (ALLOCATE ROTATING)

00047 LINGRP VM7A4A VM7A47 VM7A48 VM7B4A

00048 :END.

00049 :EXCLUDE.

00050 * USERID ADDRESS

00051 :END.

00052 :AUTOBLOCK.

00053   * IBM supplied defaults are contained in the AUTOBLK DATADVH
file.  
00054   * The following are customer overrides and supplements.

00055   *

00056   *DASDType BlockSize Blocks/Unit Alloc_Unit Architecture

00057 :END.

00058 :DEFAULTS.

00059   * IBM supplied defaults are contained in the DEFAULTS DATADVH
file. 
00060   * The following are customer overrides and supplements.

00061   *

00062   *DASDType Max-Size

00063 339032760

00064 3390-9  10017

00065 3390-27 32760

00066 :END.

 
and when I issue the DIRM FREE GROUPS= LINGRP I get the following
 
FREEXT GROUP= LINGRP

 

  GROUP   REGION  VOLUMESTART  SIZE   (END) OWNER  ADDR
SA   
  -- -- -- --  

 

LINGRP   VM7A47   VM7A47  1  18228  18228 .FREE.   
*   
LINGRP   VM7A47   VM7A47  27343   5417  32759 .FREE.   
*   
LINGRP   VM7A48   VM7A48  1   3038   3038 .FREE.   
*   
LINGRP   VM7B4A   VM7B4A  11297  21463  32759 .FREE.   
*   
* * * End of File * * *

 
 
I believe I should be able to find 10016 cyls on VM6A47 and on VM7B4A.
The AUTHDASD DATADVH file is as per the defaults * * * so shouldn't
restrict the add.  
 
 
Any clues as to what I have missed ? 
 
Thanks
 
 
 
 

 Jerry Whitteridge

Mainframe Engineering

Safeway Inc

925 951 4184

[EMAIL PROTECTED]

 

"Email Firewall" made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended recipient(s), you are notified that you have received this 
message in error and that any review, dissemination, distribution or copying of 
this message is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately.   
 
==


Re: z/VM 5.3 FLIST

2007-12-17 Thread Mike Walter
>IBM PCOMM, of course!  :-)  I get any size I want by editing the .ws file 

and manually filling in the height and width. 
> The standard pull-down on the configuration GUI limits you to the 1980s. 
 :-(
Thanks, Alan!
IIRC, sometime in the distant past IBM PComm's pull-down had the 
capability to permit fill-in-the-blank as well as the standard Models 
2/3/4/5. 
Or maybe that was an OS/2 thing (talk about "distant past!").

I'll have to set up a separate .ws file for Model 5+ (133 across, 42 
down)!

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.

(Sent in "plain-text", as requested.)



"Alan Altmark" <[EMAIL PROTECTED]> 

Sent by: "The IBM z/VM Operating System" 
12/17/2007 08:49 AM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: z/VM 5.3 FLIST






On Friday, 12/14/2007 at 01:27 EST, "Schuh, Richard" <[EMAIL PROTECTED]> 
wrote:
> 40x90 is not even an option offered by my emulator. What one do you use
> and what other exotic sizes does it support?

IBM PCOMM, of course!  :-)  I get any size I want by editing the .ws file 
and manually filling in the height and width.  The standard pull-down on 
the configuration GUI limits you to the 1980s.  :-(

I see that Seagull's Bluezone emulator includes a Custom option on the GUI 

that lets you fill in the dimensions of BOTH the primary and alternate 
screen sizes.  (Though I shudder to think of how apps will respond to an 
alternate screen size of other than 24x80!  It's not like they query the 
dimensions of anything)  Bluezone supports a maximum configuration of 
98x160.  But that's ok -- I noticed last week XEDIT has a limit of 255 
columns!

Alan Altmark
z/VM Development
IBM Endicott




 
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

2007-12-17 Thread Alan Altmark
On Saturday, 12/15/2007 at 10:25 EST, Phil Smith III 
<[EMAIL PROTECTED]> wrote:

> Do you know anyone in VM development?

Yes, though they won't admit it.

> >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.
> 
> Nice idea, but unrealistic, since 24x80 is the alternate (should have 
been 
> "alternative") size by default.  I've spent decades designing screens 
knowing 
> that I have to fit in 24x80; would that I could do otherwise.  But I've 
been to 
> far too many customer sites where they have no idea how to configure 
their 
> emulator and/or they're going through some VTAM that won't accommodate a 
weird 
> size...

I didn't mean to suggest that people shouldn't be free to limit themselves 
to a measly 24x80 or live with the restrictions imposed by some hidebound 
VTAM sysprogs, but that the programs should advantage themselves of the 
any additional real estate the Wise user has configured.

Hmmm I wonder if the 3270 CREATE PARTITION outbound structured field 
will override the emulator configuration hmmm. 
bwahahahahaaa!

Alan Altmark
z/VM Development
IBM Endicott


Re: z/VM 5.3 FLIST

2007-12-17 Thread Alan Altmark
On Friday, 12/14/2007 at 01:27 EST, "Schuh, Richard" <[EMAIL PROTECTED]> 
wrote:
> 40x90 is not even an option offered by my emulator. What one do you use
> and what other exotic sizes does it support?

IBM PCOMM, of course!  :-)  I get any size I want by editing the .ws file 
and manually filling in the height and width.  The standard pull-down on 
the configuration GUI limits you to the 1980s.  :-(

I see that Seagull's Bluezone emulator includes a Custom option on the GUI 
that lets you fill in the dimensions of BOTH the primary and alternate 
screen sizes.  (Though I shudder to think of how apps will respond to an 
alternate screen size of other than 24x80!  It's not like they query the 
dimensions of anything)  Bluezone supports a maximum configuration of 
98x160.  But that's ok -- I noticed last week XEDIT has a limit of 255 
columns!

Alan Altmark
z/VM Development
IBM Endicott


Re: VM 5.2 using Racf can you password protect an individual file?

2007-12-17 Thread David Boyes
While not exactly what you asked for, one alternative might be to use
Ken Chamberlain's LIB tool and hardcode the passwords into a compiled
exec.  LIB allows storing the exec in a separate virtual machine and
transferring it into the user's virtual machine directly into memory, so
no "file" copy actually exists in the user's virtual machine (and no
LINK required). LIB provides security levels, some forms of password
control, version control, and is a fantastic example of how to use IUCV
to move data really, really fast between systems. (It's remarkably
useful for maintaining common minidisks or software collections as well
as it's original purpose of maintaining COPYLIB members). Execution of
FTP would then look like 'LIB EXEC SOMEFTP EXEC' with all the parameters
self contained; no copy of the exec or data is ever accessible to the
user outside program execution. 

 

You might also be able to use LIB to just maintain the NETRC file and
retrieve it onto a CMS RAMDISK (thanks, Arty!). While not as secure as
the exec approach (a clever user could get at the file if they could
escape from the FTP client), at least it would give you more
sophisticated control of the file itself and not rely on public access
to the file. 

 

Neither method involves RACF, but RACF support could easily be added to
LIB if someone really wanted it. 

 

LIB should be available on the VM Workshop tapes available in various
places around the net.