0 INFO-VAX	Sun, 29 Jan 2006	Volume 2006 : Issue 57      Contents:) Re: forgetting my DCL: what am I missing? ) Re: forgetting my DCL: what am I missing? ) Re: forgetting my DCL: what am I missing? ) Re: forgetting my DCL: what am I missing? , Re: Here it is: OpenVMS/Alpha on a simulator, Re: Here it is: OpenVMS/Alpha on a simulator, Re: Here it is: OpenVMS/Alpha on a simulator& Re: Intel/Hp spend $10 billion on IA64# Re: Looking for .ISO files for SIMH   F ----------------------------------------------------------------------  % Date: Sat, 28 Jan 2006 16:23:09 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>2 Subject: Re: forgetting my DCL: what am I missing?+ Message-ID: <43DBEECC.445E8513@comcast.net>   
 AEF wrote: >  > Ken Fairfield wrote:
 > > [snip]D > > Yes, we traced this down to the way DCL expands the command lineH > > to include a space between the last parameter of the expanded symbolI > > and the supplied qualifier.  And yes, that is just the way the people G > > who wrote DCL wrote it.  But the *point* is that added space during G > > symbol expansion is *not* an issue either for (a) a native DCL verb D > > with its parameters and qualifiers, or (b) a program that uses aF > > .CLD to define its syntax and LIB$DCL_PARSE, for example, to parseE > > the command line.  It becomes an issue when the program defines a H > > syntax that appears to be DCL, i.e., because it uses slash-delimitedJ > > "qualifiers", but it doesn't behave like DCL because it makes implicitC > > assumptions about the command-line tokens it will receive...and B > > parse...that DCL doesn't do, i.e., requiring a qualifier to beC > > "attached" to the 2nd parameter instead standing by itself as a  > > 3rd blank-delimited token. > G > I thought the point was why the extra space is added. Anyway, perhaps  > that's nitpicking. > I > Anyway, I checked the User's Manual and the instructions for defining a G > foreign command do not say anything about including parameters in the G > defitinion. The format clearly shows only the file-spec for the image I > *without* any parameters. So, strictly speaking, we are in undocumented G > territory here. Now this question of the extra space is actually more  > general in scope. Consider > % >     $ DIR:==DIRECTORY/SIZE/DATE/SEC  >     $ DIR.OBJ  > ? > For some reason, this actually works. In the second line, DCL H > interprets DIR as the command verb, performs symbol substitution, adds > the "space", and runs  > $ >     $ DIRECTORY/SIZE/DATE/SEC .OBJ > I > So I think this is really the question that Phillip was asking. I don't A > know the answer. Perhaps there was some perceived need for this  > behavior at one point.  G Indeed. The documentation does not cover this level of detail; however, & consider this foreign command exmaple:  . $ UNZIP :== $ddcu:<dir>UNZIP	! or use DCL$PATH $ UNZIP/LIST archive_spec   G Apparently, DCL sees the "/" character, detects that its ASCII value is H less than "A", and interprets the characters up to but not including theE "/" as a "token" it should treat as either a verb name, a symbol name H (for foreign commands) or a file name which it should use to seek either a .COM or a .EXE via DCL$PATH.   Another example:   $ fsp := myfile.dat  $ del/lo &fsp;  G This command works as expected. The symbol named "FSP" is evaluated and F the contents inserted into the command buffer. Processing continues byH inserting the ";" at the next position in the command buffer. The entire9 command buffer is then processed as usual. It expands to:    $ DEL/LO MYFILE.DAT;  C Clearly, the ";" delimits the symbol name and DCL uses that name to 1 locate the symbol. ";" is less than an ASCII "A".   ' This behavior appears to be consistent.   < As to the insertion of a space, that is a bit more puzzling.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Sat, 28 Jan 2006 19:55:27 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>2 Subject: Re: forgetting my DCL: what am I missing?- Message-ID: <43DC1274.1CDAFFDD@vaxination.ca>    David J Dachtera wrote: > > As to the insertion of a space, that is a bit more puzzling.  9 Looking back at the story, there may be some consistency.   E The first "token" in a line is treated differently because DCL checks D for a non explicit symbol substitution (whether a foreign command orF just a command redefinition). The rest of the line is checked only forD explicit symbols (eg: use of & or ' to request symbol substitution).  F For a non explicit symbol substitution the space is probably added forH safety to prevent the rest of the line from changing the actual command.E (think ambiguous commands). the addition of the space ensure that the 1 translated command remains by itself on the line.    ------------------------------    Date: 28 Jan 2006 20:02:30 -0800$ From: "AEF" <spamsink2001@yahoo.com>2 Subject: Re: forgetting my DCL: what am I missing?C Message-ID: <1138507350.758178.169490@g49g2000cwa.googlegroups.com>    David J Dachtera wrote:  > AEF wrote: > >  > > Ken Fairfield wrote: > > > [snip]F > > > Yes, we traced this down to the way DCL expands the command lineJ > > > to include a space between the last parameter of the expanded symbolK > > > and the supplied qualifier.  And yes, that is just the way the people I > > > who wrote DCL wrote it.  But the *point* is that added space during I > > > symbol expansion is *not* an issue either for (a) a native DCL verb F > > > with its parameters and qualifiers, or (b) a program that uses aH > > > .CLD to define its syntax and LIB$DCL_PARSE, for example, to parseG > > > the command line.  It becomes an issue when the program defines a J > > > syntax that appears to be DCL, i.e., because it uses slash-delimitedL > > > "qualifiers", but it doesn't behave like DCL because it makes implicitE > > > assumptions about the command-line tokens it will receive...and D > > > parse...that DCL doesn't do, i.e., requiring a qualifier to beE > > > "attached" to the 2nd parameter instead standing by itself as a   > > > 3rd blank-delimited token. > > I > > I thought the point was why the extra space is added. Anyway, perhaps  > > that's nitpicking. > > K > > Anyway, I checked the User's Manual and the instructions for defining a I > > foreign command do not say anything about including parameters in the I > > defitinion. The format clearly shows only the file-spec for the image K > > *without* any parameters. So, strictly speaking, we are in undocumented I > > territory here. Now this question of the extra space is actually more  > > general in scope. Consider > > ' > >     $ DIR:==DIRECTORY/SIZE/DATE/SEC  > >     $ DIR.OBJ  > > A > > For some reason, this actually works. In the second line, DCL J > > interprets DIR as the command verb, performs symbol substitution, adds > > the "space", and runs  > > & > >     $ DIRECTORY/SIZE/DATE/SEC .OBJ > > K > > So I think this is really the question that Phillip was asking. I don't C > > know the answer. Perhaps there was some perceived need for this  > > behavior at one point. > I > Indeed. The documentation does not cover this level of detail; however, ( > consider this foreign command exmaple: > 0 > $ UNZIP :== $ddcu:<dir>UNZIP	! or use DCL$PATH > $ UNZIP/LIST archive_spec  > I > Apparently, DCL sees the "/" character, detects that its ASCII value is J > less than "A", and interprets the characters up to but not including theG > "/" as a "token" it should treat as either a verb name, a symbol name J > (for foreign commands) or a file name which it should use to seek either  > a .COM or a .EXE via DCL$PATH.  B This behavior is, in fact, "documented" (well, to be more precise,G alluded to) in the User's Manual under Automatic Foreign Commands in an  example.   > Another example: >  > $ fsp := myfile.dat  > $ del/lo &fsp; > I > This command works as expected. The symbol named "FSP" is evaluated and H > the contents inserted into the command buffer. Processing continues byJ > inserting the ";" at the next position in the command buffer. The entire; > command buffer is then processed as usual. It expands to:  >  > $ DEL/LO MYFILE.DAT; > E > Clearly, the ";" delimits the symbol name and DCL uses that name to 3 > locate the symbol. ";" is less than an ASCII "A".  > ) > This behavior appears to be consistent.    Good point.    > > > As to the insertion of a space, that is a bit more puzzling.  A Well. I think it might be to ensure that everything following the B foreign command is interpreted as parameters. After all, qualfiersD starting with slashes don't really mean anything until parsed by theD program, so they might as well be parsed as parameters. Putting thatD extra space in ensures that any parameters are not absorbed into theF command verb. Well**2, that still seems a little "ad hoc". But I thinkE it may make at least a little more sense to consider this extra space E in the context of the evolution of DCL. DCL as it exists today wasn't C designed in one grand project; it evolved over the years as various F features were added and some changes were made. And evolution producesG a thing that in general will be different from what that thing would be E if it were designed all at once from the outset, so to speak. Combine F that with not wanting to break command procedures with new versions of: DCL and this is what you get. Just speculation, of course.   AEF    >  > -- > David J Dachtera > dba DJE Systems  > http://www.djesys.com/ > ( > Unofficial OpenVMS Marketing Home Page# > http://www.djesys.com/vms/market/  > * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/  > $ > Unofficial OpenVMS-IA32 Home Page:! > http://www.djesys.com/vms/ia32/  > + > Unofficial OpenVMS Hobbyist Support Page: $ > http://www.djesys.com/vms/support/   ------------------------------    Date: 28 Jan 2006 20:13:20 -0800$ From: "AEF" <spamsink2001@yahoo.com>2 Subject: Re: forgetting my DCL: what am I missing?C Message-ID: <1138508000.254470.206580@g49g2000cwa.googlegroups.com>    JF Mezei wrote:  > David J Dachtera wrote: @ > > As to the insertion of a space, that is a bit more puzzling. > ; > Looking back at the story, there may be some consistency.  > G > The first "token" in a line is treated differently because DCL checks F > for a non explicit symbol substitution (whether a foreign command orH > just a command redefinition). The rest of the line is checked only forF > explicit symbols (eg: use of & or ' to request symbol substitution).  D Please keep in mind that apostrophe substitution happens entirely inC phase 1. In this phase, the command string is simply a text string. B Ampersand substitution happens in phase 2 in which at least *some*G structure has been imposed on the "text string". My evidence to support 3 this statement is that the following example works:    $ DT="2-JAN 23:33" $ DIRECTORY/SINCE=&DT/DATE/SIZE   > Note that this cannot be purely a text string during ampersandD substitution because it works without the quotation marks that wouldG normally be needed to tell the command interpreter that a date and time D separated by a space is the single argument of the /SINCE qualifier.A This structure has been imposed on the command *before* ampersand F substitution occurs (which is consistent with the User's Manual). Yet,= it is text-string enough (well, the parameters are still text * string-ish) so that David's recent example   $ fsp := myfile.dat  $ del/lo &fsp;   also works.   H > For a non explicit symbol substitution the space is probably added forJ > safety to prevent the rest of the line from changing the actual command.G > (think ambiguous commands). the addition of the space ensure that the 3 > translated command remains by itself on the line.   G Yes, I think this statement is quite relevant, especially with the fact E that DCL, in phase 2, uses the first illegal symbol-name character to 9 determine the end of the first token on the command line.    AEF    ------------------------------  % Date: Sat, 28 Jan 2006 16:07:33 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>5 Subject: Re: Here it is: OpenVMS/Alpha on a simulator + Message-ID: <43DBEB25.978756D8@comcast.net>    Dave Froble wrote: >  > David J Dachtera wrote:  > > Bill Gunshannon wrote:
 > > [snip] > >>F > >>Except that the market is much more likely to be those who are not > >>willing  > >  > > 1 > > ...or able, due to ISV abandonment of VMS ...  > >  > > @ > >>to move to that IA64 thing but want to remain on VMS.  ThoseH > >>who are willing to move to an IA64 box that is running VMS will justH > >>port their applications to native mode. (I know about certification,H > >>but if they move to an Alpha emulator on IA64 they would have to re- > >>certify as well.)  > >  > > K > > Assuming one has the source code, or that the existing VAX/Alpha images 3 > > can be translated. If neither, then guess what?  > >  > # > I get some VMS work??????????????   H Non capisco. If you don't have the source code, and you can't translate, you're screwed.   * How does that translate to an opportunity?  G (Not intentionally being negative here, just playing devil's advocate.)   B ...unless a keystone of your business is to "unassemble" VAX/AlphaE images into source code that can be recompiled/linked on I64, even if A maintenance/modification is rather more challenging from then on.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Sat, 28 Jan 2006 16:11:16 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>5 Subject: Re: Here it is: OpenVMS/Alpha on a simulator + Message-ID: <43DBEC04.4E3A6383@comcast.net>    S wrote: >  > David J Dachtera wrote:  > > S wrote:K > >>"To help you decide about Alpha emulation we have created PersonalAlpha E > >>that is proof that this concept works. PersonalAlpha is a special K > >>VirtualAlpha version that runs on your standard 32 bit laptop or PC and ? > >>shows you Alpha virtualization at work. It provides limited L > >>functionality and performance compared to its 64 bit family members, but2 > >>it is not meant for production installations." > >  > > G > > I don't think anyone needs to "decide" about Alpha emulation - this K > > group has been looking for it almost since the dawn of PicoVAX (Yes - I # > > *KNOW* that's a VAX emulator!).  > H > Note that one has to decide by looking at a "limited functionality andI > performance" version. I hope it's not like you'd decide for your mobile ' > phone by trying the plastic mockup...   = Exactly my point. If your application, etc. won't run in 96MB   (0.0937GB), how do you evaluate?   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Sat, 28 Jan 2006 18:41:39 -0500 ' From: Dave Froble <davef@tsoft-inc.com> 5 Subject: Re: Here it is: OpenVMS/Alpha on a simulator 9 Message-ID: <vM2dnWqLlq-YnEHenZ2dnUVZ_tGdnZ2d@libcom.com>    David J Dachtera wrote:  > Dave Froble wrote: >  >>David J Dachtera wrote:  >> >>>Bill Gunshannon wrote: 	 >>>[snip]  >>> F >>>>Except that the market is much more likely to be those who are not >>>>willing  >>>  >>> 0 >>>...or able, due to ISV abandonment of VMS ... >>>  >>>  >>> @ >>>>to move to that IA64 thing but want to remain on VMS.  ThoseH >>>>who are willing to move to an IA64 box that is running VMS will justH >>>>port their applications to native mode. (I know about certification,H >>>>but if they move to an Alpha emulator on IA64 they would have to re- >>>>certify as well.)  >>>  >>> J >>>Assuming one has the source code, or that the existing VAX/Alpha images2 >>>can be translated. If neither, then guess what? >>>  >># >>I get some VMS work??????????????  >  > J > Non capisco. If you don't have the source code, and you can't translate, > you're screwed.   D Ever hear of design and implement software?  If the desired goal is E known, then new programming is an option.  Not everything ever to be   needed is already written.  , > How does that translate to an opportunity?  H I and others could gather the specs, requirements, and such, design the = application, and write the software.  There are a few actual  $ programmers/analysts/designers left.  I > (Not intentionally being negative here, just playing devil's advocate.)  > D > ...unless a keystone of your business is to "unassemble" VAX/AlphaG > images into source code that can be recompiled/linked on I64, even if C > maintenance/modification is rather more challenging from then on.  >   E Perhaps a modern implementation of the solution would be better than   what it's replacing.   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Sat, 28 Jan 2006 21:00:19 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>/ Subject: Re: Intel/Hp spend $10 billion on IA64 + Message-ID: <43DC2FC3.229FBBEB@comcast.net>    FredK wrote: > 7 > "Bill Gunshannon" <bill@cs.uofs.edu> wrote in message ( > news:43upnbF1pm66dU1@individual.net... > 5 > >  One thing has to be kept in sight, while the way D > > things sit right now the failure of Itanium means the failure of- > > VMS, the inverse is not necessarily true.  > L > With this, I agree.  So if you want to ensure the failure of VMS, root for > the failure of Itanium.   C That's probably about as close as we can expect to come as far as a G statement regarding VMS's fate if HP can't sell I64 to the industry. If = "the world" goes x86-64, VMS goes bye-bye, according to Fred.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Sat, 28 Jan 2006 21:06:16 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>, Subject: Re: Looking for .ISO files for SIMH+ Message-ID: <43DC3127.A62965CA@comcast.net>    rcyoung wrote: > A > I took a VMS 6 and a VMS 7 install CD, and used the Mac/X "disk B > utility" to make a disk image (compression off). SIMH on Mac andI > windows had no problem with the resulting file.  I was able to boot and  > install VMS.  $ An alternate method for VMS systems:    1. MOUNT the CD drive /FOREIGN *  2. COPY from the CD drive to a disk file.>     The COPY will complete with an illegal block number error B     (trying to read past the end of the physical medium); however,/     the image file will be complete and intact. 7  3. FTP the image file as binary to the target machine.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------   End of INFO-VAX 2006.057 ************************