INFO-VAX Wed, 08 Oct 2008 Volume 2008 : Issue 544 Contents: Re: Elvis is dead - get over it! Re: How to create a shareable image on IA64 using Pascal Re: How to create a shareable image on IA64 using Pascal Re: How to create a shareable image on IA64 using Pascal Industrial Automation Services Mumbai Re: Macro compiler error on Itanium Re: Macro compiler error on Itanium media of old VMS versions New LaserJet fun (or upward compatibility? What is that?) Re: New LaserJet fun (or upward compatibility? What is that?) Re: New LaserJet fun (or upward compatibility? What is that?) Re: New LaserJet fun (or upward compatibility? What is that?) Re: New LaserJet fun (or upward compatibility? What is that?) Re: Status of DECUS Canada ? Re: VMS news reader Re: VMS news reader ---------------------------------------------------------------------- Date: 8 Oct 2008 12:46:51 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Elvis is dead - get over it! Message-ID: <6l3odrFaekigU1@mid.individual.net> In article <871eaafc-2d55-41cd-82c2-cd1f9882ba57@z6g2000pre.googlegroups.com>, PR writes: > On Oct 5, 4:53 am, "Richard Maher" > wrote: >> Hi Michael, >> >> > Then why do you bother with VMS at all? >> >> 'cos it's the best server on the planet you fucking idiot! >> >> If only the incompetent, self-serving, vms-appologists at HP would open the >> flood-gates and let the users *INTEGRATE* their VMS apps with this >> feature-rich, cheap, ubiquitous, full-function client platform(s) then maybe >> we might get somewhere? >> >> Regards Richard Maher >> >> "Michael Kraemer" wrote in message >> >> news:gc9spk$1lc$00$1@news.t-online.com... >> >> > Richard Maher schrieb: >> >> > > Personally, I love FireFox and Firebug! I love Flex (and FlexBuilder)! I >> > > love .NET (a bit less)! Silverlight is getting better! I love Java >> Applets! >> > > (and the new 1.6_10 jnlp deployment options) I love Chrome's Application >> > > Launch shortcuts! I love HTML/DOM/Javascript! I love the price of >> laptops, >> > > PCs and Macs! I have no problem with Windows! *And so do the users!* >> >> > Then why do you bother with VMS at all? > Amen brother 0 thou do preach to the choir! > I've said it before and I will say it yet again, from a dead zero > start, I've put in five VMS installations in a little less than a > year, including the time to convert the darn software, spec out RX26xx > servers, install em, and even - get this - > *get paid!* > If 100 more people would get out there and evangelize VMS, a whole > hell of a lot of GOOD things would happen. Yeah, that will be great great for youyr career. I did it here for years and I can still hear then snickering when I walk by in the hall as they whisper to each other, "There goes our resident dinosaur". I just recently had someone visiting the department on business look at my Storageworks Cabinet and comment on it's obsoleteness. > It is a GREAT server, and affordable. How is VMS more affordable than Windows? We pay something like $300-600 a year and can run any and as much MS Server software as we want. No doubt it's a great server, but technical superiority has never been a requirement in this industry. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 08 Oct 2008 06:15:58 GMT From: John Santos Subject: Re: How to create a shareable image on IA64 using Pascal Message-ID: Richard B. Gilbert wrote: > Ade wrote: > >> "Bob Gezelter" wrote in message >> news:b435d1ed-5fbb-4401-8d10-19fa66740aea@l42g2000hsc.googlegroups.com... >> On Oct 6, 6:42 am, "Ade" wrote: >> >>> Hi, >>> >>> Does anyone have a quick example of how to create a shareable image >>> using >>> Pascal on IA64 (or please correct the code below). It is intended >>> that this >>> image, when installed with /open/header/share/write, will be used >>> simply as >>> a data repository for other applications which are linked together >>> with it. >>> All the examples I have seen in the documentation refer to shared memory >>> between linked object files rather than against a shareable image. >>> Any help >>> you can give me would be greatly appreciated. >>> >>> Regards, >>> >>> Adrian Birkett >>> >>> My example: >>> >>> $ edit common.pas >>> { potential common storage module } >>> [environment ('common')] >>> module common; >>> type >>> common_r = record >>> my_int : integer; >>> my_str : varying [10] of char; >>> end; >>> end. >>> >>> $ pascal common.pas >>> $ link common/share >>> $ install add/open/head/share/write disk1:[dir]common.exe >>> $ define common disk1:[dir]common.exe >>> >>> $ edit prog1.pas >>> {simple data writer program} >>> [inherit ('disk1:[dir]common')] >>> >>> program prog1(input output); >>> var common:[common]common_r; >>> begin >>> common.my_int := 1000; >>> common.my_str := 'Hello'; >>> end. >>> >>> $ pascal/debug/nooptim prog1 >>> $ link prog1, sys$input/opt >>> disk1:[dir]common.exe/share >>> $ run prog1 !step through to end >>> >>> [in a different process] >>> >>> $ edit prog2.pas >>> {simple data reader} >>> [inherit ('disk1:[dir]common')] >>> >>> program prog2(input output); >>> var common:[common]common_r; >>> begin >>> writeln('int = ', common.my_int); >>> writeln('str = ', common.my_str); >>> end. >>> >>> $ pascal/debug/nooptim prog2 >>> $ link prog2, sys$input/opt >>> disk1:[dir]common.exe/share >>> $ run prog2 !noting that prog1 is still running in your other process >>> int = 0 >>> str = >> >> >> Adrian, >> >> [SET SOAPBOX/SAVE] >> [SET SOAPBOX/MODERATE] >> >> I read things a little TOO quickly yesterday morning (here in New York >> City). >> >> I strongly recommend AGAINST using shareable storage between processes >> for data storage. The perceived performance benefits are not >> significant in the overwhelming majority of cases. The hazards of >> improper synchronization are far more disruptive and damaging. I have >> troubleshot many truly bizarre problems caused by nothing more >> egregious than the "performance" improvement cited by using shared >> memory. >> >> On the other hand, I have used intra-node DECnet logical links to >> query a server process for information in a far safer fashion. >> Admittedly, it is not as theoretically efficient, but in the scheme of >> things, it is not measurable in most cases. This is even more true >> today than it was 25 years ago. For most purposes, the substantially >> extra effort to design, implement, and qualify shared memory code is >> simply unjustified by the overall performance impact on the system. >> >> In short, if one is designing the OpenVMS file system, it is worth the >> effort. If one is maintaining applications data, it is far, far easier >> to debug a DECnet logical link-based reference monitor (which is >> straightforward to instrument) than to debug a collection of processes >> accessing a shared region. The increase in complexity is quite often >> exponential, for negligible increases in "efficiency". This is >> particularly true on today's multicore and multithread processors. >> >> For static data, consider the use of an applications specific logical >> name table, perhaps maintained by a control process and readable by >> designated other processes. >> >> DECnet logical links are also preferable to mailboxes, as they have >> the inherent ability to synchronize BOTH sides of the connection. The >> loss of either process is automatically reported to its correspondent, >> allowing appropriate action to be taken. This is far more subtle with >> mailboxes. >> >> [SET SOAPBOX/RESTORE] >> >> - Bob Gezelter, http://www.rlgsc.com >> >> Bob, >> >> I'm going to hold my hands up now and admit that what I'm doing is not >> just an out-of-interest project. I have been asked by a customer to >> assist in porting a huge application (million lines plus of pascal) >> from the current VAX to a new Blade they have purchased. >> Unfortunately, you guessed it, the system uses common shared memory >> for data storage and re-writing this for any other method is >> completely out of the question. The common memory of just one of the >> seven shareable images in this suite contains over a quarter mb of >> non-static real-time data. >> >> For my example, I have tested it on the old VAX and it works but I am >> still at a loss as to how to get it working on the IA64. I do, >> however, have to carry on with this and find the correct solution for >> the applications in question. If not, it starts to cost some serious >> money in lost revenue. >> >> Whatever happened to the use of files and disks and such - did I miss >> that particular boat? >> >> Anyway, upward and onward, there's a few windows left in the building >> that I haven't thrown something through yet. >> >> Thanks again, >> >> Ade >> > > I hope you know that using "COMMON" storage (I'm assuming you mean > something like Fortran COMMON) is an extremely poor idea. Yes, it gives > you easy access to variables but the cost is that your code has access > to variables that it does not need and should not be able to touch. It > also means that the code is not portable unless you port the COMMON > environment. > > Code like that can be a nightmare to work with. In my younger days I > had to dekludge a fair amount of it. Imagine a dozen or more named > common blocks, each with a dozen or more variables. Imagine that each > subroutine or function uses ONE variable from each COMMON block. > > If a COMMON variable is being stepped on, you have as suspects every > line of code in the program! I've done a fair share of this too, and would also advise against it, for yet another reason... You can share RMS files (with full locking) across a cluster, but sharing writable memory across a cluster is an incredible morass! (You can do it, I think, as I've done it as a thought experiment, not in real code, but it involves masses of locks, special processes to sync the data, etc., and a lot of torn-out hair. And you lose any performance advantage originally derived from shared memory.) I've ported code (BASIC and Macro-32) that uses shared sections to Alpha and Itanium from VAX, and it was pretty much as earlier posters (Hein, I think it was) described, and not too difficult, for pretty much the same reasons as Ade: a large existing code base. It works, it's not too much harder to maintain than it ever was, but it's not easy to make it cluster-aware. If I had it to do over again, I would definitely use files instead of commons for shared data, and let RMS worry about the locking! Good luck. P.S. the method we used to create the shareable read/write images was to write them in Macro-32 (no code, just a data PSECT), and link the BASIC programs to the shareable image. I think we had to play games with PSECT_ATTR in the linker options file, and it was somewhat different from VAX and Alpha, but I64 was identical to Alpha. So we didn't have a BASIC equivalent of Ade's COMMON.PAS, just a COMMON.MAR that consisted solely of an appropriate .PSECT directive and a .END We did use a COMMON.INC file defining the common that we %include'd in all the BASIC programs that needed it. Hope this helps! -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Wed, 8 Oct 2008 18:52:53 +0800 From: "Richard Maher" Subject: Re: How to create a shareable image on IA64 using Pascal Message-ID: Hi Adrian, (Not so much for your benefit as for aothers that may be reading here) Please do not listen to the incompetent filfth that have responded here! Heaven forbid that VMS has to contend with the "Can't handle shared memory slur" on top of everything else :-( There is nothing wrong with "COMMON" areas and shared PSECTs! Tell the usual suspects to "you know what"! OOh! Global Sections are spooky; leave them to Unix! What about Cache Fusion? What about an operating system that offers functionality? Global Sections "a bridge too far"? You all make me sick! Regards Richard Maher "Ade" wrote in message news:rYlGk.35222$0D6.20078@newsfe01.ams2... > Hi, > > Does anyone have a quick example of how to create a shareable image using > Pascal on IA64 (or please correct the code below). It is intended that this > image, when installed with /open/header/share/write, will be used simply as > a data repository for other applications which are linked together with it. > All the examples I have seen in the documentation refer to shared memory > between linked object files rather than against a shareable image. Any help > you can give me would be greatly appreciated. > > Regards, > > Adrian Birkett > > > > > My example: > > $ edit common.pas > { potential common storage module } > [environment ('common')] > module common; > type > common_r = record > my_int : integer; > my_str : varying [10] of char; > end; > end. > > $ pascal common.pas > $ link common/share > $ install add/open/head/share/write disk1:[dir]common.exe > $ define common disk1:[dir]common.exe > > $ edit prog1.pas > {simple data writer program} > [inherit ('disk1:[dir]common')] > > program prog1(input output); > var common:[common]common_r; > begin > common.my_int := 1000; > common.my_str := 'Hello'; > end. > > $ pascal/debug/nooptim prog1 > $ link prog1, sys$input/opt > disk1:[dir]common.exe/share > $ run prog1 !step through to end > > [in a different process] > > $ edit prog2.pas > {simple data reader} > [inherit ('disk1:[dir]common')] > > program prog2(input output); > var common:[common]common_r; > begin > writeln('int = ', common.my_int); > writeln('str = ', common.my_str); > end. > > $ pascal/debug/nooptim prog2 > $ link prog2, sys$input/opt > disk1:[dir]common.exe/share > $ run prog2 !noting that prog1 is still running in your other process > int = 0 > str = > > ------------------------------ Date: Wed, 8 Oct 2008 09:21:32 -0700 (PDT) From: Bob Gezelter Subject: Re: How to create a shareable image on IA64 using Pascal Message-ID: <8a3dbb4d-bfc9-433b-ba9f-efa9b3ae84ec@q26g2000prq.googlegroups.com> On Oct 8, 5:52 am, "Richard Maher" wrote: > Hi Adrian, > > (Not so much for your benefit as for aothers that may be reading here) > > Please do not listen to the incompetent filfth that have responded here! > Heaven forbid that VMS has to contend with the "Can't handle shared memory > slur" on top of everything else :-( > > There is nothing wrong with "COMMON" areas and shared PSECTs! Tell the usual > suspects to "you know what"! > > OOh! Global Sections are spooky; leave them to Unix! What about Cache > Fusion? What about an operating system that offers functionality? Global > Sections "a bridge too far"? > > You all make me sick! > > Regards Richard Maher > > "Ade" wrote in message > > news:rYlGk.35222$0D6.20078@newsfe01.ams2... > > > Hi, > > > Does anyone have a quick example of how to create a shareable image using > > Pascal on IA64 (or please correct the code below). It is intended that > this > > image, when installed with /open/header/share/write, will be used simply > as > > a data repository for other applications which are linked together with > it. > > All the examples I have seen in the documentation refer to shared memory > > between linked object files rather than against a shareable image. Any > help > > you can give me would be greatly appreciated. > > > Regards, > > > Adrian Birkett > > > My example: > > > $ edit common.pas > > { potential common storage module } > > [environment ('common')] > > module common; > > type > > common_r = record > > my_int : integer; > > my_str : varying [10] of char; > > end; > > end. > > > $ pascal common.pas > > $ link common/share > > $ install add/open/head/share/write disk1:[dir]common.exe > > $ define common disk1:[dir]common.exe > > > $ edit prog1.pas > > {simple data writer program} > > [inherit ('disk1:[dir]common')] > > > program prog1(input output); > > var common:[common]common_r; > > begin > > common.my_int := 1000; > > common.my_str := 'Hello'; > > end. > > > $ pascal/debug/nooptim prog1 > > $ link prog1, sys$input/opt > > disk1:[dir]common.exe/share > > $ run prog1 !step through to end > > > [in a different process] > > > $ edit prog2.pas > > {simple data reader} > > [inherit ('disk1:[dir]common')] > > > program prog2(input output); > > var common:[common]common_r; > > begin > > writeln('int = ', common.my_int); > > writeln('str = ', common.my_str); > > end. > > > $ pascal/debug/nooptim prog2 > > $ link prog2, sys$input/opt > > disk1:[dir]common.exe/share > > $ run prog2 !noting that prog1 is still running in your other > process > > int = 0 > > str = Richard, I normally do not respond to comments of this sort, but a clarification is in order. As I can read it, none of the posts in this thread said "OpenVMS cannot do it". What was said was "In almost all cases, this is a dangerous practice". I have NEVER claimed that OpenVMS cannot handle shareable storage, merely that in my extensive, 30+ year experience, I have seen far move (actually, overwhelmingly more) incorrect implementations of shared memory management than I have seen correctly done ones. Synchronization errors (e.g., race conditions) are devilish difficult to identify and eliminate, and virtually impossible to reproduce on demand. Avoiding deadlocks and synchronization starvation in complex systems is even more difficult. Even something as simple as setting switch variable can be fraught with hazard. Many programmers who first learned to program using COBOL (and indeed, those working in COBOL) use strings to store switch values. In one of my AST talks (admittedly multithread -- AST and regular; not multiprocessor, which is worse) I reminded attendees that the MOVC3 and MOVC5 instructions were interruptable, thus could be interrupted by a number of events, including AST delivery. The "simple" act of setting changing a switch string from "YES" to "NO " could give rise to intermediate values of "YO ", "YE ", "NES", "NOS", etc.). Nobody in the audience had considered that possibility (admittedly several members of Engineering who heard about my example found it amusing). The same thing can happen with inadvertantly mis- aligned data. At one conference, someone overheard my discussion of that hazard and realized that that was the likely reason why his large scale simulation system sporadically produced invalid floating point values. These problems are exacerbated when the underlying architecture or processor is changed, and the timing relationships alter.I have even seen situations where a change in the IO configuration caused timing issues. My overall recommendation is to proceed with EXTREME care. A LINK, or a simple test case is far different than multiple processes doing a lot of work at high speed. It is all too easy to jump into shared memory as a way to avoid complexity and become mired in a quagmire. Since I have not seen Adrian's code base, I do not know if this is a highly dynamic global area, or a set of read-only parameters. Even a set of shared performance counters can become complex. If the application is something along the lines of a large scale cache (e.g., RMS global buffers, a DBMS, a very high performance system) than I would consider the option of global storage, after: - the fact of the global storage was hidden behind an API (or at least a set of macros) - a first implementation of the API was done using a resource monitor model (a separate process that implemented the data store) - the performance issue was severe enough to justify the extensive developer time and review to make sure that the implementation was valid and reliable. As noted, I had a most entertaining converesation more than a decade ago on the implementation of a stock trading message switch where the client took exception to not using shared commons (I used DECnet logical links, a client subroutine shareable library, and a central datalink and server process; in effect a non-privileged device driver/ ACP model) to implement data link management. They even wanted me to guarantee that if the performance was not adequate, I would reimplement things at no charge. I did the implementation on an Alphastation 3000, and the bottleneck was somewhere around 10K transactions/minute. I was limited by the trace code (using DECterm) and the link to the trading switch. I probably could have gone quite a bit further with a little work. The beta went into production without any problems. I had a similar experience several years earlier with an application that was supposed to support multiple terminals. It was quite a bit more cost effective to install the single user image as a shareable image than it was to spend man years to work multithreading the application. It was also far more resilient. Rule 1: Architect allowing the complex solution, but use a less complex solution if at all possible. Context switches between processes may be costly, but system crashes in the middle of the day, are far costlier. Thus, my comment that if one is in the applications business, one should "Tread with care" - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Wed, 8 Oct 2008 00:53:03 -0700 (PDT) From: paryana1@gmail.com Subject: Industrial Automation Services Mumbai Message-ID: Paryana Automation formely known as Labdhi Automation and Controls are committed to the art and science of automation. Our automation and integration solutions - whether through project implementation, best- in-class product distribution or customized development - ensure that Innovation works hand in hand with intelligence to deliver measurable business value for our clients. Parayana automation service available in mumbai, mulund, thane, bhandup and mumbai sub-urbs area. Find automation and integration solutions, product distribution, project implementation, product development services using SCADA software and plc control. Product Distribution : of a wide range of products in line with the customer's business needs. Project Implementation : of end-to-end project execution on different hardware and SCADA software solutions with integrated architecture components. Product Development : of customized products to OEM's and machine manufacturers using embedded technology for measurable business benefits. http://www.paryanaautomation.com ------------------------------ Date: Wed, 8 Oct 2008 02:28:34 -0700 (PDT) From: H Vlems Subject: Re: Macro compiler error on Itanium Message-ID: On 8 okt, 02:06, VAXman- @SendSpamHere.ORG wrote: > Has anybody here ever seen one of these errors from the Macro compiler > on Itanium? > > Code cell integrity check: > Operand literal value out of range: > COD INSTRUCTION =A0adds =A0: NEXT=3D02010770, PREV=3D01F0CA28, LOCATOR=3D= {15155:0-22}, > =A0 =A0 =A0 =A0 =A0SCOPE=3DSOME_ROUTINE, MUST_WRITE, IS_DEBUG_PROLOG, UDB= =3D?ACCVIO: > =A0 =A0 =A0 =A0 00004070?, OPCODE=3D4, INSTRUCTION_SLOT=3D2, OP1=3Dpr0, O= P2=3Dr12, OP3=3D#-8208, > =A0 =A0 =A0 =A0 OP4=3Dr12; > for operand 2 > Assertion failure: =A0Compiler internal error - please submit problem rep= ort > %GEM-F-ASSERTION, Compiler internal error - please submit problem report > %MMK-F-ERRUPD, error status %X19DB800C occurred when updating target > OBJ$:SOME_PROGRAM.OBJ > > I'm sending a report to John Reagan but curious if there's already some > know fix/workaround for this. > -- > VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0 =A0VAXman(at)TME= SIS(dot)COM > > ... pejorative statements of opinion are entitled to constitutional prote= ction > no matter how extreme, vituperous, or vigorously expressed they may be. (= NJSC) > > Copr. 2008 Brian Schenkenberger. =A0Publication of _this_ usenet article = outside > of usenet _must_ include its contents in its entirety including this copy= right > notice, disclaimer and quotations. Brian, I'm pretty sure this is going to be a dialogue between you and John :-) I just hope that the discussion takes place in c.o.v. for our education. Even though I can't afford an Itanium yet Hans ------------------------------ Date: Wed, 8 Oct 2008 09:30:18 -0400 From: "John Reagan" Subject: Re: Macro compiler error on Itanium Message-ID: <74OdnVsVEJqVK3HVnZ2dnUVZ_vadnZ2d@earthlink.com> wrote in message news:00A80C40.9F03122D@SendSpamHere.ORG... > Has anybody here ever seen one of these errors from the Macro compiler > on Itanium? > > Code cell integrity check: > Operand literal value out of range: > COD INSTRUCTION adds : NEXT=02010770, PREV=01F0CA28, > LOCATOR={15155:0-22}, > SCOPE=SOME_ROUTINE, MUST_WRITE, IS_DEBUG_PROLOG, UDB=?ACCVIO: > 00004070?, OPCODE=4, INSTRUCTION_SLOT=2, OP1=pr0, OP2=r12, > OP3=#-8208, > OP4=r12; > for operand 2 > Assertion failure: Compiler internal error - please submit problem report > %GEM-F-ASSERTION, Compiler internal error - please submit problem report > %MMK-F-ERRUPD, error status %X19DB800C occurred when updating target > OBJ$:SOME_PROGRAM.OBJ > > For those of you keeping score at home, what happened is... Brian had a cut-n-paste error like we all do. That resulted in references to large offsets from the (AP) when he meant large offsets from (SP). Macro then decided to home the argument list for whatever reason (somebody taking the address of a parameter or getting the value of AP). It then needed to decide how many arguments to home. Since it saw the bogus large offset, it wanted to allocate 8208 bytes of stack for the homed argument list. For those of you who've studied the Itanium instruction set :-), you'll know that the literal field of the "adds" instruction cannot handle such a large value. So after IMACRO asked for the instruction, the GEM backend was kind enough to kick me in the pants and remind me to RTFM. The solution is for IMACRO (and probably AMACRO as well) to check for large values and print some more meaning full error message like "EH?" or perhaps "large offset from (AP) exceeds the largest possible homed argument list". I'll pick the more useful message and fix the compiler to be more helpful in the future to track down invalid programs. John ------------------------------ Date: Wed, 8 Oct 2008 10:29:12 -0700 (PDT) From: shadoooo Subject: media of old VMS versions Message-ID: <57e48dc6-ee7a-42dd-abc8-1f2b7da2658c@d10g2000pra.googlegroups.com> Hello! I'm an enthusiast of retrocomputing, especially of big/large machines. Recently I acquired my first VAX machines, a 4000-100A and a 3100/20 (no frame buffer). The 4000 works good (except a problem with the cache, that has to be disabled) and has VMS 5.5 installed. I managed to reset the system passwd and to start to learn about. I did a backup of the disk on DAT tape and found that the licenses installed are good and working, good thing! Unfortunately I don't have an installation media for thie version of VMS. The 3100 has some problem to boot the OS. Thre disks (two RZ23) seems to work, but if I boot it, only the first row of text presenting VMS 5.3 appears, then the system seems to search something on all other SCSI devices connected, in sequence, until an HALT error appears... I tried to do a conversational boot, putting the system to "MIN" and to enable the step-by-step log, but again nothing happens. The idea is to reinstall the same OS in this machine (I have also 7.3, but it's too big for this disks and RAM amount, I think), so basically is a bootable an installation media on some kind of support, to reinstall VMS 5.3. As far as I know, this version is no more available around for an affordable "collector" price, so my question is if it is possible to receive by internet an image or something like it, in way I can use SIMH and then DD to create a DAT tape to boot the machine from. I think I should already have licence also for it, inside the disk of the 3100 (as is for the 4000). Is it a praticable idea? There's some other way to try to recover the machine? Thanks ------------------------------ Date: Wed, 8 Oct 2008 08:48:48 -0700 (PDT) From: Rich Jordan Subject: New LaserJet fun (or upward compatibility? What is that?) Message-ID: <72494b8e-d570-438f-bf56-a09d705e50a5@40g2000prx.googlegroups.com> Just a note if any of you are still spec'ing LaserJet printers for use on VMS systems. I'm not aware of any available PCL6 support info or libraries on VMS (PCL5 either for that matter, but its easy enough to roll your own with that). We've used PCL (3, then 5) as our primary 'print forms' language for 16 years. HP hasn't always made that easy as their backward compatibility has been less than stellar, and their penchant for producing badly crippled firmware in their low end printers has also not helped. Soft fonts were a particular problem over the years as certain low end printers refused to load them; these limitations were often not documented; we found out 'in use'. The newest printer we've tried to use is the P2015-N. There is one, and only one note, indicating a font limitation: 45 scalable fonts (PCL6), 35 scalable fonts (PS), 11 Scalable fonts plus 11 lineprint fonts (PCL5e). None of the scalable fonts available to PCL5e have proportional spacing. This printer has been crippled back to a fixed pitch dumb printer for anyone not running a PCL6 driver. It is NOT their bottom line stuff; its in the mid-range. And not suitable to our forms printing needs. At the same time, the HP developer website that was supposed to provide links to the various PCL5/PCL6 specs and docs has apparently been lobotomized. All my searches ended up going to dead pages or to the hp.com pages with the PCL5 docs; nothing on PCL6. If anyone knows where the PCL6 developer or spec docs are I'd appreciate a heads-up. In the meantime these printers are sidelined while we locate some real LaserJets that haven't been crippled into PC toys. ------------------------------ Date: Wed, 8 Oct 2008 09:33:33 -0700 (PDT) From: sean@obanion.us Subject: Re: New LaserJet fun (or upward compatibility? What is that?) Message-ID: <28938c35-38f6-4258-afb2-3ce828858350@a18g2000pra.googlegroups.com> On Oct 8, 8:48=A0am, Rich Jordan wrote: > Just a note if any of you are still spec'ing LaserJet printers for use > on VMS systems. =A0I'm not aware of any available PCL6 support info or > libraries on VMS (PCL5 either for that matter, but its easy enough to > roll your own with that). > > We've used PCL (3, then 5) as our primary 'print forms' language for > 16 years. =A0HP hasn't always made that easy as their backward > compatibility has been less than stellar, and their penchant for > producing badly crippled firmware in their low end printers has also > not helped. =A0Soft fonts were a particular problem over the years as > certain low end printers refused to load them; these limitations were > often not documented; we found out 'in use'. > > The newest printer we've tried to use is the P2015-N. =A0There is one, > and only one note, indicating a font limitation: =A045 scalable fonts > (PCL6), 35 scalable fonts (PS), 11 Scalable fonts plus 11 lineprint > fonts (PCL5e). > I ran into the "no PLC6 documentation" about a year ago in trying to figure out what the printer reset string was supposed to be. As far as I could figure out, if you need to use PCL6, you must use Windows and it's PCL6 driver. Sean > None of the scalable fonts available to PCL5e have proportional > spacing. =A0This printer has been crippled back to a fixed pitch dumb > printer for anyone not running a PCL6 driver. =A0It is NOT their bottom > line stuff; its in the mid-range. =A0And not suitable to our forms > printing needs. > > At the same time, the HP developer website that was supposed to > provide links to the various PCL5/PCL6 specs and docs has apparently > been lobotomized. =A0All my searches ended up going to dead pages or to > the hp.com pages with the PCL5 docs; nothing on PCL6. =A0If anyone knows > where the PCL6 developer or spec docs are I'd appreciate a heads-up. > In the meantime these printers are sidelined while we locate some real > LaserJets that haven't been crippled into PC toys. ------------------------------ Date: Wed, 8 Oct 2008 09:54:55 -0700 (PDT) From: Rich Jordan Subject: Re: New LaserJet fun (or upward compatibility? What is that?) Message-ID: <3053e90e-1391-4e93-9936-28be76223a5e@p10g2000prf.googlegroups.com> On Oct 8, 11:33=A0am, s...@obanion.us wrote: > On Oct 8, 8:48=A0am, Rich Jordan wrote: > > > Just a note if any of you are still spec'ing LaserJet printers for use > > on VMS systems. =A0I'm not aware of any available PCL6 support info or > > libraries on VMS (PCL5 either for that matter, but its easy enough to > > roll your own with that). > > > We've used PCL (3, then 5) as our primary 'print forms' language for > > 16 years. =A0HP hasn't always made that easy as their backward > > compatibility has been less than stellar, and their penchant for > > producing badly crippled firmware in their low end printers has also > > not helped. =A0Soft fonts were a particular problem over the years as > > certain low end printers refused to load them; these limitations were > > often not documented; we found out 'in use'. > > > The newest printer we've tried to use is the P2015-N. =A0There is one, > > and only one note, indicating a font limitation: =A045 scalable fonts > > (PCL6), 35 scalable fonts (PS), 11 Scalable fonts plus 11 lineprint > > fonts (PCL5e). > > I ran into the "no PLC6 documentation" about a year ago in trying to > figure out what the printer reset string was supposed to be. > > As far as I could figure out, if you need to use PCL6, you must use > Windows and it's PCL6 driver. > > Sean > > > None of the scalable fonts available to PCL5e have proportional > > spacing. =A0This printer has been crippled back to a fixed pitch dumb > > printer for anyone not running a PCL6 driver. =A0It is NOT their bottom > > line stuff; its in the mid-range. =A0And not suitable to our forms > > printing needs. > > > At the same time, the HP developer website that was supposed to > > provide links to the various PCL5/PCL6 specs and docs has apparently > > been lobotomized. =A0All my searches ended up going to dead pages or to > > the hp.com pages with the PCL5 docs; nothing on PCL6. =A0If anyone know= s > > where the PCL6 developer or spec docs are I'd appreciate a heads-up. > > In the meantime these printers are sidelined while we locate some real > > LaserJets that haven't been crippled into PC toys. There are entries in the ITRC forums from late last year that point to an HP developers website, with drilldown info to get to the PCL documentation. The site is still there, but none of the mentioned links are available, and a search from that page only pulls up hp.com pages with no info on PCL6. ------------------------------ Date: Wed, 8 Oct 2008 10:33:25 -0700 (PDT) From: Rich Jordan Subject: Re: New LaserJet fun (or upward compatibility? What is that?) Message-ID: <60caf138-90ff-42ce-bbdd-68bdc6819eb5@f40g2000pri.googlegroups.com> On Oct 8, 12:11=A0pm, Jan-Erik S=F6derholm wrote: > Rich Jordan wrote: > > Just a note if any of you are still spec'ing LaserJet printers for use > > on VMS systems. =A0I'm not aware of any available PCL6 support info or > > libraries on VMS (PCL5 either for that matter, but its easy enough to > > roll your own with that). > > > We've used PCL (3, then 5) as our primary 'print forms' language for > > 16 years. =A0HP hasn't always made that easy as their backward > > compatibility has been less than stellar, and their penchant for > > producing badly crippled firmware in their low end printers has also > > not helped. =A0Soft fonts were a particular problem over the years as > > certain low end printers refused to load them; these limitations were > > often not documented; we found out 'in use'. > > > The newest printer we've tried to use is the P2015-N. =A0There is one, > > and only one note, indicating a font limitation: =A045 scalable fonts > > (PCL6), 35 scalable fonts (PS), 11 Scalable fonts plus 11 lineprint > > fonts (PCL5e). > > > None of the scalable fonts available to PCL5e have proportional > > spacing. =A0This printer has been crippled back to a fixed pitch dumb > > printer for anyone not running a PCL6 driver. =A0It is NOT their bottom > > line stuff; its in the mid-range. =A0And not suitable to our forms > > printing needs. > > > At the same time, the HP developer website that was supposed to > > provide links to the various PCL5/PCL6 specs and docs has apparently > > been lobotomized. =A0All my searches ended up going to dead pages or to > > the hp.com pages with the PCL5 docs; nothing on PCL6. =A0If anyone know= s > > where the PCL6 developer or spec docs are I'd appreciate a heads-up. > > In the meantime these printers are sidelined while we locate some real > > LaserJets that haven't been crippled into PC toys. > > He, yes it's an sad development. > > I've been looking into some printing problems at a site lataly > where they had problems printing national swedish characters (=C5=C4=D6) > using 7-bit ASCII (some ISO-11 char table or something like that). > > I got a P2015-N for my in-office tests. Now, you're perfectly correct > that everything, the printer isself as well as the docs, have been > simplified into some dumb-PC-user version. I had severe problems > locating such simple things as the name of the "local printer" > used by the LPD... > > Anyway, in this particular case it all boiled down to the use > of a character set command "(91S" that only could be found > in some old manual for some OKI laser not sold anymore. After > checking with the customer they verified that yes, they had used > OKI printers many years ago... > > A few changes in the COBOL source (where all PCL command > are hardcoded, over 600 ESC-sequences in one singe COBOL source) > it worked fine on the P2015-N and on the printers at the site, > mainly Xerox lasers. > > Well, maybe it didn't helped you, but I do understand your > problem... :-) > > Jan-Erik. This particular site has always been all genuine LaserJets. They started with IID and 3D printers and worked up to current. We do have issues sometimes when a (different) customer gets a 'great deal' on a Canon or Brother or somesuch, or when some walk in salesman talks them into some other wonderful new printer and they call us when "your program doesn't print right", but outside of soft font loads, they've been minor. Yeah you have to tweak a program sometimes, or spend time on the phone with the new printer tech support informing them that their PCL compatibility is not so compatible. Once we even got Canon and Ricoh both to issue firmware updates to fix problems our requirements exposed. HP can't be bothered, and thats been the case for many many years. If documented PCL5 code that worked in your LJ3, LJ4, LJ5, 4si, 5si, 4000, 8000, etc printers causes a 2100 to lose its mind, well then don't DO that. Don't do what? Use the printer? Pretty much the only choice. With this P2015 toy we can't print a proportional font from VMS. That is a lack of compatibility that makes all the third party copycats look like paragons. And this printer is listed at the low end of the 'middle tier' small business printers. We have always been safe getting these before; its the 'desktop' and personal printers that were seriously crippled in the past. The disease is moving up the chain. ------------------------------ Date: Wed, 08 Oct 2008 17:39:42 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: New LaserJet fun (or upward compatibility? What is that?) Message-ID: VAXman- @SendSpamHere.ORG wrote: > Send that printer *BACK* to HP with strongly worded message that you > need support for something other than the Redmond game console! In > the mean time, I will lament the purchase of my d|i|g|i|t|a|l LNCO2 > that has been rendered useless by HP without a source of consumables > to keep it functioning. If I *DO* ever purchase another printer, it > will most certainly NOT be an HP model. Nme *one* other *current* printer mgf that doesn't do exactly as HP... ------------------------------ Date: Wed, 8 Oct 2008 01:35:38 -0700 (PDT) From: Rob Subject: Re: Status of DECUS Canada ? Message-ID: <928c6938-c7af-4392-a456-a7ceeaf7c341@v16g2000prc.googlegroups.com> On Oct 7, 11:21=A0pm, JF Mezei wrote: > Does anyone have any information on the status of the user group > formerly known as Decus Canada ? > > I have not received anything from them in quite some time. Does anyone > have AnneM's new email address since she moved back to Toronto ? > > I heard that the USA group formerly known as DECUS USA seems to have > been folded into the main Interex group and gotten yet another new name. > Has the same happened in Canada and the new group simply doesn't care > about its Decus constituency ? Connect only lists a Canadian 'Non Stop' affiliate - http://www.connect-community.org/Chapters/CanadianChapterNonStop/tabid/160/= Default.aspx ------------------------------ Date: Wed, 8 Oct 2008 07:20:16 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: VMS news reader Message-ID: In article , H Vlems writes: > I"ve looked at NEWSRDR but have problems making it run. > I get this: > $ news > NEWSRDR V4.9-2 > Copyright =A9 1993-1998, MadGoat Software. All Rights Reserved. > %NEWS-I-NOOPNPROF, could not open NEWS profile > -RMS-E-FNF, file not found I've used it for so long that I don't remember how it was set up. This seems to be a setup problem. NEWSRDR has extensive documentation, including documentation in BOOKREADER format. What more could one want? Normally one has a profile file in SYS$LOGIN, but I assume this is created if it is not there. Hhmmm.... ------------------------------ Date: Wed, 08 Oct 2008 11:23:00 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: VMS news reader Message-ID: <00A80C9F.2840F0CB@SendSpamHere.ORG> In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: >In article <48ebdfa1$0$12363$c3e8da3@news.astraweb.com>, JF Mezei > writes: > >> It is very memory hungry, and you want to give yourself some inordinate >> amount of PGFILQUOTA like 1 gig. Also, some newsgroups with very long >> names may not work under VMS when the software tries to create its own >> files. (comp.os.vms is nowhere near the limit, but some newsgroup names >> are extremely long (like the one about the hamster and ducttape) > >As long as alt.sex.fetish.dec-hardware is not too long, you should be >OK! :-) What about alt.binaries.erotica.fetish.dec-hardware.unibus.flip-chip? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM ... pejorative statements of opinion are entitled to constitutional protection no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC) Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside of usenet _must_ include its contents in its entirety including this copyright notice, disclaimer and quotations. ------------------------------ End of INFO-VAX 2008.544 ************************