Re: Can c89 create a loadlib member?
I'm using the OS simulation LOAD macro to load assembler modules which ar e not LE conforming. We're a software vendor and the application will be distributed to customers. I would prefer to distribute everything in a loadlib instead of some parts in a loadlib and some parts as CMS modules.
Re: Backup
Thank you everyone for the feed back. I now have some options to study. prg Phillip Gramly Systems Programmer Communications Data Group Champaign, IL
LPR printing problem
I have set up an LPD on our network with the desired printers. The printer characteristics (font, orientation, etc.) are all set up on the LPD queue (printer name) entries. When printing from VSE, everything is fine. We have specified on the LPD entry to include banners, to print duplex, and to have an initial forms-feed start the start of job. This allows the banner page to eject before printing the report. Otherwise (if NOT utilizing the initial form feed) the first page of the report starts on the BACK of the banner. So, in VSE everything prints correctly. However, when printing from VM (using the LPR command) to the same LPD and same printers, the first page ALWAYS prints on the back of the banner! Is there any way of fixing this? Which VM LPR are you using, RSCS or the TCP/IP LPR command? If RSCS, specify SEP=2P on the link parm. Best Regards, Les Geer IBM z/VM and Linux Development
Re: LPR printing problem
Les: No, I am NOT using the RSCS command - I am using the TCP LPR command. Is there such an option for TCP? Also, since this is supposed to be controlled by the LPD, why would VM's TCPIP cause it to work differently? David Wakser -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) Sent: Wednesday, January 31, 2007 1:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: LPR printing problem I have set up an LPD on our network with the desired printers. The printer characteristics (font, orientation, etc.) are all set up on the LPD queue (printer name) entries. When printing from VSE, everything is fine. We have specified on the LPD entry to include banners, to print duplex, and to have an initial forms-feed start the start of job. This allows the banner page to eject before printing the report. Otherwise (if NOT utilizing the initial form feed) the first page of the report starts on the BACK of the banner. So, in VSE everything prints correctly. However, when printing from VM (using the LPR command) to the same LPD and same printers, the first page ALWAYS prints on the back of the banner! Is there any way of fixing this? Which VM LPR are you using, RSCS or the TCP/IP LPR command? If RSCS, specify SEP=2P on the link parm. Best Regards, Les Geer IBM z/VM and Linux Development
Re: ICKDSF Release 16
We are in the process of 'decommissioning' our mainframe platform (MP3000 runing v/VM 3.1). We formatted all our internal and external DASD (3380s and 3390s) using ICKDSF R16 with the following command: I found this in a recent post by searching the archives at: http://listserv.uark.edu/archives/ibmvm.html Look at ICKDSF TRKFMT FROMRANGE(0,0) ERASEDATA CYCLES(n). It writes a special pattern (as opposed to binary zeroes, I guess). Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
LPR printing problem
Cross-posted to both VM VSE lists. I have set up an LPD on our network with the desired printers. The printer characteristics (font, orientation, etc.) are all set up on the LPD queue (printer name) entries. When printing from VSE, everything is fine. We have specified on the LPD entry to include banners, to print duplex, and to have an initial forms-feed start the start of job. This allows the banner page to eject before printing the report. Otherwise (if NOT utilizing the initial form feed) the first page of the report starts on the BACK of the banner. So, in VSE everything prints correctly. However, when printing from VM (using the LPR command) to the same LPD and same printers, the first page ALWAYS prints on the back of the banner! Is there any way of fixing this? David Wakser InfoCrossing
Re: ICKDSF Release 16
After reviewing the DoD specifications for destruction by overwriting, I would say that your method does not meet them. Specifications are available here: http://www.tricare.mil/tmis_new/ia/02%20-%20Sanitization.pdf , section 3.1.2. They specify that you must overwrite with a pattern, then the complement of the pattern, then with random data. They further specify that you must overwrite the entire disk, independent of any BIOS or firmware capacity that the system may have. Among other things. My question would be, do you really need to meet DoD specifications? If so, you'll probably need something like FDRERASE, which is certified to meet those specifications. Original Message Subject: ICKDSF Release 16 From: Cliff Brenner [EMAIL PROTECTED] Date: Wed, January 31, 2007 4:03 pm To: IBMVM@LISTSERV.UARK.EDU Hi Folks, We are in the process of 'decommissioning' our mainframe platform (MP3000 runing v/VM 3.1). We formatted all our internal and external DASD (3380s and 3390s) using ICKDSF R16 with the following command: CPVOLUME FORMAT UNIT(nnn) NOVERIFY VOLID(Lnnn) - where nnn is the real pack address We formatted most of the packs on VM, then shut down the system and formatted the CP-owned packs using ICKDSF standalone. Now that the work is done, we are getting questions as to whether ICKDSF formatting conforms to certain Department of Defense standards which recommends multiple formats to guarantee all data has been removed. The ICKDSF manual reads that CPVOLUME FORMAT writes CP information to cylinder 0 and then lays out 4K pages on the remaining cylinders. Does anyone know whether this means 4K pages comprising of binary zeroes? Since our DASD are CKD, what happens to any tracks (if any) that don't fall into 4K boundaries? Is formatting a pack once good enough to insure all data is irrecoverable? Any assistance with these questions would be greatly appreciated. Thank you. Cliff Brenner Pace University Computer Systems Dept.
Re: ICKDSF Release 16
I think it varies the pattern for each cycle. IIRC (memories from the 'nam days) the number of cycles had to be at least 8 for any magnetic media that had anything classified written on it at any time. The CAD folks claimed to be able to recover information from several levels deep at that time, so 8 = several + some undisclosed constant. (Did the intelligence services of 1967 presage the vertical recording of today?) If there was nothing classified on the disks the rules were relaxed. You need to use current rules to determine the number of cycles. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Wednesday, January 31, 2007 1:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ICKDSF Release 16 We are in the process of 'decommissioning' our mainframe platform (MP3000 runing v/VM 3.1). We formatted all our internal and external DASD (3380s and 3390s) using ICKDSF R16 with the following command: I found this in a recent post by searching the archives at: http://listserv.uark.edu/archives/ibmvm.html Look at ICKDSF TRKFMT FROMRANGE(0,0) ERASEDATA CYCLES(n). It writes a special pattern (as opposed to binary zeroes, I guess). Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ICKDSF Release 16
Hi Dave, Thanks for your reply. I received a message from Ed Zell re: the ICKDSF TRKFMT command, which allows for an overwrite of special patterns a specified number of times. Do you know if that would serve the same function as FDRERASE? Cliff After reviewing the DoD specifications for destruction by overwriting, I would say that your method does not meet them. Specifications are available here: http://www.tricare.mil/tmis_new/ia/02%20-%20Sanitization.pdf , section 3.1.2. They specify that you must overwrite with a pattern, then the complement of the pattern, then with random data. They further specify that you must overwrite the entire disk, independent of any BIOS or firmware capacity that the system may have. Among other things. My question would be, do you really need to meet DoD specifications? If so, you'll probably need something like FDRERASE, which is certified to meet those specifications. Original Message Subject: ICKDSF Release 16 From: Cliff Brenner [EMAIL PROTECTED] Date: Wed, January 31, 2007 4:03 pm To: IBMVM@LISTSERV.UARK.EDU Hi Folks, We are in the process of 'decommissioning' our mainframe platform (MP3000 runing v/VM 3.1). We formatted all our internal and external DASD (3380s and 3390s) using ICKDSF R16 with the following command: CPVOLUME FORMAT UNIT(nnn) NOVERIFY VOLID(Lnnn) - where nnn is the real pack address We formatted most of the packs on VM, then shut down the system and formatted the CP-owned packs using ICKDSF standalone. Now that the work is done, we are getting questions as to whether ICKDSF formatting conforms to certain Department of Defense standards which recommends multiple formats to guarantee all data has been removed. The ICKDSF manual reads that CPVOLUME FORMAT writes CP information to cylinder 0 and then lays out 4K pages on the remaining cylinders. Does anyone know whether this means 4K pages comprising of binary zeroes? Since our DASD are CKD, what happens to any tracks (if any) that don't fall into 4K boundaries? Is formatting a pack once good enough to insure all data is irrecoverable? Any assistance with these questions would be greatly appreciated. Thank you. Cliff Brenner Pace University Computer Systems Dept.
Re: ICKDSF Release 16
There are at least two potential problems with using FDRERASE. The first is that it REQUIRES a z/OS (maybe OS/390) operating system to run it. This i s not too much of a problem at a Disaster Recovery vendor site but not easy when you are decommissioning your only mainframe. The second problem is t hat some government agencies have chosen to re-interpret DOD guidelines/specifications to be a triple-pass of random data, random data and a known pattern. It may be just as good, but it isn't exactly what ou r security management wants, and this kind of legalistic landmines is the k ind that will HURT you at the worst time. I would love a standalone version of FDRERASE and an option for any versi on of FDRERASE that would let me specify pattern(random,random,x5a5a). /Tom Kern On Wed, 31 Jan 2007 14:34:15 -0700, Dave Reinken [EMAIL PROTECTED] wrote : After reviewing the DoD specifications for destruction by overwriting, I would say that your method does not meet them. Specifications are available here: http://www.tricare.mil/tmis_new/ia/02%20-%20Sanitization.pdf , section 3.1.2. They specify that you must overwrite with a pattern, then the complement of the pattern, then with random data. They further specify that you must overwrite the entire disk, independent of any BIOS or firmware capacity that the system may have. Among other things. My question would be, do you really need to meet DoD specifications? If so, you'll probably need something like FDRERASE, which is certified to meet those specifications.
Re: ICKDSF Release 16
I worked for CAD for a number of years and they NEVER returned used DASD (HDA's in those days) back to the vendor. They were physically destroyed. - Judson West Teradata, a division of NCR Corporation -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, January 31, 2007 1:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ICKDSF Release 16 I think it varies the pattern for each cycle. IIRC (memories from the 'nam days) the number of cycles had to be at least 8 for any magnetic media that had anything classified written on it at any time. The CAD folks claimed to be able to recover information from several levels deep at that time, so 8 = several + some undisclosed constant. (Did the intelligence services of 1967 presage the vertical recording of today?) If there was nothing classified on the disks the rules were relaxed. You need to use current rules to determine the number of cycles. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Wednesday, January 31, 2007 1:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ICKDSF Release 16 We are in the process of 'decommissioning' our mainframe platform (MP3000 runing v/VM 3.1). We formatted all our internal and external DASD (3380s and 3390s) using ICKDSF R16 with the following command: I found this in a recent post by searching the archives at: http://listserv.uark.edu/archives/ibmvm.html Look at ICKDSF TRKFMT FROMRANGE(0,0) ERASEDATA CYCLES(n). It writes a special pattern (as opposed to binary zeroes, I guess). Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ICKDSF Release 16
This may sound crazy but if you really have to meet DOD standards, and if your equipment is old and has no real value, it may be cheaper and faster to remove the disks out of the system and have them destroyed by a certified company. On Wed, 31 Jan 2007 16:03:56 -0500 Cliff Brenner said: Hi Folks, We are in the process of 'decommissioning' our mainframe platform (MP3000 runing v/VM 3.1). We formatted all our internal and external DASD (3380s and 3390s) using ICKDSF R16 with the following command: CPVOLUME FORMAT UNIT(nnn) NOVERIFY VOLID(Lnnn) - where nnn is the real pack address We formatted most of the packs on VM, then shut down the system and formatted the CP-owned packs using ICKDSF standalone. Now that the work is done, we are getting questions as to whether ICKDSF formatting conforms to certain Department of Defense standards which recommends multiple formats to guarantee all data has been removed. The ICKDSF manual reads that CPVOLUME FORMAT writes CP information to cylinder 0 and then lays out 4K pages on the remaining cylinders. Does anyone know whether this means 4K pages comprising of binary zeroes? Since our DASD are CKD, what happens to any tracks (if any) that don't fall into 4K boundaries? Is formatting a pack once good enough to insure all data is irrecoverable? Any assistance with these questions would be greatly appreciated. Thank you. Cliff Brenner Pace University Computer Systems Dept.
Re: ICKDSF Release 16
Thanks for your reply. I received a message from Ed Zell re: the ICKDSF TRKFMT command, which allows for an overwrite of special patterns Cliff, Just to be complete, I was quoting from a previous post that I found in the archives that mentioned ICKDSF TRKFMT. I have no experience with it or knowledge of what should be done to wipe out DASD that you are getting rid of. Sorry for not being clear the first time around. Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ICKDSF Release 16
On Wednesday, 01/31/2007 at 03:57 CST, McKown, John [EMAIL PROTECTED] wrote: Have you looked at SAE? It has a stand-alone ERASE capability. You can even IPL it off of the DVD in the HMC! Or DASD or Tape. I find such products ... interesting. If you look at the S/390 Command Reference for ESS (SHARK), you will find that the ERASE CCW or formatting record 0 of a track are documented to erase data. But when you read what it says about erasure, things get fuzzy. To wit: A record is said to be erased when it is rendered incapable of being read by the commands and facilities normally used for reading recorded data from the device. The manner in which the erase operation is performed is overwriting the record referenced with pad characters and then erasing the remainder of the track. Of course, it uses the word erase in the definition of the operation, so who knows what it will do. Consider, too, that modern drives separate the appearance of ECKD from reality. It can simply mark some metadata that says erased which the microcode will respect. But take the RAID drives out and read them elsewhere, and who knows what you will find. Then there's that nasty word normally used in there. It makes me nervous. And if you have a moving cursor algorithm, rewriting the same record may not, in fact, rewrite the same record. It may get written and then index pointers are updated. I find lots of information about data security erase for tapes, but not for disks. Methinks I must contact a Reverened Engineer to find out what gives these days... Alan Altmark z/VM Development IBM Endicott
Re: ICKDSF Release 16
Hi Ed, I reviewed the TRKFMT parameters you provided in the ICKDSF R16 manual to confirm their function. Thanks to all who have replied to me so far. Please note I no longer have an operating system, so only a standalone utility like ICKDSF would benefit me at this point. Cliff Thanks for your reply. I received a message from Ed Zell re: the ICKDSF TRKFMT command, which allows for an overwrite of special patterns Cliff, Just to be complete, I was quoting from a previous post that I found in the archives that mentioned ICKDSF TRKFMT. I have no experience with it or knowledge of what should be done to wipe out DASD that you are getting rid of. Sorry for not being clear the first time around. Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED]
Re: ICKDSF Release 16
Perfectly clear to me. When you erase a disk, ... you erase it. What else would you do? :-) Precisely why our storage management group does whatever it is that they do to decommission disks and then contracts with the disk manufacturers to destroy them. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Wednesday, January 31, 2007 2:23 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ICKDSF Release 16 On Wednesday, 01/31/2007 at 03:57 CST, McKown, John [EMAIL PROTECTED] wrote: Have you looked at SAE? It has a stand-alone ERASE capability. You can even IPL it off of the DVD in the HMC! Or DASD or Tape. I find such products ... interesting. If you look at the S/390 Command Reference for ESS (SHARK), you will find that the ERASE CCW or formatting record 0 of a track are documented to erase data. But when you read what it says about erasure, things get fuzzy. To wit: A record is said to be erased when it is rendered incapable of being read by the commands and facilities normally used for reading recorded data from the device. The manner in which the erase operation is performed is overwriting the record referenced with pad characters and then erasing the remainder of the track. Of course, it uses the word erase in the definition of the operation, so who knows what it will do. Consider, too, that modern drives separate the appearance of ECKD from reality. It can simply mark some metadata that says erased which the microcode will respect. But take the RAID drives out and read them elsewhere, and who knows what you will find. Then there's that nasty word normally used in there. It makes me nervous. And if you have a moving cursor algorithm, rewriting the same record may not, in fact, rewrite the same record. It may get written and then index pointers are updated. I find lots of information about data security erase for tapes, but not for disks. Methinks I must contact a Reverened Engineer to find out what gives these days... Alan Altmark z/VM Development IBM Endicott
Re: ICKDSF Release 16
On 1/31/07, Alan Altmark [EMAIL PROTECTED] wrote: I find lots of information about data security erase for tapes, but not for disks. So, that leaves him the option to DDR from disk to tape, and then security erase those tapes. ;-) Rob
