INFO-VAX Sat, 24 Nov 2007 Volume 2007 : Issue 644 Contents: Re: Getting Fortran to read CTRL/Z in a file as data Handling large numbers in DCL Re: Handling large numbers in DCL Re: Handling large numbers in DCL ---------------------------------------------------------------------- Date: Sat, 24 Nov 2007 06:30:34 -0800 (PST) From: Steve Lionel Subject: Re: Getting Fortran to read CTRL/Z in a file as data Message-ID: <3d74866b-76ab-4839-9cb0-df510feded00@j20g2000hsi.googlegroups.com> On Nov 21, 1:19 pm, bri...@encompasserve.org wrote: > I don't know chapter and verse (presumably Steve Lionel does), but if > the Fortran spec requires an end-of-file record as a concept distinct > from physical end-of-file on the media and if you're going to emulate > such a record under VMS, using a one byte record containing control-Z is > as good a choice as any and better than most. The concept of an ENDFILE record derives from "tape marks" on magnetic tapes. Reading a tape-mark generates an end-of-file condition, but programs often were written to continue reading past these. In Fortran, an ENDFILE record has the appearance of an actual record - for example, you can BACKSPACE over it - but it need not be implemented by any physical encoding. I don't know the origins of the DEC extension of embedding ENDFILE records in a file - it predates me - but I know there are VMS programs that depend on it even today (about once or twice a year I see gripes from people moving to Intel Fortran from VMS and wanting this behavior, which we do support with an option.) The use of a single-byte CTRL-Z is fine for "SEGMENTED" unformatted files, as you can't write such a record in any other way. But for other record types, one can write such a record. If someone asked me today about this, I'd recommend against implementing such a feature for other record types. I wish I could suggest a compiler option for you to disable this, but I don't know of one for the VMS compilers. I don't think we had one back when I was working on them. Steve ------------------------------ Date: Sat, 24 Nov 2007 08:33:16 -0500 From: JF Mezei Subject: Handling large numbers in DCL Message-ID: Same results on VAX 7.3 and Alpha 8.3 $ tot = f$getdvi("$11$dqa0","MAXBLOCK") $ show symbol tot TOT = 58633344 Hex = 037EAC80 Octal = 00337526200 $ used = tot - f$getdvi("$11$dqa0","FREEBLOCKS") $ show symbol used USED = 21928928 Hex = 014E9BE0 Octal = 00123515740 $ percent = used * 100 / tot $ show symbol percent PERCENT = -35 Hex = FFFFFFDD Octal = 37777777735 After some testing, I have found that the largest number DCL can handle is A = 2147483647 Hex = 7FFFFFFF Octal = 17777777777 (2^31 - 1) How do folks deal with this issue ? I am dealing with 18 gig drives here, and I suspect that those with bigger drives would encounter such issues much more. What happens when disks contain a MAXBLOCK value that is greater than 2^31 - 1 ? Does it return a negative value ? In my case, I am thinking about testing the value of "used" against 0x7FFFFFFF / 100, and if greater, then I know I can't multiply it by 100 and would then need to divide both "used" and "tot" by 100 before executing the ration on them ------------------------------ Date: Sat, 24 Nov 2007 06:03:21 -0800 (PST) From: Hein RMS van den Heuvel Subject: Re: Handling large numbers in DCL Message-ID: <53fe270a-b1fc-4c50-b99d-9bc16fb29dc7@b40g2000prf.googlegroups.com> On Nov 24, 8:33 am, JF Mezei wrote: > Same results on VAX 7.3 and Alpha 8.3 No duh! It's by law. > $ percent = used * 100 / tot > $ show symbol percent > PERCENT = -35 Hex = FFFFFFDD Octal = 37777777735 > > After some testing, I have found that the largest number DCL can handle is > > A = 2147483647 Hex = 7FFFFFFF Octal = 17777777777 (2^31 - 1) And you only now found out about this? Jeez.... > How do folks deal with this issue ? We use 'advanced' math. > What happens when disks contain a MAXBLOCK value that is greater than > 2^31 - 1 ? Does it return a negative value ? That would be why the maximum volume size in OpenVMS is limited to 1TB (1024*1024*1024). > > In my case, I am thinking about testing the value of "used" against > 0x7FFFFFFF / 100, and if greater, then I know I can't multiply it by 100 > and would then need to divide both "used" and "tot" by 100 before > executing the ration on them Think about it for a moment my friend. Think back to 4th grade primary school a*b/c = a*(b/b) / (c/b) = a / ( c / b ) in your case: $ IF tot > 100000 ! MD, LD devices? $ THEN $ percent = used / ( tot / 100 ) $ ELSE $ percent = used * 100 / tot $ ENDIF Cheers, Hein ------------------------------ Date: Sat, 24 Nov 2007 09:27:06 -0500 From: bradhamilton Subject: Re: Handling large numbers in DCL Message-ID: <474834BA.7010304@comcast.net> JF Mezei wrote: > Same results on VAX 7.3 and Alpha 8.3 > > $ tot = f$getdvi("$11$dqa0","MAXBLOCK") > $ show symbol tot > TOT = 58633344 Hex = 037EAC80 Octal = 00337526200 > > $ used = tot - f$getdvi("$11$dqa0","FREEBLOCKS") > $ show symbol used > USED = 21928928 Hex = 014E9BE0 Octal = 00123515740 > > $ percent = used * 100 / tot > $ show symbol percent > PERCENT = -35 Hex = FFFFFFDD Octal = 37777777735 > After some testing, I have found that the largest number DCL can handle is > > A = 2147483647 Hex = 7FFFFFFF Octal = 17777777777 > (2^31 - 1) > > How do folks deal with this issue ? I am dealing with 18 gig drives > here, and I suspect that those with bigger drives would encounter such > issues much more. I used to have some DCL to deal with this issue at my last IT job, and some of my customer sites had large disks to deal with. The DCL I was "given" was written with smaller disks in mind, and I know I had to make adjustments to deal with larger-disk "cases". I re-wrote the DCL to handle "all" cases, but unfortunately, I did not save a copy to take home with me after I was laid off. Check dcl.openvms.org for some examples of general-case disk capacity DCL that you could adapt for use (search for "disk" using the handy search facility provided). I have 72G drives, and I have no worries with this issue at present - then again, I'm just a hobbyist. > What happens when disks contain a MAXBLOCK value that is greater than > 2^31 - 1 ? Does it return a negative value ? > Well, by some rough "back of the envelope calculations", drives would have to be close to 1 TB each to approach this limit. Such drives are possible (especially with FC products like XP?), but the mind boggles trying to imagine a system that would approach, say, +10 (or +100) TB of data storage, and the system manager that would be concerned that his/her storage needs are approaching that capacity! > In my case, I am thinking about testing the value of "used" against > 0x7FFFFFFF / 100, and if greater, then I know I can't multiply it by 100 > and would then need to divide both "used" and "tot" by 100 before > executing the ration on them ------------------------------ End of INFO-VAX 2007.644 ************************