INFO-VAX Wed, 14 Nov 2007 Volume 2007 : Issue 624 Contents: Alphaservers and HP integrity servers Re: Alphaservers and HP integrity servers Re: Alphaservers and HP integrity servers Re: Alphaservers and HP integrity servers Re: Alphaservers and HP integrity servers Re: Alphaservers and HP integrity servers Re: Alphaservers and HP integrity servers Re: Alphaservers and HP integrity servers Re: Alphaservers and HP integrity servers Re: SYS$GRANT_LICENSE output codes Re: SYS$GRANT_LICENSE output codes Re: SYS$GRANT_LICENSE output codes TCPIP SMTP and/or BIND Resolver bug Re: TCPIP SMTP and/or BIND Resolver bug ---------------------------------------------------------------------- Date: Wed, 14 Nov 2007 03:33:10 -0800 From: "mb301@hotmail.com" Subject: Alphaservers and HP integrity servers Message-ID: <1195039990.848737.292940@19g2000hsx.googlegroups.com> Please could someone assist here:- If I write, link and complie a C or Cobol program on Alphaserver to make an image ".exe" will the ".exe" work on the new platform? (non- privileged type coding) un-modified or do you have to review update and re-complie your program again thus having two programs of the same name? Kind regards ------------------------------ Date: Wed, 14 Nov 2007 11:41:04 -0000 From: Hein RMS van den Heuvel Subject: Re: Alphaservers and HP integrity servers Message-ID: <1195040464.536577.42140@50g2000hsm.googlegroups.com> On Nov 14, 6:33 am, "mb...@hotmail.com" wrote: : > If I write, link and complie a C or Cobol program on Alphaserver to > make an image ".exe" will the ".exe" work on the new platform? You'll have to recompile and relink, so you will have two sets of objects and executables. For sake of completeness, that are binary translators, but if you have the source handy, then you really should update that (if needed) to be acceptable for both systems and re-compile and re-link. hth, Hein. ------------------------------ Date: Wed, 14 Nov 2007 06:08:12 -0800 From: Bob Gezelter Subject: Re: Alphaservers and HP integrity servers Message-ID: <1195049292.292912.100940@57g2000hsv.googlegroups.com> On Nov 14, 6:33 am, "mb...@hotmail.com" wrote: > Please could someone assist here:- > > If I write, link and complie a C or Cobol program on Alphaserver to > make an image ".exe" will the ".exe" work on the new platform? (non- > privileged type coding) un-modified or do you have to review update > and re-complie your program again thus having two programs of the same > name? > > Kind regards mb301, While the two executable files would have the same name, the binary images contained in the files are dramatically different, as they are for executables compiled for both the Alpha and VAX architectures. In environments where multiple architectures are in use, this is often solved in one of two ways: - using a file type other than .EXE (e.g., EXE_VAX, EXE_IA64, .EXE_AXP) [In general, I do NOT prefer this option] - using different directories to hold the relevant executables (e.g., [.VAX], [.ALPHA], and [.IA64] to hold the actual .EXE files, and using a concealed logical name to point to the appropriate directory, depending on the architecture of the system. In the general case, I define this name during the STARTUP processing (or LOGIN processing) that sets up the application environment. For completeness, two of my articles describe some of these techniques, and how they can be used effectively: "Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters", published in the HP OpenVMS Technical Journal, Volume 3, February 2004 (reprint available at http://www.rlgsc.com/publications/vmstechjournal/inheritance.html ) "Strategies for Migrating from Alpha and VAX systems to HP Integrity Servers on OpenVMS", published in the HP OpenVMS Technical Journal, Volume 10, June 2007 (abstract and link available at http://www.rlgsc.com/publications/vmstechjournal/migrationstrategies.html ) I hope that the above is helpful! - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: 14 Nov 2007 14:16:10 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Alphaservers and HP integrity servers Message-ID: <5q0e9aFso182U1@mid.individual.net> In article <1195049292.292912.100940@57g2000hsv.googlegroups.com>, Bob Gezelter writes: > On Nov 14, 6:33 am, "mb...@hotmail.com" wrote: >> Please could someone assist here:- >> >> If I write, link and complie a C or Cobol program on Alphaserver to >> make an image ".exe" will the ".exe" work on the new platform? (non- >> privileged type coding) un-modified or do you have to review update >> and re-complie your program again thus having two programs of the same >> name? >> >> Kind regards > > mb301, > > While the two executable files would have the same name, the binary > images contained in the files are dramatically different, as they are > for executables compiled for both the Alpha and VAX architectures. VAX??? Shouldn't that be Itanium? I was not aware of any VAX Integrity Systems. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 14 Nov 2007 09:15:58 -0500 From: "Richard B. Gilbert" Subject: Re: Alphaservers and HP integrity servers Message-ID: <473B031E.3020709@comcast.net> mb301@hotmail.com wrote: > Please could someone assist here:- > > If I write, link and complie a C or Cobol program on Alphaserver to > make an image ".exe" will the ".exe" work on the new platform? (non- > privileged type coding) un-modified or do you have to review update > and re-complie your program again thus having two programs of the same > name? > > Kind regards > I don't, and won't, have an "Integrity Server" to experiment with but AFAIK, the machines are NOT binary compatible with either Alpha or VAX and AFAIK there is NO Alpha or VAX emulation offered in either hardware or software. So yes, recompile and relink. If you didn't include any hardware dependencies in your code, that should be all you need to do. If you did include hardware dependencies you will have to find and fix them. Doing so will teach you valuable lessons about writing portable code! ------------------------------ Date: Wed, 14 Nov 2007 07:29:28 -0800 From: Bob Gezelter Subject: Re: Alphaservers and HP integrity servers Message-ID: <1195054168.263289.95220@o38g2000hse.googlegroups.com> On Nov 14, 9:16 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > In article <1195049292.292912.100...@57g2000hsv.googlegroups.com>, > Bob Gezelter writes: > > > > > On Nov 14, 6:33 am, "mb...@hotmail.com" wrote: > >> Please could someone assist here:- > > >> If I write, link and complie a C or Cobol program on Alphaserver to > >> make an image ".exe" will the ".exe" work on the new platform? (non- > >> privileged type coding) un-modified or do you have to review update > >> and re-complie your program again thus having two programs of the same > >> name? > > >> Kind regards > > > mb301, > > > While the two executable files would have the same name, the binary > > images contained in the files are dramatically different, as they are > > for executables compiled for both the Alpha and VAX architectures. > > VAX??? Shouldn't that be Itanium? I was not aware of any VAX Integrity > Systems. > > bill > > -- > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves > b...@cs.scranton.edu | and a sheep voting on what's for dinner. > University of Scranton | > Scranton, Pennsylvania | #include Bill, No, that is not a typographical error. Please read the full sentence. The full sentence reads "... the binary images contained in the files are dramatically different, as they are for executables compiled for both the Alpha and VAX architectures." This is correct, ALL image files on OpenVMS are named .EXE, even though the contents of the file are different for use on each architecture, the fact to which I was referring. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: 14 Nov 2007 15:40:59 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Alphaservers and HP integrity servers Message-ID: <5q0j8bFte9ggU1@mid.individual.net> In article <1195054168.263289.95220@o38g2000hse.googlegroups.com>, Bob Gezelter writes: > On Nov 14, 9:16 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote: >> In article <1195049292.292912.100...@57g2000hsv.googlegroups.com>, >> Bob Gezelter writes: >> >> >> >> > On Nov 14, 6:33 am, "mb...@hotmail.com" wrote: >> >> Please could someone assist here:- >> >> >> If I write, link and complie a C or Cobol program on Alphaserver to >> >> make an image ".exe" will the ".exe" work on the new platform? (non- >> >> privileged type coding) un-modified or do you have to review update >> >> and re-complie your program again thus having two programs of the same >> >> name? >> >> >> Kind regards >> >> > mb301, >> >> > While the two executable files would have the same name, the binary >> > images contained in the files are dramatically different, as they are >> > for executables compiled for both the Alpha and VAX architectures. >> >> VAX??? Shouldn't that be Itanium? I was not aware of any VAX Integrity >> Systems. >> > Bill, > > No, that is not a typographical error. Please read the full sentence. > > The full sentence reads "... the binary images contained in the files > are dramatically different, as they are for executables compiled for > both the Alpha and VAX architectures." > > This is correct, ALL image files on OpenVMS are named .EXE, even > though the contents of the file are different for use on each > architecture, the fact to which I was referring. > I realize that, but he never mentioned VAX and you never mentioned Itanium. It just seemed you were both not on the same sheet of music. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 14 Nov 2007 08:08:46 -0800 From: Bob Gezelter Subject: Re: Alphaservers and HP integrity servers Message-ID: <1195056526.941315.196850@v3g2000hsg.googlegroups.com> On Nov 14, 10:40 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > In article <1195054168.263289.95...@o38g2000hse.googlegroups.com>, > Bob Gezelter writes: > > > > > On Nov 14, 9:16 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > >> In article <1195049292.292912.100...@57g2000hsv.googlegroups.com>, > >> Bob Gezelter writes: > > >> > On Nov 14, 6:33 am, "mb...@hotmail.com" wrote: > >> >> Please could someone assist here:- > > >> >> If I write, link and complie a C or Cobol program on Alphaserver to > >> >> make an image ".exe" will the ".exe" work on the new platform? (non- > >> >> privileged type coding) un-modified or do you have to review update > >> >> and re-complie your program again thus having two programs of the same > >> >> name? > > >> >> Kind regards > > >> > mb301, > > >> > While the two executable files would have the same name, the binary > >> > images contained in the files are dramatically different, as they are > >> > for executables compiled for both the Alpha and VAX architectures. > > >> VAX??? Shouldn't that be Itanium? I was not aware of any VAX Integrity > >> Systems. > > > Bill, > > > No, that is not a typographical error. Please read the full sentence. > > > The full sentence reads "... the binary images contained in the files > > are dramatically different, as they are for executables compiled for > > both the Alpha and VAX architectures." > > > This is correct, ALL image files on OpenVMS are named .EXE, even > > though the contents of the file are different for use on each > > architecture, the fact to which I was referring. > > I realize that, but he never mentioned VAX and you never mentioned > Itanium. It just seemed you were both not on the same sheet of music. > > bill > > -- > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves > b...@cs.scranton.edu | and a sheep voting on what's for dinner. > University of Scranton | > Scranton, Pennsylvania | #include Bill, Not to pick nits, put while the TITLE of the original post includes "Integrity servers", the text of the post (which was in my vision when I was writing the response), just says "new architecture". Perhaps, in retrospect my wording could have been more precise, but it remains correct. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: 14 Nov 2007 12:22:32 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Alphaservers and HP integrity servers Message-ID: In article <473B031E.3020709@comcast.net>, "Richard B. Gilbert" writes: > > I don't, and won't, have an "Integrity Server" to experiment with but > AFAIK, the machines are NOT binary compatible with either Alpha or VAX > and AFAIK there is NO Alpha or VAX emulation offered in either hardware > or software. > There is a binary translator for Alpha -> Integrity for those who do not have the source code. There are restictions on it, such as not containing privileged mode code. Strictly speaking this isn't "emulation", but it's that kind of general thing to most end users. There is also real emulation of VAX via tools like Charon-VAX or SIMH which will at least rnu on Alpha (I see no reason why SIMH wouldn't run on Itanium, but I don't know if anyone has tried it). But if the OP has the source, rebuild from source is a much better path than any of the above. ------------------------------ Date: Wed, 14 Nov 2007 11:53:54 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: In article , "Tom Linden" writes: > > >On Tue, 13 Nov 2007 11:19:26 -0800, Jeff Goodwin > wrote: > >> >> "Tom Linden" wrote in message >> news:op.t1ptcubkhv4qyg@murphus.hsd1.ca.comcast.net... >>> On Mon, 12 Nov 2007 19:53:34 -0800, Larry Kilgallen >>> wrote: >>> >>>> In article , "Tom >>>> Linden" >>>> writes: >>>> >>>>> The LMF System Service Manual indicate two possible, optional >>>>> output codes, LMF$_PROD_TOKEN and LMF$_HW_ID. I am unable to get >>>>> either to work. I created an appropriate license pak in a >>>>> separate testing lmf database and loaded the license. But >>>>> when running the test, the status which should be 1 if the call >>>>> is successful, got 12. When I comment out the item_list for the >>>>> HW_ID it returns 1, so it clearly found the license. >>>> >>>> 12 is SS$_ACCVIO. so without looking at the book I would say you >>>> have something wrong in by-reference/by-value land. I would say >>>> you should remove a dot, but I do not believe you used Bliss. >>>> >>>>> Anyone have experience with this call? I am not convinced it >>>>> works as documented. >>>> >>>> LJK/Security licenses use both of those fields, but I don't believe >>>> you programmed it in Ada either. >>> >>> Quite right, this is the declaration >>> declare 1 license_items, >>> 2 prod_date, >>> 3 length fixed bin(15) initial (8), >>> 3 item fixed bin(15) initial (lmf$_prod_date), >>> 3 bufadr pointer initial (addr(binary_date)), >>> 3 retlen fixed bin(31) initial (0), >>> 2 prod_version, >>> 3 length fixed bin(15) initial (4), >>> 3 item fixed bin(15) initial (lmf$_prod_version), >>> 3 bufadr pointer initial (addr(compiler_version)), >>> 3 retlen fixed bin(31) initial (0), >>> 2 hw_id, >>> 3 length fixed bin(15) initial (31), >>> 3 item fixed bin(15) initial (lmf$_hw_id), >>> 3 bufadr pointer initial (addr(hardware_id)), >>> 3 retlen fixed bin(31) initial (0), >>> 2 endlist, >>> 3 length fixed bin(15) initial (0), >>> 3 item fixed bin(15) initial (0), >>> 3 bufadr pointer initial (null()), >>> 3 retlen fixed bin(31) initial (0); >> >> Tom, >> >> I suspect the retlen argument needs to be the address of where you store >> the >> return length, not the return length itself. > >Yes, that indeed was the issue. This is an example of the sort of >problems >that are encountered when interfaces aren't with strong typing. Digital >had the >opportunity to get it right using SDL, but got lazy. The merits of SDL and strong typing notwithstanding, I think this interface is well documented in the materials I have. If a service uses an item list to return data that can be of varying length, the RETLEN field in that item list for said item should be utilized. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: 14 Nov 2007 09:38:49 -0500 From: brooks@cuebid.zko.hp.nospam (Rob Brooks) Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: <4dxX1V3FOYId@cuebid.zko.hp.com> "Tom Linden" writes: > Jeff Goodwin wrote: >> I suspect the retlen argument needs to be the address of where you store >> the return length, not the return length itself. > Yes, that indeed was the issue. This is an example of the sort of > problems > that are encountered when interfaces aren't with strong typing. Digital > had the opportunity to get it right using SDL, but got lazy. If you actually stopped whining and looked at $ILEDEF in your language-specific STARLET library, you'd see that it's pretty apparent that it's the address of the returned length that's needed. This is a standard item list structure. From STARLET.REQ . . . !*** MODULE $ILEDEF *** ! + ! Define the 32-bit Item List Entry 3 structure ! - literal ILE3$S_ILE3 = 12; macro ILE3$W_LENGTH = 0,0,16,0 %; ! Length of buffer in bytes macro ILE3$W_CODE = 2,0,16,0 %; ! Item code value macro ILE3$PS_BUFADDR = 4,0,32,1 %; ! Buffer address macro ILE3$PS_RETLEN_ADDR = 8,0,32,1 %; ! Address of word for returned length literal ILE3$K_LENGTH = 12; ! Length of ILE3 literal ILE3$C_LENGTH = 12; ! Length of ILE3 -- Rob Brooks MSL -- Nashua brooks!cuebid.zko.hp.com ------------------------------ Date: Wed, 14 Nov 2007 10:07:46 -0800 From: "Tom Linden" Subject: Re: SYS$GRANT_LICENSE output codes Message-ID: On Wed, 14 Nov 2007 06:38:49 -0800, Rob Brooks = wrote: > "Tom Linden" writes: >> Jeff Goodwin wrote: > >>> I suspect the retlen argument needs to be the address of where you = >>> store >>> the return length, not the return length itself. > >> Yes, that indeed was the issue. This is an example of the sort = of >> problems >> that are encountered when interfaces aren't with strong typing. Digi= tal >> had the opportunity to get it right using SDL, but got lazy. > > If you actually stopped whining and looked at $ILEDEF in your > language-specific STARLET library, you'd see that it's pretty apparent= > that it's the address of the returned length that's needed. This is a= = > standard > item list structure. > > From STARLET.REQ . . . > > !*** MODULE $ILEDEF *** > ! + > ! Define the 32-bit Item List Entry 3 structure > ! - > literal ILE3$S_ILE3 =3D 12; > macro ILE3$W_LENGTH =3D 0,0,16,0 %; ! Length of buffer in bytes= > macro ILE3$W_CODE =3D 2,0,16,0 %; ! Item code value > macro ILE3$PS_BUFADDR =3D 4,0,32,1 %; ! Buffer address > macro ILE3$PS_RETLEN_ADDR =3D 8,0,32,1 %; ! Address of word for retur= ned = > length > literal ILE3$K_LENGTH =3D 12; ! Length of ILE3 > literal ILE3$C_LENGTH =3D 12; ! Length of ILE3 > This is what is in my starlet lib, and it is evidently wrong. dcl SYS$GRANT_LICENSE entry ( character(*), character(*), (1:4) fixed binary(31) reference optional, any reference optional) returns (fixed binary(31)); and this is what is in the 8.2 listings, and it likewise is wrong. { Backward compatible definition of service. iflanguage ada bas basic bliss blissf bliss64 dtr for fortran fortv3 lis= p = mac macro nparse pas pascal pli sdml tpu uil ENTRY SYS$GRANT_LICENSE ALIAS $GRANT_LICENSE PARAMETER ( CHARACTER DESCRIPTOR NAMED PRDNAM IN TYPENAME CHAR_STRING, CHARACTER DESCRIPTOR NAMED PRDUCER IN TYPENAME CHAR_STRING, LONGWORD UNSIGNED DIMENSION 4 NAMED CONTXT OUT DEFAULT 0 TYPENA= ME = CONTEXT, ANY NAMED ITMLST IN DEFAULT 0 TYPENAME ITEM_LIST_3 ) RETURNS LONGWORD TYPENAME COND_VALUE; VMS engineering is not above criticism for the software engineering = practices, if that is whining, I accept that criticism -- = PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 14 Nov 2007 07:59:02 -0500 From: JF Mezei Subject: TCPIP SMTP and/or BIND Resolver bug Message-ID: <55b85$473af11b$cef8887a$22912@TEKSAVVY.COM> If one's link to the internet is down, sending an email will result in a hard failure from the potmaster who will interpret the destination host as non-existant and generate a non-delivery notification. The expected behaviour would be for the SMTP symbiont to differentiate between a "host not found" and a "dns server not responding" and in the later case, would requeue the message for delivery. Not sure if the problem lies with the SMTP symbiont, the C socket calls (which I assume the symbiont uses), or the Bind resolver on the host which might return the same code fo host not found and DNS server not responding. ------------------------------ Date: Wed, 14 Nov 2007 07:50:11 -0800 From: FrankS Subject: Re: TCPIP SMTP and/or BIND Resolver bug Message-ID: <1195055411.651998.76090@o80g2000hse.googlegroups.com> On Nov 14, 7:59 am, JF Mezei wrote: > The expected behaviour would be for the SMTP symbiont to differentiate > between a "host not found" and a "dns server not responding" and in the > later case, would requeue the message for delivery. What error is the SMTP log file reporting? What version of OpenVMS and TCP/IP are installed? Do you have the latest TCP/IP patches applied? ------------------------------ End of INFO-VAX 2007.624 ************************